Re: SHA1 Protection from way to see what cipher/algo was used to create your key?
On 21/06/12 15:00, Sam Smith wrote: when running the command: gpg --list-packets keyname.asc there is an outputted line that reads: SHA1 protection First of all, it seems you understand it, but let me emphasize this: the algorithms you get when using the inspection method vedaal showed you, are /not/ the algorithms used to create your secret key, as you asked. There is no cipher or hashing involved in creating a key; it's just a random number which must satisfy some mathematical properties. Key creation is determining random numbers that satisfy the needed properties. The symmetric cipher and hash algorithm are used to encrypt and protect the secret key; protection is via a password. All the details are in RFC 4880; you could read it at, e.g., [1]. It's a very technical document. I'll take the output vedaal gave as an example: :secret key packet: version 4, algo 1, created 1201031494, expires 0 skey[0]: [4096 bits] skey[1]: [17 bits] iter+salt S2K, algo: 10, SHA1 protection, hash: 8, salt: A password is used to protect this key. This password, along with a known, but random salting value, is repeatedly fed through SHA256 hashing (hash: 8). This is what iter+salt S2K means: A String-To-Key method that iteratively hashes, with a salt. The result of this S2K is a symmetric encryption key. The actual secret part of the secret key is protected by a symmetric cipher, TWOFISH (algo: 10). The secret material is encrypted with TWOFISH using the key the S2K gave. However, there is the possibility for an attacker to modify this secret material. If you don't notice, he has an attack vector on you as he can modify the key you are using to sign and decrypt. To prevent modification, the secret key material is hashed using the SHA1 algorithm, and this hash is stored in the encrypted part. If the attacker modifies the encrypted part, the hash won't check out anymore, and an OpenPGP implementation will reject the key as corrupted. So that's the purpose of the SHA1 protection. The hashing algorithm you can choose is the one used to create a key with the S2K specifier. The hashing algorithm to protect against modification of the encrypted material is fixed. Note that since it is all inside the encrypted part, a lot of attacks that are possible on hashing algorithms won't work anymore. SHA1 would have to be extremely broken to be problematic for this application. Peter. PS: BTW, the absolute worst possible checksum to use to protect integrity, when put inside a streaming-mode cipher, is a cyclic redundancy check. Which they used in WEP wireless LAN protection. My mouth fell open when I learned about this :). [1] https://tools.ietf.org/html/rfc4880 -- 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://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SHA1 Protection from way to see what cipher/algo was used to create your key?
On 06/21/2012 09:57 AM, Peter Lebbing wrote: There is no cipher or hashing involved in creating a key... This may or may not be true, depending on what method of random number generation is being used. ANSI X9.17, Yarrow and Fortuna are three examples of pseudorandom number generators that are built out of cryptographic algorithms. libgcrypt supports at least the former: Linux's /dev/urandom is (I think) Yarrow-based. Nine in ten says the OP doesn't care about this and was operating under a misconception, which you and others have ably corrected. One in ten says we've been misunderstanding what the OP has been asking, and the OP's really asking a technical question about PRNG operation. :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: SHA1 Protection from way to see what cipher/algo was used to create your key?
Thanks for this detailed explanation. I really appreciate it. I've read of theoretical attacks against SHA1. whenever I hear of such things I start to be leery when using such Hash. Seeing the advanced attack capabilities demonstrated by Flame/Stuxnet leads me to believe theoretical is only temporary. I agree though that SHA1 protection implementation sounds good. But seems to me it would be safer to use SHA2 for the hash used in producing the symmetric key. Date: Thu, 21 Jun 2012 15:57:28 +0200 From: pe...@digitalbrains.com To: smick...@hotmail.com CC: ved...@nym.hush.com; gnupg-users@gnupg.org Subject: Re: SHA1 Protection from way to see what cipher/algo was used to create your key? On 21/06/12 15:00, Sam Smith wrote: when running the command: gpg --list-packets keyname.asc there is an outputted line that reads: SHA1 protection First of all, it seems you understand it, but let me emphasize this: the algorithms you get when using the inspection method vedaal showed you, are /not/ the algorithms used to create your secret key, as you asked. There is no cipher or hashing involved in creating a key; it's just a random number which must satisfy some mathematical properties. Key creation is determining random numbers that satisfy the needed properties. The symmetric cipher and hash algorithm are used to encrypt and protect the secret key; protection is via a password. All the details are in RFC 4880; you could read it at, e.g., [1]. It's a very technical document. I'll take the output vedaal gave as an example: :secret key packet: version 4, algo 1, created 1201031494, expires 0 skey[0]: [4096 bits] skey[1]: [17 bits] iter+salt S2K, algo: 10, SHA1 protection, hash: 8, salt: A password is used to protect this key. This password, along with a known, but random salting value, is repeatedly fed through SHA256 hashing (hash: 8). This is what iter+salt S2K means: A String-To-Key method that iteratively hashes, with a salt. The result of this S2K is a symmetric encryption key. The actual secret part of the secret key is protected by a symmetric cipher, TWOFISH (algo: 10). The secret material is encrypted with TWOFISH using the key the S2K gave. However, there is the possibility for an attacker to modify this secret material. If you don't notice, he has an attack vector on you as he can modify the key you are using to sign and decrypt. To prevent modification, the secret key material is hashed using the SHA1 algorithm, and this hash is stored in the encrypted part. If the attacker modifies the encrypted part, the hash won't check out anymore, and an OpenPGP implementation will reject the key as corrupted. So that's the purpose of the SHA1 protection. The hashing algorithm you can choose is the one used to create a key with the S2K specifier. The hashing algorithm to protect against modification of the encrypted material is fixed. Note that since it is all inside the encrypted part, a lot of attacks that are possible on hashing algorithms won't work anymore. SHA1 would have to be extremely broken to be problematic for this application. Peter. PS: BTW, the absolute worst possible checksum to use to protect integrity, when put inside a streaming-mode cipher, is a cyclic redundancy check. Which they used in WEP wireless LAN protection. My mouth fell open when I learned about this :). [1] https://tools.ietf.org/html/rfc4880 -- 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://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choice of encryption algorithms
On 06/21/2012 12:52 AM, Robert J. Hansen wrote: Please don't do this. It's error-prone. Those are machine-readable numbers, not human-readable ones. Use the human-readable ones: for instance, default-preference-list TWOFISH 3DES SHA256 SHA224 RIPEMD160 completely agreed. Also, default-preference-list is redundant with the other -preferences. i don't think this is the case. default-preference-list describes the default preferences used for new keys. That is, for keys created by the local installation of gpg, the embedded preference list stored in the self-sig is chosen by this value. The personal-*-preferences settings, on the other hand, allow the user of gpg to override the recipient's self-sig's stated preferences, allowing to use the highest-personally-ranked algorithm that the recipient has stated that they can handle. The description in the gpg man page for these options describes them quite well, and it doesn't mention any relationship between them. If there is indeed a relationship, the manual probably needs to change to reflect it. Regards, --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choice of encryption algorithms
On Jun 21, 2012, at 12:39 PM, Daniel Kahn Gillmor wrote: On 06/21/2012 12:52 AM, Robert J. Hansen wrote: Please don't do this. It's error-prone. Those are machine-readable numbers, not human-readable ones. Use the human-readable ones: for instance, default-preference-list TWOFISH 3DES SHA256 SHA224 RIPEMD160 completely agreed. Also, default-preference-list is redundant with the other -preferences. i don't think this is the case. default-preference-list describes the default preferences used for new keys. That is, for keys created by the local installation of gpg, the embedded preference list stored in the self-sig is chosen by this value. You are correct. default-preference-list is to give the, well, default preference list for new keys or the list that is set when you do updpref in --edit-key and don't give an explicit list. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
idea.dll
Werner Koch wk at gnupg.org wrote on Wed Jun 20 10:29:28 CEST 2012 : The next version of Libgcrypt will support IDEA and thus GnuPG 2.1 will be able to decrypt old (i.e. PGP 2) files, directly. Will GnuPG 2.x then allow importation of v3 keys? (main reason I still prefer 1.4.x over 2.x) Thanks, vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
idea.dll
vedaal at nym.hush.com vedaal at nym.hush.com wrote on Thu Jun 21 19:05:06 CEST 2012 : Will GnuPG 2.x then allow importation of v3 keys? (main reason I still prefer 1.4.x over 2.x) Sorry, my mistake, gnupg 2.x does import v3 keys, haven't looked at this aspect for a while, as I couldn't use my old v3 key in gnupg 2, without changing the algorithm protecting it, looking forward to the idea support in 2.x, Thanks ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choice of encryption algorithms
On 6/21/2012 12:39 PM, Daniel Kahn Gillmor wrote: i don't think this is the case. You and David are completely right, and I have no idea what I was thinking. Thank you both for the correction! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: idea.dll
On 06/21/2012 01:21 PM, ved...@nym.hush.com wrote: vedaal at nym.hush.com vedaal at nym.hush.com wrote on Thu Jun 21 19:05:06 CEST 2012 : Will GnuPG 2.x then allow importation of v3 keys? (main reason I still prefer 1.4.x over 2.x) Sorry, my mistake, gnupg 2.x does import v3 keys, unfortunately, this is indeed the case. v3 keys have a serious vulnerability in that their fingerprint mechanism is trivially gamable, so long keyid collisions are easy. You should retire your v3 key, as should anyone else with such a key. Please! --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: idea.dll
On 06/21/2012 04:38 PM, Daniel Kahn Gillmor wrote: unfortunately, this is indeed the case. v3 keys have a serious vulnerability in that their fingerprint mechanism is trivially gamable, so long keyid collisions are easy. It's quite a bit worse than that, really. If I understand things correctly, the news media and antivirus companies are reporting that the Flame malware used an MD5 collision to get their malware to report that it had been signed by Microsoft. If true, that's a clear sign that MD5-based signatures of all sorts are now suspect. I wish I could say that this puts the final nail in PGP 2.6's coffin, but the reality is there's a huge installed userbase that won't change for love or money. All we can do is encourage people to not join them. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
