AES improvements on Intel CPUs

[Werner Koch]

On Thu, 17 Feb 2011 11:15, smueller at chronox.de 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.