> From: owner-openssl-us...@openssl.org On Behalf Of ikuzar > Sent: Tuesday, 19 April, 2011 18:57
> So, have I to generate a prime with length = 3200 bits ?, > ( the corresponding exponent will belong to 3200-bit MODP group ) > in order to generate an AES 128 session key ? ( I use 2 as generator ). If you want the DH key agreement to provide security comparable to the AES-128 encryption, you need a DH group of roughly that size. You can either generate one yourself or use an existing one. Technically you don't *have* to provide comparable security; you could use DH-512 or even DH-128 to create an AES-128 key and it would encrypt and decrypt successfully, but it wouldn't be secure, which means it's a big waste of effort. > Here http://tools.ietf.org/html/rfc3526, it is said : > "The new Advanced Encryption Standard (AES) cipher [AES], which has > more strength, needs stronger groups. For the 128-bit AES we need > about a 3200-bit group [Orman01]. ..;" > in this IETF, 6 MODP groups are exposed. 3200-bit is not among this groups... rfc3526 does have a 3072-bit group, which is "about" 3200, since these are (as I said before) very rough estimates. In fact, according to section 8, its 2048-bit group might well be sufficient for symmetric 128-bit. It's a common convention to use sizes that are powers of two, or mostly powers of two, like 1024, 2048, 2560, 3072, 4096, but any decent software should work for any size up to the supported limit. If you want to use 3200, or 3157, go right ahead. The reason to use a published group like those in rfc3526 is that you don't need to actually transmit the group parameters between peers (or from a generator to peers). This is important for IPsec, which needs to dynamically create many "associations" rapidly and cheaply. I don't know if it matters to you. > Concretly, what should I write to obtain AES 128 session key? > i Wrote something like this ( in command line ): > openssl dhparam -outform PEM -out dhParams.pem -2 3200 > Then I decode dhParams.pem into internal C struct: dh. > Then I call DH_generate_key... then DH_compute_key ... > and I finally want to store this session key at key The DH result g^x1^x2=g^x2^x1 should be indistinguishable from uniform random over the group (1..P-1); that means except for a few high-order bits (and any bits above the high-order bit, if your size is not a multiple of 8, see above) all the bits should be effectively random. You could just use them, but extending what Mike Mohr said, the usual practice when deriving symmetric keys from *any* secret input, including a DH result but also other things, is to hash it. This provides one more safety margin, and it provides an option to derive multiple keys from the same secret(s) without risking related-key attacks. (ObTopic: SSL normally uses this to derive from one master secret four different keys: encryption and MAC, for each client and server sides.) ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
