Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:15:22
EKR (ekr@rtfm.com)
26 Oct 1998 17:39:21 -0800
"David R. Conrad" <drc@adni.net> writes:
> Protocol: variant of DH, 1024-bit modulus from Photuris draft, g=2
> Server: has fixed 800-bit x, X = g^x mod n is precomputed
> Client: has X built in at compile-time, harvests entropy for y
> computes Y = g^y mod n, K = SHA1(k = X^y mod n)
> send message Y|E_K(M1)
> Server: receives Y|E_K(M1), computes K = SHA1(k = Y^x mod n)
> decrypts E_K(M1), sends reply E_K(M2)
> Client: decrypts E_K(M2)
>
> Questions:
> anything?
> 1a) Am I correct that this is proof against the man in the middle?
> 1b) How often do I need to change x?
> 1c) The server has to compute Y^x mod n for an 800-bit x; is this
> excessive, and will it be a performance problem for the server?
> 2) Is 160 bits sufficient for y?
> 3) Is K = SHA1(k) a suitable way to generate the session key?
> 4) What symmetric cypher would you recommend I use?
David,
Is there some reason why you don't want to use SSL? It does
more or less what you're asking for here and has at least
had the benefit of _some_ analysis. Yeah, it's a bit more
work, but you wouldn't have to worry about reinventing the
crypto protocol.
That said, your protocol has a number of disadvantages:
1. As you indicate, X is a VERY attractive target, and
changing it frequently isn't that helpful, because all the
traffic encrypted under X is still vulnerable. You'd be
much better served to use a two stage protocol that used
X to authenticate an ephemeral DH key, as Photuris and
ISAKMP do.
2. K=SHA(k) isn't a very good way to generate a session key.
For starters, it's generally good practice to add some
public entropy into the session key generation algorithm.
This allows the same DH shared secret to be used for
multiple transactions. For instance, the X9.42 variant
used in CMS has two sources of this:
(a) random data (pubInfo)
(b) a counter
See <draft-ietf-smime-cms-00.txt> (Disclaimer: I wrote this
draft, but pretty much all the crypto is from X9.42).
3. It's a bad idea to use the same symmetric key for two separate
data streams. You should decouple the client->server and server->client
keys. (Hence the counter).
4. You don't specify how integrity protection is provided, nor
how the IV is specified. These details are kind of important.
Consider the case where the IV is specified inline and no
integrity is provided. You've got a nasty little integrity
attack on short block messages.
> Okay, I generated the server's x as follows: by repeatedly running an
> applet I designed which collects entropy in a SecureRandom object from
> mouse movements and dumps it to stdout in hex. I took five such 160-bit
> samples, hashed them all, then put the hash of all five plus 49 rolls of a
> ten-sided die (thanks, AD&D) in each of the five files.
>
> So, at this point, these five files each have 160 bits generated by mixing
> (with SHA1) mouse data with data from a spinner, 160 bits of hash based on
> the other files, so that they affect one another, and about 160 bits of
> physically random data. Then I hashed each file with SHA1 and
> concatenated the five hashes to get one 800-bit number, making one slight
> change in the process: I finagled the order in which they were
> concatenated to get a 1 bit as the high bit. This 800-bit number is the
> server's x.
Yuck. There's nothing inherently wrong with this approach, but why
do something so ad-hoc? A nice simple approach would be just to
use a PRNG to generate 800 bits and set the high bit on. Seed
the PRNG with all that crap you've mentioned above. (Actually,
a better approach to all this would be to get a FORTEZZA card or
the like and use it's RNG. (Disclaimer: I was until recently
an employee of SPYRUS, one of the FORTEZZA card manufacturers
and I still contract for them.)
Cheers,
-Ekr
-- [Eric Rescorla ekr@rtfm.com]
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:15:22