L.S., Seeing how AES-192 seems to hold up well against related key attacks (at least the (theoretical) one described in http://eprint.iacr.org/2009/317) I am rather surprised no AES-192 ciphers have been defined for TLS (http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4). I feel the cipher is being treated rather stepmotherly.
I do understand that the number of slots for ciphers in the above list is somewhat limited and additions should be considered carefully. However, seeing that there are over 60 TLS_DH_* ciphers in that list and well over 60 CAMMELIAs - to be clear, I am not arguing against the latter algorithm - the argument not to include AES-192 ciphers in that list seems somewhat arbitrary. Also there still seems to be plenty of space available (slots 0x01-55,* and 0x56,0x01-0xC0,0x00) until this "definition by permutation" approach can be replaced by a cheaper "definition by slot" where the slots are chained, i.e. using identifiers for key exchanges, asymmetrical ciphers, symmetrical ciphers and block modes separately. Even though I have an interest in mathematics and number theory I do not claim to have anything more than a rudimentary understanding of the mathematics involved so please correct me where my insights are wrong. On superficial reading of http://eprint.iacr.org/2009/317 I grasp that the higher resistance of AES-192 vs. AES-256 is caused by the fact that "the key schedule of AES-192 has better diffusion". Bruce Schneier seems to confirm my suspicion: https://www.schneier.com/blog/archives/2009/07/another_new_aes.html & https://www.schneier.com/academic/paperfiles/paper-rijndael.pdf In the blog he states "The attack exploits the fact that the key schedule for 256-bit version is pretty lousy -- something we pointed out in our 2000 paper -- but doesn't extend to AES with a 128-bit key." He even goes so far as to state "And for new applications I suggest that people don't use AES-256." What is causing this better diffusion? Is it the fact that the key size of AES-192 is not, and the block size is a power of 2? I seem to remember reading somewhere about DES that the odd key size vs the block size was considered a strength. Have the same analyses been done for AES-128? How is AES-128 holding up against these attacks? (Partially answered by Bruce Schneier's remark above.) Seeing that we live in "a world of 2^50 keys" and the fact that AES-192 seems to be more robust against related key attacks than AES-256 is I would like to suggest the inclusion of a few AES-192 ciphers in TLS, lets say all equivalents of AES-256, possibly reduced by the ciphers that use hashes weaker than SHA256. Not sure if "DH" and "DH_anon" are different approaches, but those could be excluded as well, resulting in something like this list: TLS_RSA_WITH_AES_192_CBC_SHA256 TLS_DHE_DSS_WITH_AES_192_CBC_SHA256 TLS_DHE_RSA_WITH_AES_192_CBC_SHA256 TLS_RSA_WITH_AES_192_GCM_SHA384 TLS_DHE_RSA_WITH_AES_192_GCM_SHA384 TLS_DHE_DSS_WITH_AES_192_GCM_SHA384 TLS_PSK_WITH_AES_192_GCM_SHA384 TLS_DHE_PSK_WITH_AES_192_GCM_SHA384 TLS_RSA_PSK_WITH_AES_192_GCM_SHA384 TLS_PSK_WITH_AES_192_CBC_SHA384 TLS_DHE_PSK_WITH_AES_192_CBC_SHA384 TLS_RSA_PSK_WITH_AES_192_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_192_CBC_SHA384 TLS_ECDH_ECDSA_WITH_AES_192_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_192_CBC_SHA384 TLS_ECDH_RSA_WITH_AES_192_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_192_GCM_SHA384 TLS_ECDH_ECDSA_WITH_AES_192_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_192_GCM_SHA384 TLS_ECDH_RSA_WITH_AES_192_GCM_SHA384 TLS_ECDHE_PSK_WITH_AES_192_CBC_SHA384 TLS_RSA_WITH_AES_192_CCM TLS_DHE_RSA_WITH_AES_192_CCM TLS_RSA_WITH_AES_192_CCM_8 TLS_DHE_RSA_WITH_AES_192_CCM_8 TLS_PSK_WITH_AES_192_CCM TLS_DHE_PSK_WITH_AES_192_CCM TLS_PSK_WITH_AES_192_CCM_8 TLS_PSK_DHE_WITH_AES_192_CCM_8 TLS_ECDHE_ECDSA_WITH_AES_192_CCM TLS_ECDHE_ECDSA_WITH_AES_192_CCM_8 Thank you for considering this request. Regards, Leonard den Ottolander. -- mount -t life -o ro /dev/dna /genetic/research _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
