Although this new SHA1 hash provides stronger protection than the older 16 bit checksum for secret key material against malicious tampering such as the Klima-Rosa attack (for a concise and readable description of this vulnerability, see Tom McCune's account ), it also presents potential problems or issues for PGP and GnuPG users, especially those who might be generating keys in newer versions of PGP and GnuPG and exporting them for use in older versions of those programs.

This web page provides a description of the problems that users of recent versions of PGP and GnuPG could run into with secret keys that employ the newer SHA1 hash for secret key material. On this page we'll also identify the PGP and GnuPG versions that use the new SHA1 hash for secret key material. For those interested, there's a more comprehensive summary table of PGP and GnuPG versions.

Finally, we'll describe and demonstrate the several tools that are available to help users recognize and deal with potential problems caused by this new secret key integrity format. We'll show you how to:

• analyze secret keys with PGP 6.5.8ckt build 09 betas 2 & 3
• analyze secret keys with PGPdump
• convert secret keys with PGP from the old 16 bit checksum to the new 20 byte SHA1 hash
• analyze secret keys in GnuPG
• convert secret keys with GnuPG from the old 16 bit checksum to the new 20 byte SHA1 hash
• convert secret keys with GnuPG from the new SHA1 hash to the old 16 bit checksum

What follows is a brief summary of the more recent versions of PGP and GnuPG that can use the SHA1 hash for secret key material. A more complete and thorough summary table of PGP and GnuPG versions is provided later.

Application	SHA1 Secret Key Hash Support & Use
PGP 8.0.0:	supports SHA1 hash on secret keys, but does not use on keys that it generates
PGP 8.0.2:	supports SHA1 hash on secret keys; uses on SHA1 hash only on DH/DSS keys that it generates
PGP 6.5.8ckt build 09:	supports SHA1 hash on secret keys; uses SHA1 hash on all keys that it generates except RSAv3 keys
GnuPG 1.0.7:	supports SHA1 hash on secret keys; uses SHA1 hash on all keys that it generates except RSAv3 keys *
GnuPG 1.1.9.x:	supports SHA1 hash on secret keys; uses SHA1 hash on all keys that it generates except RSAv3 keys *
GnuPG 1.2.x:	supports SHA1 hash on secret keys; uses SHA1 hash on all keys that it generates except RSAv3 keys *
GnuPG 1.3.x:	supports SHA1 hash on secret keys; uses SHA1 hash on all keys that it generates except RSAv3 keys *
* In order for GnuPG 1.0.7 & later to generate RSAv3 keys,� �� the RSA v3 Key Generation Patch must be applied, such as� �� the case is with the GPG "Nullify" builds.

1. Compatibility problems
   �
   Secret keys generated in these more recent versions of PGP and GnuPG cannot be exported and used in older versions of these applications.
   �
   If you simply export one of your secret keys from PGP 8.0.2 or GPG 1.0.7 and then import it into PGP 7.1.1 or GnuPG 1.0.6, for example, the key will be unusable. When you attempt to decrypt files and messages with the secret key that you imported, those older versions PGP and GnuPG will not recognize the passphrase (or even let you change the passphrase) and thus will refuse to decrypt with the secret key (and you may or may not get an error box).�You'll encounter similar problems when attempting to use the secret key to sign messages and files.
   �
   Here is a handy table to determine if you may have a problem exporting keys from one version of PGP or GnuPG and re-using them in another:
   �
   

   If you generate keys in...	You may have problems using the secret keys in...
   PGP 8.0.2 PGP 6.5.8ckt build 09 GnuPG 1.3.x GnuPG 1.2.2 GnuPG 1.2.1 GnuPG 1.2.0 GnuPG 1.1.9.x GnuPG 1.0.7	PGP 7.1.x PGP 7.0.x PGP 6.5.x PGP 6.0.x PGP 5.5.x PGP 5.0 PGP 2.6.x PGP 6.5.8ckt build 08 (& earlier) GnuPG 1.0.6 (& earlier)

   �
   These newer versions of PGP and GnuPG don't use the SHA1 hash for all types of keys that they generate, however, only some of them. See the more complete summary table below for information on which key types are affected.
   �
2. Security issues
   �
   Secret keys generated in older versions of PGP and GnuPG can be imported into the newer versions of these applications, yet those secret keys will continue to use the deprecated 16 bit checksum for secret key material, even though PGP and GnuPG support the newer SHA1 hash. In other words, these newer versions of PGP and GnuPG do not automatically convert the secret keys to use the SHA1 hash. (These newer versions of PGP and GnuPG can still use the older 16 bit checksum format.) If you want your imported secret keys to be protected with the 20 byte SHA1 hash, you'll have to deliberately convert the keys.�
   �
   Moreover, RSAv4 keys that are generated by PGP 8.0.2 do not use the SHA1 secret key hash by default, rather the old 16 bit checksum, even though PGP 8.0.2 does support the SHA1 secret key hash and uses it on DH/DSS keys that it generates. PGP 8.0.2 users who want the RSAv4 keys that they've generated in PGP 8.0.2 to be protected with the SHA1 hash will need to convert the secret key. (It should be noted, however, that RSAv4 keys appear to be less vulnerable to the malicious tampering against which the SHA1 hash for secret key material is designed to protect -- see Tom McCune's description of the Klima-Rosa attack for more information.)
   �
   The method for converting secret keys in PGP or GnuPG may not be obvious to all users, however. Some PGP 8.0.2 users, for example, may want to convert their secret keys to use the SHA1 hash, yet PGP provides no obvious way to do it, though it is possible (and indeed users may inadvertently convert their secret keys without realizing it). With PGP, however, you cannot undo the changes and revert to the 16 bit checksum. GnuPG 1.0.7 (and later) does provide a way to convert secret keys to use the SHA1 hash -- and a way to revert back to the deprecated 16 bit checksum -- but the method for doing so is obscure.

