Stephen Kent <[email protected]> wrote: > These numbers suggest a 35%-40% performance penalty for 256-bit vs. 128-bit > AES. > So, on a percentage basis, that's non-trivial. But, in terms or raw > performance, > it may not be an issue for many platforms. Not clear how this plays out > for smart phones. I hope someone has those numbers, and an indication of the > possible power (battery) costs for that context.
See https://jve.linuxwall.info/ressources/taf/aesmeasurements.txt for some numbers (the ARM section at the bottom). I want to clarify that I don't think people who choose AES-256 over AES-128 are wrong to do so. In the past, I've argued for listing AES-128 cipher suites ahead of AES-256 in web browsers' ClientHello messages. My arguments were based on tradeoffs primarily concerning web browsers on smartphones given the state of things in 2013. The less well that describes your application, the less relevant my arguments are. In general, I think that if your application isn't hurt by using AES-256 over AES-128, and particularly if you have a timing-attack-resistant implementation, then I think it makes sense to choose AES-256 over AES-128. It would be nice of the BCP didn't say or imply that AES-128 should be chosen over AES-256. But, I think the discussion could go around and around in circles. Perhaps the most practical thing to do is publish the BCP now, and then work on an updated BCP improves the cipher suite issues, particularly when ChaCha20-Poly1305 cipher suites can be considered, and when the impact of the publication of this version of the BCP can be measured (particularly with respect to the TLS_DHE_* cipher suites). Cheers, Brian _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
