PGP, GnuPG, & the New SHA1 Secret Key Hash
 
On This Page...
   
   
Overview
   
  The New 20 byte SHA1 Secret Key Hash
   
  Recent versions of PGP and GnuPG can protect the integrity of secret keys with a 20 byte SHA1 hash instead of the older 2 byte (16 bit) checksum used by previous versions of PGP and GnuPG. This new SHA1 secret key hash is specifed in RFC2440; the simple 16 bit checksum used by most previous versions of PGP and GPG is now deprecated. 

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
   
  Older vs. Newer PGP & GnuPG Versions
   
  In 2002 some versions of PGP and GnuPG began providing support for the new SHA1 secret key hash specified in RFC2440 ("Open PGP Message Format" -- see section 5.5.3. "Secret Key Packet Formats"). Some versions of these applications merely support this SHA1 hash, but don't use the SHA1 hash on keys that they generate. Other versions use the SHA1 hash on most (but not all) types of keys that they generate.

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.
  As noted above, most earlier versions of PGP and GnuPG -- including the popular PGP 6.0.x, PGP 6.5.x, PGP 7.0.x, and PGP 7.1.x versions from NAI -- use the older, deprecated 16 bit checksum instead of the newer SHA1 hash for secret key material integrity.
   
  Problems & Issues for Users
   
  Users of these more recent versions of PGP and GnuPG face at least two issues or problems when dealing with secret keys generated by these applications:
  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.

   
Basic Tools for Users
   
  There are several tools available available to help PGP and GnuPG users analyze keys, determine which keys might be using the new 20 byte SHA1 hash for secret key material, and convert secret keys. In this section we'll describe the most basic of those tools and demonstrate how they work. In a later section we'll talk about how to use GnuPG to analyze secret keys and convert them from one format to the other.
   
  PGP 6.5.8ckt build 09 Secret Key Properties
   
  PGP 6.5.8ckt build 09 betas 2 & 3 do provide one useful tool for PGP and GnuPG users: the ability to see whether a secret key incorporates the new SHA1 hash or the older 16 bit checksum. This is a valuable feature provided by no other version of PGP or GnuPG, as it allows users to identify which keys may present problems and which keys may need to be converted (either to use the new SHA1 hash or to revert to the older 16 bit checksum).

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

   
  PGP 6.5.8ckt build 09 Secret Key Properties
                                PGP 6.5.8ckt build 09 Secret Key Properties
   
  In the screenshot above we've pointed out several other unique bits of information ("S2K:" and "Protect cipher:") about the secret key that PGP 6.5.8ckt build 09 provides in addition to the SHA1 hash or 16 bit checksum used on the secret key. (For more information on the "S2K" and "Protect cipher," see below.)

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:

   
  PGP Key Import: Select Key(s) - Key Properties
   
  This brings up the Key Properties box that we saw above. Once you've finished looking at the Key Properties, you can simply Cancel the import of the key pair onto your key ring.
   
  Using PGPdump to Analyze Keys
   
  Another handy utility for analyzing secret keys and determining whether they use the new SHA1 hash for secret key integrity is PGPdump.  PGPdump analyzes and displays the raw "packets" of keys, allowing you to see just how a secret key is put together. PGPdump was originally a command line line program, but there is a web form interface version of PGPdump that you can use as well (please read this note before using it, though).You can find links to both in the Links section at the end of this document.
   
  In order to use either version of PGPdump, you'll need to export your keys to an ASCII armored key file (.ASC). Within PGPkeys, right-click on the key pair you wish to export, then select Export... from the context menu.
   
  PGPkeys: Export...
   
  Select a directory to export your key pair to. And make sure that you've got the "Include Private Key(s)" box checked (we need both parts of our key pair to be exported).
   
  Export Key to File
   
  Click Save to export your key pair to a ASCII Armored file (.ASC). Now you're ready to use PGPdump.
   
  If you're using the command line version of PGPdump, you execute the following command:
pgpdump -a my-key.asc

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

   
  If you're using the web interface version of PGPdump, you'll need to open the .ASC key file to which you exported your key pair in a plain text editor like Notepad. In Notepad, select and copy everything between and including the lines:
-----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 both the command line version of PGPdump and the web form interface version you'll get back results that look like this:
   
 

