Joe,
Hi Stephen,
The margin of safety you suggest impose a
performance hit, so it's not obvious that we ought to mandate AES-256 here,
especially for software implementations. In my experience folks will jump to
the "bigger is better" option too quickly, and the performance hit might
then cause them to reject using encryption at all, which is not the
desired outcome, right?
The "bigger is better" thing is probably cultural, you know? (Cadillac
cars are inherently more meritorious somehow than SmartCars, well, at
least if you're 6'4" and need room for a big dog and a cowboy hat, too
:-)). Of course, that "superiority" only lasts until it's time to parallel
park. :-)
maybe that's why some big, fancy cars have automatic parallel parking
options ;-).
But to get to your point on the performance "hit", when I benchmarked
AES-128 vs. AES-256 in OpenSSL with the openssl speed command, I just
didn't see a huge level of pain:
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128 cbc 110889.82k 120032.96k 123677.01k 125399.38k 125501.99k
aes-256 cbc 81992.44k 87824.68k 88246.53k 88979.11k 89647.79k
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.
And if performance IS the lynch pin criteria for excluding AES-256, I'd
note that Camellia-256 offers performance that's neck and neck with
AES-128 at least for larger block sizes:
I don't think we should focus on other algs, for now, although I understand
your point.
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.
Steve
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
