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. :-)

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

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:

camellia-128 cbc 87456.49k   132199.41k   149190.74k   154601.47k   154501.12k
camellia-256 cbc 75502.15k   102390.12k   113707.92k   116351.32k   117317.06k

I'd also note that for a long time people did RC4 because of its superior 
performance, e.g., on the same system:

rc4             318199.20k   323420.07k   334649.17k   342183.94k   344094.14k

Now, obviously, however, RC4 has been widely deprecated, and for good 
reason. So why mention it?

>From my POV there was and is a BIG difference between RC4 and ANY version 
of AES or ANY version of Camellia. And yet, folks successfully moved away 
fromv RC4 with no apparent performance-driven abandonement of TLS as a 
result!

Bottom line, I'm just not seeing the "we can't handle AES-256 because of 
its inferior performance relative to AES-128" argument, at least not based 
on the comparative metrics shown above (stipulated: that's for one crypto 
library (openssl), on one particular operating system, on one particular
piece of hardware). 

If there are dramatic issues on other configurations where it would be a 
"dealbreaker," I'd love sample metrics to be able to better understand 
that performance concern.

Thanks,

Joe

Joe St Sauver ([email protected] or [email protected])
Farsight Security

_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta

Reply via email to