> From: owner-openssl-us...@openssl.org On Behalf Of Michael D > Sent: Friday, 08 January, 2010 08:53
> Based on the old message snippet below, two questions: > 1) Are the session keys then used by the symmetric cipher > going forward? > Or is there another step used to get those keys. Session keys are for symmetric data cipher AND data HMAC. (TLS actually calls the HMAC secret parameter "secret" although RFC 2104 and IME most other usage calls it "key".) > For example, if I am using 192 bit ECC, and using AES-128, what do > I use for the 128 bit key? > Two specified 128bit chunks of TLSPRF(master,otherstuff) where master = TLSPRF(premaster,otherstuff). See RFC 4346 8.1 and 6.3 (and 5) as modified by 4492 5.10. > If I used AES 256, would I need a larger number of bits in > the ECC curve? > You don't NEED it. TLS key derivation generates enough key material, regardless of the size of premaster. However, premaster must contain enough entropy to support the desired security; per Kerckhoff (sp?) everything else is knowable by the attacker. 128bit symmetric is plenty for many years; like Schneier's "stake" it's stronger than the rest of your system. So AES256 versus 128 should only be needed for interop and/or buzzword compliance -- which can be useful, and (here) doesn't hurt. If you really want 128bit or more security level, you do need to use for keyagreement an EC curve big enough to provide that security level. According to NIST in SP 800-57, EC of 2N bits is roughly equivalent to symmetric of N bits, so even for "full" AES128 you should be using EC>=256. But you may find other experts with different judgements. And you must also have enough "good" random-data generation involved (in ECDHE transients, or as noted static-ECDH nonces). I believe in practice this has more often been a weakness (and successful attack) than actual cryptography. But it's harder to analyze and basically impossible to prove. > > 2) The last part of the Where can I read about how SSL makes session > unique with a nonce, how is that done and or where can I read > about it? > Much of RFC 4346. > > Static aka fixed ECDH (or DH) does use the certified key as > > the > > server part of keyagreement. Client similarly if client > > auth > > i.e. cert is used, which it usually isn't; but even though > > that > > gives a fixed (EC)DH result, SSL still makes the > > sessionkeys > > unique by adding per-session/handshake nonces. > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
