[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 3DES keys
> From: Hilarie Orman <ho@cs.arizona.edu>
> I think there is some concern about the starting entropy, and it is
> worthwhile to have a careful discussion about it. My understanding is
> that Photuris will have only 64 bits of initial entropy.
Goodness, where did that 64-bit limit come from?
Your elliptic curves should provide (fixed) 155 bits, correct? Do you
have some longer ones?
The currently specified moduli should provide a maximum of 1024 bits
(and we are looking at 2048 bit primes now), and a minimum of the (sum
of the?) length of the two exponents, correct? The current test code
uses 128-bit exponents for each side. As written,
The most conservative advice received to date [Hellman95] is to make
the random exponent twice as long as the intended session-key.
...
The size of the exponent is entirely implementation dependent,
is unknown to the other party, and can be easily changed.
Could you read the (rather sparse) text that I put in security
considerations, and expand it, please?
The modular exponentiation, elliptic curve, and key generator
algorithms provide a number of bits of keying material. Use of an
algorithm which produces a fewer number of keying bits than required
for a selected transform results in less robust security than would
otherwise be expected.
> Using this
> with MD5 to generate 112 bits for 3DES (2 key) is inappropriate, I
> believe. It is inappropriate in the same way that 40-bit DES is a
> crippled DES.
>
Absolutely!
> And 3DES (2 key) has its own problems.
>
Yes, which is why I was asking whether we are stuck with 2 key, or can
agree on some method of making 3 keys work.
Maybe we need some better (longer) key hashers than MD5 and SHA?
But, that is only effective if we aren't limited to 2 keys by current
implementations. Who's doing hardware 3DES out there?
Bill.Simpson@um.cc.umich.edu
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: