> From: [email protected] On Behalf Of [email protected] via RT > Sent: Monday, October 07, 2013 04:53
> While experimenting with CIPHER_LIST: > > "kEECDH:kEDH:kRSA:AESGCM:AES256:AES128:SHA256:SHA84:SHA1:!aNULL:! > eNULL:!EXP:!LOW:!MEDIUM!MD5"; > I assume SH84 is a typo. > Wireshark showed a few curves that were not expected for for the > cipher list configuration. See attached. > OpenSSL (at least to date) doesn't relate EC curve strength to data-cipher strength, which is the only thing considered in the cipherlist/ciphersuite 'strength' values. Client always offers all named curves (and no explicit ones). For ECDSA or static ECDH, server can't choose a cert/key to match client request; it uses what is configured if that matches the client accept list, and fails (or skips EC key-exchange) if not. For EECDH tmp_ecdh_callback could choose different curves depending on negotiated suite (as well as client curvelist if that's still available, I hope it is). The same is true for other key-exchange, it's just not visible in the protocol except for the 'export' suites (which limit RSA or DH for key-exchange but not auth). OpenSSL will happily use RSA512 for AES256-SHA384 session, or RSA4096 for single-DES. If an application wants to enforce auth or key-exchange strength, it must do that separately. > I guess I expected to see something like: > > HIGH => 256 to 192-bit security level > MEDIUM => 128 to 112-bit security level > LOW => 80-bit security level > > Or perhaps: > > HIGH => 256 to 192-bit security level > MEDIUM => 128-bit security level > LOW => 112 to 80-bit security level > > Or even: > > HIGH => 256-bit security level > MEDIUM => 192 to 128-bit security level > LOW => 112 to 80-bit security level > HIGH is DESEDE (168/112) and AES ARIA (whether 128 or 256) MEDIUM is fixed at 128: SEED ARIA RC4-nonexport (and way-old RC2) LOW is singleDES (56) and EXP is 40. Remember these evolved over time. Formally even AES256 and ARIA256 used with SHA1 are overall 80, and you need SHA256 to get 128 or SHA384 to get 192. In the real world, HMAC-then-encrypt is almost certainly safe with SHA1 and even MD5. > Translating security levels to curve sizes, HIGH would use the 571-bit > (256 sl), 521-bit (256 sl), 409-bit (192 sl) and 384-bit (192 sl) > binary curve; etc. > Nit: The named/standard 521 and 384 curves are prime not binary. > I can't cite a reference at the moment because NIST's website is > unavailable due to the US government shutdown. > I have copies of 800-57* if you want me to email <G> > Its kind of odd the 192-bit security level stuff is showing up > considering AES128 and AES256 are available, but not not AES192. You aren't required to be balanced, although it is usually preferred, to reduce confusion. A SuiteB peer, for example, might well implement P256 and P384 and nothing else, and we still want to interoperate. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
