Cryptography-Digest Digest #965, Volume #12 Fri, 20 Oct 00 16:13:01 EDT
Contents:
deterministic RSA key generation (Francois Grieu)
Vigenere Cipher (was: What is desCDMF?) (phil hunt)
Re: Works the md5 hash also for large datafiles (4GB) ? (Daniel Leonard)
New Encryption Regulations Take Effect On Today (Markku J. Saarelainen)
New Encryption Regulations Take Effect On Today (Markku J. Saarelainen)
Re: Looking for small implementation of an asymmetric encryption (Mike Rosing)
Re: deterministic RSA key generation (Roger)
SNAKE key exchange ([EMAIL PROTECTED])
Re: On block encryption processing with intermediate permutations (Mok-Kong Shen)
Re: Looking for small implementation of an asymmetric encryption (John Myre)
Re: Encrypting large blocks with Rijndael (Mok-Kong Shen)
Re: Which "password" is best. (John Myre)
Re: Vigenere Cipher (was: What is desCDMF?) (John Myre)
Re: Encrypting large blocks with Rijndael (John Myre)
Re: Encrypting large blocks with Rijndael (John Myre)
Re: Encrypting large blocks with Rijndael (John Myre)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? ("Seeker")
SHA-384 and SHA-512 (Daniel Leonard)
Re: Huffman stream cipher. (Benjamin Goldberg)
Re: Looking for small implementation of an asymmetric encryption algorithm (Benjamin
Goldberg)
Re: A question about DES (Benjamin Goldberg)
Re: Works the md5 hash also for large datafiles (4GB) ? (Benjamin Goldberg)
Re: Works the md5 hash also for large datafiles (4GB) ? (Benjamin Goldberg)
----------------------------------------------------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: deterministic RSA key generation
Date: Fri, 20 Oct 2000 16:17:58 +0200
One thing strikes me: it would often be usefull to use a
deterministic, standardised method to generate an RSA key from
a seed value, like a passphrase.
Question: is there an established standard for something like
(p, q) = F(passphrase, bit-size_of_pq, public_e) ?
I can vaguely remember this was suggested for ISO/IEC X.509,
but did it get standardised ?
Usage includes:
- remember (something sufficient to generate) your RSA secret
key, rather than relying on a secring file + passphrase.
- key generation for the cautious: different persons/teams,
simply trusted not to actively collaborate against you,
implement the key generator; use their program on isolated
machines (or on the same isolated machine with no remanent
memory) with the same long passphrase, and check the
results are the same.
- academicaly verifiable RSA key generation algorithm
- easily verifiable implementation
- usable as a building block for a true-random key generator
(just use true-random for the passphrase)
There is, of course, a danger: brute-force passphrase-guessing
attacks are possible on the public key alone, which is not the
case with more traditional key generation schemes. Maybe
there could be a security parameter to the algorithm, defining
the amount of computational work necessary for the generation.
There is clearly no technical difficulty in defining such a
deterministic key generation technique. Some existing RSA
key generators internaly have a deterministic engine that
operates on a pseudo-random generator, originally seeded from
an initial true-random seed. The problem is: find one key
generator generaly accepted
Francois Grieu
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Subject: Vigenere Cipher (was: What is desCDMF?)
Date: Fri, 20 Oct 2000 02:01:11 +0100
On Thu, 19 Oct 2000 18:22:23 +0100, Richard Heathfield <[EMAIL PROTECTED]> wrote:
>1) Newbie-level study of cryptanalytic techniques. This makes even a
>monoalphabetic sub or Vigenere cipher worth doing.
There was a program on UK TV this evening about the Vigenere cipher. Aparently
it was invented c. 1600 and cracked c. 1850 by Charles Babbage.
My question is: why did it take so long to crack?
It is basically a repeating Caesar cipher using a variable length key.
So to crack it, try key lengths of 1, 2, 3, ... etc until you get
a key length where frequency analysis of the letters yields
interesting results, then proceed to use this as a basis to guess
the value for that letter in the key.
(Babbage used what's probably a quicker technique: look for
repeating sequences of letters, then the key-length is likely to
be a factor of the distance between the starts of each sequence).
My question is: why did it take so long to work out this
technique? It seems a bit obvious to me.
Perhaps someone broke the cipher previously, but kept knowledge of
it secret (useful if one's adversary thinks it is unbreakable).
--
*****[ Phil Hunt ]*****
"An unforseen issue has arisen with your computer. Don't worry your
silly little head about what has gone wrong; here's a pretty animation
of a paperclip to look at instead." -- Windows2007 error message
------------------------------
From: Daniel Leonard <[EMAIL PROTECTED]>
Subject: Re: Works the md5 hash also for large datafiles (4GB) ?
Date: Fri, 20 Oct 2000 16:20:43 GMT
On Fri, 20 Oct 2000, Runu Knips wrote:
> Daniel Leonard wrote:
> > On Fri, 20 Oct 2000, Runu Knips wrote:
> >=20
> > > That of course doesn't mean it has to be SHA512. I think after SHA512
> > > is out, there will be other hashes with that output size as well. I
> > > had never liked the fact that the largest output size of a serious
> > > hash was only 192 bits (Tiger/192), even if this would fit all
> > > practical requirements for the moment. Schneier suggests not to use
> > > ciphers with less than 112 bit keys. So the minimum size for a
> > > hash should be 224 bits, shouldn't it ?
> >=20
> > You forget HAVAL that can go to 256 bits, RIPEMD256 ad RIPEMD320, and
> > finally SNEFRU that can also do 256 bits hashes. But please define
> > "serious hash".
>=20
> The RIPE MD paper says clearly that 'RIPE MD256 doesn't offer more
> security than RIPE MD128, it is only for people which need a longer
> hash'.
As is the MD4 extension in RFC1186 (for which I never saw test vectors).
Does that mean that having only a 128 bits hash is having a less secure
hash ? Or does that mean that having a longer hash means being more secure=
=20
(I think not, anybody could do a non-secure 1024 bits hash) ?
If RIPEMD 128 is secure enough (let say, for the sake of arguments,
equally secure to Tiger), then RIPEMD 256 will than be as secure as Tiger=
=20
while having a longer hash.
> HAVAL was a weak hash function anyway, if I remember correctly.
>=20
> SNEFRU - well I don't know.
SNEFRU could be optout because it is slow, but slow is relative.
> The most serious hash functions all have relatively small outputs,
> 160 or 192 bits.
==========
Daniel L=E9onard
OGMP Informatics Division E-Mail: [EMAIL PROTECTED]
D=E9partement de Biochimie Tel : (514) 343-6111 ext 5149
Universit=E9 de Montr=E9al Fax : (514) 343-2210
Montr=E9al, Quebec Office: Pavillon Principal G-312
Canada H3C 3J7 WWW : http://megasun.bch.umontreal.ca/~leonard
------------------------------
From: Markku J. Saarelainen <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia,soc.culture.nordic,soc.culture.usa
Subject: New Encryption Regulations Take Effect On Today
Date: Fri, 20 Oct 2000 16:20:34 GMT
Read the article below ..
When I started my communication in March, 2000 one of the main
intentions was to provide security and encryption solutions for
European business against the economic espionage and intelligence
activites by the U.S. government and governmentally influenced
enterprises. And my objectives have become actual results --- good work
there in European parliaments and other governments .... you see I
followed the policy developments and specific policy issues since 1993
very actively ...
==========================
New Encryption Regulations Take Effect On Today
October 19, 2000
By Brian Krebs, Newsbytes.
WASHINGTON, D.C., U.S.A.,
Published By Newsbytes News Network
In the final step toward matching the European Union's recent
liberalization of rules governing the export of encryption products,
the Commerce Department's Bureau of Export Administration has published
a final rule allowing the export of encryption products of any strength
to 15 EU nations and eight other trading partners.
http://www.pscu.com/Newsbytes/2000/156920.html
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Markku J. Saarelainen <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia,soc.culture.nordic,soc.culture.usa
Subject: New Encryption Regulations Take Effect On Today
Date: Fri, 20 Oct 2000 16:22:58 GMT
Read the article below ..
When I started my communication in March, 1999 one of the main
intentions was to provide security and encryption solutions for
European business against the economic espionage and intelligence
activites by the U.S. government and governmentally influenced
enterprises. And my objectives have become actual results --- good work
there in European parliaments and other governments .... you see I
followed the policy developments and specific policy issues since 1993
very actively ...
==========================
New Encryption Regulations Take Effect On Today
October 19, 2000
By Brian Krebs, Newsbytes.
WASHINGTON, D.C., U.S.A.,
Published By Newsbytes News Network
In the final step toward matching the European Union's recent
liberalization of rules governing the export of encryption products,
the Commerce Department's Bureau of Export Administration has published
a final rule allowing the export of encryption products of any strength
to 15 EU nations and eight other trading partners.
http://www.pscu.com/Newsbytes/2000/156920.html
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Looking for small implementation of an asymmetric encryption
Date: Fri, 20 Oct 2000 12:16:00 -0500
John Myre wrote:
> Be careful. You can certainly use more than 49 bits for the
> key even if the block size is 49 bits. Usually, brute-force
> cracking means: try all the keys, you've got the right one
> when the decryption "works". How many *blocks* do you need
> for a "brute force" attack, supposing that the block is 49
> bits and the key is, say, 128 bits? (I.e., suppose that
> simply trying all the keys is hopeless).
Good point. But to be secure against ciphertext-plaintext attack
he has to change the key every 2^24 packets. If the number of
transmissions during the life of the device is much less than
this, there's no problem. Since re-keying is a problem, (I think)
then the number of transmissions matters.
Back to the original poster - if you can expand the packet size
to 128 bits, you can have quite a bit of security. Even if only
49 of the bits mean anything.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Roger <[EMAIL PROTECTED]>
Subject: Re: deterministic RSA key generation
Date: Fri, 20 Oct 2000 10:26:49 -0700
Francois Grieu wrote:
> One thing strikes me: it would often be usefull to use a
> deterministic, standardised method to generate an RSA key from
> a seed value, like a passphrase.
>
> Question: is there an established standard for something like
> (p, q) = F(passphrase, bit-size_of_pq, public_e) ?
I think the ANSI X9.30 does that. They had some sort of
theory that the banks couldn't be trusted to generate
their own primes. So they have Bob Silverman's algorithm
for generating the primes from a given seed.
------------------------------
From: [EMAIL PROTECTED]
Subject: SNAKE key exchange
Date: Fri, 20 Oct 2000 17:21:03 GMT
A better description of the SNAKE key exchange
algorithm is available at...
http://www.kripto.org/snake
A minimal C++ library implementing the core
SNAKE functionality will be available soon.
Regards,
PG.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Fri, 20 Oct 2000 20:23:22 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
>
> > To better illustrate my difficulty of undestanding your
> > stuff and hence (indirectly) my doubt of applicability of
> > the attack you invented, I like to formulate my point a
> > bit formally:
> >
> > Let there be a cipher that is DES-like with a block
> > consiting of two words and has four rounds, i.e. two cycles,
> > and one intermediate permutation. Let there be four blocks
> > each with input (u,u).
>
> Well, there's your problem. That's not the chosen plaintext
> that the attack uses. First I use a single block (two word)
> message, call it (u, v), and then a two-block message. As I
> wrote:
>
> | Again we use
> | the same message many times, but this time the message is
> | two blocks (four words) long. The two blocks are the same
> | as each other, and the same as our one-block plaintext for
> | which we got the 64 possible outcomes. If the one-block
> | message we used was (u, v) then the two-block message is
> | (u, v, u, v).
It is very strange. For on 15th Oct you wrote:
The content of the block does not matter. Note that (u, v)
is not a special form; it just labels the first word 'u' and
the second 'v'. There is no need to use a block of the form
(u, u), but it will not impede the attack either.
Could you explain that in connection with what you just
wrote?
> What follows explains how to find the sibling pairs.
>
> Of course in your two-cycle case finding a sibling pair using
> just the one-block plaintext is vacuously easy.
Fine. Please kindly write your equations with respect to
what I denoted in the previous post which is repeated below.
(I assume that you don't retract what you wrote about
(u,u) previously. Actually using (u,v) would take more
space in the post only, for the principle is the same.)
Input of first cycle:
(u,u) (u,u) (u,u) (u,u)
Output of first cycle:
(v,w) (v,w) (v,w) (v,w)
(Assumed) permutation of words, resulting in input of
second cycle:
(v,v) (v,w) (w,v) (w,w)
Output of second cycle:
(a,b) (c,d) (e,f) (g,h)
Thanks.
M. K. Shen
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Looking for small implementation of an asymmetric encryption
Date: Fri, 20 Oct 2000 12:19:44 -0600
Mike Rosing wrote:
<snip>
> Back to the original poster - if you can expand the packet size
> to 128 bits, you can have quite a bit of security. Even if only
> 49 of the bits mean anything.
<snip>
Yes, although 64 bits might also be perfectly adequate,
depending on his situation. I forget who mentioned
Skipjack, but it has a 64 bit block, and is very well
suited to restricted-memory environments. Of course,
the actual packet will probably have to be larger than
the encrypted block (say, for address/routing bits).
JM
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Encrypting large blocks with Rijndael
Date: Fri, 20 Oct 2000 20:46:33 +0200
John Myre wrote:
>
> David Crick wrote:
> >
> > John Myre wrote:
> <snip>
> > > Under what circumstances would one be willing to pay
> > > this speed penalty?
> >
> > Security.
> <snip>
>
> Do you mean to say that encrypting with larger blocks
> is more secure? (If not, why not go with smaller blocks?)
If I remember a previous discussion correctly, the larger
block size of Rijndael with more rounds is meant to be
used by people desiring higher security and hence opting
to use a large key. (I hope that I have not falsified the
opinion of the poster of that.) That there is a trade-off
in speed isn't surprising in my humble view.
M. K. Shen
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Which "password" is best.
Date: Fri, 20 Oct 2000 12:32:47 -0600
wtshaw wrote:
<snip>
> A pangram is
> memorable. It is so memorable that it makes a good source for a
> permutation. A 26 character permutation represents 88.38 bits. I'd say
> that I was in the same ballpark as your best bet.
<snip>
I think it would be quite difficult to discover a pangram
for any given random 26 character permutation. And if you
do it the other way (thinking up the pangram first), then
your permutation isn't really random and therefore has much
less entropy. If your system allows it, I think you'd do
better to keep the entire passphrase.
On the plus side, deliberately trying for a pangram could
be an excellent way to avoid too-simple phrases, and allowing
yourself a missing letter or two could also help.
JM
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Vigenere Cipher (was: What is desCDMF?)
Date: Fri, 20 Oct 2000 12:44:35 -0600
phil hunt wrote:
<snip>
> My question is: why did it take so long to work out this
> technique? It seems a bit obvious to me.
<snip>
Of course I don't know, but how about these:
(1) Really great ideas are often obvious - in retrospect.
(2) The amount of effort put into cryptanalysis was probably
less when there was no such thing as "telecommunication".
(The value of a science of breaking codes is a bit different
when all your secret messages are hand-carried.)
JM
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Encrypting large blocks with Rijndael
Date: Fri, 20 Oct 2000 12:55:57 -0600
Ah, I'm sorry, I shouldn't have told you to check.
It's obvious that you don't have time.
What I meant was, I believe that "40% slower" is a
correct prediction for encrypting with 256-bit blocks
as compared to 128-bit blocks. That is because each
round does work proportional to the block size.
Therefore each round of 256-bit Rijndael is twice as
slow as 128-bit Rijndael. To encrypt 256 bits, we
call 128-bit Rijndael twice (assuming one of the
standard modes) or 256-bit Rijndael once. Thus the
total amount of work done is proportional to the
number of rounds. 128-bit Rijndael has 10 rounds.
256-bit Rijndael has 14 rounds. Therefore 256-bit
Rijndael takes 1.4 times as long as 128-bit Rijndael
to encrypt the same amount of data, and is thus
40% slower.
I hope that wasn't too long for you to read.
JM
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Encrypting large blocks with Rijndael
Date: Fri, 20 Oct 2000 12:57:40 -0600
Runu Knips wrote:
>
> John Myre wrote:
<snip>
> > Do you mean to say that encrypting with larger blocks
> > is more secure? (If not, why not go with smaller blocks?)
>
> Yep.
<snip>
Fine. Under what circumstances would the increase in
security over 128-bit blocks be justified?
JM
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Encrypting large blocks with Rijndael
Date: Fri, 20 Oct 2000 13:02:11 -0600
Mok-Kong Shen wrote:
<snip>
> If I remember a previous discussion correctly, the larger
> block size of Rijndael with more rounds is meant to be
> used by people desiring higher security and hence opting
> to use a large key.
<snip>
Rijndael allows for larger blocks without requiring a
larger key. I'm asking, under what circumstances would
it be a good idea to use that option.
JM
------------------------------
From: "Seeker" <[EMAIL PROTECTED]>
Subject: Re: BIOS password, will it protect PC with PGPDisk against tampering ?
Date: Fri, 20 Oct 2000 19:14:42 GMT
> Many modern motherboards use flash, and the battery trick doesn't work.
In that case a BIOS decryptor with a boot disk could work. Either way, I
think the point is that relying on a BIOS password is far from the most
secure solution.
------------------------------
From: Daniel Leonard <[EMAIL PROTECTED]>
Subject: SHA-384 and SHA-512
Date: Fri, 20 Oct 2000 19:27:18 GMT
I have updated my SHA-384 and SHA-512. They now use a 128 bit counters
instead of a 64 one as before.
http://megasun.bch.umontreal.ca/~leonard/SHA/
BTW, why is it "128 bit" and not "128 bits" ?
==========
Daniel L=E9onard
OGMP Informatics Division E-Mail: [EMAIL PROTECTED]
D=E9partement de Biochimie Tel : (514) 343-6111 ext 5149
Universit=E9 de Montr=E9al Fax : (514) 343-2210
Montr=E9al, Quebec Office: Pavillon Principal G-312
Canada H3C 3J7 WWW : http://megasun.bch.umontreal.ca/~leonard
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Huffman stream cipher.
Date: Fri, 20 Oct 2000 19:56:14 GMT
SCOTT19U.ZIP_GUY wrote:
[snip system of 2 psuedo-random huffman trees in forward direction]
> Actually a long time ago I proposed very similare stuff
> except I prefer to passes in 2 directions through the file
> so it more closely approaches an all or nothing type to transform
> all it one can use optiomal endings to make bytes endings instead
> of what your trying to do. THe code for the above it totally availble
> at my site. To do the huffman coding in revese direction of the file
> you use the reverse file program that I supply
Although making the passes go in 2 different directions adds a little
bit of security, it eliminates the possibility of using this as a stream
cipher, and can only work on files, and requires the creation of an
intermediate file containing the results of the first pass (or else a
HUGE memory buffer). Also, if you are going to make a second, backwards
pass, actually creating a reversed version of the file is stupid and
inefficient; It is much smarter to seek to the end of the file, and
seek backwards 2 characters after each read.
Also, unless I misrecall, your "proposal" contained no analysis of the
security of the system whatsoever, no examples of any attacks, or things
which could be used as attacks.
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Looking for small implementation of an asymmetric encryption algorithm
Date: Fri, 20 Oct 2000 19:56:18 GMT
[EMAIL PROTECTED] wrote:
>
> > It isn't really true that your basic requirement is to
> > encrypt your messages. Your real requirements have to do
> > with what information needs to be kept private, what it
> > is worth, what your potential attackers can do, and so on.
> > Also, you may need secrecy, or authentication, or both.
> > There are a lot of variations.
> >
> > For instance, is the low-memory embedded system intended
> > to be left alone? Could an attacker grab one and learn
> > everything stored in it? Does it have to run without
> > help, or would someone (authorized) "log in", as it were?
> >
> > The best solution always comes from realizing your exact
> > requirements, avoiding preconceptions.
>
> Thanks for answering my post.
>
> The max size of the packet sent from the device is actually only 49
> bits. I can send infrequent 13-bit messages to the device. The device
> is left alone and an attacker could access it and its memory although
> the devices will be spread out over a large area so it would be
> difficult to vist all of them.
With such a small packet size, I would suggest NTRU with N=7, p=3, q=128
This uses exactly 49 bits per encrypted message. You can only have a
plaintext message with 7*log2(3) bits of information.
> Secrecy is my primary concern. Authentication would be nice but most
> of the bits are needed for the payload. The information is timely and
> need only be kept secret for a few days. The transmission mechanism is
> not entirely reliable and it is possible that messages will get lost
> (but if I do get the message I don't believe it will have any corrupt
> bits).
>
> Device assembly is outsourced and to avoid adding another step to
> the process I had hoped that with an asymmetric algorithm all the
> units could be programmed with the same public key (or set of public
> keys and in case a private key was compromised I could use the 13-bit
> message to have the device select another key (although the device
> would need to make sure that any 13-bit message was authentic). It
> would be difficult to get a new 1024-bit key to a device) but knowing
> that public key wouldn't allow an attacker to decrypt the messages
> coming from any of the other boxes.
Hmm, only 13 bits? How do you authenticate such a small packet? There
are so few packets that size possible, that it would be easy to brute
force any signature.
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: A question about DES
Date: Fri, 20 Oct 2000 19:56:22 GMT
Massimo wrote:
>
> I'm an italian computer science student and I'm a beginner in
> cryptography. I've the following question: what's the reason 'cause,
> in last DES step, they applied the inverse of the initial permutation
> to the 64 bit block instead of a different kind of permutation ?
>
> Thanks a lot for your replies.
>
> Massimo Ancillai.
When implementing the system in hardware, including the IP and reverse
IP makes the wiring at the beginning and end of the cipher simpler.
Excluding it would have resulted in more wires (well, longer ones
anyway), and a more confusing circuit diagram.
Although it's true that IP and rIP don't help security any, they don't
hurt, either, so since DES was originally intended to be done purely in
hardware, they chose to include it.
If you want to increase speed in software, and are willing give up
interoperability with real DES, you could omit them if you want, without
loss of security.
If you want to increase security, one thing you can do is change the key
from 8 7 bit chunks (and 8 parity bits) to 8 8 bit chunks, giving 64 bit
instead of 56 bit security. This transformation also makes it
non-interoperable with real DES, but it has the advantage of increasing
security.
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Works the md5 hash also for large datafiles (4GB) ?
Date: Fri, 20 Oct 2000 19:56:29 GMT
Joseph Ashwood wrote:
>
> > Oops... sorry. At any rate who will use a 512-bit hash anyways?
>
> It all depends on your requirements. For some things the added
> security over-shadows the added space of SHA-512.
> Joe
Also, suppose you have an encryption function whose expanded key needs
to be 512 bytes, with no particular structure. Why bother to design a
key schedule when you can use SHA512?
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Works the md5 hash also for large datafiles (4GB) ?
Date: Fri, 20 Oct 2000 19:56:36 GMT
Runu Knips wrote:
>
> Paul Schlyter wrote:
> > In article <[EMAIL PROTECTED]>,
> > John Myre <[EMAIL PROTECTED]> wrote:
> > > (Not that I'd trust an implementation to get it right without
> > > checking; and few implementations allow input other than sequences
> > > of 8-bit bytes.)
> >
> > WHAT? Most MD5 implementations I've seen so far allow input of any
> > length....
>
> Hmm my own implementation of hashfunctions all allow to specify only
> bytes, not bits. It just made no sense to me - you cannot write a
> file with a bitlength, only with a bytelength. The interfaces of
> the computer simply doesn't permit it (for example, if reading with
> stdio in C).
I can think of a reason to want to use it... Suppose we're compressing a
file, and the compressed bitlength is not a multiple of 8?
> I also don't remember that I've seen an implementation which is
> actually able to handle bits instead of bytes. And it would result in
> quite a number of problems - for example, you have to start count
> bits with the MSB for SHA-1 and RIPE MD160, but with the LSB for
> Tiger/192.
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
