Tom McCune's

   PGP Questions & Answers  

Why This PGP Q&A?

Privacy & Authenticity?

Which PGP Version Should I Use?

What Is PGP Freeware?

Windows XP Issues?

Installing PGP?

PGP Without Installation?

Can't Re-Install Version 6.0.x?

PGP 6.5.x Conflicts?

PGP 7.0 Annoyances?

PGP 8.0 Annoyances?

PGP 9.x Issues?

PGP 10 Annoyances?

Installing Multiple Versions?

Remove Right-Click Menu?

Change The Version Line?

Why Not Product X?

What About GPG?

RSA Support?

What Is CAPI?

Where is PGP 2.6.4?

How Secure Is PGP?

Only 128 Bit Encryption?

PGP 5.0 Key Generation Flaw?

ADK Security Flaw?

Private Key Vulnerability?

Windows ASCII Armor Parser Vulnerability?

PGP Viewer Vulnerability?

Otterloo Attack?

Is RSA Broken?

Chosen-Ciphertext Attack?

Is SHA1 Broken?

AES Attacks?

Is PGP 2.6.x More Secure?

What Does My Passphrase Do?

What is a Smart Card?

Encryption To Multiple Recipients?

Conventional Encryption Compatibility?

Conventional Encryption More Secure?

Best Symmetric Encryption Algorithm?

Best Signature Hash Function?

Why Such A Short Signature?

Encrypts Only Text?

Use Current Window?

Email Client Problems?

Why Can't I Read Sent Messages?

Bad, Unknown, or Invalid Signature?

Signature Verification & Word Wrap Setting?

How Many Keys Can I (Should I) Have?

 The Perfect PGP Key?

Subkeys?

Key Size & Speed?

Photo ID Compatibility?

How Do I Disable a Key?

Why So Many 2047 Bit RSA Keys?

How Do I Change My Email Address On My Key?

Can I Delete My Old Key From a Server? Revoke it?

 Key Already On Server Warning?

Searching For Keys?

Additional Key Servers?

Import Key From Email?

Import X.509 Certificate?

Why Can't I Use Old Keys?

Why Can't I Use New Keys?

PGP 7.0 Key Compatibility?

Unsupported Packet Format?

How Do I Add a Private Key To My 2.6.x Keyrings?

What Is File Wiping?

What is PGPdisk?

What is PGPnet?

 What's New In Version x.x.x?


Why This PGP Q&A?

When I began this FAQ, my primary intention was to bridge the gap between then existing PGP FAQs and the use of Windows versions of PGP.  I urge you to use the very informative PGP manuals (User's Guide and Introduction to Cryptography) as your primary source of PGP information; some frequently asked questions are not answered here because they are covered so well in the manuals.  I originally presented this as an avid user - my only related professional qualification to do so, was as a mental health professional; which permited me to assure you that interest in personal privacy (and therefore the need for encryption) is probably a sign of good mental health, rather than the paranoia we like to tease each other about.  The only other assurance offered is that I believe in the facts and opinions presented here.  If your question isn't answered either here or in the manual, I recommend checking PGP Knowledge Base Articles at PGP Online Support, and asking at the PGP Forum.  In December, 2006, I began working with PGP Corporation on a part time basis as a Backline Support Engineer; the following month, I attended and successfully completed their PGP Certified Technician class.  All material at mccune.cc are my personal property and are neither endorsed nor approved by PGP Corporation.  I welcome any and all constructive criticism as to content and accuracy.


Privacy & Authenticity?

It is important for all Internet users to understand that regular email offers no privacy, and can actually be read by many people other than who it is sent to.  Your Internet Service Provider (ISP) probably keeps a copy on its computers, copies of email sent from a networked computer (such as at work or school) are probably kept behind, and all of the Internet computers the email goes through on its way to the recipient can keep a copy.  The administrators of all these computers can read your email if they choose to, and they can send it to anyone they might want to.  The US government (and other governments) routinely intercepts email and scans it for interesting words or phrases (Echelon - Carnivore).  With PGP encryption, all of these people can have free access to your email, and still have no idea as to its content - this is real privacy!

Anyone that can intercept your email, can alter your email's content; and anyone can send email that looks as if it was sent by you.  With PGP, you can digitally sign your email: Automatically, PGP will calculate a mathematical value (called a hash) based on the exact content of your email message, and will then encrypt that value to your private key.  The recipient of your email will use their PGP software to automatically make the same calculation - if the calculations match (the recipient's software automatically will use your public key to decrypt your encrypted hash), this is proof that the message has not been altered in any way (no numbers, letters, etc. have been added, deleted, or changed).  And since only you have the private key that encrypted the hash value that was now decrypted with your public key, this indicates that only you could have made the digital signature.  So when PGP says that the signature is good, this indicates that the message is both unaltered (integrity), and from who it says it is from - this is authenticity!

These concepts apply equally to computer files of all types, whether just stored safely on your own computer, transferred over the Internet, etc.

CAUTION: A digital signature actually proves that a particular private key made the signature, rather than that a particular individual made the signature.  Although the intent is that only the owner of the private key is able to use it for signatures, he/she may have given it and it's passphrase to trusted others, may have left his/her machine running without protection while the passphrase is cached, may have had the private key and passphrase stolen, may be using software that was altered to sign other files without his/her awareness, etc.

If you are new to all this, see PGP's Introduction to Cryptography.


Which PGP Version Should I Use?

As a general rule, I suggest using the current version of PGP.  This will have all the latest features, include bug and security fixes, and may include some greater ease of use.  As long as you have the ability to use both traditional RSA and DH/DSS keys, you are set to be able to securely communicate with all other users of PGP, regardless of what operating system, or what version of PGP they use (with the unlikely exception of their using a pre 2.6.2 PGP version).

If your interest is in anonymous remailing, you will likely want/need either a 2.6.x DOS version of PGP, or  the PGP 6.5.x Command Line.

All Windows versions of PGP since 5.0, require at least a 32 bit operating system, such as Windows 9x.  PGP 7.0.x states a requirement of having at least Windows 95B (OSR2); PGP 7.1 states a minimum requirement of Windows 98.  PGP 9.6 requires Windows 2000 or above.  Although PGP 6.5.2 added Windows 2000 support for all other PGP functions, PGPnet support for Windows 2000 was only available in PGP 7.x.  Windows ME support was not added until PGP 7.0.1.   Windows XP support was added with PGP 8.0.  Windows Vista (32 bit) support was added with PGP 9.6, and Windows Vista (but not Windows XP) 64 bit support was added with PGP 9.7.  Windows XP 64 bit support was added with PGP 9.9, and Windows 7 support was added with PGP 9.12.

As of this writing, PGP Desktop 10.0.2 is the current version.  This install package contains the following components; which are enabled for use is determined by the license you purchase: Whole Disk Encryption ("full disk encryption for all data (user files, swap files, system files, hidden files, etc.) on desktops, laptops, and removable media"), NetShare ("enables teams to securely share documents on file servers by automatically and transparently encrypting the files for fine-grained group access. This approach ensures that only authorized users can read or modify files"), Virtual Disk ("provides data security for desktops and laptops, making it possible for enterprises, workgroups, and individuals to protect sensitive information without changing the existing IT infrastructure or disrupting work processes. This award winning, easy-to-use solution encrypts virtual volumes"), PGP Messaging ("automatic, transparent encryption solution for securing internal and external confidential email communication"), and PGP Zip ("A PGP Zip Archive package is a single file that is encrypted and compressed for convenient transport or backup. These archive files can hold any combination of files and/or folders, and are especially convenient for secure transport or backup").  This matrix identifies which components are enabled in various product licenses.  PGP Desktop Trial (which includes the option of installing directly as PGP Freeware level of functioning) allows you to try all the applications that are part of the PGP Desktop product for 30 days; "At the end of the trial period, any local disks that have been encrypted using PGP Whole Disk Encryption will automatically decrypt.  PGP file encryption and signing, PGP Zip, “Current Window”, and “Clipboard” functionality will continue to allow encryption, and you will still be able to use the decryption capabilities for all PGP Desktop Trial product functions, thus ensuring that any encrypted data remains accessible." 

PGP Mobile "comprehensive email and data encryption for Windows Mobile smartphones and storage cards that provides powerful protection for the data stored, in transit, and shared with others"

PGP Support Package for BlackBerry "enables enterprises to extend market-leading PGP messaging security solutions for laptops and desktops to BlackBerry smartphones"

PGP Endpoint "provides built-in security that detects, authorizes, and secures removable storage devices and media (such as USB drives, CDs, and DVDs)"

PGP Universal "The first product built on PGP Corporation's Self-Managing Security Architecture.  By shifting the burden of protecting critical information from users' desktops to the network, PGP Universal makes it possible to automatically and transparently provide end-to-end email security."

PGP Command Line "enables organizations to automate encryption and signing of sensitive consumer and business information, securing it for local storage or transfer over the Internet."  This is not really priced for home/personal use.

No version of PGP is known to have a "backdoor" that will allow the government or anyone else access to your PGP encrypted email/files.  PGP releases the source code (complete for versions 2.6.2, 5.0, 5.5.3, 6.0.2, 6.5.1, 6.5.8, 8.x, 9.x, 10.x; and the PGPsdk 2.1.1 for the hotfixed PGP 7.1, which includes all the cryptographic functioning) of its PGP products that others freely examine for such backdoors or possible flaws - anyone finding one would have instant fame in the cryptology community.  Of course, most of us (including myself) are not capable of examining such source code.  If your paranoia is strong enough, you may want to take into account that 8.0 is the first version produced by PGP Corporation, 7.1 is the last version before the 9/11/01 terrorist attacks on the USA, 7.0.3 is the last version released before Phil Zimmermann (founder of PGP) left NAI, and 5.5.3 was the last version of PGP before it was purchased by NAI.

Regarding the other builds, such as the "ii", "a" and ckt: These were all builds based on the legally exported printed source code of official PGP versions (starting with PGP 6.5.8, source code is released in binary form).  The international "i" people scanned the source code and then made it available for others to compile their own builds.  Preston's "a" and Imad's ckt builds were compiled from this source code.  The "i" builds were specifically built with the purpose of making PGP available to the rest of the world that could not legally obtain PGP by export from the US/Canada.  Preston made his compiled "a" build available to US/Canada residents for personal use - it resolved one or two 5.5.3 bugs and included full RSA support.  Imad's ckt builds included multiple modifications of the official PGP source code, including very large key support.  Unlike the "i" builds, the ckt and "a" builds have not had the approval of NAI or PGP Corp., and there is controversy (but no apparent legal action) over the legality/appropriateness of their use.

I have always considered all third party builds to be less secure than the official PGP software for this reason: Any unknown problem or possible backdoor, etc., will automatically be included in any other build from that same source code; and any of the other builds might have additional problems due to a scanning error, compilation error, programming error, or even the possibility of some purposely inserted hidden weakness.  Additionally, those third party builds were not from source code designed to work properly on current Windows software.


What is PGP Freeware?

Prior to PGP 2.7 (with the exception of Viacrypt 2.4), all versions of PGP were "freeware," meaning that the software was freely given away for all to use - there was just one official build of PGP 2.6.2, and it was "freeware."  But PGP used patented algorithms (IDEA and RSA) that required royalty payments if used for commercial purposes; to help make PGP available for commercial purposes, a company (Viacrypt) was licensed to sell commercial builds of PGP (versions 2.7.x and 4.x - as well as the earlier 2.4).  PGP versions 5.5 to 7.1.1 had three official builds of each version number: "Freeware" builds are those that continued to be given away, and were not to be used for commercial purposes.  The commercial builds included Personal Security (previously named Personal Privacy) for individual users, and Corporate Desktop (previously named Desktop Security) which had provisions for setting up how PGP is used throughout an organization.  The original PGP 5.0 freeware (which was actually named Personal Privacy) included the ability to use, but not generate, RSA keys.  Except when using CAPI with PGP 6.0.x, no subsequent official "Freeware" version had any ability to use RSA keys, until "6.5.1freeware" which could both use and generate RSA keys (using RSAREF, which was allowed to be used non-commercially).  Because of the issue of royalty payments for the patented IDEA and RSA, these "Freeware" versions have emphasized the use of royalty free DH/DSS keys (and some emphasis on using royalty free CAST instead of IDEA).  PGP 8.x products all functioned as the Freeware product until you entered the appropriate license number to activate the PGP Personal Desktop, PGP Workgroup Desktop, or PGP Corporate Desktop level of components.  The PGP 9.x and 10.x Trial software gives you 30 days of full functioning; it then becomes the Freeware level of functioning, including email proxy automatic decryption (email encryption then requires Current Window usage); the Trial version can be directly installed as the Freeware if you wish to do so.  The security level of using a 2048 bit RSA key (or a 2048 bit DH key, etc.) is the same, regardless of using the Freeware, Home, Professional, or Corporate/Enterprise build of the PGP product.  It was common for people to confuse "freeware" PGP (such as the "i", "a", and ckt builds) with the official "Freeware" versions of PGP.


