3 ms·
The key schedule weakness in AES256 that I know of only applies to related-keys, which don't affect TLS as far as I know. If there's anything else I'm missing,
by xnyhps 13y ago
The key schedule weakness in AES256 that I know of only applies to related-keys, which don't affect TLS as far as I know. If there's anything else I'm missing, I would like to know.
I don't have a specific concern with AES128 (compared to the concern I have about the usage of (EXP-)DES and RC4). It merely surprised me that some clients prefer AES128 over AES256 and I think it's important for server operators to know that there are clients that will stop working when disabling all <256 bit ciphers.
Personally I don't find speed a concern when using IM, it's not full-disk encryption or a large download where speed is noticable.
- JshWright 13y agoI'll admit that my concerns are mostly theoretical (and you're absolutely right that _only_ offering AES-128 is a bad idea). The related key attacks don't apply in TLS (but still if the majority of the known attacks only apply to the higher key sizes, that sets my tin-foil a'tingling), and as far as speed goes, the bulk encryption cipher is never going to be the bottleneck, no matter the key size. It's also a matter of the right tool for the job. Why get out the 2# sledge hammer when the claw hammer will pound that nail in just fine? They'll both get the job done, and to a lay person, they might both look like the 'right' tool. The claw hammer is obviously the more 'elegant' tool though.
- ivanr 13y agoAll Java installations support only up to 128-bit AES by default. Oracle calls that "strong encryption". You can upgrade to "unlimited strength" by changing some policy files, after which 256-bit AES will be possible. I don't know if that's what you're seeing, but there's definitely a class of clients that do not support 256-bit AES.