[openssl.org #3576] Speed up AES-256 key expansion by 1.9x

[David Leon Gil via RT]

Use aesenclast to do key expansion for AES-256 rather than aeskeygenassist.

Shay Gueron gives the technique in his AES-NI whitepaper; I
discovered, after implementing my own version (and looking for places
to patch), that he and Vlad Krasnov had already implemented this
technique in NSS.

Relative speedup (key expansion microbenchmark): 1.9x

Relative speedup, AES-256-GCM seal of 16B messages (BoringSSL
tool/bssl speed): 1.17x

This can obviously be extended to other key-lengths; but since I don't
think people should be using AES-128, and no one uses AES-192, I see
little point in doing so.

License for patch: CC0.

[Salz, Rich]

AES 128 is worth supporting.
I agree that AES 192 is not.


�zt�,����-��i��0Š^��%��z�����X������^��%u������Z+

[Viktor Dukhovni]

Post by Salz, Rich
AES 128 is worth supporting.
I agree that AES 192 is not.

Isn't AES-192 part of Suite-B? Which OpenSSL supports, and it
presumably would be used in CMS, if not TLS.

[David Leon Gil]

On Mon, Oct 20, 2014 at 6:03 PM, Viktor Dukhovni

Post by Viktor Dukhovni
Isn't AES-192 part of Suite-B?

No.

No one implemented AES-192 in hardware, so it got dropped in favor of
AES-256. https://www.nsa.gov/ia/programs/suiteb_cryptography/

(And, while you marvel at the NSA serving its homepage using TLS 1.2
-- and a certain CDN -- note that "[t]he connection is encrypted using
AES_256_CBC[.]")
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org

[Viktor Dukhovni]

Post by David Leon Gil
No one implemented AES-192 in hardware, so it got dropped in favor of
AES-256. https://www.nsa.gov/ia/programs/suiteb_cryptography/

Indeed, my information was stale. So now we have a peculiar
"imbalance" in the Suite-B algorithms. The ECDH, ECDSA and Digest
for TOP SECRET all provide 192-bit security, but the bulk crypto
is AES-256.

Post by David Leon Gil
(And, while you marvel at the NSA serving its homepage using TLS 1.2
-- and a certain CDN -- note that "[t]he connection is encrypted using
AES_256_CBC[.]")

Well, that's to be expected, there are no TLS code points for AES-192.

So given that AES-192 lost the popularity contest to AES-256, perhaps
you can skip it after all.

[Andy Polyakov via RT]

Post by David Leon Gil via RT
Use aesenclast to do key expansion for AES-256 rather than aeskeygenassist.
Shay Gueron gives the technique in his AES-NI whitepaper; I
discovered, after implementing my own version (and looking for places
to patch), that he and Vlad Krasnov had already implemented this
technique in NSS.
Relative speedup (key expansion microbenchmark): 1.9x
Relative speedup, AES-256-GCM seal of 16B messages (BoringSSL
tool/bssl speed): 1.17x
This can obviously be extended to other key-lengths; but since I don't
think people should be using AES-128, and no one uses AES-192, I see
little point in doing so.

I actually have improved implementation (well, it's not actually a *lot*
better, can't be made a *lot* better because of aesenclast latency, but
it should get better on processors with lower latency) for all key
lengths. The trouble with this approach is that it's *not* faster on
processors other than contemporary i[57]-*, especially on Silvermont
it's a lot slower. One can still argue that improvement on i[57]-*
outweighs losses on others. Reasonable compromise for today can be to
detect AVX capability so that Westmere and Silvermont are exempted.
Bottom line is that specific submission is dismissed, and as there is
interest I can proceed committing my code.


______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org

[David Leon Gil via RT]

Post by Andy Polyakov via RT
I actually have improved implementation (well, it's not actually a *lot*
better, can't be made a *lot* better because of aesenclast latency, but
it should get better on processors with lower latency) for all key
lengths.

Awesome! :)

Post by Andy Polyakov via RT
Bottom line is that specific submission is dismissed, and as there is
interest I can proceed committing my code.

Thanks,

David


______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org