Old: Secret Key Packet(tag 5)(489 bytes)
        Ver 4 - new
        Public key creation time - Sat Apr 12 00:37:11 CDT 2003
        Pub alg - DSA Digital Signature Standard(pub 17)
        DSA p(1024 bits) - ...
        DSA q(160 bits) - ...
        DSA g(1021 bits) - ...
        DSA y(1021 bits) - ...
        Sym alg - AES with 256-bit key(sym 9)
        String-to-key(s2k 3):
                Hash alg - SHA1(hash 2)
                Salt - f1 58 82 cb a4 54 c6 b8
                Count - 65536(coded count 96)
        IV - 35 b3 a9 95 cd 3e b2 50 99 b6 cc 23 56 32 d5 01
        Encrypted DSA x
        Encrypted SHA1 hash
Old: User ID Packet(tag 13)(38 bytes)
        User ID - Eric L. Howes 
Old: Secret Subkey Packet(tag 7)(1145 bytes)
        Ver 4 - new
        Public key creation time - Sat Apr 12 00:37:11 CDT 2003
        Pub alg - ElGamal Encrypt-Only(pub 16)
        ElGamal p(4096 bits) - ...
        ElGamal g(2 bits) - ...
        ElGamal y(4096 bits) - ...
        Sym alg - AES with 256-bit key(sym 9)
        String-to-key(s2k 3):
                Hash alg - SHA1(hash 2)
                Salt - 01 ba 5a fa 4d ec 34 5c
                Count - 65536(coded count 96)
        IV - c9 34 cf a2 62 9f 48 01 e8 63 b3 99 65 f5 fa 40
        Encrypted ElGamal x
        Encrypted SHA1 hash
   
  The example above is a DH/DSS key, which is comprised of a DSS signing key and a DH encrypting subkey. RSAv4 keys also have a signing key and encrypting subkey; RSAv3 keys (also known as RSA Legacy Keys) have only a single signing and encrypting key. 

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.

   
  If the key you're analyzing uses some version of the old 16 bit checksum, then you'll see one of the following lines instead:
Encrypted checksum
 
Checksum - xx xx

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

   
  One final note about the results you see above: PGPdump provides much other useful information, including the "protect cipher"  -- Sym alg - AES with 256-bit key(sym 9) -- and the "S2K"  -- String-to-key(s2k 3). We saw both of these bits of information on the Key Properties box in PGP 6.5.8ckt build 09 above, and we can also find them here. The "protect cipher" is "AES256." The "S2K" is a bit more obscure -- it's "S2K Iterated Salted," which we can tell by the S2K specifier 3. Here's a handy chart from RFC2440 for determining the type of S2K used on a key:
 
 
ID          S2K Type
--          --- ----
0           Simple S2K
1           Salted S2K
2           Illegal value
3           Iterated and Salted S2K
100 to 110  Private/Experimental S2K
  For more information on the "S2K" and "protect cipher," see the "What's in a Secret Key" section below.
   
  Using PGP to Convert Keys
   
  You can use PGP 6.5.8ckt build 09 and PGP 8.0.2 to convert keys generated in older versions of PGP and GnuPG so that they incorporate the new SHA1 hash instead of the older deprecated 16 bit checksum. (PGP 8.0.0 will not convert secret keys to the SHA1 hash, even though it can use such keys.) No version of PGP, however, provides a way to convert keys that use the new SHA1 secret key hash to use the older 16 bit checksum format, however. To revert to the 16 bit checksum, you'll need to use some version of GnuPG 1.0.7 or later, which we describe in a later section.
   
  If you've imported keys generated in an older version of PGP into PGP 8.0.2 or PGP 6.5.8ckt build 09, and if you're sure that you won't need to re-export those keys for use in older version of PGP or GnuPG (hint: backups of the original, unconverted keys would be handy here), you can convert those keys to use the new SHA1 hash by changing the the passphrase for your secrey key. (Note: there are a few anomalies and caveats, which we discuss below.)

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

   
 
1. Open the Key Properties for the Key You Wish to Convert
   
  Within PGPkeys, select (highlight) the key you wish to convert. Then, either select Keys >> Properties... from the PGPkeys menu bar, or right-click on the key and select Key Properties from the context menu that pops up: 
   
  PGPkeys (context menu): Key Properties                Key Properties
 
  Notice that the Checksum: listed is Encrypted (2 bytes), meaning that the secret key uses the older, deprecated 16 bit checksum instead of the newer 20 byte SHA1 hash. Depending on the key type, you might also see Plaintext (2 bytes), which is a variant on the older 16 bit checksum. If you see Encrypted SHA1 Hash (20 bytes) instead, there's no need to convert the key -- it already uses the new SHA1 hash. (Note: if you're using PGP 8.0.2, you won't see the Checksum: field -- it's unique to PGP 6.5.8ckt build 09.)
   
2. Change the Passphrase on the Secret Key
   
  Hit the Change Passphrase button. PGP first prompts you for the current passphrase:
   
  PGP Enter Passphrase for Key
   
  Once you've typed in your current passphrase, PGP allows you to enter a new passphrase:
   
  PGP Enter Confirmed Passphrase
   
  You will have to enter a passphrase that's different from the current one (you can't re-use the same passphrase). When you've finished typing your new passphrase, hit the OK button to save your changes. PGP confirms the change of passphrase.
   
  PGP: The passphrase has been changed.
   
  More importantly, though, once you're returned to the Key Properties box, you should see that the Checksum: listed is Encrypted SHA1 Hash (20 bytes). (Again, if you're using PGP 8.0.2, you won't see the Checksum: field -- it's found only in PGP 6.5.8ckt build 09.)
   
  Remember, though: PGP only allows you to convert older format keys to use the new SHA1 hash for secret key material. It does not provide any way to revert back to the older 16 bit checksum. To do that, you'll need to use GnuPG 1.0.7 or later, which we'll discuss later.

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.

   
  Using GnuPG to Analyze & Convert Keys
   
  GnuPG 1.0.7 and later can be used to analyze secret keys, just like PGP 6.5.8ckt build 09 and PGPdump. GnuPG can also be used to convert old format keys that use the 16 bit checksum to use the newer SHA1 hash. Importantly, though, recent versions of GnuPG can convert keys that use the new SHA1 hash to revert back to the older 16 bit checksum, which you can't do with any version of PGP.

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.

   
Summary of Secret Key Properties
   
  Earlier we provided several handy tables to identify the newer versions of PGP and GnuPG that are capable of using the 20 byte SHA1 hash for secret key material. Those tables were designed for easy reference, but did not provide a complete picture of the use of the SHA1 hash in PGP and GnuPG.

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.

   
 
PGP 6.5.8ckt 09 b3
Key Type S2K Checksum Protect Cipher
DH/DSS S2K Iterated Salted Encrypted SHA1 Hash (20 bytes) AES256
RSAv4 S2K Iterated Salted Encrypted SHA1 Hash (20 bytes) AES256
RSAv3 S2K Simple Plaintext (2 bytes) IDEA
ElGamal S2K Iterated Salted Encrypted SHA1 Hash (20 bytes) AES256
Notes: PGP 6.5.8ckt build 09 uses the SHA1 hash on all keys that it generates, except RSAv3 keys. Keys generated with older versions of PGP are left as they were by PGP 6.5.8ckt build 09. Even when PGP 6.5.8ckt build 09 incorporates older keyrings, the older 2 byte secret key checksum is left as is on those keys. This version of PGP, however, will convert keys from the old 16 bit checksum to the new 20 byte SHA1 hash when the passphrase on the key is changed (see above for details on how to do it).
 
PGP 6.5.8ckt 08
Key Type S2K Checksum Protect Cipher
DH/DSS S2K Iterated Salted Encrypted (2 bytes) AES256
RSAv4 S2K Iterated Salted Encrypted (2 bytes) AES256
RSAv3 S2K Simple Plaintext (2 bytes) IDEA
ElGamal S2K Iterated Salted Encrypted (2 bytes) AES256
Notes: PGP 6.5.8ckt build 09 uses the older 2 byte checksum (encrypted or plaintext) on all keys that it generates. It cannot use secret keys that make use of the newer SHA1 hash. If you attempt to use a secret key with the SHA1 hash, PGP 6.5.8ckt build 08 will generate an error.
 
PGP 8.0.2
Key Type S2K Checksum Protect Cipher
DH/DSS S2K Iterated Salted Encrypted SHA1 Hash (20 bytes) AES256
RSAv4 S2K Simple  Plaintext (2 bytes) AES256
RSAv3 S2K Simple  Plaintext (2 bytes) AES256
Notes: PGP 8.0.2 uses the SHA1 hash on DH/DSS keys that it generates, but still uses the older 2 byte checksum format for RSAv3 and RSAv4 keys that it generates. It can handle all secret keys that use the newer SHA1 hash. Keys generated with older versions of PGP are left as they were by PGP 8.0.2. Even when PGP 8.0.2 incorporates older keyrings, the older 2 byte secret key checksum is left as is on those keys. This version of PGP, however, will convert keys from the old 16 bit checksum to the new 20 byte SHA1 hash when the passphrase on the key is changed (see above for details on how to do it).
 
PGP 8.0.0
Key Type S2K Checksum Protect Cipher
DH/DSS S2K Iterated Salted Encrypted (2 bytes) AES256
RSAv4 S2K Simple Plaintext (2 bytes) AES256
RSAv3 S2K Simple Plaintext (2 bytes) AES256
Notes: PGP 8.0.0 can use (interpret) secret keys that make use of the SHA1 hash, but on the keys it generates it uses the older 2 byte checksum format (encrypted or plaintext).
 
PGP 7.x
Key Type S2K Checksum Protect Cipher
DH/DSS S2K Iterated Salted Encrypted (2 bytes) CAST5
RSAv4 S2K Simple  Plaintext (2 bytes) CAST5
RSAv3 S2K Simple  Plaintext (2 bytes) CAST5
Notes: PGP 7.x cannot use keys with the newer SHA1 hash. On keys that it generates, the secret keys make use of the older 2 byte checksum (encrypted or plaintext). If you attempt to use a secret key with the SHA1 hash, PGP 7.x will generate an error.
 
PGP 5.0 - PGP 6.5.x
Key Type S2K Checksum Protect Cipher
DH/DSS S2K Iterated Salted Encrypted (2 bytes) CAST5
RSAv3 S2K Simple Plaintext (2 bytes) IDEA
Notes: PGP 5.0, PGP 5.5.x, PGP 6.0.x, and PGP 6.5.x cannot use keys with the newer SHA1 hash. On keys that these versions of PGP generate, the secret keys make use of the older 2 byte checksum (encrypted or plaintext). If you attempt to use a secret key with the SHA1 hash, these versions of PGP will generate an error.
 
PGP 2.6.x
Key Type S2K Checksum Protect Cipher
RSAv3 S2K Simple Plaintext (2 bytes) IDEA
Notes: No version of PGP 2.6.x can use keys with the newer SHA1 hash. On keys that it generates, the secret keys make use of the older 2 byte checksum (plaintext). If you attempt to use a secret key with the SHA1 hash, PGP 2.6.x will generate an error.
 
GPG 1.0.7 - GPG 1.3.x
Key Type S2K Checksum Protect Cipher
DH/DSS S2K Iterated Salted Encrypted SHA1 Hash (20 bytes) CAST5
RSAv4 S2K Iterated Salted Encrypted SHA1 Hash (20 bytes) CAST5
RSAv3 S2K Iterated Salted Encrypted (2 bytes) CAST5
Notes: GPG 1.0.7, GPG 1.1.9.x, GPG 1.2.x, and GPG 1.3.x all use the SHA1 hash on keys that they generate, with exception of RSAv3 keys (when the RSA v3 Key Generation Patch has been applied, such as the case is with the GPG "Nullify" builds). Keys generated with older versions of GnuPG are left as they were by GnuPG 1.0.7 and later. Even when GnuPG 1.0.7 and later incorporate older keyrings, the older 2 byte secret key checksum is left as is on those keys. These versions of GnuPG,  however, will convert keys from the old 16 bit checksum to the new 20 byte SHA1 hash when the passphrase on the key is changed; they can also convert keys with the 20 byte SHA1 hash to the older 16 bit checksum, unlike any version of PGP (see below for details on how to perform both of these coversions).
 
GPG 1.0.6
Key Type S2K Checksum Protect Cipher
DH/DSS S2K Iterated Salted Encrypted (2 bytes) CAST5
Notes: GPG 1.0.6 (and earlier) cannot use keys with the newer SHA1 hash. On keys that it generates, the secret keys make use of the older 2 byte checksum (encrypted). If you attempt to use a secret key with the SHA1 hash, GPG 1.0.6 will generate an error.
   
 
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    
   
Using GnuPG to Analyze & Convert Keys
   
  Starting with GnuPG 1.0.7, GnuPG provides support for the new 20 byte SHA1 hash of secret key material. More importantly, though, GnuPG 1.0.7 and later can be used to convert secret keys that use the older 2 byte (16 bit) checksum to the SHA1 hash format. These recent versions of GnuPG can also be used to revert secret keys that use the SHA1 hash back to the older checksum format, something which no version of PGP can do (not even PGP 6.5.8ckt build 09). 

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.

   
  Analyzing Secret Keys
   
  You can use the --list-packets command in GnuPG to analyze secret keys in order to determine whether they use the new 20 byte SHA1 hash for secret key material or the older 16 bit checksum. 
   
  You'll need to export the secret key(s) to be analyzed to an .ASC key file first. Once you've done that, use the --list-packets command on the key file:
   
 
              
D:\Programs\gnupg> gpg --list-packets my-key.asc

:secret key packet:
        version 4, algo 1, created 1050121319, expires 0
        skey[0]: [4096 bits]
        skey[1]: [6 bits]
        iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: e120bafd7f06f58e

        protect count: 96
        protect IV:  a7 f6 90 ad 39 b9 a1 2b 02 e4 6e 41 cc 10 d4 47
        encrypted stuff follows
:user ID packet: "Eric L. Howes "
:secret sub key packet:
        version 4, algo 1, created 1050121468, expires 0
        skey[0]: [4096 bits]
        skey[1]: [6 bits]
        iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 04c1447626d59160

        protect count: 96
        protect IV:  da 46 a4 a6 54 fc 9b b9 23 8c 4f 5f 02 58 b1 6f
        encrypted stuff follows
   
  The example above is an RSAv4 key, which is comprised of an RSA signing key and an RSA encrypting subkey. DH/DSS keys (known to GnuPG as DSA/ElGamal keys) also have a signing key (DSA/DSS) and encrypting subkey (DH/ElGamal); RSAv3 keys (known to PGP as RSA Legacy Keys) have only a single signing and encrypting key. 

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).

   
  One final note about the results you see above: the --list-packets command provides much other useful information, including the "protect cipher"  -- algo: 9 -- and the "S2K"  -- iter+salt S2K. We saw both of these bits of information on the Key Properties box in PGP 6.5.8ckt build 09 above, and we can also find them here. The "S2K" is "S2K Iterated Salted." The "protect cipher" is a bit more obscure -- it's "AES128," which we can tell by the algorithm ID 7. Here's a handy chart for converting the specified symmetric algorithm ID to the symmetric cipher name:
   
 
Algo ID Cipher
1 IDEA
2 3DES
3 CAST5
4 Blowfish
7 AES (128)
8 AES192
9 AES256
10 Twofish
   
  For more information on the "S2K" and "protect cipher," see the "What's in a Secret Key" section above.
   
  Converting Secret Keys from SHA1 Hash to 16 bit Checksum (New to Old)
   
  If you're running a more recent version of PGP or GnuPG and plan to export one of your secret keys to import and re-use in an earlier version of PGP or GnuPG, you'll first need to convert your secret keys to a format that those older programs recognize. To perform that conversion, use the --simple-sk-checksum option in conjunction with the --edit-key | passwd command. This process converts the key integrity check from the newer 20 byte SHA1 hash format to the older 16 bit checksum format. Once you convert the secret keys, you can export them for re-use in an older version of PGP or GnuPG.

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.

   
 
 
D:\Programs\gnupg>gpg --simple-sk-checksum --edit-key george

gpg (GnuPG) 1.0.7; Copyright (C) 2002 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

Secret key is available.

pub 1024D/0A484ECB created: 2002-05-26 expires: never trust: u/u
sub 2048g/C31174A2 created: 2002-05-26 expires: never
(1). George P. Gumbel <gpgumbel@cowtownu.edu>

Command>
 
   
  Next, change the passphrase on your secret key with the passwd command. You'll have to enter the current passphrase before you can change it.
   
 
 
Command> passwd

Key is protected.

You need a passphrase to unlock the secret key for
user: "George P. Gumbel <gpgumbel@cowtownu.edu>"
1024-bit DSA key, ID 0A484ECB, created 2002-05-26

Enter passphrase: My_31337_Passphrase

Enter the new passphrase for this secret key.

Enter passphrase: My_31337_Passphrase
Repeat passphrase: My_31337_Passphrase

gpg: generating the deprecated 16-bit checksum for secret key protection
gpg: generating the deprecated 16-bit checksum for secret key protection

Command> save

