Re: AES-NI, symmetric key generation
On Thu, 12 Mar 2015 11:08, p...@heypete.com said: I (perhaps incorrectly) interpreted the question as If GnuPG makes backwards-incompatible changes in the future, would it be possible for one who knows the encryption algorithm used, key, etc. of a message to decrypt that message with other, non-GnuPG tools? Sure. As long as the tool understand the OpenPGP protocol. For example, if one knows that CAST5-CFB, ZIP, and salted-and-iterated S2K was used (as well as the value of the salt and number of iterations), might one be able to decrypt the message using OpenSSL and other common utilities? I suspect yes, as the encryption and Yes. Many years ago there used to be a toolset with reference implementation based on OpenSSL. IIRC, it was also available as a printed book. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
On Wed, 11 Mar 2015 20:39, p...@heypete.com said: One more question: Is there any standardization in output formats between encryption programs and libraries, for example say you encrypt with AES128 in CBC, with the same key (directly or via passphrase), and since the output will have to have, in addition to the actual ciphertext, algorithm indentification on it, possible pasphrase-to-key, plus mode-specific data such as the iv/nonce, is there a specification of the format of how these come in? You'd have to ask Werner, the head developer, about that. Sorry, I do not understand the question. The format is defined by the OpenPGP standard or the CMS standard (aka S/MIME). There are also some other less common formats. Or is the question how applications present this to the user or whether a standard API is defined? That is not defined by one of these protocols. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
Peter,My understanding was that if you don't pass --symmetric, then a session key is generated, with which the clear text is (symmetrically) encrypted and then the session key is encrypted (asymmetrically) with the public key. Conversely, if you do pass --symmetric, then there is no random-generated session key, and gpg simply generates a symmetric key from the passphrase, that it encrypts the clear text with. Are you saying that that is not the case, and there there is a session key, used to encrypt the clear text, and the session key gets encrypted, again, symmetrically with the passphrase-generated key? However my question regarding the standardization format was not necessarily related to the OpenPGP protocol, but rather, at the most basic level of symmetric encryption in general: you have a key, a cleartext, a symmetric block cipher algorithm and a mode of operation . Is the format of the output standardized within this context, of a symmetric block cipher encryption, rather than as part of OpenPGP? Would another software or encryption library be able to decrypt a text symmetrically encrypted with gpg, not taking into account additional layers of asymmetric encryption?Thank you for your help. From: Peter Lebbing pe...@digitalbrains.com To: Maricel Gregoraschko maricelgregorasc...@yahoo.com; Gnupg-users Gnupg-users@gnupg.org Sent: Wednesday, March 11, 2015 3:06 PM Subject: Re: AES-NI, symmetric key generation On 11/03/15 18:55, Maricel Gregoraschko wrote: One more question: Is there any standardization in output formats between encryption programs and libraries, for example say you encrypt with AES128 in CBC, with the same key (directly or via passphrase), and since the output will have to have, in addition to the actual ciphertext, algorithm indentification on it, possible pasphrase-to-key, plus mode-specific data such as the iv/nonce, is there a specification of the format of how these come in? The passphrase-based encryption of GnuPG is entirely specified in RFC 4880, and there is no reason to worry that future versions of GnuPG cannot read a symmetrically encrypted file created now. Also, it is *not* the case that the key used to encrypt the data is the key derived from your password! The key to encrypt the data, the session key, is randomly generated. The passphrase is used to derive a key, and this derived key is used to encrypt the session key, and only the session key! However, I do notice that RFC 4880 allows the use of a password-derived key to encrypt the data[1]. I don't think GnuPG will generate such OpenPGP messages, but it might accept and decrypt them. HTH, Peter. [1] RFC 4880 section 5.3: If the encrypted session key is not present (which can be detected on the basis of packet length and S2K specifier size), then the S2K algorithm applied to the passphrase produces the session key for decrypting the file, using the symmetric cipher algorithm from the Symmetric-Key Encrypted Session Key packet. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
Thanks Vedaal, yep that would be one mighty strong password! From: ved...@nym.hush.com ved...@nym.hush.com To: Maricel Gregoraschko maricelgregorasc...@yahoo.com; gnupg-users@gnupg.org Sent: Tuesday, March 10, 2015 4:42 PM Subject: Re: AES-NI, symmetric key generation On 3/10/2015 at 4:19 PM, Maricel Gregoraschko maricelgregorasc...@yahoo.com wrote: I agree, using key instead of passphrase doesn't enhance security (assuming an attacker knows that the key was derived from a passphrase and with what key derivation algorithm? I assume the randomness/entropy of the key itself is high enough regardless of the passphrase strength?). The reason I was asking if it's a possibility to store the symmetric key to decrypt with later, was to protect against future changes in the key derivation algorithm, that would make gpg generate a different key for the same passphrase, useless to decrypt previously encrypted data.Thank you for your support. - If you don't want to keep your passsphrase, and want only to keep the session key, and you want this to have no weakness because of a questionably strong enough password that was used to generate the key, then there is an easy way to do what you want: [1] Encrypt a test message to any of your own keys. [2] Decrypt this test message, with the option of --show-session-key [3] Use this session key as the 64 character password for your symmetric encryption, (and save it, or you won't be able to decrypt the symmetric message). [4] Decrypt your symmetrically encrypted file or message, using the option of --show-session-key [5] Save this session key, and if you wish, you can destroy the first one. (you can always get it back by decrypting your message of step [1] ). The string-to-key part of generating the session key for the symmetrically encrypted message, will be using a random 64 character GnuPG generated session key as it's password. You can't find a better password (especially even one that you don't have to remember ;-) ) vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
Thank you Pete for clearing things up. Makes a lot of sense to store passphrase-to-key identification data, in addition to actual algorithm used, in the output message rather than have the decryptor just assume things. I figured out how to use --show-session-key: in my tests it doesn't show the key when encrypting, only when decrypting, that's good enough, I'm ok with doing a test decryption just to show the key. One more question: Is there any standardization in output formats between encryption programs and libraries, for example say you encrypt with AES128 in CBC, with the same key (directly or via passphrase), and since the output will have to have, in addition to the actual ciphertext, algorithm indentification on it, possible pasphrase-to-key, plus mode-specific data such as the iv/nonce, is there a specification of the format of how these come in?Thanks! From: Pete Stephenson p...@heypete.com To: Maricel Gregoraschko maricelgregorasc...@yahoo.com; gnupg-users@gnupg.org Sent: Tuesday, March 10, 2015 5:32 PM Subject: Re: AES-NI, symmetric key generation On 3/10/2015 8:28 PM, Maricel Gregoraschko wrote: Pete, Very useful info about using --show-session-key to avoid revealing your private asymmetric key. No worries. In your example (gpg --show-session-key example.txt) , had you somehow set up gpg to use symmetric by default, rather than asymmetric + symmetric? No. It was a nearly out of the box setup with only some minor changes to my gpg.conf file in regards to accessing keyservers. Nothing that would affect the modes of encryption. If I explicitly pass --symmetric, --show-session-key does nothing (gpg4win) (and I guess the key is not really a random session key as when sending a PGP message) but rather the key deterministically generated from the passphrase. Works fine for me. Try copy-pasting the text into the command prompt rather than reading from a file. Use Ctrl-Z then Enter to tell GnuPG you're done entering a message and it should start processing things. Here's an encrypted message I generated with gpg --symmetric --armor on GPG4Win 2.2.3: -BEGIN PGP MESSAGE- Version: GnuPG v2 jA0EAwMC2lG4z3grm9G1ySTYXvITlKTun7NvaLnznJZI4AhGJyTk+rFkAdufNRzB cC6eqAI= =j73k -END PGP MESSAGE- (password is test with no quotes) gpg --show-session-key yields a session key of 3:C4A5BBCBB7C8F846FCA3A9BDDED0EB7F. The same message encrypted a few seconds later with the same password yields: -BEGIN PGP MESSAGE- Version: GnuPG v2 jA0EAwMCgnIlCp86aLq1ySQt2veDYta5U1uxPiust4siTyduBe7+CVhupax2HKeI Zcm3Rx0= =kZPs -END PGP MESSAGE- and a session key of 3:A81A96428D44DEAD3A6079CC22145B51 It appears that GnuPG uses the iterated-and-salted secret-to-key method (see https://tools.ietf.org/html/rfc4880#section-3.7.1.3 ) to generate the session key. You're right: the key is derived from a passphrase and so is not truly random, but the salt is random which helps a bit. Of course, the salt is not encrypted, so the message protection depends only on the strength of your passphrase. I agree, using key instead of passphrase doesn't enhance security (assuming an attacker knows that the key was derived from a passphrase and with what key derivation algorithm? I assume the randomness/entropy of the key itself is high enough regardless of the passphrase strength?). The attacker would be able determine quite a bit of information about how the message was encrypted (as this same information would be needed by a legitimate user to decrypt the message): Here's an excerpt from the double-verbose (-vv) output from the second encrypted message above (all this is available without entering the passphrase): :symkey enc packet: version 4, cipher 3, s2k 3, hash 2 salt 8272250a9f3a68ba, count 2752512 (181) The attacker would know the cipher being used (cipher 3 = CAST5), the fact that the key is derived from a user-provided string (the fact that s2k is used), which string-to-key algorithm is used (s2k 3 = iterated-and-salted), the hash used (hash 2 = SHA-1), the salt, and the number of times to iterate the S2K algorithm. The attacker won't know the strength of your passphrase -- it could be cat or a long string of random characters -- but it tells them that the key was generated using user-provided input. The reason I was asking if it's a possibility to store the symmetric key to decrypt with later, was to protect against future changes in the key derivation algorithm, that would make gpg generate a different key for the same passphrase, useless to decrypt previously encrypted data. GnuPG follows the OpenPGP standard (RFC 4880). The standard defines certain key derivation algorithms and provides the ability to add new ones if needed. Adding new key derivation algorithms in the future should not have any affect on existing encrypted messages. Since each message clearly identifies the algorithm used to encrypt it, future versions of GnuPG should
Re: AES-NI, symmetric key generation
On 3/11/2015 6:55 PM, Maricel Gregoraschko wrote: Thank you Pete for clearing things up. Makes a lot of sense to store passphrase-to-key identification data, in addition to actual algorithm used, in the output message rather than have the decryptor just assume things. Indeed. The folks who created the OpenPGP standard were quite forward-thinking in regards to such things. I figured out how to use --show-session-key: in my tests it doesn't show the key when encrypting, only when decrypting, that's good enough, I'm ok with doing a test decryption just to show the key. Ah, that was my mistake: I forgot to specify that --show-session-key only works when decrypting a message. Considering the intended purpose of that option (being compelled to turn over a key), I suppose that's a reasonable limitation in when it can be used. One more question: Is there any standardization in output formats between encryption programs and libraries, for example say you encrypt with AES128 in CBC, with the same key (directly or via passphrase), and since the output will have to have, in addition to the actual ciphertext, algorithm indentification on it, possible pasphrase-to-key, plus mode-specific data such as the iv/nonce, is there a specification of the format of how these come in? You'd have to ask Werner, the head developer, about that. RFC 4880 completely specifies how the algorithms are implemented. In theory, it should be possible to split a message into it's various packets (gpgsplit is designed to do this), then decrypt the symmetrically-encrypted packet using the method specified in the RFC, but I have not attempted to do this. Cheers! -Pete ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
On 11/03/15 18:55, Maricel Gregoraschko wrote: One more question: Is there any standardization in output formats between encryption programs and libraries, for example say you encrypt with AES128 in CBC, with the same key (directly or via passphrase), and since the output will have to have, in addition to the actual ciphertext, algorithm indentification on it, possible pasphrase-to-key, plus mode-specific data such as the iv/nonce, is there a specification of the format of how these come in? The passphrase-based encryption of GnuPG is entirely specified in RFC 4880, and there is no reason to worry that future versions of GnuPG cannot read a symmetrically encrypted file created now. Also, it is *not* the case that the key used to encrypt the data is the key derived from your password! The key to encrypt the data, the session key, is randomly generated. The passphrase is used to derive a key, and this derived key is used to encrypt the session key, and only the session key! However, I do notice that RFC 4880 allows the use of a password-derived key to encrypt the data[1]. I don't think GnuPG will generate such OpenPGP messages, but it might accept and decrypt them. HTH, Peter. [1] RFC 4880 section 5.3: If the encrypted session key is not present (which can be detected on the basis of packet length and S2K specifier size), then the S2K algorithm applied to the passphrase produces the session key for decrypting the file, using the symmetric cipher algorithm from the Symmetric-Key Encrypted Session Key packet. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
Thanks Vedaal, yep that would be one mighty strong password! It's also way overkill. :) gpg --armor --gen-rand 1 16 will produce a (relatively) short passphrase suitable for pretty much any imaginable usage. 128 shannons of entropy's nothing to sneeze at. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
Hi, To answer your first question regarding gpg4win: On Monday, March 09, 2015 05:15:14 PM Maricel Gregoraschko wrote: Hello All,I would first like to thank you for your effort and time developing gnupgp.I have a couple of questions: 1. Does GnuGP (in particular, the Windows binaries distributed for gpg4win) use AES-NI, the Intel dedicated AES instruction set? No, it has been disabled due to a bug. I've opened gnupg/issue1919 to track this. There are some concerns, I'm not sure how realistic, about backdoors built into the CPU themselves. AES is an algorithm that produces deterministic results. Not really something to backdoor like a RNG. I noticed there is an option to configure, --disable-aesni-support. Where can I get the full configure command as it was used to build the posted gpg4win binaries, to check if that switch was present or not? http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpg4win.git;a=blob;f=src/Makefile.am Look for gpg4win_pkg_package_configure (e.g. gpg4win_pkg_libgcrypt_configure) Also is there any option to turn hardware acceleration on or off at runtime? No. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
On Tue, 10 Mar 2015 10:05, aheine...@intevation.de said:
Also is there any
option to turn hardware acceleration on or off at runtime?
You can globally disable certain hardware features: Create a file
--8---cut here---start-8---
# We do not want to use AES-NI
intel-aesni
--8---cut here---end---8---
and store it as /etc/gcrypt/hwf.deny . This should work also on Windows
if you copy that file to every drive. The list of hardware
features in the current development version is:
{ HWF_PADLOCK_RNG, padlock-rng },
{ HWF_PADLOCK_AES, padlock-aes },
{ HWF_PADLOCK_SHA, padlock-sha },
{ HWF_PADLOCK_MMUL,padlock-mmul},
{ HWF_INTEL_CPU, intel-cpu },
{ HWF_INTEL_BMI2, intel-bmi2 },
{ HWF_INTEL_SSSE3, intel-ssse3 },
{ HWF_INTEL_PCLMUL,intel-pclmul },
{ HWF_INTEL_AESNI, intel-aesni },
{ HWF_INTEL_RDRAND,intel-rdrand },
{ HWF_INTEL_AVX, intel-avx },
{ HWF_INTEL_AVX2, intel-avx2 },
{ HWF_ARM_NEON,arm-neon }
Libgcrypt 1.6 has less features.
BTW, I just pushed a change for 2.1 to show the used Libgcrypt
configuration:
--8---cut here---start-8---
$ gpg --list-gcrypt-config
version:1.6.3-beta12:
ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:
pubkeys:dsa:elgamal:rsa:ecc:
digests:crc:gostr3411-94:md4:md5:rmd160:sha1:sha256:sha512:tiger:whirlpool:stribog:
rnd-mod:linux:
cpu-arch:x86:
mpi-asm:amd64/mpih-add1.S:amd64/mpih-sub1.S:amd64/mpih-mul1.S:amd64/mpih-mul2.S:amd64/mpih-mul3.S:amd64/mpih-lshift.S:amd64/mpih-rshift.S:
threads:none:
hwflist:intel-cpu:intel-ssse3:intel-pclmul:intel-aesni:intel-avx:
fips-mode:n:n:
rng-type:standard:1:
--8---cut here---end---8---
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
On 3/9/2015 6:15 PM, Maricel Gregoraschko wrote: Hello All, Hi! 2. 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? Correct. If the user wanted, can they dump the encryption key to store it securely, and use it to decrypt, instead of the password? Yes, but the security is only as strong as the weakest link: if one uses a weak passphrase to encrypt a message, an adversary could guess the password. If one used a long random string as a passphrase, this is functionally equivalent to a strong key, so why bother with using the key itself to decrypt instead of the passphrase? You can show the symmetric session key for a message using the --show-session-key option. Here's an example of text I encrypted with gpg --symmetric: -BEGIN PGP MESSAGE- Version: GnuPG v1 jA0EAwMCYFod0NxVEONgySM6oLcax81PoXTPKk2R+zdP2XZ+rA1ILbKy3+sg0xs8 B8SW2A== =Iz40 -END PGP MESSAGE- The passphrase is test (no quotes). pete@kaylee:~$ gpg --show-session-key example.txt [prompt for password] gpg: CAST5 encrypted data gpg: gpg-agent is not available in this session gpg: encrypted with 1 passphrase gpg: session key: `3:62A2421F805F6CB1767A9DF07983ADDF' gpg: example.txt: unknown suffix Later, I can use gpg with the --override-session-key option to supply the decryption key directly. Use gpg --override-session-key [session key], using the format given above: pete@kaylee:~$ gpg --override-session-key 3:62A2421F805F6CB1767A9DF07983ADDF example.txt gpg: CAST5 encrypted data gpg: encrypted with 1 passphrase Hello world! gpg: WARNING: message was not integrity protected See the manpage or https://www.gnupg.org/documentation/manpage.html for more details. One interesting note about show/override-session-key: if one is compelled to decrypt a message (or else...), one can use those options on messages encrypted using GnuPG's symmetric or the more usual asymmetric (i.e., public key) encryption methods. The manpage says, This option is normally not used but comes handy in case someone forces you to reveal the content of an encrypted message; using this option you can do this without handing out the secret key. In other words, if you're compelled to decrypt a message that was encrypted to your public key, you don't need to hand over your private key (which would allow someone to decrypt all your messages, sign new messages, etc.). Instead, you would just hand over the encrypted message and the session key used to encrypt it. Since each message uses a new, random session key, only that single message can be decrypted and your private key is not compromised. Cheers! -Pete ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
Pete,Very useful info about using --show-session-key to avoid revealing your private asymmetric key.In your example (gpg --show-session-key example.txt) , had you somehow set up gpg to use symmetric by default, rather than asymmetric + symmetric?If I explicitly pass --symmetric, --show-session-key does nothing (gpg4win) (and I guess the key is not really a random session key as when sending a PGP message) but rather the key deterministically generated from the passphrase. I agree, using key instead of passphrase doesn't enhance security (assuming an attacker knows that the key was derived from a passphrase and with what key derivation algorithm? I assume the randomness/entropy of the key itself is high enough regardless of the passphrase strength?). The reason I was asking if it's a possibility to store the symmetric key to decrypt with later, was to protect against future changes in the key derivation algorithm, that would make gpg generate a different key for the same passphrase, useless to decrypt previously encrypted data.Thank you for your support. From: Pete Stephenson p...@heypete.com To: Maricel Gregoraschko maricelgregorasc...@yahoo.com Cc: gnupg-users@gnupg.org Sent: Tuesday, March 10, 2015 10:36 AM Subject: Re: AES-NI, symmetric key generation On 3/9/2015 6:15 PM, Maricel Gregoraschko wrote: Hello All, Hi! 2. 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? Correct. If the user wanted, can they dump the encryption key to store it securely, and use it to decrypt, instead of the password? Yes, but the security is only as strong as the weakest link: if one uses a weak passphrase to encrypt a message, an adversary could guess the password. If one used a long random string as a passphrase, this is functionally equivalent to a strong key, so why bother with using the key itself to decrypt instead of the passphrase? You can show the symmetric session key for a message using the --show-session-key option. Here's an example of text I encrypted with gpg --symmetric: -BEGIN PGP MESSAGE- Version: GnuPG v1 jA0EAwMCYFod0NxVEONgySM6oLcax81PoXTPKk2R+zdP2XZ+rA1ILbKy3+sg0xs8 B8SW2A== =Iz40 -END PGP MESSAGE- The passphrase is test (no quotes). pete@kaylee:~$ gpg --show-session-key example.txt [prompt for password] gpg: CAST5 encrypted data gpg: gpg-agent is not available in this session gpg: encrypted with 1 passphrase gpg: session key: `3:62A2421F805F6CB1767A9DF07983ADDF' gpg: example.txt: unknown suffix Later, I can use gpg with the --override-session-key option to supply the decryption key directly. Use gpg --override-session-key [session key], using the format given above: pete@kaylee:~$ gpg --override-session-key 3:62A2421F805F6CB1767A9DF07983ADDF example.txt gpg: CAST5 encrypted data gpg: encrypted with 1 passphrase Hello world! gpg: WARNING: message was not integrity protected See the manpage or https://www.gnupg.org/documentation/manpage.html for more details. One interesting note about show/override-session-key: if one is compelled to decrypt a message (or else...), one can use those options on messages encrypted using GnuPG's symmetric or the more usual asymmetric (i.e., public key) encryption methods. The manpage says, This option is normally not used but comes handy in case someone forces you to reveal the content of an encrypted message; using this option you can do this without handing out the secret key. In other words, if you're compelled to decrypt a message that was encrypted to your public key, you don't need to hand over your private key (which would allow someone to decrypt all your messages, sign new messages, etc.). Instead, you would just hand over the encrypted message and the session key used to encrypt it. Since each message uses a new, random session key, only that single message can be decrypted and your private key is not compromised. Cheers! -Pete ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
AES is an algorithm that produces deterministic results. Not really something to backdoor like a RNG. I admit I haven't looked at the AES-NI instruction set, but I've read that it could be easy for the CPU to reconstruct the key from a sequence of calls typical to AES encryption/decryption (I think implementations even use Intel-provided code), and store it for later retrieval through a secret CPU instruction set. From: Andre Heinecke aheine...@intevation.de To: gnupg-users@gnupg.org; Maricel Gregoraschko maricelgregorasc...@yahoo.com Sent: Tuesday, March 10, 2015 5:05 AM Subject: Re: AES-NI, symmetric key generation Hi, To answer your first question regarding gpg4win: On Monday, March 09, 2015 05:15:14 PM Maricel Gregoraschko wrote: Hello All,I would first like to thank you for your effort and time developing gnupgp.I have a couple of questions: 1. Does GnuGP (in particular, the Windows binaries distributed for gpg4win) use AES-NI, the Intel dedicated AES instruction set? No, it has been disabled due to a bug. I've opened gnupg/issue1919 to track this. There are some concerns, I'm not sure how realistic, about backdoors built into the CPU themselves. AES is an algorithm that produces deterministic results. Not really something to backdoor like a RNG. I noticed there is an option to configure, --disable-aesni-support. Where can I get the full configure command as it was used to build the posted gpg4win binaries, to check if that switch was present or not? http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpg4win.git;a=blob;f=src/Makefile.am Look for gpg4win_pkg_package_configure (e.g. gpg4win_pkg_libgcrypt_configure) Also is there any option to turn hardware acceleration on or off at runtime? No. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
On 3/10/2015 at 4:19 PM, Maricel Gregoraschko maricelgregorasc...@yahoo.com wrote: I agree, using key instead of passphrase doesn't enhance security (assuming an attacker knows that the key was derived from a passphrase and with what key derivation algorithm? I assume the randomness/entropy of the key itself is high enough regardless of the passphrase strength?). The reason I was asking if it's a possibility to store the symmetric key to decrypt with later, was to protect against future changes in the key derivation algorithm, that would make gpg generate a different key for the same passphrase, useless to decrypt previously encrypted data.Thank you for your support. - If you don't want to keep your passsphrase, and want only to keep the session key, and you want this to have no weakness because of a questionably strong enough password that was used to generate the key, then there is an easy way to do what you want: [1] Encrypt a test message to any of your own keys. [2] Decrypt this test message, with the option of --show-session-key [3] Use this session key as the 64 character password for your symmetric encryption, (and save it, or you won't be able to decrypt the symmetric message). [4] Decrypt your symmetrically encrypted file or message, using the option of --show-session-key [5] Save this session key, and if you wish, you can destroy the first one. (you can always get it back by decrypting your message of step [1] ). The string-to-key part of generating the session key for the symmetrically encrypted message, will be using a random 64 character GnuPG generated session key as it's password. You can't find a better password (especially even one that you don't have to remember ;-) ) vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
Thanks Werner.On Windows, you mean on each drive letter, in the root directory?
(e.g. c:\hwf.deny, d:\hwf.deny, etc.?).Also would there be a way to make gpg
display which hardware features are being used when encrypting/decrypting (to
confirm that the deny file was correctly placed and actually had an effect)?
Thank you.
From: Werner Koch w...@gnupg.org
To: Andre Heinecke aheine...@intevation.de
Cc: gnupg-users@gnupg.org; Maricel Gregoraschko maricelgregorasc...@yahoo.com
Sent: Tuesday, March 10, 2015 10:58 AM
Subject: Re: AES-NI, symmetric key generation
On Tue, 10 Mar 2015 10:05, aheine...@intevation.de said:
Also is there any
option to turn hardware acceleration on or off at runtime?
You can globally disable certain hardware features: Create a file
--8---cut here---start-8---
# We do not want to use AES-NI
intel-aesni
--8---cut here---end---8---
and store it as /etc/gcrypt/hwf.deny . This should work also on Windows
if you copy that file to every drive. The list of hardware
features in the current development version is:
{ HWF_PADLOCK_RNG, padlock-rng },
{ HWF_PADLOCK_AES, padlock-aes },
{ HWF_PADLOCK_SHA, padlock-sha },
{ HWF_PADLOCK_MMUL,padlock-mmul},
{ HWF_INTEL_CPU, intel-cpu },
{ HWF_INTEL_BMI2, intel-bmi2 },
{ HWF_INTEL_SSSE3, intel-ssse3 },
{ HWF_INTEL_PCLMUL,intel-pclmul },
{ HWF_INTEL_AESNI, intel-aesni },
{ HWF_INTEL_RDRAND,intel-rdrand },
{ HWF_INTEL_AVX, intel-avx },
{ HWF_INTEL_AVX2, intel-avx2 },
{ HWF_ARM_NEON, arm-neon }
Libgcrypt 1.6 has less features.
BTW, I just pushed a change for 2.1 to show the used Libgcrypt
configuration:
--8---cut here---start-8---
$ gpg --list-gcrypt-config
version:1.6.3-beta12:
ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:
pubkeys:dsa:elgamal:rsa:ecc:
digests:crc:gostr3411-94:md4:md5:rmd160:sha1:sha256:sha512:tiger:whirlpool:stribog:
rnd-mod:linux:
cpu-arch:x86:
mpi-asm:amd64/mpih-add1.S:amd64/mpih-sub1.S:amd64/mpih-mul1.S:amd64/mpih-mul2.S:amd64/mpih-mul3.S:amd64/mpih-lshift.S:amd64/mpih-rshift.S:
threads:none:
hwflist:intel-cpu:intel-ssse3:intel-pclmul:intel-aesni:intel-avx:
fips-mode:n:n:
rng-type:standard:1:
--8---cut here---end---8---
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
On Tue, 10 Mar 2015 20:39, maricelgregorasc...@yahoo.com said: Thanks Werner.On Windows, you mean on each drive letter, in the root directory? (e.g. c:\hwf.deny, d:\hwf.deny, etc.?).Also would there be Yes, that was the idea. The file names should however be c:\etc\gcrypt\hwf.deny d:\etc\gcrypt\hwf.deny I have not tested this. a way to make gpg display which hardware features are being used when encrypting/decrypting (to confirm that the deny file was correctly placed and actually had an effect)? Thank you. From: Werner Koch Not yet. 2.1.3 will have a command to list it. You may simply encrypt a large file and compare the times. It is way faster with AES-NI enabled. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
On 3/10/2015 8:28 PM, Maricel Gregoraschko wrote: Pete, Very useful info about using --show-session-key to avoid revealing your private asymmetric key. No worries. In your example (gpg --show-session-key example.txt) , had you somehow set up gpg to use symmetric by default, rather than asymmetric + symmetric? No. It was a nearly out of the box setup with only some minor changes to my gpg.conf file in regards to accessing keyservers. Nothing that would affect the modes of encryption. If I explicitly pass --symmetric, --show-session-key does nothing (gpg4win) (and I guess the key is not really a random session key as when sending a PGP message) but rather the key deterministically generated from the passphrase. Works fine for me. Try copy-pasting the text into the command prompt rather than reading from a file. Use Ctrl-Z then Enter to tell GnuPG you're done entering a message and it should start processing things. Here's an encrypted message I generated with gpg --symmetric --armor on GPG4Win 2.2.3: -BEGIN PGP MESSAGE- Version: GnuPG v2 jA0EAwMC2lG4z3grm9G1ySTYXvITlKTun7NvaLnznJZI4AhGJyTk+rFkAdufNRzB cC6eqAI= =j73k -END PGP MESSAGE- (password is test with no quotes) gpg --show-session-key yields a session key of 3:C4A5BBCBB7C8F846FCA3A9BDDED0EB7F. The same message encrypted a few seconds later with the same password yields: -BEGIN PGP MESSAGE- Version: GnuPG v2 jA0EAwMCgnIlCp86aLq1ySQt2veDYta5U1uxPiust4siTyduBe7+CVhupax2HKeI Zcm3Rx0= =kZPs -END PGP MESSAGE- and a session key of 3:A81A96428D44DEAD3A6079CC22145B51 It appears that GnuPG uses the iterated-and-salted secret-to-key method (see https://tools.ietf.org/html/rfc4880#section-3.7.1.3 ) to generate the session key. You're right: the key is derived from a passphrase and so is not truly random, but the salt is random which helps a bit. Of course, the salt is not encrypted, so the message protection depends only on the strength of your passphrase. I agree, using key instead of passphrase doesn't enhance security (assuming an attacker knows that the key was derived from a passphrase and with what key derivation algorithm? I assume the randomness/entropy of the key itself is high enough regardless of the passphrase strength?). The attacker would be able determine quite a bit of information about how the message was encrypted (as this same information would be needed by a legitimate user to decrypt the message): Here's an excerpt from the double-verbose (-vv) output from the second encrypted message above (all this is available without entering the passphrase): :symkey enc packet: version 4, cipher 3, s2k 3, hash 2 salt 8272250a9f3a68ba, count 2752512 (181) The attacker would know the cipher being used (cipher 3 = CAST5), the fact that the key is derived from a user-provided string (the fact that s2k is used), which string-to-key algorithm is used (s2k 3 = iterated-and-salted), the hash used (hash 2 = SHA-1), the salt, and the number of times to iterate the S2K algorithm. The attacker won't know the strength of your passphrase -- it could be cat or a long string of random characters -- but it tells them that the key was generated using user-provided input. The reason I was asking if it's a possibility to store the symmetric key to decrypt with later, was to protect against future changes in the key derivation algorithm, that would make gpg generate a different key for the same passphrase, useless to decrypt previously encrypted data. GnuPG follows the OpenPGP standard (RFC 4880). The standard defines certain key derivation algorithms and provides the ability to add new ones if needed. Adding new key derivation algorithms in the future should not have any affect on existing encrypted messages. Since each message clearly identifies the algorithm used to encrypt it, future versions of GnuPG should have no problem decrypting it. Indeed, the current version of GnuPG is able to decrypt messages generated from old (even ancient!) versions of PGP and GnuPG with few, if any, issues. Cheers! -Pete ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
On Tue, 10 Mar 2015 20:33, maricelgregorasc...@yahoo.com said: I admit I haven't looked at the AES-NI instruction set, but I've read that it could be easy for the CPU to reconstruct the key from a Possible. It is also easy to detect the instructions used for software based AES keyscheduling and leak the key from that knowledge. I'd pick AES-NI for its better performace and SCA resistance. RDRAND for random numbers is a different story. No sane crypto tool should soley rely on this instruction. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
AES-NI, symmetric key generation
Hello All,I would first like to thank you for your effort and time developing gnupgp.I have a couple of questions: 1. 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. I noticed there is an option to configure, --disable-aesni-support. Where can I get the full configure command as it was used to build the posted gpg4win binaries, to check if that switch was present or not?Also is there any option to turn hardware acceleration on or off at runtime? 2. 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? If the user wanted, can they dump the encryption key to store it securely, and use it to decrypt, instead of the password?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)? Thank you very much for your support. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
