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: [email protected] > To: [email protected] > CC: [email protected]; [email protected] > 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 [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