Windows XP Issues?

PGP 8.0 is the first version with full Windows XP compatibility.  PGP 7.5 was to add Windows XP support, but due to the reorganization of NAI, it never made it out of production.  Windows XP 64 bit support is added with PGP 9.9.

The basic functions of PGP 6.5.x and 7.x versions **appear** to work properly in WinXP, if the PGPnet/PGPvpn component (PGPfire may also be a problem) is not installed - DO NOT install the PGPnet or PGPvpn component on Windows XP.  Some PGP 7.0.3 users reported having an 'IP Stack Disabled' problem when having installed the PGPnet component, but being able to resolve it by running the command "sc config ipsec start= system" at the command prompt (some people needed to use Microsoft's How to Reset Internet Protocol (TCP/IP) in Windows XP) - it was also reported that this would then even let you use the PGP Personal Firewall.  If you made the mistake of installing PGPnet, PGPvpn, or PGPfire, and needed to remove it, Microsoft advised the use of System Restore - they warned against attempting to resolve this by uninstalling PGP, because doing so “uninstalls the TCP/IP stack, and the TCP/IP stack does not support manual reinstallation.”  However, there was also report that the above command would resolve this resulting uninstall problem.  There were problems with the PGPdisk drive not appearing in Windows Explorer; this was fixed as of PGP 7.1.1 - reported work arounds for earlier PGP versions: 1) Mount the PGPdisk volume, use Ctrl-Alt-Delete to bring up Windows Task Manager, End the Explorer.exe process, and then reopen Windows Explorer.  2) "When you create a new PGP disk, select the "advanced" options at the second page of the wizard (disk location and size). Instead of mounting it as a drive with a letter, select 'as a directory on an NTFS volume.' But be sure to use the FAT32 option for filesystem format rather than NTFS- the disk won't be created if you don't."  There were problems with the Outlook and Outlook Express plug-ins and their expected PGP buttons (icons) on the tool bars (I'm not aware of a fix for these plug-in problems, but the PGP Current Window options would work).  PGP 7.1.x was reported to have preliminary work for support of Outlook XP, but Outlook XP was not officially supported.  Windows XP users having error messages about PGPsdk Service could use the relevant part of PGP 7.0 Annoyances.  If you were having error messages about "PGP memory page locking driver is not functioning correctly" after upgrading to Windows XP from Windows 9x, PGP needed to be reinstalled.  Some people were not able to install PGP 7.x after installing Windows XP's Service Pack 1, but there were work arounds for this.


Installing PGP?

PGP 9.x and 10.x installs rather automatically without user intervention. 

Perhaps the most common PGP 9.x install problem was loss of Internet access after the installation.  This was usually caused by having conflict with already installed AntiVirus or firewall software.  If you are having such difficulty, read the installed Release Notes about known specific conflicts.  However, most people successfully resolve this by uninstalling and re-installing their AV and/or firewall software; for some, it was necessary to uninstall the AV and/or firewall software before the PGP 9.0.x installation.  If you only lost email usage, it was likely because of your using email AV scanning, and would work properly if you disabled email AV scanning.  If upgrading from a Windows PGP version less than 8.0, it was necessary to uninstall that PGP version before running the PGP 9.0.x installation file.  When installing PGP 9.12 on 64 bit Windows 7, I had to disable the McAfee Proxy Service for use of PGP Messaging.

Save the email giving you the URL for your original PGP download and/or bookmark the URL.  The minor version upgrades (such as 9.0 to 9.0.1, 9.0.2, etc.) were free upgrades and could be downloaded (I'm not sure this is still current) from that same URL when they became available.  In the early 9.0.x versions, I had some problems doing the automatic minor version upgrades through PGPtray - Check for Updates, and did not recommend its use, but this has not  happened for some time.

PGP default settings are secure.  Do not make changes unless you have specific reasons for doing so, and you really know what you are doing.

Installing PGP 8.0 Freeware is an excellent guide to installing the 8.x PGP products.  PGP 6.0.x has an Installation Guide that should be quite helpful for the first time PGP user.  PGPnet has sometimes been reported to cause problems, so you may not want to install that component unless you really have plans for using it - DO NOT install those old PGPnet/PGPvpn and/or PGPfire components on Windows XP, Windows Vista, or Windows 7. 

Prior to PGP 7.0, if you wanted to add an additional PGP component to your existing PGP installation, you had to first uninstall, and then do a reinstallation.  For  PGP 7.0 through 8.1, you can do a basic PGP installation - then if you later decide you want to add PGPdisk or PGPnet, etc., you can run the original install file to add additional components.

For PGP 6.0.2 through 8.1, installing a new PGP version will automatically uninstall a prior Windows version (5.5 and above), but I still prefered to first uninstall in this manner:

In PGP versions prior to 9.0, before generating your first PGP key, I suggested changing some of PGP Preferences/Options, available as a menu option when you click on PGPtray:
When generating your PGP key(s), unless you have a good reason not to, please enter your correct name and email address - it makes it a lot easier for others to find and use your public key for encryption to you.  When closing PGPkeys, accept the offer to make a backup of your keyrings.  I recommend also making a backup to removable media that you keep in a safe place - PGP keyrings can be copied just as any other files (it may be necessary to close PGPnet, PGPkeys, and ICQ; and purge any cached passphrase).  With PGP 9.x and 10.x, you can backup your keyrings by clicking on the PGP Desktop PGP Keys control box, and selecting Export from the  File menu.  Many PGP users highly recommend that you create a Key Revocation Certificate immediately after generating a new key.

Just to satisfy my own personal preference, in versions prior to 9.0, I renamed PGPlog.exe so that it wouldn't be used.

CAUTION: When using the Windows power saving option of Hibernation, be aware that this saves the content of your RAM to your hard disk.  PGP takes measures to prevent either your passphrase or private key from being written to the hard disk from this.  The contents of PGP's Secure Viewer will also be prevented from being written to the hard disk in this manner, but the contents of the PGP Viewer will be written to disk when entering Hibernation.  I suggest that Hibernation users set PGP versions prior to 9.0 to use the Secure Viewer (PGPtray-Options-Email tab) and/or regularly disable (and later re-enable) Hibernation, which will result in Windows deleting Hiberfil.sys - which should result in all the Hibernation written information being overwritten, IF you have PGP set to "automatically wipe on delete" (PGPtray-Options-General tab) - the PGP 9.x and 10.x setting is "automatically shred when emptying the Windows Recycle Bin (PGP Options-Shredding tab).


PGP Without Installation?

With Windows PGP versions 5.x and 6.x, it is possible to use PGP without the formal installation process.  For any of these versions, you can copy the EXE and DLL files (for 5.0, be sure to include bn.dll, simple.dll, and keydb.dll) of a particular version to a folder on either the hard drive, or removable media (such as a CD, or a flash memory USB drive), and run PGPtray from that folder.  I've tried this with the PGP files placed on a CD, with Windows 98SE and Windows NT4, with neither machine having PGP installed (when I tried this on a WinXP machine with PGP 7.1.1 installed, it only worked for 5.0).  In addition to the usual use of PGPtray, PGPkeys (for 5.0, the file had to be launched directly, rather than from PGPtray) and PGPtools worked as expected, but PGPdisk would not run.  With PGP 6.x, there was an initial message about memory locking not working; and this apparently caused a registry entry.  But when I made the choice to not have this reported again, and deleted that registry entry, it did not reappear until PGPtray was closed and reopened.  On the NT machine, each time the 6.x PGPtray was run, there was an entry made in the System Log about the failed memory locking.  PGP 5.0 caused registry entries, at least on the NT machine.  Use of PGPtools apparently did make a few minor registry entries; these entries pointed to the CD-ROM drive, and also appeared related to my designating pgp.exe as the program to always open pgp extension files.  Using PGP in this manner also created some PGP preferences files on the hard drive (do a file search for *pgp*.* to find them).  One needs to remember that doing this without PGP's memory locking leaves open the possibility of your passphrase winding up on the hard disk in your swap file.  If using this for use of PGP on a machine that is not yours, there is also the chance that the machine might copy your private key and/or record your passphrase.


Can't Re-Install Version 6.0.x?

A number of us had been unable to successfully re-install 6.0.x after trying 6.5.x - the keyring settings wouldn't stick.  It turned out that when un-installing PGP, not all the files had been removed; and that when installing an earlier version, the newer files were not overwritten - the newer files of 6.5.x are not compatible with 6.0.x.  To resolve this, un-install the version that is not working properly, go to Windows\System, delete the remaining PGP DLLs (such as PGPdskSE.dll, pgpsdkUI.dll, pgpsdkNL.dll and pgp_sdk.dll), and then install PGP.


PGP 6.5.x Conflicts?

Many PGP 6.5.x users have experienced a variety of annoying conflicts, most of which could be avoided by closing PGPtray.  This included not being able to use Microsoft accessories of Hearts, Solitaire, Free Cell, and/or Character Map.  Less frequently experienced, but normally also avoided by closing PGPtray, was inability to print. Also less frequently, and sometimes requiring a reboot, was inability to redial one's ISP.  Some 6.5.2a users reported this version having resolved some or all of these conflicts.  Since I had experienced all of the above (between usage of my old Win95b machine, and my subsequent Win98SE machine), and 6.5.2a continued to leave my conflicts unresolved, I continued to use PGP 6.0.2 Personal Privacy.  After trying 6.5.3 and still having these conflicts, NAI provided me with a file replacementtthat successfully eliminated these problems with each 6.5.x version that I subsequently installed (I don't know if the dialing problem would have been corrected though, because I then used a cable modem connection).

Norton AntiVirus 2000 users were not able to scan the Master Boot Record when doing a full disk scan.


PGP 7.0 Annoyances?

The PGP 7.0.3 (and above) versions have most of the following fixed.  PGP Desktop Security 7.0.3 (messages, etc., showed the version line as 7.0.1) was such an improvement over 7.0, that if I had tried it first, this section may never have been written.

Issues that remain with PGP 7.0.3:

PGP 8.0 Annoyances?



PGP 9.x Issues?

When wanting to use the Email proxy for auto encryption and/or signing, but keeping incoming email encrypted, while also using SSL for incoming email, try this: Use separate POP and SMTP services as above, set your email client to use SLL for POP, set the email client's SMTP to not use SSL; in the PGP policy for the POP server, click on the server, and place a check for ignore SSL for the POP server. Of course, this requires your ISP to have SSL available for POP.  If you also have SSL available for SMTP, you may want to set the SMTP service to require SSL.
                From:   <key>fastKeyGen</key>
                            <true></true>
                To:       <key>fastKeyGen</key>
                            <false></false>
                From:    <key>wordWrapEnable</key>
                            <true></true>
                            <key>wordWrapWidth</key>
                            <integer>72</integer>


PGP 10 Annoyances?



Installing Multiple Versions?

Sometimes people wanted more than one version of PGP installed at the same time.  Often they had wanted a 2.6.x version for anonymous remailing, or due to a feeling of greater trust in it not having some kind of backdoor; while also wanting a Windows version for its newer features and greater ease of use.  Some of us had wanted a 6.x version installed for its newer features, but also wanted a 5.5.x version installed for its handling of RSA keys larger than 2048 bits.  I once had 2.6.2, 4.0, 5.5.3, and 6.0.2 all installed at the same time.

There is no conflict in having 2.6.x and any Windows version installed at the same time.  There is no problem with 4.x being installed at the same time as any other version.  Both 5.0 and 5.5.x can be installed at the same time as any other version up to at least 6.5.8.  6.0.x and 6.5.x CAN NOT be installed at the same time (see next paragraph for possible work arounds).  Any time two PGP Windows versions of 5.0 and later are installed at the same time, the Windows Explorer PGP options will be those of the last one installed.  Most 6.x versions (if my memory is correct, 6.0 is an exception) will insist on uninstalling any prior 5.5 or later version that is already installed; so if you want a 5.5.x version and a 6.x version installed at the same time, the 6.x.x version may have to be installed first.  Interestingly, none of these 6.x versions (or 7.0) will uninstall 5.0 if you additionally install one of them - the 5.0 PGPtray can even run at the same time as the 7.0 PGPtray.

I'm told of two methods others have used to have PGP 6.0.x and 6.5.x installed at the same time.  The first way is to install one of the two versions, and then move the PGP DLLs from Windows\System (or Windows\System32) to the PGP install folder before installing the second PGP version.  The second way is described as installing 6.0.2i and then installing 6.5.8 Freeware before doing the reboot required for the 6.0.2i install.  This appears to work fine; with being able to use PGPdisk from 6.0.2i, using PGP 6.5.8 normally, and even being able to use 6.0.2i for encryption/signing, etc.  The second method results in the 6.5.8 files of pgpsdkUI.dll, pgpsdkNL.dll, and pgp_sdk.dll overwriting the 6.0.2i files of the same name - I don't know if this has adverse security implications.

Other than testing with 5.0, I have not tested installing any other Windows version of PGP while also having PGP 7.0 installed - it looks like there may be PGP DLL conflicts.


Remove Right-Click Menu?

PGP versions 5.0 and above allow for easy encryption/decryption/signing of files in Windows Explorer, by using the "right-click menu."  This can easily be disabled for versions 5.5.x and 6.x, by removing pgp55mn.dll, pgp60mn.dll, or PGPmn.dll from the Windows\System folder (close and re-open Windows Explorer before doing this removal).  PGP can then still be used on files through the use of PGPtools, and the right-click menu can be re-enabled by returning the appropriate file.  There is another way (the only way I know to remove it for PGP 5.0), but which is not reversible without re-installing PGP: Any time another Windows version of PGP is installed, that second version is the one used for the right-click menu; you can then uninstall that second Windows version of PGP, and the remaining first Windows version will still be without the right-click menu.


Change The Version Line?

Many people have used a Hex Editor to edit the version line in PGP.  For 5.5.x: edit PGP55sc.dll and PGP55km.dll in Windows/System.  Do a search for 5.5. in each. In PGP 6.0.x, search for 6.0 in PGP60sc.dll and PGP60cl.dll. In 6.5.x, edit PGPsc.dll and PGPcl.dll.  In PGP 7.x and 8.x, edit PGPkeys.exe and PGPsc.dll (this one needs to be copied into another directory for editing, and copied back to Windows\System from either DOS mode or Safe Mode - Windows 2000 users may want to use the Microsoft File-In-Use Replace Utility).  In the right side view, you can overwrite the "for non commercial, etc." with spaces or other text, but don't just select and delete anything, or write beyond the text already there.  Be sure to close PGPtray before starting this - not necessary in PGP 7.x and 8.x.  If you use one of the official PGP email plug-ins, you may also want to edit the version line in the DLL for that plug-in (named something like PGPExch.dll or PGPOE.dll).  I've done this with Hex Workshop.


Why Not Product X?

PGP includes these important features:


What About GPG?

"GnuPG is a complete and free replacement for PGP."  GPG (GNU Privacy Guard) is a PGP compatible alternative based on the OpenPGP standard.  It has received funding from the German Federal Ministry of Economics and Technology, and there are two great reasons to consider it: It is completely open source software that can be peer reviewed for any security weaknesses; and it is absolutely free to use for both commercial and noncommercial purposes.  Although designed for command line operating systems such as Linux, it has been ported for 32 bit Windows use.  GPG includes all the usual PGP email and file encryption/signing functions, but none of the additional PGP components such as PGP Virtual Disk, Self Decrypting Archives, Email Proxy and Whole Disk Encryption.

Although now appearing to be a feasible alternative, Windows users will tend to prefer PGP because it is what we expect in Windows software, with easy installation, and a complete GUI (graphical user interface).   A major issue for Windows users, is that when GPG is used in Windows, it does not use memory locking to prevent your passphrase from being saved to your hard disk via the swap/paging file.

I suggest that interested Windows users visit  Gnupg-users and Gpg4win.  I've not tried them, but there is a Pegasus Mail plug-in, an Outlook plug-in, and the Enigmail extension for Mozilla products.


RSA Support?

All versions of PGP prior to version 5.0, use only traditional v3 RSA keys.  In version 5.0, PGP introduced the use of DH/DSS keys; and the ability to use RSA keys was not included unless it was indicated as having RSA Support.  This change in emphasis from RSA key usage to DH/DSS key usage appears to have been an economic issue - RSA remained patented (until Sept., 2000) and required payment of a royalty fee if used commercially, but both DH and DSS were royalty free.  The original 5.0 freeware included the ability to use, but not generate RSA keys, up to 2048 bits.  Until 6.x, all subsequent official Freeware had no ability to use RSA keys.  6.0.x Freeware has the ability to use standard size RSA keys, if you have Internet Explorer 4.x/5.x 128 bit security installed.  For an additional fee, the 5.x, and 6.0.x Personal Privacy and Business (progressively named Business Security, Email & Files, Desktop Security) versions could have RSA Support.  Since PGP 6.5.x, all versions have included full RSA support.  No official PGP software has ever generated Legacy RSA keys larger than 2048 bits, but 5.5.x versions with RSA Support can use RSA keys up to 8192 bits (6.x versions with RSA Support are limited to 2048 bit RSA keys).  RSA enabled Personal Privacy 5.5.x was not able to generate RSA keys, but RSA enabled Personal Privacy 6.x can generate RSA keys (except for 6.0.1).  The third party builds of these 5.x and 6.x versions (such as "a", "i", and ckt) include an emphasis on having RSA Support.  In addition to the ability to generate (up to 2048 bits) and use (up to 4096 bits) traditional "legacy" RSA keys, PGP 7.0 (and above) has the ability to generate and use "new format" (v4) RSA keys up to 4096 bits, with features previously reserved to DH/DSS keys.  PGP 9.x and 10.x can use, but cannot generate traditional v3 RSA  keys.


What Is CAPI?

A major new feature of PGP 6.0.x: "Limited and **unsupported** RSA functionality is available in the Windows versions (ONLY) of PGP through Microsoft's Cryptographic API (CAPI), as installed with Internet Explorer 4.0."  So, even DH only versions of PGP 6.0.x could use (but not generate) standard size RSA keys, if you had the 128 bit version of Internet Explorer 4 (or IE5) installed.  And you didn't actually have to have Internet Explorer 4 or 5 installed, as long as you had installed the IE4 128 bit security upgrade.  USA/Canada residents use to be able to obtain this as nph-iefinal.pl at the Microsoft site; I'm told that it was at the Replay (now zedz.net) site as nph-iefinal.exe.  With assistance from others, I was able to install this and use RSA keys with PGP 6.0 Freeware, without having IE4.  My machine had Windows 95b (OSR2) and Internet Explorer 3.x, but I don't believe these were required.  I used WinZip to extract sigres.exe, rsabase.dll and rsaenh.dll to Windows\System, renamed nph-iefinal.pl to nph-iefinal.exe, ran it, and then registered rsabase.dll and rsaenh.dll:

Start | Run | regsvr32.exe rsabase.dll      &      Start | Run | regsvr32.exe rsaenh.dll

USA/Canada residents use to be able to get the 128 bit upgrade to their IE4/5 from Microsoft.


Where is PGP 2.6.4?

Both the PGP 5.x and the PGP 6.x documentation refer to a "patched PGP 2.6.4 version" that can replace 2.6.2 and allow it to "read the RSA keys on the new" 5.0 and 6.0 "keyrings and will not fail when it encounters the new" DH/DSS "format keys."  The 5.x documentation said that this 2.6.4 was available at the MIT site, while the 6.x documentation says that it is available at the NAI site.  Such a version would have been great to have as one's DOS version of PGP because it would allow it to use the same keyrings as the newer Windows version of PGP.  Unfortunately, this 2.6.4 was not available at either the MIT or the NAI site.  Although I was told by NAI that 2.6.4 was really given to MIT for release, I've never heard of anyone actually having it.   2.6.4ui is not this "mythical" 2.6.4, but reportedly has some of the same ability.


How Secure Is PGP?

Using any of the standard PGP algorithms, consider a message or file encrypted to a 2048 bit (or larger) public key to be completely secure from direct attack on the encryption.  There is no known successful attack on PGP's encryption algorithms except when using relatively small public keys of about 540 bits or less, so even a 1024 bit public key appears secure at this time.  Of course, there may be some future mathematical or computing breakthrough that might change this.  If your secret is important enough to have the full computing power of the US government (including the NSA) thrown against it, it might be wise to use a 4096 bit key.  The realistic weakness of the PGP system, is allowing someone to have access to your private key, and even this might be okay if you have a truly secure passphrase for your key.  Unfortunately, if the NSA or some other very powerful organization wants your private key and its passphrase (from a typical work or home computer), there is little you can do to prevent this.  The most likely successful attacks against a PGP user require capturing his/her passphrase, by such means as keystroke recording hardware or software, hidden camera or telescope, worms/trojans/viruses, substituting altered PGP and/or operating system files on your machine, intimidation/torture, or brute force/dictionary attacks on weak passphrases.


Only 128 Bit Encryption?

Since PGP uses public keys so much larger than this, it is easy to become confused when we hear the "reality" of PGP being "only" 128 bit encryption.  To understand this, it is necessary to know that PGP uses both symmetric algorithms (IDEA, CAST, or Triple DES; Twofish is an additional option as of PGP 7.0, and AES is still an additional option as of 7.0.1) and asymmetric algorithms (RSA or DH).  The process is the same regardless of the algorithms used, so my explanation will simplify it by referring only to the traditional use of IDEA and RSA.  IDEA is a thousand (or more) times faster than RSA, but cannot be used for encrypting a file/message to one key, and then decrypting that file/message to a different matching key (public key encryption, which RSA can do).  So, PGP speeds up the whole process by first encrypting the file or message to IDEA, using a randomly generated "session key" (an IDEA key used just for that one instance of encryption).  That randomly generated session key is then encrypted to the recipient's public key(s), and packaged along with the IDEA encrypted file/message.  The recipient(s) then uses his/her private key to decrypt the session key, which is then used to decrypt the file/message. In addition to tremendously speeding everything up, this use of underlying symmetric encryption to a randomly generated session key, improves the overall security of PGP - and also helps explain why the same file/message encrypted to the same public key always looks different (a different session key was used).  These underlying symmetric algorithms are believed to be best broken by a brute force attack of trying all possible keys, which is considered impossible to do because of the sheer number of keys to try - each additional bit doubles the number of keys that would have to be tried, so that a 57 bit algorithm would have twice the number of possible keys as a 56 bit algorithm.  The asymmetric RSA algorithm is believed to be best broken by mathematical factoring.  It is believed that a 3000 bit RSA asymmetric key would require as much time and effort to factor, as the time and effort to do a brute force attack on 128 bit IDEA.  These key size comparisons are considered roughly comparable for the other algorithms used in PGP (except that 256 bit Twofish and AES compare to a 15000 (yes, really 15,000) bit DH or RSA key) - so if you want the highest possible level of security in PGP, you should use an RSA or DH key at least as large as 3000 bits.


PGP 5.0 Key Generation Flaw?

"Under certain circumstances, PGP v5.0 generates keys that are not sufficiently random, which may allow an attacker to predict keys and, hence, recover information encrypted with that key."  This affects UNIX/Linux systems, but is not an issue for Windows users.


ADK Security Flaw?

On 8/24/00, researchers announced that PGP versions 5.5.x through 6.5.3 have an implementation flaw that made it possible for unauthorized persons to add an Additional Decryption Key (ADK) to your public key.  This flaw is not known to have actually been exploited, but it was a potentially serious security issue that NAI quickly corrected.  NAI checked all the keys on their keyservers, found none affected by this, and immediately updated their keyserver software to prevent it from accepting such keys.  If such an ADK was added to your public key, it is possible that some unknown person might be able to read email/files encrypted to your public key.  For this to actually occur, the following is necessary:

This issue does not apply to any Legacyl v3 RSA key, including all RSA keys generated by any PGP version up to and including 6.5.8.

If a public key on your keyring has been altered, and you have PGPkeys-View-ADK set, PGPkeys will show a red dot indicating that key has an ADK.  Of course, any such indicated ADK is probably going to be a valid ADK for the key - you would have to ask the key owner to find out otherwise.  Any ADK will also be indicated if you right click on the key and select Properties.

Unless you have changed the default setting in PGPkeys-Preferences/Options-Advanced, PGP will automatically let you know if you attempt to encrypt to any key with an ADK.

If your passphrase is not cached, when you use PGPtray to decrypt a message/file, it will show all keys to which the message/file is encrypted, including any ADK.

Users of PGP versions from 5.5 to 6.5.3 should consider upgrading to 6.5.8 (or higher), applying the appropriate hotfix (NAI appears to no longer be offering the hotfix) to their Windows 6.5.3 or Mac 6.5.2a versions, or applying the 6.5.8 patch (pgp658au.exe) - these upgrades will prevent you from encrypting to any such unauthorized ADK.


Private Key Vulnerability?

In March, 2001, Czech cryptologists reported a successful attack (often referred to as Klima/Rosa attack or ICZ 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.  PGP 2.6.3in (3/22/2001 or later) has been updated to prevent this attack.

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.   It might be advisable to keep your private key on removable media (such as a floppy, USB flash drive, or CD) that is kept in a safe location until needed, or on encrypted volumes such as PGPdisk, etc.  In addition, PGP 7.1 (and above) provides the option of using smart cards that may help protect against such an attack.  On the other hand, if you are allowing an attacker to have direct access to the files on your computer, there are probably multiple ways of defeating your PGP encryption, including the option of substituting altered PGP files. 

PGP 8.0.2 has been updated to prevent this attack.  This applies to all newly generated DH/DSS keys, and to any existing DH/DSS key if you now change the passphrase  - see PGP, GnuPG, & the New SHA1 Secret Key Hash.


Windows ASCII Armor Parser Vulnerability?

On 4/9/01, a Windows ASCII armor parser vulnerability was announced that could potentially adversely affect users of Windows PGP versions:

"Opening an ASCII armored file such as a public key or a detached signature can cause  the creation of an arbitrary file on the target machine. On the Windows platform this can lead to the execution of arbitrary code on the target machine."
Although really a Windows problem rather than a PGP problem, NAI released hotfixes for Desktop Security 7.0.4 and for PGPfreeware 7.0.3.  PGP Personal Security 7.0.3 users were to use the PGPfreeware 7.0.3 hotfix, which reports the version number as 7.0.4 when subsequently signing/encrypting messages.  Imad  provided a "quick and dirty fix" to add PGP 6.5.8 DLLs to the Windows Known DLLs list to assist with this issue.  I used a similar reg file for my Personal Security 7.0.3;  the NAI hotfixes additionally "will force a 'Save As' dialog for any extracted files with a .dll, .sys, or .vxd extension."


PGP Viewer Vulnerability?

"The way that the pgp viewer is implemented, allows for a composite forgery of a signed and encrypted pgp message to appear, when viewed using the 'current window'/'decrypt and verify' option in pgp 7.xx and 6.5.8."  I see this as more of a faked signature, but Vedaal presents a potential problem.  He has now extended this to show that added text may appear to be part of an encrypted html message or Word document.  Vedaal advises that the 6.5.8ckt and GPG added protection for this. 

PGP 8.0.3 has added "support for automatically detecting attempts to spoof signature verification text blocks."  However, this protection is only for the content between the Begin PGP and the End PGP lines.  For best protection against these attacks, one should select (highlight) the data from the Begin line through the End line before using the Current Window option of  Decrypt & Verify.


Otterloo Attack?

On September 6, 2001, Sieuwert van Otterloo announced "a practical attack on PGP. The attack allows an attacker to make a public key appear under an invalid name in the PGP keyring.  The attacker can use this to forge signatures, and in the right circumstances to read messages sent to that name.  The attack is not a 'life-threatening danger', but can compromise the web of trust system.  One should check all keys one imports for unusual extra names."

He had appropriately alerted NAI to this attack, and NAI quickly responded with hotfixes for this potentially serious problem.

I see this attack as taking advantage of a PGP weakness to mount a "Man-in-the-Middle" type attack, rather than actually permitting one to "forge signatures."  This attack applies to PGP versions 5.0 to 7.1.  It does not apply to keys with only one user ID, or to individuals not assigning trust to the keys of other users.


Is RSA Broken?

RSA is not broken.  There is a theory for attacking public key algorithms, that is not yet successfully tested; but if successful, might demonstrate that RSA keys need to be 3 times larger than currently thought, to provide the same level of expected security.  Noted cryptologist Bruce Schneier states "The improvements described in Bernstein's paper are unlikely to produce the claimed speed improvements for practically useful numbers."  Although this theory might also apply to DH and DSS keys, it appears to have no effect on the security of PGP's symmetric algorithms of IDEA, CAST5, Triple DES, Twofish, and AES.  It appears that even if this theory could be successfully tested, that it would have no effect on the security of PGP's keys, because it would not apply to the key sizes used by PGP.


Chosen-Ciphertext Attack?

The report Implementation of Chosen-Ciphertext Attacks against PGP and GnuPG discusses a potential PGP vulnerability.  This is my understanding of the attack:

An individual intercepts an encrypted email.  He places a plaintext addition within the package, in such a manner that when the originally intended recipient decrypts the message, the symmetric session key also "decrypts" the addition.  But since the plaintext addition was not encrypted (but probably looked encrypted), it is now encrypted to the symmetric session key.  If the originally intended recipient then sends this "gibberish" back to the original sender (to inquire about it), the interceptor again intercepts this, and now has both his original plaintext addition, and the symmetric session key encryption of that plaintext.  From this, he is able to reverse the XOR processing of the original encryption to produce the plaintext of the originally intercepted encrypted message.

Although the Open PGP standard needed to be updated to prevent such an attack, this attack was unlikely to actually succeed against a PGP user – PGP compresses before encrypting, in such a manner that this alteration would normally result in a corrupt package.

If the original encrypted message was signed, this alteration will result in the intended recipient receiving a Bad signature verification.

The attack would fail under any of the following conditions:

PGP Corp states that as of PGP 8.0.2 "special MDC support" includes additional protection against this kind of attack.


AES Attacks?

There are two fairly recently announced attacks against AES that suggest that 256 bit (but not 128 bit) AES may be a little less secure than previously thought.  Both the first and the second are considered too complex to be practical..


  Is SHA1 Broken?

Bruce Schneier's report  that SHA1 is broken has produced quite a stir.  Although the cited study has not yet been confirmed, it appears that an unexpected weakness in the SHA1 hash has been found.  If confirmed, a birthday attack collision could be found in 2**69 hash operations, instead of the expected 2**80 hash operations.

As PGP users we need to put this in a realistic perspective:

SHA1 remains more secure than MD5 was even before MD5's collision problems were found.  It was already known that a larger hash needed to be implemented for future use, and this report just helps confirm that need.  If you feel a need for a more secure hash, you may need to use PGP 9.x or 10.x with a v4 RSA key (which defaults to using SHA2-256); I am not sure when it started, but since at least PGP 9.8.3, PGP defaults to newly generated DH/DSS keys having a preferred hash of SHA2-256.

There is now a newer report indicating that SHA1 has been reduced to an effective 2**63 hash operations, making SHA1 in the above birthday attack even weaker than previously reported.  This is further reason for those wanting maximum signature security to use PGP 9.x or 10.x with  v4 RSA keys, or PGP 9.8.3 (or newer) newly generated DH/DSS keys.

Is PGP 2.6.x More Secure?

There is one good reason to consider this to be so:  The source code is much smaller, and it is therefore much less likely to contain undetected features that would either accidentally or purposely flaw the product.

There are a number of reasons to consider this not to be so:

  • When run from Windows:
  • PGP 2.6.x can only sign with the weak MD5 hash.
  • Official 2.6.x versions have a maximum key size of 2048 bits, which is much less than the 3000* bit equivalency of the underlying 128 bit symmetric encryption.
  • Most 2.6.x versions are reported to be subject to the Private Key Vulnerability.
  • Current PGP versions generate slightly more secure RSA keys - due to not requiring "Blum primes."
  • Current versions of PGP offer additional security features such as PGP Virtual Disk and Self-Decrypting Archives; as well as many new options.

  • What Does My Passphrase Do?

    Your key's passphrase really has only one purpose, but a very important one.  The passphrase is hashed to become the key to which your private key is encrypted.  Its whole purpose is to protect your private key, so that no one else can use your private key.  This is why any time you try to use your private key, you are prompted to enter your passphrase (as long as you have not already cached it, that is).  You need your passphrase to sign a message/file, to decrypt a message/file, to revoke a key, to add a name or email address to your key, etc.; but not for any use of your public key (and changing your passphrase has no effect on your public key). Secure passphrases are recommended.

    Until PGP 7.0, all RSA private keys are encrypted to IDEA; and all DH/DSS private keys are encrypted to CAST, but (since PGP 6.5.1) will be re-encrypted to the key's preferred algorithm if the key's passphrase is changed.  With PGP 7.x and 8.0.x, all private keys are encrypted to the PGP-Options preferred algorithm setting at the time of key generation; traditional v3 RSA private keys will be re-encrypted to IDEA if the passphrase is changed.


    What is a Smart Card?

    Since PGP 7.1, "PGP now provides full support for smart cards. Smart cards allow private key storage on secured hardware. Decryption and signing operations using private keys stored on smart cards occur on the smart card itself.  Keys can also be generated on the card, and  the cards do not allow the private keys to be read off the card."

    Smart card support had been provided at the Personal and Corporate level of licensing, but since PGP 9.0 is only available with the Desktop Professional license.  Some smart cards require a smart card reader, while others connect via a USB port.  PGP 9.x's Whole Disk Encryption can be to either a passphrase or an Aladdin eToken Pro (and with additional smart cards as of PGP 9.7) that contains your PGP keypair.

    Since the private key cannot be removed from the smart card, all use of it is on the smart card itself. This is why smart cards currently only support RSA keys, and why the key size is limited (to either 1024 or 2048 bits, depending on the smart card you have).  You can use your private key without any risk of it being captured by someone having access to any computer you are using, either your own or someone elses.

    If you want the greatest level of security from your smart card, generate your keypair on it.  This assures that the private key will never be available to anyone not in possession of the smart card.  The problem is that if you lose the smart card, or if it is damaged or otherwise stops working, you have no backup of your private key.  If you want a backup, you need to generate your keypair on your computer, and then add it to your smart card; with probably then wanting to delete it from your computer stored keyrings after exporting it to safe removable media. 

    If you take your smartcard with you when you leave your computer, no one will be able to decrypt your data on the computer regardless of what access they may obtain to your computer.  If you instead encrypt data on your computer to a passphrase (or to a public keypair that is stored on the computer), the passphrase security will probably be much less secure, and therefore more likely to be successfully attacked.

    When private keys are stored on smart cards, they are protected by the password or PIN number protection of the card - the private key is no longer encrypted.  Current versions of smart cards should have the protection of being permanently locked if several consecutive unsuccessful attempts to access it are made - be sure to consider the need to have your private key backed up.

    In some situations, when using Whole Disk Encrypton on your boot drive, it may be necessary to use Ctrl-Enter or Ctrl-R to be able to enter your smart card passphrase.

    Be aware that if someone captures your smart card, there may be the possibility of it being physically opened, and the non-encrypted private key being captured. - see Attacks on and Countermeasures for USB Hardware Token Devices.
     


    Encryption To Multiple Recipients?

    A PGP message or file can be encrypted to as many public keys as you wish.  The level of security will be determined by the weakest key it is encrypted to, which is usually the smallest key size used.  If all the keys are 2048 bit keys, the security is essentially the same as if it was encrypted to only one 2048 bit key - the security would be due to the time and effort required to factor (if RSA) any one of the keys; trying to factor more than one key would be splitting one's resources and therefore make the factoring of any one of those keys less likely.  However, if it was encrypted to ten 2048 bit keys, and then also to a 512 bit key, it would then be less secure, but only because of the inclusion of a less secure key.  If one of the algorithms is suddenly broken, and if one of the multiple keys that were being encrypted to, used that algorithm, then including that key would also reduce the security - but only to the same level as if the encryption was only to that one key.  Of course, with encrypting to more people, it is more likely that you will be encrypting to someone with a compromised private key.

    Which symmetric algorithm is used?  If I'm using Pegasus Mail with QDPGP and select multiple people to encrypt to, the message is actually encrypted individually to each recipient, so each individual public key's preference is honored.  But when I use PGPtray (or official PGP email plug-ins) and select multiple public keys for the encryption, PGP will encrypt the message to only one randomly generated session key, which is then encrypted to each of the selected public keys.  So, only one symmetric algorithm is used for all of the recipients, regardless of whether the public keys have different preferences.  My understanding is that PGP will check for a symmetric algorithm acceptable to all the chosen keys (checking in a predetermined order, which might not be the same from one PGP version to another).  Previously, it was reported that if one of the public keys is a traditional "legacy" RSA key, the symmetric algorithm will always be IDEA because IDEA is the only symmetric algorithm allowed (under normal circumstances) for traditional RSA keys.  As of PGP 9.5.x, it is reported that if the group of keys being encrypted to do not shared an allowed symmetric algorithm, that the encryption will be to the Open PGP mandated available symmetric encryption algorithm of 3DES.


    Conventional Encryption Compatibility?

    All PGP versions, except 5.0, include the option of encrypting files conventionally.  When using this option, the file is encrypted to a chosen passphrase (actually, a hash of the passphrase), rather than to a chosen public key.  PGP conventional encryption is often considered a good way of storing encrypted files on your computer; the security of this encryption is as good as the passphrase you use, and you don't need to worry about possible loss of a private key.  If you are using one of the newer versions of PGP (pre-9.0) and want your conventionally encrypted file to be capable of decryption by a 2.6.x version, then you must set your PGP Preferences/Options - Advanced tab - Preferred Algorithm (in addition to setting a preferred algorithm for your next generated DH and "new format" RSA keys, this setting determines what algorithm will be used in conventional encryption) to use IDEA.  For decryption by a 5.x through 6.5.8 PGP version, the conventional encryption must be to IDEA, CAST, or Triple DES.  PGP 9.x uses 256 bit AES (however, this may be changed in PGP Universal managed installations) for conventional encryption; this is backwards compatible to PGP 7.0.1.

    The PGP 6.5.x (and above) versions also include the option of making a Self Decrypting Archive (SDA) that lets you send conventionally encrypted files to people who do not have PGP installed.  PGP 9.x uses 256 bit AES for the symmetric encryption of SDAs; earlier versions always use 128 bit CAST.  In Windows Explorer, right click on the file and select PGP-Encrypt-Self Decrypting Archive; in PGP 9.x: PGP Zip - Create SDA.  The SDA will only decrypt on systems using the same operating system (32 bit Windows versions are compatible with each other), and you have to somehow let the other person know what passphrase you used.  Although the SDA encryption is as secure as PGP's usual conventional encryption, you need to be cautious in deciding whether to decrypt a received SDA;  just as with any other executable file you receive from someone else, you never know what it may have been altered to do - such as possibly capturing and transmitting your passphrase, deleting files from your computer, etc.


    Conventional Encryption More Secure?

    I think it depends on your public key size, where these encrypted files will be stored, and your passphrase quality.  Unless you have an extremely secure passphrase and a weak public key (smaller than 1024 bits, and esp. if 512 bits or smaller), it is unlikely that conventional encryption of your files will be stronger than public key encryption.  With conventional encryption, the security level is directly determined by your passphrase quality, which is probably at a much lower security level than your public key.  To successfully decrypt your conventionally encrypted files, an attacker has to somehow come up with your passphrase.  But to successfully attack your public key encrypted files, that attacker has to somehow come up with both your private key and your private key's passphrase (unless you are using a small public key; esp. if about 512 bits or less).  So if you use a good key size (at least 1024 bits, and esp. if 3000 bits or more), and store your encrypted files away from your private key (such as an Internet site, on a CD, on a different computer, etc.), public key encryption will probably be more secure.  However, if you store public key encrypted files at the same location as your reasonably sized private key, then the security level again just comes down to the security level of your private key's passphrase.


    Best Symmetric Encryption Algorithm?

    For subsequently generated DH keys (and "new format" RSA keys in PGP 7.x and 8.x), PGP lets you set a preferred symmetric algorithm (PGP Preferences/Options - Advanced tab), which is your preference as to what underlying symmetric encryption should be used when people are encrypting to you.  In PGP 9.x and 10.x, this is set by hitting the Advanced button when you start generating each new key.  The options of IDEA, CAST, and Triple DES, have all had proponents stating that each is the best choice.  All are considered strong and secure, are not known to have ever been broken, and should serve you well.  My personal preference had been IDEA because it is traditional with PGP and has a long track record.  Triple DES has been considered very strong due to its long track record, and it being based on the well designed DES, but is clearly the slowest option.

    PGP 7.0 introduced a new symmetric encryption option - Twofish, and PGP 7.0.1 additionally introduced AES.  IDEA and CAST are 128 bit algorithms that are considered equivalent to 3000 bit RSA and DH keys; Triple DES is 168 bit, with a reported effective key size of 112 bits.  Twofish and AES are 256 bit algorithms, and considered equivalent to a 15000 (yes, really 15,000) bit RSA or DH key.  Twofish and AES appear very strong, but are relatively new, and therefore have relatively short track records.  In view of possible quantum computing advances, as well as collision attacks, it is probably safer to use a 256 bit algorithm; and since AES has probably had more peer review than Twofish, it may be the best choice.

    How does PGP use a 160 bit hash to produce a 256 bit key?  See section 3.6.1.1. Simple S2k of RFC 2440.

    PGP versions prior to 9.0 do not provide the option to change your existing key's symmetric algorithm preference.  If you delete a key's self signature, PGP will show the key's preference as being IDEA; but the actual algorithm used for encryption to that key will be largely determined by one's PGP version - I'm told that 6.5.8 will encrypt to the user's PGP Options current setting for Preferred Algorithm, and that PGP 7.x will usually encrypt to CAST.


    Best Signature Hash Function?

    Although PGP (since version 5.0) has the ability to handle RIPEMD-160 hashed DH/DSS signatures, PGP software (through at least version 9.6.2) uses only SHA1 (since at least version 9.8.3, PGP defaults to using SHA2-256) when signing with a DH/DSS key, so for use of DH/DSS keys this was not a very important question.  All versions of PGP prior to 5.0 are restricted to using Legacy v3 RSA keys, and can only use MD5 for the signature hash function, so this again becomes an insignificant question for users of 2.6.x versions of PGP.  But all RSA enabled versions of PGP since 5.0 have the ability to verify RSA signatures that have used either the SHA1 or RIPEMD-160 hash function, as well as the traditional MD5 hash function.  Although no official version of PGP has a built in switch for using these improved newer hash functions with traditional RSA keys, the C-KT builds  added this optional switch; and the QDPGP plug-ins for using PGP 6.x (and above) with Pegasus Mail have also added a switch for using these newer signature hash functions.  If you want backwards compatibility with 2.6.x versions of PGP, you must use MD5 for your signature hash function - 2.6.x versions can neither decrypt nor verify messages signed with keys using either the SHA1 or RIPEMD-160 hash.  But there is some evidence that it might be possible to forge a message substitute for one that was signed using MD5.  Until recently, neither of the newer hash functions of SHA1 and RIPEMD-160 had such demonstrated weakness, and are also more secure because of their larger size (160 bit instead of MD5's 128 bit).  As far as I know, there is little reason to believe that either SHA1 or RIPEMD-160 is superior to the other.  I tended to favor RIPEMD-160 over SHA1 for this reason: SHA1 was created in part by the secret NSA, while Hans Dobbertin (famous for demonstrating the potential weakness of MD5) was a primary designer of RIPEMD-160; however, SHA1 is part of the Digital Signature Standard, and has therefore probably had much greater peer review, and had therefore been generally considered more proven.  An advantage for using either SHA1 or RIPEMD-160 with Legacy RSA keys (over SHA1 with DH/DSS keys), is that the signing key is your RSA key, and is therefore not limited to the maximum 1024 bit key size of DH/DSS signatures that was in effect before PGP 9.x.  PGP 7.1 through PGP 8.1 uses SHA1 instead of MD5 when signing with "new format" v4 RSA keys.

    For recent comment on MD5 and SHA1, see Cryptanalysis of MD5 and SHA.  For v4 RSA keys, PGP 9.x and 10.x defaults to using the more secure 256 bit SHA2; such signatures can be verified by PGP 8.l users.  Additional PGP 9.x options include 384 bit and 512 bit SHA2.


    Why Such A Short Signature?

    Until PGP 9.x, DH/DSS keys always used SHA1 for the signature hash, and the signing portion of the key (the DSS of the DH/DSS key pair) was never larger than 1024 bits.  So no matter how large your encryption portion of the key (the DH of the DH/DSS key pair), your DH/DSS signature will never have more than 3 encrypted lines in your digital signature.  Legacy v3 RSA keys normally use the MD5 signature hash; the RSA key is used for both encryption and signing, and the number of encrypted lines in the digital signature is determined by the size of the RSA key:

    Despite the size difference, it should be noted that a 1024 bit DSS signature is considered more secure than a 2048 bit Legacy v3 RSA signature (when MD5 is use for the signature hash) - because of a known weakness of the MD5 signature hash, and because of SHA1's 160 bit hash versus MD5's 128 bit hash.

    The newer v4 RSA keys will also have these longer signature blocks, based on the size of the signing key.


    Encrypts Only Text?

    PGP had normally encrypted email messages as unformatted text - any html files (or other formatted text), pictures, etc., had to be sent as email attachments.  If the message was encrypted by use of an official PGP email plug-in (except when using Outlook Express), the attachments would also automatically be encrypted - this was/is also the case when using the QDPGP plug-in with Pegasus Mail.  When using Outlook Express (prior to PGP 9.0) or PGPtray to encrypt the message, attachments should have first been encrypted in Windows Explorer (right click on the file and select PGP (PGP Zip in PGP 9.x)).  Eudora was rather unique: an html message could be encrypted and retained as an html message if PGP/MIME had been set in PGP Options/Preferences (setting Eudora to use PGP/MIME was discouraged if you sent encrypted email to people not using Eudora - it made decryption more difficult for people using most other email programs).  With PGP 7.0 to 8.1, Outlook and Lotus Notes plug-ins were reported to be able to encrypt html, and to be able to retain text formatting.

    Since PGP 9.0, PGP defaults to using its Email Proxy for encryption of both email and attachments regardless of the email client used.  When using the Email Proxy, all email clients are able to use PGP/MIME, and just about any email client is therefore able to successfully encrypt html and other formated email messages, as well as email attachments.


    Use Current Window?

    This was my favorite new feature of PGP 6.x.  Checking the Use Current Window option in PGPtray, was a very convenient way to automate the usual PGPtray use of the clipboard.  I often used this handy feature to easily sign my newsgroup postings: Instead of having to select all the text, use the copy command to copy it to the clipboard, then using the PGP Sign Clipboard option, and then manually pasting the signed text back to my newsreader editor window; I just used PGPtray to select the Sign Clipboard option, and the rest was all automatically done for me.  In the same way, this automated the use of the clipboard for encryption when using email programs without PGP plug-ins.  At least prior to PGP 9.0, email decryption is actually more secure when using PGP's Current Window usage - unlike the use of a plug-in (with its additional security risks - see Email Client Problems) which will decrypt the message to the email client software, the decryption will be to the PGP Viewer, which uses PGP's memory locking to prevent the contents from being written to the swap file.

    Since the PGP 6.5.x versions, this has changed some; PGPtray gives you the menu option of using either the Current Window or the Clipboard, and then has a submenu for each that includes all the usual PGP actions.  These newer versions (since 6.5) also offer HotKeys settings that allow you to use all the Current Window options without taking your hands off the keyboard.

    CAUTION: To avoid an Internet Explorer security risk that allows a visited web site to capture the contents of the Windows clipboard, make this IE setting change: Tools - Options - Internet Zone - Custom Level; set security zone to Medium; scroll down to Scripting section; disable "Allow paste operations via script."


    Email Client Problems?

    Using PGP with Eudora

    This section applies primarily to PGP versions prior to 9.0.

    GENERAL COMMENT: If you are receiving encrypted email as attachments that you are having difficulty decrypting, and if your email client does not have PGP/MIME capability (and/or you are using PGP's Current Window usage), ask your correspondent to disable PGP/MIME when encrypting to you.

    OUTLOOK:

    OUTLOOK EXPRESS: PEGASUS MAIL:

    Why Can't I Read Sent Messages?

    If your saved copies of sent encrypted email messages are encrypted, you cannot read them unless you have also encrypted them to one of your public keys.  The easiest way to automatically do this is to use the "Always encrypt to default key" option.  For the newer PGP versions (prior to 9.0), go to Preferences/Options - General tab (you should also use PGPkeys to set one of your keys as your default key).  In PGP 9.x and 10.x, add the desired key to your Master Key List (PGPtray-Options-Keys tab).  In the DOS 2.6.x versions, this setting can be set in config.txt or pgp.ini.


    Bad, Unknown, or Invalid Signature?

    When verifying PGP signed messages/files, there will sometimes be a notation that the Signature Status is Bad.  This means that the message/file has somehow changed since it was signed; this might simply be because of a line wrap problem or from some accidental corruption while the message/file was in transit, or it could mean that someone purposely altered the content of the message/file.

    If the Signature Status is Unknown, this means that you do not have the signer's public key, and therefore cannot determine whether the signature is Good or Bad.

    Sometimes the Signer is noted as Invalid (PGP 8.0.x changes this message to "Alert: Please verify signer's key before trusting signature").  This just means that you have not verified that the key used for the signing belongs to who it is suppose to belong to.  When you are sure that the public key you have for the person really belongs to that person, then you can sign his/her public key that you have on your keyring (and you will no longer get the Invalid message when that key is used for a signature).


    Signature Verification & Word Wrap Setting?

    When using PGPtray for signing messages that will be pasted to email or newsgroup programs, the signatures will probably not be verifiable unless the PGP word wrap setting (PGPtray - PGP Preferences/Options - Email tab) has been set for at least one space less than the word wrap (or line length, etc.) setting of the program it is being pasted into (there should be at least one space there for possible insertion of a carriage return).  But there are exceptions, and apparently it is sometimes necessary to play around with this setting to get it right for your software.  I'm told that The Bat! and Becky! require the opposite settings - PGP's wrap setting needing to be slightly larger than used in these email clients.  Turnpike is apparently so closely integrated with PGP that this setting apparently doesn't matter.

    With PGP 9.x, if you are getting bad signature verifications, try setting your news or email client to a higher line length setting; I increased my Xnews wrap to 78.


    How Many Keys Can I (Should I) Have?

    You can have as many keys, of each type, as you want.  They can all have the same user name, email address, passphrase, size, preferred algorithm, etc.; all be different, or any mixture thereof.  To avoid confusion for both yourself and others (and especially when you decide to replace or revoke keys), I suggest using restraint and only having the number of keys you think really serves a useful purpose.  It might be helpful to think of your key(s) as being there for others to use - it is others who will select one or more of your keys to use in encryption to you.  You might want to use different keys for different parts of your life, such as not mixing work and home use.  Although most key servers let you upload as many keys as you wish, the PGP Global Directory only allows one key per email address.


    The Perfect PGP Key?

    Although the default key (2048/1024 DH/DSS in PGP 5.0-8.1; 2048/2048 RSA in PGP 9.x and 10.x) appears completely secure at this time and should serve you well, there is no one perfect key, and the following deserve consideration.  It should be noted that PGP's DH keys are actually ElGamal, sometimes referred to as a DH variant.

    2048 bit traditional RSA ("legacy"):

  • v3 RSA keys are the traditional PGP keys that have withstood extensive and prolonged attacks.
  • Traditional RSA keys are backwards compatible with pre-5.0 versions of PGP, and can be used with the relatively few people who cannot use the newer DH keys.  The best reason to currently use this key type. would appear to be if you actually have this backward compatibility need.
  • The 2048 bit size is the largest RSA key that can be used by official versions prior to 5.5.x, and in the 6.x versions.  The 2048 bit key remains very secure at this time.
  • With a traditional RSA key as one's default key, there is no problem caused by signing any other key or by also encrypting anyone else's message with your default key.  If you use a DH/DSS key as your default and sign someone's RSA key with it, or also encrypt/sign a message with it, that goes to someone using a 2.6.x version of PGP, they are likely to not be able to either use the key or decrypt the message.
  • Traditional RSA keys are not subject to the ADK security flaw.
  • 4096/1024 DH/DSS: 4096/2048 RSA:
    1. Generate a 2048/2048 bit RSA key.
    2. Right click on the key in PGPkeys, and select Key Properties.
    3. On the Subkeys tab, click the New button (Add button in PGP 9.x and 10.x); and generate a new 4096 bit subkey.
    4. Then click on the original subkey and click the Remove button.
    2048/2048 RSA:


    Subkeys?

    While traditional RSA keys are composed of one key pair (the private key is used for signing and decryption; the public key is used for signature verification and encryption), DH/DSS keys and "new format" v4 RSA keys are actually two linked key pairs - a "Master" key pair that is used for signing and signature verification; and a "Subkey" key pair that is used for decryption and encryption.  An idea behind this is that one can continue to use the Master key pair (which provides the PGP reported Key ID and Key Fingerprint; and which contains signatures others have made to the key pair), while being able to replace the encryption key pair that is being used when people encrypt to you.  With PGP versions prior to 9.x, I didn't think this had much practical benefit: with DH/DSS keys, it is the Master (signing) key that has a maximum key size of 1024 bits, and is therefore much more likely to be compromised, than the encryption key that defaults to being 2048 bits.

    But there were some exceptions.  If you generated a default encryption key of 2048 bits, you could later add a more secure 4096 bit encryption subkey.  When you sent this updated key to a server, and people downloaded it, and encrypted to it, they would be encrypting to the newer subkey, unless you have set start and expiration dates to indicate otherwise when you generated your new subkey.  This was despite PGPkeys still showing the key as having the original subkey size, which would only be changed if you deleted the prior subkey - BUT, deleting the original subkey would not let you decrypt anything ever encrypted to it, such as files or email on your computer, or people encrypting to your key that they obtained before you added the new subkey.

    Another exception was for PGP 7.1 (and above) users of v4 RSA keys.  A 2048/2048 bit v4 RSA key lets you have a much larger signing key than the 1024 bit signing key used by DH/DSS keys.  And then for stronger encryption, you could add a 4096 bit subkey.  This gave you a 2048 bit signing key (PGP 7.1-8.1 will use SHA1 for the signature hash) that will produce a signature verifiable by any RSA enabled PGP version back to 5.0.  PGP 7.0, and above, users would be encrypting to the more secure 4096 bit subkey, while PGP 6.x users (who are not able to encrypt to RSA keys larger than 2048 bits) would be encrypting to the still very secure 2048 bit subkey.  PGP 9.x defaults to using the more secure 256 bit SHA2 signatures that are only backward compatible to PGP 8.1 for signature verification, but PGP 9.x users can choose to use other hashes, including SHA1.

    A possible additional exception was the idea of replacing your subkey, "just in case" someone may have been at your computer in the past year, who might have somehow captured both your key and your passphrase.  But if you had real security needs, and thought this a realistic possibility, you should have instead revoked that key and generated a new key pair.

    GPG began using subkeys for signing before PGP.  Until PGP 8.1, PGP had no support for this, and could not verify signatures made with such a signing subkey.  PGP 9.x adds signing subkey functioning.  With PGP 9.x, you can now generate and use signing subkeys - this allows you to continue using your original signing key ID and fingerprint  for continuity purposes, while being able to enhance your signing security with key replacement.


    Key Size & Speed?

    Over the years, there have been various statements about key size and how that impacts PGP usage on slower computers.  I've done some interesting non-scientific timing (using C-KT builds of PGP) that I will report here - it looks as if key size selection is becoming much less of a speed concern with the increasingly fast computers.

    For RSA keys, I report only on results from using the private key (signing and decryption) because use of the public key is practically instantaneous regardless of key size.  For DH/DSS keys, I report only DH key usage because the DSS key had a limit of 1024 bits at the time of this testing; but both encrypt and decrypt times are reported because both vary based on key size.
     

    RSA Keys
    Key Size
    Pentium 133 
    Decrypt/Sign 
    Pentium 200mmx
    Decrypt/Sign 
    Celeron 500
    Decrypt/Sign 
    Pentium III 800
    Decrypt/Sign 
    Pentium 4  1.7ghz
    Decrypt/Sign
    Pentium D 3.0ghz
    Decrypt/Sign
    2047 bits
    not tested   1 second



    3072 bits
     2 seconds




    4095 bits
    not tested   3 seconds  1 second   1 second

    8192 bits
    30 seconds 18 seconds  4 seconds   3 seconds  3 seconds   2 seconds
    16K
    3.5 minutes 2.3 minutes 0.5 minutes 21 seconds 16 seconds  11 seconds

     
    DH Keys
    Key Size

    Pentium 200mmx Celeron 500 Pentium III 800 Pentium 4  1.7ghz Pentium D 3.0ghz
    4096 bits 
    Encrypt Time not tested 1 second 1 second


    Decrypt Time not tested 0 second 1 second

    8192 bits
    Encrypt Time 15 seconds 3 seconds 2 seconds 2 seconds 1 second

    Decrypt Time   9 seconds 2 seconds 2 seconds 1 second 1 second

     
    Large Key Generation Time
    Key Size & Type Pentium 200mmx Celeron 500 Pentium III 800EB Pentium 4  1.7ghz Pentium D 3.0ghz
    8192 bit DH 7 3/4 hours 1 1/4 to 1 2/3 hours 14 minutes 1 1/2 hours  6 minutes
    8192 bit RSA 11 minutes 6 to 9 minutes   3 minutes 3 minutes  1.5 minutes
    16K RSA 7 hours 1 2/3 to 4 hours   1 hour 1 5/6 hours 20 minutes


    Photo ID Compatibility?

    Since PGP 6.0, DH/DSS keys (and the PGP 7.x added v4 RSA keys) have the ability to have a small picture of yourself added to the key.  This is reported to be non-compatible with PGP 5.x versions of PGP, and you were warned to export such a key in Compatible Mode (without the photo) if you are sending it to someone with an earlier version of PGP.  When I tried to import one of these keys (with photo) into 5.5.3, I got an error message stating that the file did not contain a valid PGP key.  Interestingly, when I used 6.0.2 to place that same key on my 5.5.3 keyrings, 5.5.3 could use the key normally for signing/verification and encryption/decryption.  With PGP 5.0, the key (with Photo ID) appears to be properly imported; but will not encrypt to it, and will not produce a verifiable signature.  Again, when I used 6.0.2 to place the key on my 5.0 keyrings, 5.0 then properly used the key (with the Photo ID).


    How Do I Disable a Key?

    PGP makes it easy to disable public keys on your keyring: Right click on the key in PGPkeys (PGP Desktop - All Keys in PGP 9.x) and select Disable.  After a public key is disabled, it will not be available in the Key Selection Dialog box when you are encrypting a message or file (and the PGP 9.x email proxy default policies will not encrypt to it), but will still be available to verify a signature from the owner of the key.  When having multiple keys of an individual (so you can verify his/her signature regardless of which key is used for the signature), this is a way to control which key is used when encrypting to that person.

    You can also disable one of your own key pairs, but first you need to right click on your key, select Properties, and uncheck Implicit Trust; in PGP 9.x, right click on your key and select Key Properties - then use the Trust down arrow to select None.  When your key pair is disabled, it will not be available in the Key Selection Dialog box for signing, but it will still be available for decryption of a message/file encrypted to you.


    Why So Many 2047 Bit RSA Keys?

    PGP 2.6.2 has a bug in it that will not allow keys to be generated larger than 2047 bits; when instructed to create a 2048 bit key, it creates a 2047 bit key.  Some people continued to either use their past 2.6.2 generated keys, or to use 2.6.2 to generate their new RSA keys.


    How Do I Change My Email Address On My Key?

    For earlier PGP versions, in PGPkeys, right click on the key and select Add-Name.  In PGP 9.x and 10.x, right click on the key in PGP Desktop, select Key Properties, and click the Add Email Address button.  You can then right click on the new User ID and select Set As Primary Name.  And if you wish, you can then delete the original User ID; but if you then send the updated key to a traditional server, remember that updating a key on a traditional server will only add new information (the old User ID cannot be deleted from the key that is already on the traditional server).  Prior to deleting the original User ID and/or prior to uploading your updated key to a traditional server, it might be advisable to revoke your signature on the original User ID, as an indication that the address should not be used - as of PGP 8.0.2, such a revoked User ID cannot be encrypted to.


    Can I Delete My Old Key From a Server? Revoke it?

    The PGP Global Directory is a major change from the information in the rest of this section. 

    Except when using PGP 6.x and higher (see below), there is no way to delete a key from a traditional key server (you still cannot delete a revoked key).  I'm not sure how helpful this is anyway, because a number of  traditional key servers distribute keys to each other on a regular basis - it seems that your key is likely to be on one of the traditional servers that doesn't allow key removal.  But if you want to: Search for your key on an LDAP or LDAPS server, right click on the key, and select Delete From Server (you must have the matching private key and know its passphrase).

    If you have an old key on a server that you don't want used anymore, usually the best you can do is to revoke the key, and send the revoked key to the server.  When someone downloads your revoked key, they will not be able to use it to encrypt messages.  Except when using a designated revoker (see below) with PGP 6.x or higher, you absolutely must have both the private key and the private key's passphrase to revoke it.  Revoked keys should be retained - except in version 5.5.x, revoked keys (but not revoked subkeys, unless using PGP Command Line 6.5.x or PGP 7.x or higher) can still be used to decrypt messages that were previously or subsequently (others may still have a copy of the key before it was revoked) encrypted to that key.

    The Global Directory (ldap://keyserver.pgp.com) offers exception to the above.  It does not exchange keys with other keyservers, so deleting a key from it should result in that key remaining off that server (until/unless you upload the key again).  They have also been reported to be willing to remove keys for which you do not have the private key or passphrase: email customerservice(use the at symbol here)pgp.com ("include the Key ID and the email address assigned to that public key you wish removed").  If your email address is still valid, you should also be able to remove your key via the Global Directory web interface.

    "Designated Revokers.  You may now specify that another public key on your keyring is allowed to revoke your key.  This can be useful in situations where you are afraid of losing your private key, forgetting your passphrase, or in extreme cases such as a physical incapacity to use the key." -PGP 6.0 whatsnew.doc
    "NOTE: For a key to appear revoked to another user, both the revoked key and the Designated Revoker key must be on his/her keyring." -PGP 7.0 manual
    "NOTE: This feature is available for Diffie-Hellman/DSS and RSA keys.  Designated Revokers are not supported by RSA Legacy keys." -PGP 8.0 manual

    "Secure deletion from the PGP Certificate Server.  On servers configured to allow it, a long awaited and eagerly anticipated feature has been introduced.  Users may be allowed to delete or disable their own keys on the server by authenticating themselves through TLS (Transport Layer Security).  If you can authenticate with your own key, you may delete it.  All of this is very simply automated by choosing the appropriate commands from the menu. The public server at ldaps://certserver.pgp.com is TLS-enabled." -PGP 6.0 whatsnew.doc
    My note to this: Despite what the above says, PGP users are usually not allowed to disable their keys on public key servers.


    Key Already On Server Warning?

    When uploading your updated public key to a traditional server, it use to be common to get "PGP Warning - The selected key is already on the server." or some other similar message making it sound as if the update was unsuccessful.  I can't explain why such an inappropriate message is returned; but if you later check your key on the server, you will probably find that it was updated as you had intended.  Just as a reminder: Updating your key on a traditional server just adds information (such as a signature, name or email address) - it will not remove any information already on the key at the server.


    Searching For Keys?

    With PGP 6.0 to 8.1, the easy way to search for someone's key is if you have a signed message from them: Set PGP Preferences/Options - Servers tab for Verification; then any time you attempt to verify a PGP signed message for which you do not have the necessary public key, PGP will automatically connect to a server and begin searching for it.  Probably the next easiest way is to use PGPkeys, Server - Search, and enter either the person's email address or name; if you know the Key ID, use the drop down arrow to select Key ID, and then enter the known Key ID.

    PGP 9.x and 10.x default to automatically/transparently connecting to the PGP Global Directory to find any keys it needs for either encryption or signature verification.


    Additional Key Servers?

    Additional Key Servers can be added to PGPtray-Options-Servers (Keys tab in PGP 9.x and 10.x) by clicking the New button.  This allows you to add any key server that is used for a local need, personal preference, or when other servers are out of service.  Key servers seem to be up and down.  The following are some I find to be pretty reliable.  For a more comprehensive listing, see PGP: Public Key Servers

    PGP Global Directory
    LDAP: keyserver.pgp.com

    HTTP servers: 

    Import Key From Email?

    Usually, all you need to do is to open the email message that contains the key, and select PGPtray-Current Window-Decrypt & Verify.  But if there is a problem:

    Is there really a key in the message?  People new to PGP often think the encrypted hash of a clearsigned message is a public key.  If there is a public key inside a clearsigned message, the key will begin with a line like this:
    - -----BEGIN PGP PUBLIC KEY BLOCK-----
    and end with a line like this:
    - -----END PGP PUBLIC KEY BLOCK-----
    The clearsigning adds a "- " to each of those lines.  So to import the key, the additions of "- " need to be removed so that the lines are the usual
    -----BEGIN PGP PUBLIC KEY BLOCK-----
    and
    -----END PGP PUBLIC KEY BLOCK-----
    For some situations, it will be necessary to do the original PGPtray-Current Window-Decrypt & Verify, then click the Copy to Clipboard option, and then do PGPtray-Clipboard-Decrypt & Verify.

    Another alternative that should always work (unless the key block is somehow corrupted) is to use the mouse to select (highlight) just the key block, including the Begin and End lines, and use PGPtray-Current Window-Decrypt & Verify.


    Import X.509 Certificate?

    Ridge had provided some very helpful guidelines on importing  X.509 certificates into PGP that I can no longer find a link to (PGP_X509s.pd).  When exporting such imported X.509 keys from PGP, be sure to export in Complete mode.
    CAUTION:  When importing X.509 private keys into PGP 7.x through PGP 8.1 (9.x?, 10.x?), PGP will ask for the password.  It will then store the imported X.509 private key unencrypted and without any password or passphrase protection.  In PGPkeys, you should right click on the imported key, select Key Properties, click the Change Passphrase button, and entered your desired passphrase.


    Why Can't I Use Old Keys?

    When using PGP 5.x or PGP 6.0.x, and not being able to use RSA keys, you are probably using a DH only version of PGP - unless you paid additionally for RSA support, most of those versions were without RSA support due to then existing patent and royalty issues.  Such unusable keys appeared in faded italics in PGPkeys.  Options to resolve this included switching to a PGP version with RSA support, additionally using another version of PGP with RSA support; or if using a DH only version of PGP 6.0.x, adding the IE4/5 128 bit security upgrade.


    Why Can't I Use New Keys?

    PGP 2.6.x versions (2.6.2 and “i” builds) can only use traditional v3 RSA keys (which must not be signed by DH/DSS keys - running the command "pgp -kc" should allow you to remove DSS signatures), and cannot use RSA keys larger than 2048 bits.  PGP 2.6.x might not be able to use traditional RSA private keys generated in PGP 7.0 (and above) unless the passphrase is changed before exporting the private key (this will ensure that the RSA private key is encrypted to IDEA).

    PGP 8.0.2 (and above) generated DH/DSS private keys should not be usable in pre-8.0 versions; this also applies to DH/DSS keys generated in earlier PGP versions when the passphrase is changed in PGP 8.0.2 (and above).  This is because of changes taken to resolve the Private Key Vulnerability.  A way to resolve this is by removing the key's passphrase in PGP 8.x before exporting it for the earlier PGP version, and then restoring the passphrase from within the earlier PGP version.

    Private keys of key pairs with a preference for Twofish can not be used by PGP versions below 7.0; as is the case for key pairs with a preference for AES when attempting to use them in a version below 7.0.1.  This is because the private key is encrypted to the preferred algorithm, and these algorithms are not supported in earlier PGP versions.  This can be resolved by removing the passphrase before exporting the key from the newer PGP version.  However, at least for PGP versions 7.1.1 and above, the public key will be encrypted to with its original symmetric algorithm preference - so when PGP 7.x and above users encrypt to you, it will be to an algorithm that PGP 6.5.8 and below cannot decrypt.  Actually, for PGP 7.x, but not for PGP 8.0.2 (and above), this last problem can be overcome by deleting the key's self signature.

    PGP 8.0.2 (and above) will not encrypt to a key unless it has a User ID with a self signature that has not been revoked.  As of PGP 8.0.2, keyrings must not contain any keys that have a blank User ID.

    Using v4 RSA keys in versions below 7.0, is covered in the next section of PGP 7.0 Key Compatibility.

    Official versions of PGP cannot use DH keys larger than 4096 bits, and prior to PGP 9.x cannot use DSS keys larger than 1024 bits.  Official 6.x versions cannot use RSA keys larger than 2048 bits (5.5.x will use RSA keys up to 8192 bits, and 7.0 (and above) will use RSA keys up to 4096 bits). 

    Check DH/DSS key properties to make sure they have an encryption subkey that has reached its start date, is not expired, and is not revoked.

    When these conditions are met and the newer public keys are not available for encryption, it is likely because either your computer time is set for some time in the past, or the public key was created on a computer with the date set to a future time (PGP will not use keys with a creation date beyond the date currently set for your computer clock). 


    PGP 7.0 Key Compatibility?

    PGP 7.0 introduces two major new key features.  In addition to the symmetric algorithms available in PGP versions of 5.0 to 6.5.8 (CAST, IDEA, Triple DES), 256 bit Twofish is now available (256 bit AES is included since PGP 7.0.1).  I generated a DH/DSS key pair with a preference for Twofish, exported the key pair in compatible mode, and then imported this key pair to PGP 6.5.x.  PGP 6.5.x could not decrypt messages encrypted to this key, but it could verify signatures made by the key.  The PGP 6.5.x GUI identified this key as having a preference for IDEA, and could encrypt to it (I'm told that PGP 6.x will normally use CAST, despite the GUI display of a preference for IDEA), but could not sign with it.  Since  PGP 6.5.3 can use the PGP 7.0 Twofish preference public key for both encryption and signature verification, such a key does not appear to cause any new backward compatibility problem for the PGP 7.0 (and above) user.

    I was surprised to find that PGP 7.0 can encrypt to an 8k DH key, but it cannot sign with it or decrypt with it (same for 6k DH key).

    In addition to traditional RSA keys (PGP 7.0 refers to these as "legacy" RSA keys), RSA keys have an additional format (v4) available that allows features previously reserved for DH/DSS keys: ADK, designated revoker, multiple encryption subkeys and photo ID.   I generated two of these "new format" RSA key pairs, one with a preference for IDEA, and one with a preference for CAST.  As above, I placed these key pairs on my 6.5.x keyrings.  In both cases, PGP 7.0 encrypted messages were able to be decrypted, and PGP 7.0 signed messages could be verified by PGP 6.5.x; but PGP 7.0 signed AND encrypted messages could not be decrypted.  PGP 6.5.x was able to use both of these key pairs to encrypt, sign, and encrypt AND sign messages.  When I used v4 RSA keys as a PGP 7.x user in correspondence with a 6.5.x user, there was full compatibility.  Although a new format RSA key has the same reported key ID in 7.0 and 6.5.3, the fingerprints are different (the fingerprints will match if the key ID is added to the end of the 6.5.x reported fingerprint).  I was not able to use these new format RSA keys in PGP 2.6.2.


    Unsupported Packet Format?

    The error message of "Unsupported Packet Format - you need a newer version of PGP for this file," probably means that you are using a PGP 2.6.x version and were unable to decrypt a message or file sent to you.  The most likely reasons are that the message to you was also encrypted to a DH/DSS key (possibly due to the sender's use of "always encrypt to default," if their default is a DH/DSS key), the message was signed with a DH/DSS key, or the message was signed with an RSA key using either the SHA1 or RIPEMD-160 hash.


    How Do I Add a Private Key To My 2.6.x Keyrings?

    In addition to the usual Extract and Import procedures, I have often used 5.x or 6.x PGPkeys to manage my 2.6.x keyrings.  You can change PGP Preferences/Options - Files tab (in PGP 9.x, right click on All Keys in the PGP Keys menu box of PGP Desktop, and select Properties), to point to any keyring pair that you want to manage.  With PGP 7.x - 8.1, you can open another set of keyrings from PGPkeys-File-Open; for PGP 9.x, use New Keyring instead of previous reference to All Keys.  Then from PGPkeys, use the Keys - Import command to select the other public keyring that you want to import a public key from; in PGP 9.x, right click on the key in its original keyring, and select Add To.  Or if you want to import a private/public key pair, select the private keyring instead (if you also want to import signatures, you will also need to do this with selection of the public keyring).  If importing a PGP 7.0 (or above) generated RSA private key, it might be necessary to first change the key's passphrase (which will ensure that the Legacy RSA private key is encrypted to IDEA).  After importing the key, you can then right click the key in PGPkeys, select Properties, and adjust trust settings (be sure that private keys are set for Implicit Trust), etc.  Sometimes a private RSA key created in a newer PGP version won't work properly in PGP 2.6.x, but there has been some report that running the command "pgp -kc" will take care of this problem.  Before setting PGPkeys Preferences/Options back to the original keyring pair, it is convenient to sign any keys needing to be signed, and to inspect your keyring to remove any DH/DSS signatures on the RSA keys (2.6.x versions of PGP will choke on any RSA keys that are signed with DH/DSS keys).


    What Is File Wiping?

    When a file is deleted in DOS or Windows, the space the file occupied is marked as available; but until the file happens to be overwritten by some other data, it remains on the disk and can be easily recovered by various utilities.  Wiping is the process of overwriting the file with useless data and securely deleting the file so that the original file can no longer be recovered.  Although one overwrite will prevent recovery by undelete utilities, it is questionable whether any file can be sufficiently overwritten to the point of being absolutely unrecoverable when very sophisticated equipment and software is used; but multiple overwrites with various patterns make recovery less likely.  For more information, see Secure Deletion of Data from Magnetic Solid-State Memory.

    In addition to the file and freespace wipe of earlier PGP versions, PGP 7.x (and above) versions have the option of having all file deletions (including all system and application temp files that you usually don't see) being automatically overwritten at the time of deletion.  For Win98 and WinME users, it is common to have freezes when this "Automatically wipe on delete" is set in PGP Options-General (in PGP 9.x, set "Automatically shred when emptying the Windows Recycle Bin" in PGPtray-Options-Shredding tab).  With WinXP Pro, when using NTFS but not when using FAT32, using the PGP 8.0.x auto wipe on delete resulted in my having a problem with files sometimes not actually being deleted; and was the apparent cause of sometimes having a blue screen of death when opening the laptop lid to bring it out of Stand by - this went away after I uninstalled Norton 2002 products.  There are Windows created problems with using auto wipe on delete with EFS encrypted data (on both Win2000 and WinXP) - there was a hotfix released for PGP 7.x that would let the EFS encrypted files be deleted as they normally are (but be aware that EFS only deletes the files that it is encrypting - it does not wipe them).  It may actually be a good idea to additionally use another free space wiping software such as the free Eraser, but if you do so, make sure to first temporarily disable PGP's auto wipe on delete.

    Some wiping software leaves the wiped file names recoverable - this can usually be taken care of by defragmenting the drive.  When free space wiping is not reported below, it is because I have not tested it for that PGP version.

    Please note that the following test results for PGP versions prior to 8.0, were only on Win9x machines formatted FAT32. 

    PGP 2.6.x provides file wiping consisting of one overwrite.  I found that when this was done from Windows that no wiping had occurred.  When done from DOS Mode, the files were wiped.  File names were recoverable.

    PGP 4.0 "wiped" files were fully recoverable - they are not really wiped.

    PGP 5.0 does not have a wipe function.

    PGP 5.5.x Wipe often does not wipe files and leaves them completely recoverable - I'm told that the wipe works properly in Windows NT.  The C-KT 5.5.3  corrected this problem, but file names are still recoverable.

    PGP 6.0.x does wipe files, but names are often recoverable.  Despite PGP 6.x allowing you to set the number of desired overwrites in PGP Preferences/Options, some people have reported that it usually only overwrites one time.

    PGP 6.5.x consistently wipes files, with the names usually being recoverable.  It always takes the same amount of time for the wipe despite the Options setting, so I have doubt that it really overwrites more than once.  The 6.5.8 free space wipe appears to work properly on both the hard drive and on floppies.

    PGP 7.0 (tested only on Windows 98SE) leaves the names of wiped files available for recovery.  The time taken to do the wipe varies consistently with the number of wipes set in PGP Options.  When I wiped small text files, I found some words in the wiped files were available for recovery until the computer was rebooted.

    PGP 7.0.3 (tested on Windows 98SE and ME) leaves the names of wiped files available for recovery.  Files are consistently wiped.  The auto wipe on delete option also produces these results.

    PGP 7.1 and 7.1.1 have the same results as 7.0.3.  The 7.1.1 free space wipe appears to work properly on both the hard drive and on floppies.

    PGP 8.0 also has the same results as 7.0.3, and these same results are on Windows XP Pro (FAT32). 

    With PGP 8.0.2 on Windows XP, I've had the same successful wiping results.  The free space wiping appears to work properly on hard drives (both FAT32 and NTFS), but failed when tried on both my WinXP machines floppy drives.  I'm aware of a Windows 2000 user reporting that floppy free space wiping fails, and of a Win98 user reporting that floppy free space wiping works. 

    PGP 8.1 wiping on WinXP Pro SP2 appears to all work correctly, including floppy free space wiping.

    PGP 9.0.1 (build  2185) successfully wipes files on both the hard drive and floppies - file names are removed! The "Automatically shred when emptying the Windows Recycle Bin" also successfully wipes deleted files.  The floppy free space wiping produces an error message about not being able to be completed successfully, but deleted files are wiped.  Free space wiping on both the boot drive and a logical drive (both NTFS) does not consistently remove file names; deleted files are wiped, except for files less than 1KB in size (this is reported in the User's Guide, but is also the case in non-boot drives even when the option "Wipe NTFS internal data sturctures" is used).


    What is PGPdisk?

    PGPdisk is included with PGP 6.x (and above) Personal Desktop (previously named Personal Security or Personal Privacy) and Workgroup Desktop (previously named Corporate Desktop or Desktop Security) versions.  PGPdisk was also included with PGP 6.0.2i and the C-KT builds of 6.x, but not in any official PGP Freeware.  PGPdisk enables you to set up a file that can be "mounted" and then used just as any other drive on your hard disk.   When your passphrase has been entered, and the "volume" mounted, these programs and data are used just as any other programs and data - files are transparently decrypted for use upon access.  But when "unmounted," there is no access to the contents of this securely encrypted (using the 128 bit CAST algorithm - since PGP 7.0, PGPdisk has the option of using 256 bit Twofish; since PGP 8.0.2, there is also the option of 256 bit AES) PGPdisk file. 

    PGP Desktop 9.x and 10.x includes "PGPdisk" in its Professional and Home products.  However, the name is now PGP Virtual Disk, which along with the PGP Whole Disk Encryption (WDE), are the two components of  "PGP Disk."  PGP 9.x generated PGP Virtual Disk volumes are encrypted to 256 bit AES (however, this can be changed in PGP Universal managed installations).  With Whole Disk Encryption, every sector (except for the MBR and the sector contaning the PGP bootloader, which is in the file PGPWDE01 located in the root directory of your WDE hard disk)  of your hard disk is encrypted to 256 bit AES.  The file PGPWDE01 (and PGPWDE02 in PGP 10.x) must not be moved from that sector - Windows defrag will not move it, but some third party defrag software may move it, making your WDE disk incapable of being booted from.

    In Windows 95/98/ME, but not in Windows NT (NTFS PGPdisk volumes don't seem to have a size limit), PGPdisk volume size had an upper limit of 2GB; with PGP 7.x, the Win 95b/98/ME PGPdisk maximum volume size went up to 4095 MB.  FAT32 PGPdisk volumes on Win2000/XP have a maximum size of 32GB. 

    If you need to change PGPdisk settings, such as whether your PGPdisk volume wants to mount on startup, use the PGPdisk Editor (very well described in manual/User's Guide).  If you want to change the drive or folder designation for opening a PGPdisk volume, hit the Options button before you enter your passphrase for mounting it.  Such change of a designated drive letter is reported to have resolved a problematic situation in which a drive letter was not showing for the mounted volume, and having an error message about the drive not supporting long file names.

    If you want others on your network to have Read Only access to a PGPdisk volume you mount, it must be mounted locally on your computer, rather than remotely (such as on a server from over the network).

    CAUTION:  If you copy a PGPdisk volume that is formated to FAT or FAT32 to a CD or DVD and then mount it from the CD or DVD, it will be mounted as Read Only.  When I did this to CD-RW and DVD+RW, and then added a file to the mounted volume, then unmounted, and then later attempted to mount such volumes, there were error messages about the PGPdisk volume not being formatted, and I could no longer access the data in the PGPdisk volumes.  I did this testing with PGP 8.1.

    If having trouble deleting a large PGPdisk volume, try holding down the Shift key when hitting the Delete key - this will make the deletion bypass the Recycle Bin.  Be aware that if you have PGP Options set for auto wipe on delete, the overwriting of a large PGPdisk volume may take a long time.

    It was reported that there is a "compatibility issue with PGPdisk from PGP 8.03 under Windows XP when using a SiS IDE mainboard driver" that "copying larger files (around 20 MB and up) to/from PGPdisk volumes would immediately hang the system."

    NTFS Issues:

    Be aware that the PGPdisk (1.0) included with PGP 6.0 was found to have a serious security flaw and should not be used - this was corrected in the PGPdisk included with PGP 6.0.2.  When PGPdisk is installed with PGP 6.0.x, it places 26 PGPdisk entries in the Windows Device Manager (one for each possible drive designation); since PGP 6.5.x, installing PGPdisk results in only one PGPdisk entry in the Windows Device Manager.  If you are using Windows 2000, be aware that the PGPdisk with PGP 6.x  may cause problems with using hibernate/standby.  Windows XP users have had problems with the PGPdisk drive not appearing in Windows Explorer, but this is fixed as of PGP 7.1.1 (for use of earlier PGPdisk versions, see Windows XP Issues?).  Windows users need to be aware that if a previously created PGPdisk volume is mounted with PGP 7.0 (or above), the PGPdisk volume will be updated in a manner that will not let it be mounted by PGP 6.x versions.

    A possible alternative for individuals not having PGPdisk (such as Freeware users) is to place all the files you want encrypted into one folder.  Then right click on that folder, and select PGP-Encrypt.  All the files will be individually encrypted, to your choice of either a public key, or a conventional encryption passphrase.  They can then each be decrypted in the usual individual manner, or all at once by right clicking on the folder, and selecting PGP-Decrypt.  With PGP 9.0.x, the files in the folder will be encrypted to one zipped file, rather than each file being individually encrypted - with PGP 9.5.x, the files can still be encrypted individually; in the first PGP Zip window, select the fourth icon from the left on the bottom of the window (PGP Zip advanced options).


    What Is PGPnet?

    PGPnet is a feature included in the 6.5.x and 7.x PGP versions.  Although PGP 6.5.2 added Windows 2000 support for all other PGP functions, PGPnet support for Windows 2000 is only available in PGP 7.x.  People have reported some PGPnet related problems (such as difficulties dialing in to their ISP, and conflicts with firewall software) until reinstalling PGP without the PGPnet component, so you may want to be conservative in deciding whether to install PGPnet.  DO NOT install the PGPnet/PGPvpn and/or PGPfire component on Windows XP.  The manual includes a whole chapter devoted to PGPnet; the following quotes are from the documentation and an NAI official:

    "PGPnet, a Virtual Private Network (VPN), is an easy-to-use encryption application that allows you to communicate securely and economically with other PGPnet users."

    "A VPN extends a company’s intranet (that is, its internal network) or an individual’s machine across the Internet, creating a secure private tunnel.  How does this work?  A VPN uses a tunneling protocol (for example, Internet Protocol Security (IPSec)) and encryption to protect data from the time it leaves the sender to the time it reaches the designated recipient."

    "Basically, PGPnet is included in PGPfreeware, but X.509 and Gateways are not supported in it.  This should allow all normal PGPnet usage with the exception of usages associated with corporate VPN solutions."

    In the PGP 7.0.x Personal Security and Desktop Security builds, PGPnet also includes a Personal Firewall/Intrusion Detection System component.  I've installed PGP Personal Security 7.0.3 PGPnet to try its Personal Firewall - setting it to the pre-defined Client Medium level worked without problem; and all web testing sites I tried showed all ports as Stealth.  With the Client Medium setting in PGP 7.1 Personal Firewall (which added application rules), there may be difficulty establishing connections with FTP clients - it might be possible to bypass this by setting the FTP client to use the PASV option (which forces connections to be established by the client rather than the server).

    To help avoid potential PGPnet problems, be sure to read the PGPnet information on the PGP readme.txt.  If you have deleted or renamed rpcss.exe, DO NOT run PGPnet/Personal Firewall - I thought I was going to have to restore a disk image of my drive.

    As of PGP 8.0, PGPnet/PGPvpn and PGPfire are not part of PGP - it was not included in the PGP Corporation purchase of PGP from NAI.


    Return to Tom McCune's PGP Page

    Return to Tom McCune's Homepage

    Comments or Suggestions: web@DELETE_THISmccune.cc

    Please notice that part of the above address needs to be removed.