wk at gnupg
Feb 17, 2011, 9:24 AM
Post #5 of 9
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
> 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
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg