"SHA1 Protection" from way to see what cipher/algo was used to create your key?

Sam Smith smickson at hotmail.com
Thu Jun 21 16:39:54 CEST 2012

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: peter at digitalbrains.com
> To: smickson at hotmail.com
> CC: vedaal at nym.hush.com; gnupg-users at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120621/0cae4c2c/attachment.htm>

More information about the Gnupg-users mailing list