Compounding these problems is the fact that no version of PGP -- with the sole exception of PGP 6.5.8ckt build 09 betas 2 & 3 -- provides an easy way for users to check whether secret keys on their key rings actually employ the new SHA1 hash or older 16 bit checksum.

Public Keys Not Affected

Keep in mind that the new 20 byte SHA1 hash is an issue only for secret key use, not public key use. In other words, users could run into problems only when using secret keys that employ the SHA1 hash, and even then only under certain circumstances (primarily when exporting keys from a newer version of PGP or GnuPG for re-use in an older version).�The public keys that PGP and GnuPG users exchange with one another, however, are not affected.

Thus, this SHA1 hash does not affect PGP and GnuPG users who use someone's public key to encrypt messages or to verify signatures, because this SHA1 hash is used only with secret keys. (It could affect those who attempt to use the corresponding secret key to decrypt messages encrypted with those public keys or generate signatures to be verified with those public keys, though.) In other words, even if you're using a newer version of PGP or GnuPG and your secret keys do incorporate the SHA1 hash, that should present no problems whatsoever for your email correspondents who continue to use an older version of PGP or GnuPG.

To access this information, open the Key Properties for the key you want to check. Here's what you'll see:

You won't find this information on the Key Properties box of any other version of PGP; it's unique to PGP 6.5.8ckt build 09 betas 1 & 2. CKT versions of PGP, by the way, are special versions of PGP 6.5.8 that have been built by Imad R. Faiad. For more information about PGP CKT builds and links to download the latest versions, see the Links section at the bottom of this page.�

Note: the "Cipher:" listed on the Key Properties (right above the "Protect Cipher:") is the key's "preferred cipher" -- the symmetric cipher that the key owner prefers be used for the encryption of messages and files. This "preferred cipher" is stored with the public key (not the secret or private key) and can be found on the Key Properties of every version of PGP 5.0 and above, not just PGP 6.5.8ckt build 09.���

To check the properties of a secret key, you must have the key pair (the Key Properties for a public key alone won't contain this information), however, you do not need to have the key on your key ring. You can merely double-click on an .ASC file that contains a PGP key pair, for example, which brings up the key import dialog box. From that box, right-click on the key and select Key Properties:

pgpdump -a my-key.asc

...where my-key.asc is the name of the key file to which you exported your key pair.

-----BEGIN PGP PRIVATE KEY BLOCK-----
�
-----END PGP PRIVATE KEY BLOCK-----

That is your secret key. (You'll also see a PUBLIC KEY BLOCK section in the .ASC key file -- you can ignore that.)� You can then paste your copied secret key into the web form interface for PGPdump and hit the Show Packets button.

With the DH/DSS key above, we see that both the signing key and the encrypting subkey use the 20 byte Encrypted SHA1 hash to protect the secret key.

Encrypted checksum
�
Checksum - xx xx

...where xx xx is the actual checksum (in the unencrypted, plaintext version).

Here's how to do it. (We'll be using PGP 6.5.8ckt build 09 beta 3.)

Caveats & Anomalies in PGP Secret Key Conversion

Although both PGP 6.5.8ckt build 09 and PGP 8.0.2 can convert secret keys from the older 16 bit checksum to the newer SHA1 hash, there are some differences in the way they do it.

PGP 6.5.8ckt build 09�
�
PGP 6.5.8ckt build 09 will convert all DH/DSS and RSAv4 secrets keys to the new SHA1 hash when the passphrase is on the secret key is changed. If the S2K on RSAv4 keys is "S2K Simple," it also converts the S2K to "S2K Iterated Salted". It will not convert RSAv3 secret keys to the SHA1 hash -- instead, all RSAv3 keys are changed to an S2K of "S2K Simple" and a checksum of "Plaintext (2 bytes)."

PGP 8.0.2�
�
PGP 8.0.2 will convert DH/DSS and RSAv4 secret keys to the new SHA1 hash when the passphrase is on the secret key is changed.� If the S2K on RSAv4 keys is "S2K Simple," it also converts the S2K to "S2K Iterated Salted." PGP 8.0.2 handles RSAv3 keys similar to PGP 6.5.8ckt build 09: it will not convert RSAv3 secret keys to the SHA1 hash -- instead, all RSAv3 keys are changed to an S2K of "S2K Simple" and a checksum of "Plaintext (2 bytes)."
�
That PGP 8.0.2 converts all RSAv4 keys to the SHA1 hash is odd, however, because it generates RSAv4 keys with the 16 bit checksum. PGP converts even secret keys that were generated by PGP 8.0.2 (and which originally used that 16 bit checksum) to the SHA1 hash (and in the process also converts the S2K from "S2K Simple" to "S2K Iterated Salted"). Thus, PGP 8.0.2 users who generate RSAv4 keys within PGP 8.0.2 will need to change the passphrase in order to force PGP 8.0.2 to protect the secret key with the new 20 byte SHA1 hash.

Because GnuPG is primarily a command line program -- which many PGP users may have problems using, even with a graphical front end such as GPGShell or WinPT -- and because the secret key conversion process in GnuPG is a bit more involved, we'll discuss how to use GnuPG to analyze and convert keys in a later section.

What follows below is a more thorough summary of PGP and GnuPG versions, which versions use the SHA1 hash for secret key material on keys that they generate, and which still use the older, deprecated 16 bit checksum. This summary table also includes "S2K" (string-to-key) and "Protect Cipher" information for the secret key materials on the keys that these versions of PGP and GnuPG generate. (For more information on the "S2K" and "Protect cipher," see below.)

The information for this table was gleaned from sample keys generated by these applications and examined within PGP 6.5.8ckt build 09 beta 3. All PGP Options were left at the defaults for the purposes of key generation.

What's in a Secret Key?
�
As you undoubtedly know, your PGP/GnuPG secret key is the secret half of the asymmetric key�
that PGP and GnuPG use when decrypting or signing messages and files. PGP and GnuPG don't�
store that secret key "in the clear" on your key ring, though. That secret key is protected in several�
ways. In the two notes that follow, we'll discuss how PGP and GnuPG protect your secret key by�
encrypting it with a symmetric cipher algorithm (known as a "protect cipher") and using a special�
data string (known as an "S2K") to generate and manage a session key for that "protect cipher."
�
A Note on the "Protect Cipher":�
�
The "protect cipher" is the symmetric cipher algorithm used to encrypt the secret key on the user's�
key ring.�The "protect cipher" is used for purposes different than the "preferred cipher," which is
the cipher�algorithm�that the key owner prefers be used during encyption of�messages and files.�
(All versions of PGP 5.0 and above list the "preferred cipher" on the Key Properties box.) The
"protect�cipher," by contrast, is used to protect the secret key on the user's key ring.�
�
When used to encrypt the secret key, this protect cipher uses a session key. This session key is�
the based on the passphrase. You can read more about how this passphrase-based session key is
generated and managed below in the "Note on the S2K."
�

The protect ciphers shown above are the defaults generated by PGP and GnuPG for the various�
key types. PGP and GnuPG determine the protect cipher for keys in slightly different ways.
�
PGP

�
In PGP the protect cipher has a complicated relationship with the preferred cipher specified in�
PGP Options and the preferred cipher actually set on the key.
�
For RSAv4 and DH/DSS keys in PGP 7.x and later, the protect cipher is set to whatever the
topmost preferred�cipher in PGP Options is during key generation. Thus, the protect cipher�
matches the preferred�cipher�on the key. (The preferred cipher on the key is also determined�
by the PGP Options preferred cipher.)
�
For DH/DSS keys in PGP 6.5.x (except the original PGP 6.5), the protect cipher is set to CAST5�
during key generation. If the passphrase for the secret key is changed, the protect cipher is set to�
whatever the preferred cipher on the key is. (The preferred cipher on the key is determined�by�
what the PGP Options�preferred cipher is during key generation.)
�
For DH/DSS keys in the original PGP 6.5 and pre-6.5 versions of PGP, the protect cipher is�
set to CAST5 and cannot�be changed, even if the PGP Options preferred cipher or the key's�
preferred cipher is set to�another cipher and the passphrase is changed. (The preferred cipher�
on the key is determined�by what the PGP Options preferred cipher is during key generation.)
�
For RSAv3 keys in PGP 7.x and later, PGP sets the protect cipher to whatever the topmost
preferred cipher in PGP Options is during key generation. If the passphrase is changed, the
protect cipher is changed to IDEA, no matter what the PGP Options preferred cipher is.�
(The preferred cipher on RSAv3 keys is�always IDEA, though, no matter what the preferred�
cipher in PGP Options is.)
�
For RSAv3 keys in pre-7.x versions of PGP, PGP sets the protect cipher to IDEA, ignoring the
preferred cipher in PGP Options, but ensuring that the protect cipher matches the preferred
cipher on the key, which is IDEA. (PGP ignores the preferred cipher specified in PGP Options
when setting the preferred cipher on RSAv3 keys.)
�
GnuPG

GnuPG, by contrast, always seems to use CAST5, no matter what the preferred cipher on the key�
or the preferred cipher specified in the OPTIONS or GPG.CONF file is during key generation.�
�
It is possible in GnuPG 1.0.7 and later to use the --s2k-cipher-algo option to specify a protect�
cipher in the OPTIONS or GPG.CONF file (depending on the GnuPG version being used).�To�
change the protect cipher on an existing key, you must edit the key with the --edit-key command
in�conjunction with the --s2k-cipher-algo option and change the password with the passwd �
command. (Note: this process is similar to using the --simple-sk-checksum option described�
below to change the secret key checksum or hash.)

A Note on the "S2K":

According to RFC2440, S2K (string-to-key) specifiers "are used to convert passphrase strings�
into symmetric-key encryption/decryption keys. They are used...to encrypt the secret part of�
private keys in the private keyring..." Let's unpack that a bit.
�
PGP and GnuPG use a passphrase (which is collected from the user during key generation) to�
protect the secret key, which is encrypted with the protect cipher. The passphrase is, in a way,�
the session key for the symmetric cipher used as the protect cipher to encrypt the secret key.�
But PGP uses this passphrase in a special way, and the resultant data is known as the S2K.
�
PGP and GnuPG use two different types of S2K's:
�
1. Simple S2K: with a Simple S2K, PGP uses an MDC (message digest cipher) such as
��� SHA1 to hash the passphrase. The passphrase is then thrown away and the SHA1 hash of
��� the passphrase is used as the session key to encrypt the secret key material. After the�
��� secret key material is encrypted, the SHA1 hash (which is the session key) is thrown
��� away. When the user attempts to use the secret key, s/he is prompted for the passphrase�
��� used to protect the secret key. The passphrase that the user inputs is hashed, and the hash
��� is used as a session key to unlock the secret key material. If the user has inputted the
��� correct passphrase, the hashed passphrase will work as the session key to unlock the secret
��� key material. If the user has not inputted the correct passphrase, then the SHA1 hash of
��� the passphrase will not work as the session key for the secret key material, and the user
��� is told that an incorrect passphrase has been entered.
�
2. S2K Iterated Salted: this type of S2K works in much the same way as a Simple S2K,
��� with one twist: PGP and GnuPG hash the passphrase along with a bit of "arbitrary data"
��� known as a "salt." The passphrase is thrown away, the hashed passphrase and "salt" is used
��� as a session key to encrypt the secret key, and then the session key is thrown�away. The
��� "salt" (along with an octet count based on a specified formula) is stored with the encrypted�
��� secret key material. When the user attempts to use the secret key, the user's inputted�
��� passphrase is hashed along with the "salt" to produce the session key to unlock the secret
��� key material. Use of a "salt" protects the session key (which is based on the passphrase)
��� against dictionary attacks which might be launched to crack the session key�by increasing
��� the amount of work that an attacker must perform.
�
Note that the SHA1 hash of the passphrase or the passphrase+salt is not the same thing as
the 20 byte SHA1 hash of the secret key material that we've been discussing on this page.�
The SHA1 hash of the passphrase or the passphrase+salt is used as the session key for the�
encrypted secret key material. The 20 byte SHA1 hash of the secret key, by contrast, is used
as an integrity check for the secret key (as is the older 16 bit checksum) and is encrypted�
along with the secret key.�
�
When unlocking the secret key, PGP and GnuPG use the SHA1 hash of the passphrase or the�
passphrase+salt (which is the session key) to decrypt the secret key material, which includes�
the secret key along with the 20 byte SHA1 hash or 16 bit checksum. Once that secret key�
material is unlocked,�the 20 byte�SHA1 hash or 16 bit checksum is used to verify that the�
secret key has not been�altered or�tampered�with.

For more information on the "S2K" for secret keys, see the following sections of RFC2440bis-07:

3.7.     String-to-key (S2K) specifiers       10
3.7.1.   String-to-key (S2K) specifier types  10
3.7.1.1. Simple S2K                           10
3.7.1.2. Salted S2K                           11
3.7.1.3. Iterated and Salted S2K              11
3.7.2.   String-to-key usage                  12
3.7.2.1. Secret key encryption                12    

Like PGP 8.0.2 and PGP 6.5.8ckt build 09, GnuPG will not automatically convert secret keys that use the deprecated 16 bit checksum to the new SHA1 hash when you import those keys onto GnuPG's key rings. If you want those secret keys generated in older versions of GnuPG or PGP to use the SHA1 hash, you will have to deliberately convert the secret keys with GnuPG.

In this section we'll demonstrate how to use GnuPG 1.0.7 and later to analyze secret keys with the --list-packets command. We'll also show you how to convert secret keys from one integrity protection format to another.�

In order to perform these operations, you'll have to have GnuPG installed (obviously). You'll also have to know how to import and export keys from GnuPG's key rings. We won't cover either of those topics here. If you need more help using GnuPG, please consult this GnuPG Command Reference, also found on this web site.

The processes described in this section can be used with GnuPG 1.0.7, GnuPG 1.1.9.x, GnuPG 1.2.x, and GnuPG 1.3.x. For download links to GnuPG (as well as Windows front-ends), see the Links section at the end of this document.

In the case of this RSAv4 key, we see that both the signing key and the encrypting subkey use the 20 byte SHA1 hash (SHA1 protection). If the key you analyze uses some version of the older 16 bit checksum, you would see one of the following:

simple checksum
�
checksum: xxxx

...where xxxx is the actual checksum (in the unencrypted, plaintext version).

Algo ID	Cipher
1	IDEA
2	3DES
3	CAST5
4	Blowfish
7	AES (128)
8	AES192
9	AES256
10	Twofish

You'll need to import the secret key(s) to be converted onto your key ring (if they're not already there). Once you've done that, you can convert the key.�

