On 11/19/14, 12:34 PM, Aaron Zauner wrote:
* 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.
Hear, hear!
And: this BCP is a snapshot. It can be updated or obsoleted by other
RFCs at any time - even next year if we please. IMHO 128-bit AES is good
enough for *this* document and we will update the recommendations as
needed through the usual processes.
Peter
--
Peter Saint-Andre
https://andyet.com/
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
