Hello All,
I would first like to thank you for your effort and time developing gnupgp.
I have a couple of questions:
Does GnuGP (in particular, the Windows binaries distributed for gpg4win) use AES-NI, the Intel dedicated AES instruction set? There are some concerns, I’m not sure how realistic, about backdoors built into the CPU themselves. Is there any switch to turn hardware acceleration on or off?
When using symmetric encryption and providing a passphrase, I understand the actual encryption key is generated on the spot, used to do the encryption, and then discarded from memory and not stored anywhere, is that correct?
Is there a guarantee that the key derivation (passphrase to key) algorithm does not change between versions of GnuPG, so that a file encrypted with a passphrase and a previous GnuPG version can be decrypted with the same passphrase and a newer GnuPG version (i.e., the same key is generated from the passphrase)?
On Windows there is no “man” command. gpg4win --version instructs to read the man page for the full reference. Is there a way to display the man page in Windows? There is one available on the gnupgp site itself, but that warns that it might be slightly outdated and I’m looking for definitive, up to date information for the version that I am running.
I notice the GnuPG version used in gpg4win is one behind the stable for GnuPG (2.0.26 vs 2.0.27). Where can I find the differences between the two versions?
The page at https://www.gnupg.org/download/release_notes.html
looks outdated as it lists 2.0.26 as the latest stable, whereas the download page for GnuPG https://www.gnupg.org/download/index.html
states 2.0.27 as stable.
Hi Gigel,
thanks for your questions! Let me try to address them:
Re usage of AES-NI instruction set:
The component that does handles the AES is libgcrypt, I am not sure if it uses
the intel instruction set or not, you would need to inspect it or ask on gnupg-users@ oder gnupg-devel@
Re encryption key for symmetric encryption use in memory: To my knowledge the symmetric is not stored by GnuPG (or any other Gpg4win component) however there may be other mechanisms of your operating system that are beyond GnuPG’s control and still hold a copy of some data (e.g. an unencrypted swapping mechanism), so it depends on how you run your windows in detail.
Re key derivation function, in principle GnuPG uses OpenPGP and tries to be quite stable over time. So my strong guess is that the KDF stays the same. Asking on gnupg-users@ could get you an explicit answer about GnuPG’s policy here.
Re man page, good question. In principle there could be a webpage with the full instruction, afaik there is one having the full manual (the “info” or “textinfo” manual) which is more comprehensive and authorititative than the manpage. So the man page is not needed in this case.
Hi Bernhard,
Thank you for your response.
I found the info documentation files in the doc directory (readable even though Windows doesn’t have the “info” command).
Looking through the source, it seems that the only place where AES-NI support can be enabled/disabled is at the time of configuration, before compilation. In that case, the question is how was the Windows binary pre-configured. I can of course recompile myself too to make sure, was just hoping that the behavior could be changed at run time.
Hi Bernhard,
Thank you for your response.
I found the info documentation files in the doc directory (readable even though Windows doesn’t have the “info” command).
Looking through the source, it seems that the only place where AES-NI support can be enabled/disabled is at the time of configuration, before compilation. In that case, the question is how was the Windows binary pre-configured. I can of course recompile myself too to make sure, was just hoping that the behavior could be changed at run time.
Hi Bernhard,
Thank you for your response.
I found the info documentation files in the doc directory (readable even though Windows doesn’t have the “info” command).
Looking through the source, it seems that the only place where AES-NI support can be enabled/disabled is at the time of configuration, before compilation. In that case, the question is how was the Windows binary pre-configured. I can of course recompile myself too to make sure, was just hoping that the behavior could be changed at run time.
For documentation you can use https://gnupg.org/documentation/manuals.html but yes we should probably disable the “check the man page” message for windows or better provide another means of accessing the documentation offline.
And look for gpg4win_pkg__configure to see which configure options were used when building gpg4win.
There you can see that aesni is explicitly disabled for libgcrypt :-/
We’ll have to investigate if this is really still necessary or if the bug has been fixed. Thanks for bringing this to our attention again. I’ve opened an issue in the gnupg tracker for this https://bugs.g10code.com/gnupg/issue1919
Then this should be discussed on gnupg-devel or gcrypt devel as it is enabled by default for other plattforms.
I see no security gain by disabling it (AES-NI instructions are not something like “give me an ultra random number”) and it has been disabled because of a bug.
The performance of GnuPG’s AES encryption is bad compared to something like PolarsSSL on Windows probably because of dedicated instructions. So this could be an important improvement.
But this is imho more something for a major release and not a minor maintenance release.
