| Author |
Message |
Anthony Towns
*nix forums Guru Wannabe
Joined: 06 Mar 2005
Posts: 274
|
 Posted: Sun Nov 27, 2005 3:50 am Post subject:
Re: dpkg-sig support wanted?
|
|
|
On Fri, Nov 25, 2005 at 11:08:32PM -0600, Peter Samuelson wrote:
| Quote: | You may laugh if you wish, but I think it's annoying to have to move to
a hash function whose hexadecimal representation takes 64 bytes, which
doesn't leave much room on an 80-column line to describe what the hash
is hashing. Maybe by the time coreutils ships a sha256sum program, the
world will have settled upon BASE64, which requires only 43 bytes.
|
Why should we wait for the rest of the world to settle on a standard?
Cheers,
aj |
|
| Back to top |
|
 |
Anthony Towns
*nix forums Guru Wannabe
Joined: 06 Mar 2005
Posts: 274
|
| Posted: Sun Nov 27, 2005 4:40 am Post subject:
Re: dpkg-sig support wanted?
|
|
|
On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote:
| Quote: | For the "exploits" we have seen so far to work, the malicious party
needs upload access to the archive and has to plant a specially
crafted package there, for which they have created an evil twin
package. (Same for attacking one of the text files listing hashes.)
Looks a bit far-fatched to me.
|
Not really. Joining Debian isn't particularly difficult, and it might
not even be out of the question to find someone who'll sponsor an upload
without rebuilding the .deb. I think it's safe to imagine that there are
developers right now who've done some shady things in the past; is it
that far fetched to imagine it's worth protecting against developers
who try to abuse their priveleges?
The way we do that has to be mostly after the fact, of course: someone
uploads a bad package, people find out it's bad, we trace it back to
whoever uploaded it, then we kick them out of the project.
But that only works if the bad package is actually discovered. If the
.deb's distributed across hundreds of mirrors and to thousands of users,
it's reasonably likely that it will be discovered; but if it's possible
to target the attack against an individual user, and leave the rest of
the Debian universe untouched, you've got a much better chance of
not getting caught. Hence: distribute an iced .deb in the archive, that
does no harm ever and thus needn't arouse any suspicion; and sneak a
fire .deb that has the exploit activated onto the mirror of your target.
"Looks a bit far-fetched" comes under the "famous last words" heading
for security analysis.
Worse, the existance of a practical md5(A+B+C)=md5(A+D+C) attack means
that it's not out of the question that there're md5(A+B)=md5(C+D)
attacks in the hands of particularly well resourced groups (which is
worse, since the version uploaded to the archive could then be entirely
innocent looking). Personally, I don't have any interest in making the
NSA's job any easier, or that of other signals intelligence groups.
| Quote: | Moving away from MD5 is certainly not a bad idea, but it's not clear
whether the alternatives are any better. Sure, everyone recommends
SHA-256 at this stage, but nobody can give a rationale.
MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or
higher) are significantly harder to break in practice,
So? If SHA256 is so much better, why is that nobody can prove it, or
at least can provide some evidence which supports that claim? "The
numbers are bigger" is the main argument at this point, which is
awfully similar to the usual snake-oil arguments (although there is a
slight difference, of course).
|
SHA256 is better than SHA1 in the same way 2048 bit RSA keys are better
than 512 bit RSA keys. MD5 is broken, and isn't extensible. SHA1 is
fragile, but not broken, and is extensible. Do you have other
suggestions?
| Quote: | and there's nothing better yet.
In terms of security, there are some better hash functions.
|
My understanding was that there aren't other hash functions that've had
remotely similar levels of cryptographic analysis to md5 and sha. IIRC,
the elliptic curve cryptography stuff was supposed to be similarly neat,
until people started analysing it seriously, at which point it broke.
Cheers,
aj |
|
| Back to top |
|
|
Peter Samuelson
*nix forums Guru Wannabe
Joined: 21 Feb 2005
Posts: 212
|
| Posted: Sun Nov 27, 2005 5:20 am Post subject:
Re: dpkg-sig support wanted?
|
|
|
[Florian Weimer]
| Quote: | It should be replaced with "-". Beyond alphanumerics, only ".",
"_", "-" are in the POSIX portable filename character set[1], and
some systems do not allow the character "+" in file names.
|
[Henning Makholm]
| Quote: | However there are already plenty of files with "+" in their names
involved in Debian (e.g. /usr/lib/libstdc++.so.6).
|
Well, if we're trying to drive a standard representation, there will be
people outside Debian who will care about POSIX filename characters.
| Quote: | Having every 64th hash-based filename start with "-" or "." would
lead to failure modes for shell scripts
|
True.
| Quote: | (Yes: substitute /+ with _-, and then move the last character of the
base64 encoding to the front. Due to zero padding it must come from
the set [AEIMQUYcgkosw048].)
|
Or: substitute /+ with _- and then add a short prefix like "s-" to
denote the hash type, in case other 256-bit hashes become popular. I
guess we didn't really have that problem with 128-bit and 160-bit
checksums, but we could've.
sha256sum () {
local f;
if [ $# = 0 ]; then
openssl dgst -sha256 -binary | base64-encode |
sed 'y|/+|_-|; s|^|s-|; s|=|\t-|'
else for f; do
echo "s-$(openssl dgst -sha256 -binary "$f" | base64-encode |
sed 'y|/+|_-|; s|=|\t|')$f"
done; fi
}
(Implementation of -c left as an exercise, etc.) |
|
| Back to top |
|
|
Marc Haber
*nix forums Guru
Joined: 20 Feb 2005
Posts: 646
|
| Posted: Sun Nov 27, 2005 9:30 am Post subject:
Re: dpkg-sig support wanted?
|
|
|
On Sat, 26 Nov 2005 14:14:38 +0100, Henning Makholm
<henning@makholm.net> wrote:
| Quote: | Scripsit Florian Weimer <fw@deneb.enyo.de
I wouldn't use real base64, though, because it would mean that you can
use its hashed output as a file name.
Good point. One might replace "/" with "_" and omit the final "=".
Having a "+" in the hash should be safe in most contexts.
|
Isn't base62, which for example exim uses to create its message-ids, a
standard? I have never seen it outside exim.
Greetins
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 |
|
| Back to top |
|
|
Steinar H. Gunderson
*nix forums Guru Wannabe
Joined: 25 Feb 2005
Posts: 133
|
| Posted: Sun Nov 27, 2005 11:50 am Post subject:
Re: dpkg-sig support wanted?
|
|
|
On Sun, Nov 27, 2005 at 02:18:00PM +1000, Anthony Towns wrote:
| Quote: | My understanding was that there aren't other hash functions that've had
remotely similar levels of cryptographic analysis to md5 and sha. IIRC,
the elliptic curve cryptography stuff was supposed to be similarly neat,
until people started analysing it seriously, at which point it broke.
|
To the best of my knowledge, elliptic curve cryptography isn't any more
broken than RSA or ElGamal is.
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Moritz Muehlenhoff
*nix forums beginner
Joined: 28 Feb 2005
Posts: 29
|
| Posted: Sun Nov 27, 2005 2:30 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
In linux.debian.devel, you wrote:
| Quote: | Worse, the existance of a practical md5(A+B+C)=3Dmd5(A+D+C) attack means
that it's not out of the question that there're md5(A+B)=3Dmd5(C+D)
attacks in the hands of particularly well resourced groups (which is
worse, since the version uploaded to the archive could then be entirely
innocent looking). Personally, I don't have any interest in making the
NSA's job any easier, or that of other signals intelligence groups.
|
While this is arguably true (the NSA claims to have developed asymmetric
cryptography ten years ahead of Diffie/Hellman), it seems that nowadays
the end of the cold war and improved corporate interest have shifted
things, so I'm personally not _too_ worried about that.
| Quote: | Moving away from MD5 is certainly not a bad idea, but it's not clear
whether the alternatives are any better. Sure, everyone recommends
SHA-256 at this stage, but nobody can give a rationale.
MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or
higher) are significantly harder to break in practice,
So? If SHA256 is so much better, why is that nobody can prove it, or
at least can provide some evidence which supports that claim? "The
numbers are bigger" is the main argument at this point, which is
awfully similar to the usual snake-oil arguments (although there is a
slight difference, of course).
SHA256 is better than SHA1 in the same way 2048 bit RSA keys are better
than 512 bit RSA keys. MD5 is broken, and isn't extensible. SHA1 is
fragile, but not broken, and is extensible. Do you have other
suggestions?
|
I'd suggest the combination of several hash systems, e.g. RIPEMD-160, a
SHA-based algorithm and possibly Tiger.
| Quote: | and there's nothing better yet.
In terms of security, there are some better hash functions. =20
My understanding was that there aren't other hash functions that've had
remotely similar levels of cryptographic analysis to md5 and sha. IIRC,
the elliptic curve cryptography stuff was supposed to be similarly neat,
until people started analysing it seriously, at which point it broke.
|
I'm not aware of any attacks beyond birthday attacks, which are still
infeasible for the recommended key sizes of >= 160 bits.
ECC has several patent problems, though.
Cheers,
Moritz
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Anthony Towns
*nix forums Guru Wannabe
Joined: 06 Mar 2005
Posts: 274
|
| Posted: Mon Nov 28, 2005 5:40 am Post subject:
Re: dpkg-sig support wanted?
|
|
|
On Sun, Nov 27, 2005 at 12:42:42PM +0100, Steinar H. Gunderson wrote:
| Quote: | On Sun, Nov 27, 2005 at 02:18:00PM +1000, Anthony Towns wrote:
My understanding was that there aren't other hash functions that've had
remotely similar levels of cryptographic analysis to md5 and sha. IIRC,
the elliptic curve cryptography stuff was supposed to be similarly neat,
until people started analysing it seriously, at which point it broke.
To the best of my knowledge, elliptic curve cryptography isn't any more
broken than RSA or ElGamal is.
|
Oh god, how embarassing. I'm confusing elliptic curves and knapsacks,
my bad. Knapsack cryptograph's "provably" secure (in that a general
solution is NP), and practically insecure (in that it's hard to find
instances that are reliably hard enough, at least without obscene key
sizes).
But hey, SHA-something, Tiger, or whatever; it's well past time to choose
one, get a /usr/bin/<...> binary we can use, and replace md5 with it.
Cheers,
aj |
|
| Back to top |
|
|
Lionel Elie Mamane
*nix forums Guru Wannabe
Joined: 11 Mar 2005
Posts: 100
|
| Posted: Mon Nov 28, 2005 7:00 am Post subject:
Re: dpkg-sig support wanted?
|
|
|
On Sun, Nov 27, 2005 at 12:42:42PM +0100, Steinar H. Gunderson wrote:
| Quote: | On Sun, Nov 27, 2005 at 02:18:00PM +1000, Anthony Towns wrote:
My understanding was that there aren't other hash functions that've
had remotely similar levels of cryptographic analysis to md5 and
sha. IIRC, the elliptic curve cryptography stuff was supposed to be
similarly neat, until people started analysing it seriously, at
which point it broke.
To the best of my knowledge, elliptic curve cryptography isn't any
more broken than RSA or ElGamal is.
|
It isn't really broken, but the recommended key sizes have grown
significantly. I mean, the factor to divide RSA/DH/ElGamal key sizes
by to get equivalent security in ECC has shrunk. At least, I've heard
so, I don't remember what keys sizes were advertised in the beginnings
of ECC.
--
Lionel
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Lionel Elie Mamane
*nix forums Guru Wannabe
Joined: 11 Mar 2005
Posts: 100
|
| Posted: Mon Nov 28, 2005 7:10 am Post subject:
Re: dpkg-sig support wanted?
|
|
|
On Mon, Nov 28, 2005 at 03:32:21PM +1000, Anthony Towns wrote:
| Quote: | Knapsack cryptograph's "provably" secure (in that a general solution
is NP),
|
You mean NP-_complete_. (Sorting is also NP, but not NP-complete. NP
is "can be done in polynomial time by a non-deterministic Turing
machine, so anything polynomial by a normal machine is also
NP. "Foo is NP-complete" is "any NP problem can be polynomially
reduced to foo", or in other words, if there is a normal machine that
does foo in polynomial time, all NP problems can be done in polynomial
time.)
--
Lionel
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Lionel Elie Mamane
*nix forums Guru Wannabe
Joined: 11 Mar 2005
Posts: 100
|
| Posted: Mon Nov 28, 2005 7:40 am Post subject:
Re: dpkg-sig support wanted?
|
|
|
On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote:
| Quote: | * Anthony Towns:
On Fri, Nov 25, 2005 at 07:59:40PM +0100, Florian Weimer wrote:
* Anthony Towns:
Moving away from MD5 is certainly not a bad idea, but it's not
clear whether the alternatives are any better. Sure, everyone
recommends SHA-256 at this stage, but nobody can give a rationale.
MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256
(or higher) are significantly harder to break in practice,
So? If SHA256 is so much better, why is that nobody can prove it,
or at least can provide some evidence which supports that claim?
|
The idea behind using SHA256 (or SHA512) is that we have more
_margin_. If we are targeting MD5's design security (2^64 against
collisions), even if SHA512 is "broken" significantly - say an attack
four times better than birthday - we still have our expected strength.
It is also the best we can get to *right* *now*, unless we escape to
humongous hash sizes (arithmetic-based designs).
| Quote: | and there's nothing better yet.
In terms of security, there are some better hash functions. But
those are academic designs, most of them based on big integer
arithmetic instead of bit fiddling. Currently, nobody seems to be
willing to pay the price that comes with them.
|
What this means is that your hashes will be as big as your asymmetric
keys, and hashing as slow as asymmetric cryptography. That's
significant.
They also seem to have deeply different security properties as far as
the user is concerned: the one I know, at least
(http://diswww.mit.edu/bloom-picayune/crypto/13190) relies (as
asymmetric crypto) on n a hard to factor product of two primes p and
q. The "security proof under assumption that factoring is hard" is
that if you generate a collision, you have factored n (roughly).
Now, what I don't get is who generates n and thus knows p and q and
thus _can_ generate collisions? Does everyone use his own n (and thus
everyone can generate collisions for the hash _he_ uses, but not for
the hash others use), do we use a trusted third party (that's a
_significantly_ different security model!) that publishes n?
(When I write n above, I obviously mean the pair (n,g), g element of
maximal order in Z/nZ.)
--
Lionel
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Anthony Towns
*nix forums Guru Wannabe
Joined: 06 Mar 2005
Posts: 274
|
| Posted: Mon Nov 28, 2005 9:20 am Post subject:
Re: dpkg-sig support wanted?
|
|
|
On Sat, Nov 26, 2005 at 11:10:27PM -0600, Peter Samuelson wrote:
| Quote: | sha256sum () {
(Implementation of -c left as an exercise, etc.)
|
Hrm, if we're writing our own thing, maybe we should do it properly:
have a single program that can do multiple hash algorithms, have the
default hash be secure, and update it in future, and so on.
gnupg comes close to being this, except for two things: it's got too
many dependencies, and it's command line arguments are overly complex. A
"gpgh" variant (like gpgv but for hashing) might work, though. It
doesn't support --check, and "gpg --print-md md5 /etc/motd" has a
different format to "md5sum /etc/motd" though.
Of course, if we're doing it "right", we probably want to have some way
of telling what hash was used, so we don't have to wonder whether a
given 160bit hash is sha1 or ripemd160 or something else that gets
cooked up in future. OpenBSD's cksum apparently does this, by having its
output be:
MD5 (filename) = hash
That strikes me as pretty inconvenient, but cksum does do most of what we
want.
OTOH, it would be far more convenient for *us* if it supported the
.changes style we use, ie:
MD5Sum:
hash size filename
Then there are the encoding questions; both the one above (do we switch
from hexadeximal to something more compact for longer hashes?) and also
the question of what happens if there's a ")" or a "\n" in the filename
-- is it worth doing some sort of http-style % encoding that apt uses
in that case?
Something like this might work well:
$ dsum -a sha1 foo; sha1sum foo
f572d396fae9206628714fb2ce00f72e94f2258f foo
f572d396fae9206628714fb2ce00f72e94f2258f foo
$ dsum -d foo
SHA1Sum:
f572d396fae9206628714fb2ce00f72e94f2258f 6 foo
$ dsum -b foo
SHA1 (foo) = f572d396fae9206628714fb2ce00f72e94f2258f
$ dsum -d foo | dsum --check; echo $?
0
$ dsum -b foo | dsum --check; echo $?
0
Though what "dsum foo" should do is a trickier question (particularly
whether it's better to be compatible with current md5sum/sha1sum
output, or if "dsumA foo > foo.sum" and "dsumB --check < foo.sum" will
work if dsumA's default cypher is sha1 and dsumB's is ripemd160).
(Note that "dsum" would probably need to become Priority:required,
and possibly Essential:yes, with the complications that entails)
Cheers,
aj |
|
| Back to top |
|
|
Peter Samuelson
*nix forums Guru Wannabe
Joined: 21 Feb 2005
Posts: 212
|
| Posted: Mon Nov 28, 2005 6:10 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
[Anthony Towns]
| Quote: | gnupg comes close to being this, except for two things: it's got too
many dependencies, and it's command line arguments are overly
complex. A "gpgh" variant (like gpgv but for hashing) might work,
though. It doesn't support --check, and "gpg --print-md md5
/etc/motd" has a different format to "md5sum /etc/motd" though.
|
I think it's important to support md5sum/sha1sum format, in cases where
md5 or sha1 are used, so people can conveniently use --check with their
existing binaries. That might be just me, though.
| Quote: | Of course, if we're doing it "right", we probably want to have some
way of telling what hash was used, so we don't have to wonder whether
a given 160bit hash is sha1 or ripemd160 or something else that gets
cooked up in future.
|
For large files, getting a cryptographic checksum is more about reading
blocks off the disk than about CPU time. So it wouldn't be completely
ridiculous to allow sha-1 to remain ambiguous with competing 160-bit
hashes, and have --check check for all of them (reading the file only
once).
I still think two-byte prefixes for non-md5-non-sha1 hashes makes some
sense, like s- for sha-256. Avoids the filename encoding issue you
mentioned later (unless we want to encode newlines).
| Quote: | OTOH, it would be far more convenient for *us* if it supported the
.changes style we use, ie:
MD5Sum:
hash size filename
|
This might be generally reasonable, but we do want our dsum tool to
work with arbitrary MD5SUMS style files. And if such files require a
hash-type header, dsum will have to produce one, at least optionally.
I really like the default behavior of our existing md5sum outputting
just a single line per file, and nothing more.
| Quote: | $ dsum -a sha1 foo; sha1sum foo
f572d396fae9206628714fb2ce00f72e94f2258f foo
f572d396fae9206628714fb2ce00f72e94f2258f foo
$ dsum -d foo
SHA1Sum:
f572d396fae9206628714fb2ce00f72e94f2258f 6 foo
$ dsum -b foo
SHA1 (foo) = f572d396fae9206628714fb2ce00f72e94f2258f
|
What's the " 6 " above? Surely not a hollerith-like string. Other
than that, I like your proposed command line quite a lot.
| Quote: | (Note that "dsum" would probably need to become Priority:required,
and possibly Essential:yes, with the complications that entails)
|
Hmmm, promoting libgcrypt11 + libgpg-error0 to Required adds 516 kB on
i386, plus a trivial amount for dsum itself. I wonder if it'd be
better to just copy / paste the algorithm code into dsum. |
|
| Back to top |
|
|
Lars Wirzenius
*nix forums Guru Wannabe
Joined: 01 Mar 2005
Posts: 168
|
| Posted: Mon Nov 28, 2005 8:40 pm Post subject:
Checksumming tool
|
|
|
ma, 2005-11-28 kello 19:07 +1000, Anthony Towns kirjoitti:
| Quote: | Hrm, if we're writing our own thing, maybe we should do it properly:
have a single program that can do multiple hash algorithms, have the
default hash be secure, and update it in future, and so on.
|
As it happens, I've been wanting a really nice checksum program for a
couple of years now. When I burn a CD or DVD with files, I put a
checksum file ("md5sum.txt" usually) at the root, so that I can easily
check that the disk is still working years later. It would be nice to
not have a zillion different, incompatible checksum tools.
The md5sum program isn't very user friendly and my main motivation has
been for more usability (feedback of how long the check will still take,
and stuff like that). I have, however, also thought about other checksum
algorithms than MD5, and about a format that is extensible enough that
it won't need to be changed every time the algorithm changes. A few
thoughts:
1. Definitely use URL encoding for filenames. It's cheap, well
known, and usually not needed (% being a nicely rare character),
and sometimes it really is important to be able to deal with
pathnames with weird characters.
2. A little bit of verbosity doesn't add very much to the file
size, and will make dealing with the files much easier.
3. Who knows what else one might want in the file later.
4. md5sum and sha1sum compatibility is pretty much required for
the new tool. It makes the transition tolerable. I don't feel
new files need to be backwards compatible by default, however.
The best I've come up with so far is a pseudo rfc822 syntax:
File: foo%20bar/hellurei.txt
Size: 12345
MD5: 012345667
SHA-256: 0a0a0a0a0a0a0a0a0a0a0a0a
Mode: 0644
Empty lines separate blocks of "headers" for different files. This
should all be very simple to use and immediately logical and familiar to
anyone who'se seen e-mail headers.
It would be cool for file(1) or GNOME's and KDE's MIME type heuristics
to easily recognize the format, so that (eventually) a GUI tool can be
written to deal with such files.
I put an old draft of the manual page for my work-in-progress tool at
http://liw.iki.fi/liw/temp/summain.txt and the bzr (a.k.a. bazaar-ng)
repository at http://liw.iki.fi/liw/bzr/ in case anyone is interested. I
don't have all that much code (this being a project I hack on whenever I
don't have anything useful to do, like reading Debian mailing lists). It
tends to get rewritten every now and then (happiness is going NIH on
your own code). It shouldn't take that much effort to write the tool, so
most of my efforts have gone into thinking about the exactly correct
command line user interface features, and about the prettiest
implementation design.
I also write it in Python, and a pure C version would probably be
preferable for Debian's purposes. The file format is more important at
this point, though, and any sensible file format should be quite simple
to support in any language.
--
The most difficult thing in programming is to be simple and
straightforward.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Henning Makholm
*nix forums Guru
Joined: 21 Feb 2005
Posts: 310
|
| Posted: Mon Nov 28, 2005 9:50 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
Scripsit Peter Samuelson <peter@p12n.org>
| Quote: | For large files, getting a cryptographic checksum is more about reading
blocks off the disk than about CPU time. So it wouldn't be completely
ridiculous to allow sha-1 to remain ambiguous with competing 160-bit
hashes, and have --check check for all of them (reading the file only
once).
|
That sounds cryptographically unsafe. It would mean that a practical
preimage attack against _any_ of the supported hashes would break the
entire system. That's not the kind of algorithm agility we need.
| Quote: | I still think two-byte prefixes for non-md5-non-sha1 hashes makes some
sense, like s- for sha-256.
|
That is much better. But let's use "s." as a prefix and do a
[/+] -> [_-] substitution on the following base64 data. The dot
in the prefix will prevent the prefix from being mistaken as part of a
slightly larger non-tagged hash value.
| Quote: | $ dsum -a sha1 foo; sha1sum foo
f572d396fae9206628714fb2ce00f72e94f2258f foo
f572d396fae9206628714fb2ce00f72e94f2258f foo
|
There appears to be to few characters of hash there, at least unless
it is a cosmically weird coincidence that it base64 encodes to all hex
digits. :-)
I would expect something like
$ dsum -a sha1 COPYING; sha1sum COPYING
s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI COPYING
s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI COPYING
$ dsum -a sha1 -a md5 COPYING
s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI COPYING
4325afd396febcb659c36b49533135d4 COPYING
$ echo moooooooo | sha1sum -
s.-tUTs04N4IxBOtWpdoIXt1b0qgHIgNm9IC_OgYjm-mU -
--
Henning Makholm "But I am a Sunni Muslim," the bemused Arab said.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Adam Heath
*nix forums Guru Wannabe
Joined: 22 Feb 2005
Posts: 100
|
| Posted: Tue Nov 29, 2005 12:30 am Post subject:
Re: Checksumming tool
|
|
|
On Mon, 28 Nov 2005, Lars Wirzenius wrote:
| Quote: | File: foo%20bar/hellurei.txt
Size: 12345
MD5: 012345667
SHA-256: 0a0a0a0a0a0a0a0a0a0a0a0a
Mode: 0644
|
Checksum:
md5: 0123456789[B
sha-256: 0a0a0a0a0a0a0a0a0a0a0a0a
Having the names of the checksums be the header names could lead to clashes.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
Linux
»
Distributions
»
Debian
»
devel