D:\Programs\gnupg>
 
   
  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. Once you enter a "new" passphrase, GnuPG generates the "deprecated 16-bit checksum" that older versions of PGP and GnuPG recognize. Make sure to save your changes. Now 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.

It is possible to use the --simple-sk-checksum option in the OPTIONS file (GnuPG 1.0.7/GnuPG 1.1.9.1) or GPG.CONF file (GnuPG 1.1.9.2/GnuPG 1.2.x/GnuPG 1.3.x). With --simple-sk-checksum in the OPTIONS or GPG.CONF file, any new keys generated with GnuPG will use the older key integrity format. Keys that were generated and placed on your keyring before --simple-sk-checksum was added to the OPTIONS or GPG.CONF file must still be converted with the --edit-key | passwd command, as described above (though you won't need to use the --simple-sk-checksum option with the --edit-key command since that option is already in the OPTIONS/GPG.CONF file).
   
  Converting Secret Keys from 16 bit Checksum to SHA1 Hash (Old to New)
   
  If you import secret keys created in an older version on GnuPG or PGP onto your GnuPG key rings and you want those secret keys to use the new 20 byte SHA1 hash instead of the older 16 bit (2 byte) checksum, you can convert those secret keys with GnuPG 1.0.7 and later. Also, if you've converted secret keys from the SHA1 hash to the 16 bit checksum and wish to change your secret key's integrity check back to the SHA1 hash format (which provides protection against certain kinds of attacks), you can do that as well.

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.)

   
 
 
D:\Programs\gnupg>gpg --edit-key 0x
0A484ECB

gpg (GnuPG) 1.0.7; Copyright (C) 2002 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

Secret key is available.

pub 1024D/0A484ECB created: 2002-05-26 expires: never trust: u/u
sub 2048g/C31174A2 created: 2002-05-26 expires: never
(1). George P. Gumbel <gpgumbel@cowtownu.edu>


Command> passwd

Key is protected.

You need a passphrase to unlock the secret key for
user: "George P. Gumbel <gpgumbel@cowtownu.edu>"
1024-bit DSA key, ID 0A484ECB, created 2002-05-26


Enter passphrase: My_31337_Passphrase

Enter the new passphrase for this secret key.

Enter passphrase: My_31337_Passphrase
Repeat passphrase: My_31337_Passphrase

Command> save

D:\Programs\gnupg>
 
   
  Once you save your changes, GnuPG will change the format of the secret key integrity check to the newer SHA1 hash format. Unlike the process of converting the secret keys from the SHA1 hash to the 16 bit checksum, this time GnuPG does not explicitly notify us that it has changed the integrity protection format on the secret key.

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.
   
Notes
   
  From Imad's ReadMe for PGP 6.5.8ckt build 09 beta 1
   
 
New secret key format with encrypted SHA1 hash
of the key material.  This is only supported
by GnuPG 1.0.7 or better.  To convert your existing
v4 key to this new format change it's passphrase.
This will guard your secret key against Klima/Rosa
style key tempering.  This new format is the recommended
one according to RFC2440, the older 2 bytes checksum
formats are now deprecated.

To revert to the older deprecated format, use GPG 1.0.7.

To do so:

a) Export the key, including the secret part from PGP.
b) Add the followings to your GnuPG options file:
   simple-sk-checksum
   allow-secret-key-import
   compress-algo 1
c) import the key into GnuPG.
d) Change the passphrase in GnuPG.
e) Export it, and it should be in the old format.
   
  Relevant Sections of RFC2440bis-07
   
 
5.5.3. Secret Key Packet Formats

   The Secret Key and Secret Subkey packets contain all the data of the
   Public Key and Public Subkey packets, with additional
   algorithm-specific secret key data appended, in encrypted form.

   The packet contains:

    [...]

     - One octet indicating string-to-key (S2K) usage conventions.  0
       indicates that the secret key data is not encrypted.  255 or 254
       indicates that a string-to-key specifier is being given.  Any
       other value is a symmetric-key encryption algorithm identifier.

     - [Optional] If string-to-key usage octet was 255 or 254, a
       one-octet symmetric encryption algorithm.

     - [Optional] If string-to-key usage octet was 255 or 254, a
       string-to-key specifier.  The length of the string-to-key
       specifier is implied by its type, as described above.

    [...]

     - If the string-to-key (S2K) usage octet was 255, then a two-octet
       checksum of the plaintext of the algorithm-specific portion (sum
       of all octets, mod 65536). If the string-to-key usage octet was
       254, then a 20-octet SHA-1 hash of the plaintext of the
       algorithm-specific portion. This checksum or hash is encrypted
       together with the algorithm-specific fields.

   [...]

   The 16-bit checksum that follows the algorithm-specific portion is
   the algebraic sum, mod 65536, of the plaintext of all the
   algorithm-specific octets (including MPI prefix and data).  With V3
   keys, the checksum is stored in the clear.  With V4 keys, the
   checksum is encrypted like the algorithm-specific data.  This value
   is used to check that the passphrase was correct. However, this
   checksum is deprecated; an implementation SHOULD NOT use it, but
   should rather use the SHA-1 hash denoted with a usage octet of 254.
   The reason for this is that there are some attacks on the private
   key that can undetectably modify the secret key. Using a SHA-1 hash
   prevents this.      
   
  From the GnuPG 1.2.2 Man Page
   
 
--simple-sk-checksum
     Secret keys are integrity protected by using a SHA-1 checksum. This
     method will be part of an enhanced OpenPGP specification but GnuPG
     already uses it as a countermeasure against certain attacks. Old
     applications don't understand this new format, so this option may
     be used to switch back to the old behaviour. Using this this option
     bears a security risk. Note that using this option only takes
     effect when the secret key is encrypted - the simplest way to make
     this happen is to change the passphrase on the key (even changing
     it to the same value is acceptable).
   
  The Klima-Rosa Attack: from Tom McCune's "PGP Questions & Answers" Page
   
 
Private Key Vulnerability?

In March, 2001, Czech cryptologists reported a successful attack on the implementation of PGP's encryption of the private signing key. This is based on an attacker having access to your encrypted private signing key, making a specific alteration to this encrypted private key, and then having access to a subsequently signed message or file. The result is that an attacker is then able to quickly calculate your private key, and can then produce valid signatures with your private key. This attack was done using the current PGP 7.0.3 on Windows NT, and resulted in the capture and use of DSS keys. The same attack can be done with RSA keys, but PGP 7.0.3 did not allow the altered RSA keys to be used for signing, and therefore the attack failed on both traditional v3 RSA and "new format" v4 RSA keys.

Although the authors did not test this attack with earlier PGP versions, they express a "strong feeling" that this attack will also be successful on DSS keys used in prior PGP versions. I've been told that "validation tests are performed for RSA private keys prior to using them in PGP 5.0, 5.5.3, 6.0.2, 6.5.1, and 6.5.8," and that this attack should therefore also fail on RSA keys in these PGP versions. I'm told that PGP 2.6.x versions do not have such needed validation tests to prevent such an attack on your traditional RSA key, which is of particular importance because the RSA signing key is also your decryption key. [...]

If you have such an altered key on your keyring, it will not produce a verifiable signature; but if an attacker was able to access and modify your private key in the first place, he/she may well be able to later replace your altered key with the original. This attack is not known to have ever been actually exploited against a PGP user, and cannot occur if the attacker cannot gain write access to your encrypted private signing key. 
   
 
Note: Used with the kind permission of Tom McCune. See also David Ross's account of the same attack.
   
Links for PGP & GnuPG
   
  Pretty Good Privacy (PGP) 8.0.2
   
  PGP 8.0.2 can be obtained from PGP Corporation:

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

   
  PGP 6.5.8ckt
   
  PGP 6.5.8ckt build 08 and PGP 6.5.8ckt build 09 beta 3 can be downloaded from:

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.

 
  Gnu Privacy Guard (GnuPG)
 
  GnuPG can be downloaded from:

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

   
  GnuPG users may also be interested in the "Nullify" version of GnuPG:

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 
GnuPG is a command line program. There are two popular Windows shells or front-ends for GnuPG:
   
  PGPdump
   
  PGPdump was originally developed as a command line program. You can download the source from the original author, Kazuhiko Yamamoto, here:

There's a Win32 command line binary here:

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

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.

   
  More Information
   
  This web site contains other information on PGP and GnuPG that you may be interested in:
   
  Acknowledgements
   
  Thanks to Erik "Tranquilo" and Tom McCune for looking this page over and providing invaluable tips and suggestions.
   

Home [frames]        Home [no frames]

© 2000-2003 Eric L. Howes (eburger68@myrealbox.com)