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

[Salz, Rich]

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

[Viktor Dukhovni]

On Mon, Oct 20, 2014 at 04:40:09PM -0400, Salz, Rich wrote:

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

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

[David Leon Gil]

On Mon, Oct 20, 2014 at 6:03 PM, Viktor Dukhovni
<openss...@dukhovni.org> wrote:
> 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[.]")

[Viktor Dukhovni]

On Mon, Oct 20, 2014 at 08:20:00PM -0400, David Leon Gil wrote:

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

> (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.

--
Viktor.

[Andy Polyakov 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.

[David Leon Gil via RT]

On Wed, Oct 22, 2014 at 1:19 PM, Andy Polyakov via RT <r...@openssl.org> wrote:
> 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! :)

> Bottom line is that specific submission is dismissed, and as there is
> interest I can proceed committing my code.

Thanks,

David