Mailing List Archive: GnuPG: gcrypt

AES improvements on Intel CPUs

Index | Next | Previous | View Threaded

wk at gnupg

Feb 16, 2011, 9:51 AM

Post #1 of 9 (1466 views)
Permalink

AES improvements on Intel CPUs

Hi!

The last days a played a bit with a loaned box from Intel (Core i5) and
implemented asm code to use the AES-NI instructions. It is quite an
improvement over the pure C code:

First without AES-NI (AES-128, AES-192 and AES-256):
$ ./benchmark --cipher-repetitions 100 --alignment 16 \
--disable-hwf intel-aesni cipher aes aes192 aes256
ECB/Stream CBC CFB OFB CTR
-------------- --------------- --------------- --------------- ---------------
1360ms 1350ms 1170ms 1180ms 1120ms 1120ms 1550ms 1570ms 1730ms 1740ms
1560ms 1570ms 1370ms 1400ms 1320ms 1320ms 1750ms 1770ms 1930ms 1930ms
1770ms 1770ms 1560ms 1600ms 1520ms 1520ms 1950ms 1970ms 2140ms 2130ms

Now with AES-NI (AES-128, AES-192 and AES-256):
$ ./benchmark --cipher-repetitions 100 --alignment 16 \
cipher aes aes192 aes256
ECB/Stream CBC CFB OFB CTR
--------------- --------------- --------------- --------------- ---------------
80ms 90ms 250ms 220ms 140ms 70ms 300ms 290ms 440ms 430ms
110ms 110ms 260ms 250ms 160ms 80ms 320ms 320ms 450ms 450ms
130ms 130ms 290ms 260ms 200ms 100ms 340ms 340ms 470ms 470ms

Of course, most other crypto libs use these instructions also. CFB mode
has been optimized because that is what OpenPGP requires. CBC and CTR
will follow as time permits. 64 bit is not yet supported. There is a
lot of room for more improvements of course.

We are using inline asm and this may result in problems with some gcc
versions. Please report such problems. There is a configure option to
disable the use of AES-NI.

Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

tom at ritter

Feb 16, 2011, 11:34 AM

Post #2 of 9 (1429 views)
Permalink

Re: AES improvements on Intel CPUs [In reply to]

Very cool. Is the benchmark code you're using public? It looks pretty
powerful, and I'd love a suite to play with...

bradh at frogmouth

Feb 16, 2011, 12:37 PM

Post #3 of 9 (1430 views)
Permalink

Re: AES improvements on Intel CPUs [In reply to]

On Thursday, February 17, 2011 06:34:42 am Tom Ritter wrote:
> Very cool. Is the benchmark code you're using public? It looks pretty
> powerful, and I'd love a suite to play with...
Its in the gcrypt source tree.

Brad

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

smueller at chronox

Feb 17, 2011, 2:15 AM

Post #4 of 9 (1423 views)
Permalink

Re: AES improvements on Intel CPUs [In reply to]

Am Mittwoch, 16. Februar 2011, um 18:51:47 schrieb Werner Koch:

Hi Werner,

> Hi!
>
> The last days a played a bit with a loaned box from Intel (Core i5) and
> implemented asm code to use the AES-NI instructions. It is quite an
> improvement over the pure C code:
>

Impressive numbers!

What are your plans on using the AES-NI instruction when you merge your code?
Do you want the caller to select the used code (i.e. have a cipher
implementation of, say, AES-NI that the caller must explicitly use) or do you
plan to allow libgcrypt to select the use of the AES-NI optimized version "on
the fly" without allowing the caller to even detect that.

I guess you know where I am coming from: it would be great when it is possible
for the caller/administrator (at least in FIPS mode) to allow or disallow that
AES-NI cipher use.

Thanks
Stephan

--
| Cui bono? |

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

wk at gnupg

Feb 17, 2011, 9:24 AM

Post #5 of 9 (1434 views)
Permalink

Re: AES improvements on Intel CPUs [In reply to]

On Thu, 17 Feb 2011 11:15, smueller [at] chronox said:

> What are your plans on using the AES-NI instruction when you merge your code?

Already merged, it will go into 1.5.0.

> implementation of, say, AES-NI that the caller must explicitly use) or do you
> plan to allow libgcrypt to select the use of the AES-NI optimized version "on
> the fly" without allowing the caller to even detect that.

Libgcrypt does hardware detection at initialization time. We use that
for quite some time for the Padlock engine of VIA CPUs. With my last
commit it does now really work on all Intel CPUs.

There is even a way to disable the use of AES-NI:

@item GCRYCTL_DISABLE_HWF; Arguments: const char *name

Libgcrypt detects certain features of the CPU at startup time. For
performace tests it is sometimes required not to use such a feature.
This option may be used to disabale a certain feature; i.e. Libgcrypt
behaves as if this feature has not been detected. Note that the
detection code might be run if the feature has been disabled. This
command must be used at initialization time; i.e. before calling
@code{gcry_check_version}.

> I guess you know where I am coming from: it would be great when it is possible
> for the caller/administrator (at least in FIPS mode) to allow or disallow that
> AES-NI cipher use.

If you run in FIPS mode, no hardware features will be detected. Of
course that can easily be changed. Details need to be discussed;
e.g. whether it is allowed to run the detection code in fips mode or
whether it is sufficient to mask out the features which are not to be
validated.

Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

smueller at chronox

Feb 17, 2011, 10:20 PM

Post #6 of 9 (1417 views)
Permalink

Re: AES improvements on Intel CPUs [In reply to]

Am Donnerstag, 17. Februar 2011, um 18:24:27 schrieb Werner Koch:

Hi Werner,

>
> There is even a way to disable the use of AES-NI:
>
> @item GCRYCTL_DISABLE_HWF; Arguments: const char *name

Thank you very much for pointing that out.
>
> > I guess you know where I am coming from: it would be great when it is
> > possible for the caller/administrator (at least in FIPS mode) to allow
> > or disallow that AES-NI cipher use.
>
> If you run in FIPS mode, no hardware features will be detected. Of
> course that can easily be changed. Details need to be discussed;
> e.g. whether it is allowed to run the detection code in fips mode or
> whether it is sufficient to mask out the features which are not to be
> validated.

That sounds great.

As we all do not know what the next FIPS validation will cover, all that would
be interesting is an easy way (even with a small code change) to define with
cipher implementations will be available in FIPS mode and which not. And that
seems the case for AES-NI. I would guess that is also the case for padlock.

For example, is it possible to easily flip the FIPS switch for either padlock
or AES-NI in cipher.c:cipher_table?

Thanks
Stephan

--
| Cui bono? |

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

wk at gnupg

Feb 18, 2011, 12:04 AM

Post #7 of 9 (1421 views)
Permalink

Re: AES improvements on Intel CPUs [In reply to]

On Fri, 18 Feb 2011 07:20, smueller [at] chronox said:

> For example, is it possible to easily flip the FIPS switch for either padlock
> or AES-NI in cipher.c:cipher_table?

No, you would change

void
_gcry_detect_hw_features (unsigned int disabled_features)
{
hw_features = 0;

if (fips_mode ())
return; /* Hardware support is not to be evaluated. */

#if defined (__i386__) && SIZEOF_UNSIGNED_LONG == 4
#ifdef __GNUC__
detect_ia32_gnuc ();
#endif
#elif defined (__i386__) && SIZEOF_UNSIGNED_LONG == 8
#ifdef __GNUC__
#endif
#endif

hw_features &= ~disabled_features;
}

to something like

void
_gcry_detect_hw_features (unsigned int disabled_features)
{
hw_features = 0;

#if defined (__i386__) && SIZEOF_UNSIGNED_LONG == 4
#ifdef __GNUC__
detect_ia32_gnuc ();
#endif
#elif defined (__i386__) && SIZEOF_UNSIGNED_LONG == 8
#ifdef __GNUC__
#endif
#endif

if (fips_mode ())
hw_features &= MASK_OF_FIPS_ALLOWED_FEATURES;

hw_features &= ~disabled_features;
}

and those features are disabled.

Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

n3npq at mac

Feb 18, 2011, 5:54 AM

Post #8 of 9 (1437 views)
Permalink

Re: AES improvements on Intel CPUs [In reply to]

On Feb 18, 2011, at 3:04 AM, Werner Koch wrote:

> On Fri, 18 Feb 2011 07:20, smueller [at] chronox said:
>
>> For example, is it possible to easily flip the FIPS switch for either padlock
>> or AES-NI in cipher.c:cipher_table?
>
> No, you would change
>

...

> and those features are disabled.
>

Have you looked at the ELF functionality hinted at
"Automatic use of optimized function" here:

http://udrepper.livejournal.com/

73 de Jeff

Attachments:

smime.p7s (4.54 KB)

wk at gnupg

Feb 18, 2011, 10:23 AM

Post #9 of 9 (1423 views)
Permalink

Re: AES improvements on Intel CPUs [In reply to]

On Fri, 18 Feb 2011 14:54, n3npq [at] mac said:

> Have you looked at the ELF functionality hinted at

The problem with such an approach is that it is not portable. There is
more than just ELF in our world.

Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads