* Stephen Kent <[email protected]> [141119 20:20]: > 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.
I'm far from an expert on GCM, but as far as I know from feedback from Google engineers there are problems with GCM on mobile devices, which is why they (and others) are pushing to standardize ChaCha/Poly1305 in TLS. If a more qualified person can comment and clarify on that matter I think that'd be useful for the discussion. > I didn't say "we can't handle" 256-bit AES. I suggested that it's not clear > that we need to mandate its use, or even make it the 1ts choice in a > negotiation, > and that it might impose a performance burden that would be > counterproductive, > relative to the goals of this WG. I agree. As to the whole "quantum threat" point made earlier: This has been blown out of proportion by the media. We're far away from a usable quantum computing architecture and even more so for one that might pose a threat to cryptographic primitives. Then again Post Quantum algorithms are the best direction we should be looking into not building upon existing algorithms. AES128 should suffice for the timeframe of this WG and the current documents that we should - really - get out of the door soon. Just my 3 Cents, Aaron
signature.asc
Description: Digital signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