Here's how to do it. First edit the key (--edit-key) with the --simple-sk-checksum option.

To convert your secret key from the older, deprecated 16 bit checksum to the newer SHA1 hash, simply edit your key (--edit-key) without the --simple-sk-checksum option (which we used above) and change the passphrase with the passwd command.�(Note that you don't actually have to choose a new passphrase, unlike PGP 6.5.8ckt build 09 or PGP 8.0.2 -- you can simply enter the same passphrase as before.)

Now, if you wish, you can export your secret key with the --export-secret-keys command and import that secret key onto your keyring for PGP or another version of GnuPG.

A Note on the --edit-key Command: in these GnuPG examples we used the --edit-key command with both the UserID (george) and the KeyID (0x0A484ECB). Either will work to identify the key to be edited or changed.

Note: Used with the kind permission of Tom McCune. See also David Ross's account of the same attack.

• http://www.pgp.com/

As with previous versions of PGP, there are Freeware, Personal, and Desktop versions available.

• http://ipgpp.veniece.com/
• ftp://ftp.zedz.net/pub/crypto/pgp/pgp60/pgp658_ckt/

PGP 6.5.8 build 09 beta 3 is "test" software is not recommended for everyday use, because it has several problems. These problems include the lack of an uninstaller and a PGP Command Line (PGP.exe). You can download a replacement uninstaller for PGP 6.5.8ckt build 09 beta 3 HERE and a PGP Command Line HERE.

According to a recent post (18 Mar. 2003) from Imad on the PGP-Basics Mailing List, PGP 6.5.8ckt build 09 final should be released "Winter 2004."�

The latest regular release of PGP 6.5.8ckt is build 08, but that version does not support any of the unique features described on this page.

You can read more about the unique features of the CKT builds HERE.

• http://www.gnupg.org/

The current release version is GnuPG 1.2.1, although alpha and beta versions are available from that site.

• http://www.nullify.org/

The "Nullify" builds of GnuPG have several important enhancements, including:

• SHA-2 Clearsignature Patch
• RSA v3 Key Generation Patch
• Display Windows version in ascii armor
• Pentium optimized with Microsoft Visual Studio.NET
• SHA-2 is compiled into the binary
• --passphrase option�

• GPGShell
  �
• WinPT

• http://pgp.iijlab.net/pgpdump.html

There's a Win32 command line binary here:

• http://www.chez.com/winterminator/gnupg.html
• http://www.chez.com/winterminator/pgpdump.zip (direct download)

And the web form interface version for PGPdump can be found here:

• http://www.pgpdump.net/

A note on PGPdump web interface: when you use the web form interface version of PGPdump to analyze your secret keys, you are in fact transmitting those keys over the Internet, which is a public network and not necessarily the most secure medium. Even though the key material of your secret key is encrypted (as explained above), for security reasons it is recommended that you use the command line version of PGPdump on your local machine to analyze secret keys.

• PGP Versions, Sources, & Alternatives
• PGP Add-on Components
• PGP Compatibility Tables
• PGPdisk Volume Sizes
• GnuPG Command Reference
• Creating a Key Revocation Certificate in PGP
• PGP/GPG Guided Tour