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.

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
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:

Make backups of your PGP keyrings: pubring.pkr & secring.skr

Uninstall with Start-Settings-Control Panel-Add/Remove Programs

Go to the Windows\System (or System32) folder and delete
any remaining PGP
DLLs
(such as PGPdskSE.dll, pgpsdkUI.dll, pgpsdkNL.dll and pgp_sdk.dll)

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:

On the Email tab, check Word Wrap, and
set it for your needs, usually one or two spaces less than used in your
email and newsgroup software for line length. The other settings on
this
tab only apply to use of official PGP email plug-ins; uncheck Use
PGP/MIME When Sending Mail.

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.

Some PGP operations are noticeably slower than in prior PGP
versions, reportedly related to keyring file sizes (larger keyrings are
slower). This is now much improved.

The default location for your keyrings is a PGP folder in My
Documents. You can designate another location for your keyrings,
but even if you delete this PGP folder, it will reappear. This has been corrected.

PGP keyrings cannot be stored on a PGPdisk volume. This has been corrected for PGP 7.0.x, but is again a
problem with PGP 7.1, and yet is again fixed in PGP 7.1.1.

There are error messages on boot if your keyrings cannot be
accessed, such as if your keyrings are on a drive that your computer
cannot access at that time. This has been
corrected.

PGPtray must always be running. Your only choice is to set
a PGP Option to either show or not show PGPtray in the system
tray. It is now easier to add/remove the
PGPtray icon to/from the system tray, but PGP does not provide the
option to stop PGPtray from running (can use Ctrl-Alt-Delete).

Keyrings are always locked and you cannot copy them. This has been corrected (you may need to close
PGPkeys, PGPnet, and ICQ; and purge your passphrase), but for
the 7.0 version NAI advised:

"For systems *with* PGPnet installed: Use different
keyring files for PGP and PGPnet. If you are using a VPN
authentication key, you will need to copy this key into a different
keyring file (use the new File|Open or File|New menu items in PGPkeys)
and then point PGPnet to these new keyrings (with Options|Files).
This will result in the PGPnet keyring files being locked continuously,
but at least your PGP keyrings will behave more 'normally'.

For systems *without* PGPnet installed: Find your
"PGPnetPrefs.txt" file (not to be confused with "PGPprefs.txt").
On Win98 this file may be in \Windows\All Users\Application
Data\Network
Associates\PGP. It will be in analogous locations on other
OSes. Delete the "PGPnetPrefs.txt" file and reboot. Note
that this file will get recreated on reboot, but the new file will
contain more benign settings. At this point you should only
experience your keyring files being locked when you would normally
expect them to be (e.g. when PGPkeys is running, etc.)."

It is reported to use more system memory.

Direct CD is stated to be incompatible with PGPdisk.
Apparently, the only new issue is not being able to create a PGPdisk on
a CD. But you should be able to create a PGPdisk on your hard
drive and then move or copy it to a CD.

"PGP 7.0 is designed to run on all versions of Win2K (Pro,
Server, Advanced Server) and is routinely tested on all those
platforms. PGP 7.0 is designed to *not* run under a Terminal
Services client. There are many technical and security issues
involved when running PGP on a multiuser system like Win32 Terminal
Services. Given our limited resources here, and in the interest
of
security, it was decided to not allow PGP to run in this
environment.... PGP should run fine on the console of a server
which is acting as a Terminal Services server. It will refuse to
run under a Terminal Services client (no matter what mode)."
-NAI PGP 7.1.1 has added support for
"running PGPmail and PGPdisk through a Windows Terminal Server client."

Issues that remain with PGP 7.0.3:

When Windows users open a PGPdisk volume that was created with a
pre-7.0 version of PGP, the format of the file is updated - if you
return
to using a pre-7.0 PGP version, you will not be able to access that
updated PGPdisk volume.

The command line usage of PGP 6.5.x is no longer included with
the Desktop Security and Personal Security builds.

When Faster Key Generation is disabled, generating a 4096
bit DH key will probably take a much longer time than in prior PGP
versions. This is corrected in PGP 7.1.

Windows ME users are likely to get COMCTL32.dll errors when
opening Outlook Express, if the Outlook Express PGP plug-in is
installed.

Windows 2000 and Windows XP users
may receive error messages about "PGPsdk service" until they install
Client for Microsoft Networks. I'm aware of a Windows 2000 user
saying it is also necessary to "enable 'allow interact with desktop' in
the RPC service."

"In order for PGP client modules to communicate with the SDK securely,
certain Windows
OS services must be installed. In particular,
you need the NtLmSsp (NT LanMan Security
Support Provider) service. NtLmSsp is normally
installed by default.
On WinNT4, this service is bundled with the "RPC Configuration"
service. To install the
NtLmSsp service, do the following:
a. Go to Control
Panel-->Network-->Services.
b. Click "Add", and
then select "RPC Configuration" to be added.
On Windows 2000, this service is bundled with the "Client for Microsoft
networks".
To install the NtLmSsp service, do the following:
a. Right-click on "My
Network Places", and select "Properties".
b. Right-click on
"Local Area Connection", and select "Properties".
c. Click "Install".
d. Select "Client",
and then click "Add".
e. Select "Client for
Microsoft Networks".
f. Click "OK".
If you do not have any other networking components installed, you
will get the
following message:
"You must install and enable at least one protocol for this
connection to work. Do
you want to select a protocol now?" Note that a protocol
is NOT needed for the
PGPsdk Service to work correctly.
If you are installing "Client for Microsoft Networks" only for
PGP, you can disable
the service by
deselecting the check box next to it in the Components list."
-NAI

With Windows XP, there is a change in the order of loading system
processes. On some systems, this will result in this error
message continuing even after Client for Microsoft Networks is properly
installed. PGP 7.1.1 has been fixed to take care of this
problem. This may also be resolved by not starting PGPtray from
the StartUp folder and later loading it manually (I found it convenient
to move the shortcut from the StartUp folder to the Quick Launch Bar);
or by waiting a few minutes after the system boot to log in to the
system. Another PGP user reports "...another work around.
In
the services tool (Administrative Tools) you can double click on a
service namely PGP SDK Service and PGP Service and set what happens
when
they don't start. I set the SDK service to retry a minute later and the
PGP Service to also try again a minute later (which will be after the
SDK service error). I then only have to click the first error notice
and
do nothing else because they will both start when they can."

At
least for Win98 and WinME users, it is common to have freezes when
"Automatically wipe on delete" is set in PGP Options-General (reported
to be related to causing problems with MSGSRV32). Although I had
those problems on Win98SE and WinME, it worked flawlessly for me using
PGP 7.1.1 on WinXP Pro (FAT32). But, there are Windows created
problems
with using auto wipe on delete with EFS encrypted data, that were
corrected with a PGP 7.x hotfix.

If you have deleted or renamed rpcss.exe, DO NOT run
PGPnet/Personal Firewall - I thought I was going to have to restore
an image of the drive.

PGP 8.0 Annoyances?

Some of the above 7.0 Annoyances remain, in addition to the below
listing.

On installation, PGP 8.0 does not import preference settings
from
prior pre-8.0 installations.

Commercially licensed PGP products (Personal, Desktop,
Enterprise) will only function as the Freeware product until a
successful product activation process is completed. This is
easily
done over the Internet at the time of installation (basically,
this just verifies that a valid license number is being used), and can
be done by telephone (or by writing pgp-license-administrator@pgp.com)
when Internet access is not feasible. Activation
can
be avoided during a reinstall by using the PGPprefs.txt from your first
install.

After the Desktop and Enterprise products license expires (PGP
Personal has a perpetual license), they revert to functioning as the
Freeware product. If you need to temporarily reactivate the
Desktop or Enterprise product (such as to recover PGPdisk encrypted
files), you can set your computer clock back.

The Freeware product no longer includes email plug-ins (but will
continue to work fine with the Current Window feature via either
hotkeys
or PGPtray).

When installing PGP 8.0, you can install components whose use
may
not be included in your level of chosen licensing; if you then
try
to use one of them, you will be prompted to pay for the necessary
licensing. For instance, this will happen to a Freeware user who
tries to use one of the official email plug-ins, or PGPdisk. To
avoid this, only install components that will be active for your level
of licensing. If you later increase your level of licensing, you
can re-run the install file to add the other components.

Generating v4 RSA keys in the range of about 3000 to 3004 bits,
will most likely fail with an error message of "There is not enough
random data currently available." This is fixed with PGP 8.0.2.

Previously created PGPdisk volumes
might not be able to be opened: "PGP 8 uses UTF-8 (Unicode)
passphrases. With non-PGPdisk passphrases, for backward
compatibility, when you enter a passphrase containing non-ASCII characters
into PGP 8, PGP will try both UTF-8 and high-ASCII versions of the
passphrase to unlock your data. The code to try both versions of
passphrases was inadvertantly left out of PGPdisk 8.0 so that only the
UTF-8 version of the passphrase was used." -PGP Corp. This is fixed with PGP 8.0.2;
however, this fix was not applied to the PGPdisk re-encryption
process - so if your PGPdisk volume was created with an earlier PGP
version, and its passphrase contains high ASCII characters,
re-encrypting it might make your data inaccessible. PGP Corp
states this was completely fixed as of PGP 8.0.3.

PGP 8.0.2, but not prior versions,
will reboot your machine, without asking permission, upon conclusion of
its installation. It is wise to follow its instruction to close
open applications before starting the installation. This is fixed with PGP 8.0.3.

With PGP 8.0.3 (first release;
Freeware signed on 10/22/03), exporting multiple
selected keys from PGPkeys to a single .asc file will result in only
the last selected key actually being exported. PGP 8.0.3 was updated (Freeware
signed on 10/27/03) to correct this one problem.

PGP 9.x Issues?

If installing PGP 9.0 results in your no longer have Internet
access, try uninstalling your antivirus and/or software firewall.
If that then gives you access, you may well be able to then
successfully reinstall the uninstalled software. But, if you
instead then again lose Internet access, you may need to uninstall
again, uninstall and reinstall PGP, and then install your AV and/or
software firewall. Be sure to read the PGP 9.x Release Notes,
which are shown when you begin the PGP installation, and which can be
accessed after installation at Start - Programs - PGP- Documentation.

If installing PGP 9.0.x results in your not being able to
download
email, it may be due to your use of email antivirus scanning; this may
conflict with your use of PGP's email proxy. Personally, I prefer
to have my AV software set to scan all files upon access (real time
scanning) - when using such a setting, email AV scanning is unnecessary
redundancy (in my opinion).

With PGP 9.x, there is not the option of setting a "default key"
as there was in earlier versions. Each email service will prompt
you for a default key that largely takes care of this (at least for
signing). In addition, you can set a Master Key that serves the
default key purpose (for always encrypting to): PGP Options|Keys
tab|place a check for "always add these keys...."|Master Key List
button|drag (or double click) the desired key(s) to the Recipients box.

If you want to change your keyring location, open PGP
Desktop. In the PGP Keys control box on the top of the left side,
right click on All Keys and select Properties.

To consistently sign Xnews newsgroup posts that would verify with
9.0.x, I
found it necessary to increase the Xnews Wrap setting - I went up to 78.

If you use the PGP 9.x email proxy to sign email from an email
address not on your key, PGP defaults to adding that email address to
your
key. The reason for this is that when a PGP 9.x user receives
email from you, a PGP email proxy search for the signing key on the
Global
Directory will be by the sender's email address.

PGP 9.x has two passphrase cache settings. The
Options|General tab setting works as it did in prior PGP
versions. Each PGP Messaging service also has the option of
passphrase caching ("when I log in"). This is specific to the key
associated with each service, and such cached passphrase will remain
cached until you log out of Windows. According to the User's
Guide, one of these options needs to be set (even if just set for 1
second) for the email proxy to work
properly. Personally, I prefer to set the Options|General
setting, and not
the messaging service setting.

What I think is missing in the PGP email proxy use, is the
concept of non-repudiation. An example being where one is sent
important signed and/or signed and encrypted instructions (boss to
employee, bank account holder to bank, shopper to Internet shopping
service, etc.). The receiver of the email verifies it was the key owner
sending the email, and that the email was not altered. But, the
receiver of the email could not later prove this if the sender denied
having sent that specific email. I don't think the Email Proxy
processed message and the Messaging Log would really do that; and a
copy of the received signed and/or signed and encrypted email is not
retained anywhere.

Incoming and outgoing services in PGP 9.x can be separated into
two different services. Then either can be set to require
SSL and/or either can be disabled so that the PGP Email Proxy is not
used for that one service. If you want SSL used for your email
account, make sure that this is not set in your email client, so that
PGP Messaging can handle it. On
the POP service, leave the SMTP server blank and vice-versa.
Using this, I have PGP 9.x using SSL for my POP server, while
also having PGP use my non SSL enabled SMTP server properly. If
you want incoming email to be left encrypted on your computer, you can
disable the POP service, while leaving the SMTP service enabled.

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.

If a public key has the "preferred keyserver" set to something,
when encrypting to that key, the format will be PGP/MIME. If
the keyserver setting is set to None, PGP 9.x will use PGP
Partitioned. If your key is sent to the Global Directory via PGP
9.x, it will be set to having that preferred keyserver. If you
right click on your key, select properties, and set the keyserver
preference to "none," and then send it to the PGP Global
Directory via the web interface, the "none" setting will be
retained. Outlook w/ MAPI (Exchange) always sends PGP Partitioned.

If wanting to decrypt a file to the same folder, right click on
the encrypted file, and
select PGP Zip|Decrypt & Verify. If wanting to decrypt the
file to a different folder, double click on the file, enter your
passphrase, right click on the file in PGP Desktop, select Extract, and
browse to the folder you want the decrypted file in.

Eudora users may have difficulty handling special characters that
can
be remedied when using the PGP Email Proxy - see UTF8 to ISO plugin.

If using PGP Whole Disk Encryption, and also using third party
software to defrag, very seriously consider excluding PGPWDE01
(the PGP bootloader; PGP 10.x also has PGPWDE02 that should
addditionally be excluded) from the defrag. If it is moved to
another
sector of the hard
disk (PGP 9.5.x makes this much less likely), your WDE hard disk will
no longer be a bootable disk.

If having trouble using the Email Proxy with a Gmail account,
check this PGP
Forum article.

When encrypting from PGPtray Current Window usage, there is the
option to set the encryption to require the Secure Viewer for
decryption. Although the decryption of such messages via the
Current Window usage does use the Secure Viewer, decryption via the
Email Proxy does not.

In order to generate a keypair on the eToken Pro 64k, it may be
necessary to first temporarily disable the PGP Options setting of
Automatically shred when emptying the Windows Recycle
Bin. PGP 9.0.3 fixes this.

PGP 9.0 begins phasing out traditional v3 RSA keys. They
can no longer be generated, cannot be set for Implicit Trust, and
cannot be placed on the Global Directory. As of PGP 9.0.3,
traditional v3 RSA keys can again be set for Implicit Trust.

Be aware that if you have PGP synch keys with the Global
Directory, when a key in your public key ring is removed from the
Global Directory, that the
key may be automatically disabled, and email (via the Email Proxy) to
that address would therefore now be sent as clear text, instead of
being encrypted as in the past.

PGP 9.x Options (Keys tab) has only one key synching option - you
either have it enabled or you have it disabled. When disabled,
PGP will NOT automatically check a server for a public key needed to
verify a signature you are checking via Current Window usage (I'm not
sure about the email proxy use in this regard). However, when
enabled, PGP will also synchronize all your keys with all your
configured keyservers every time you log in - for this, it uses 25 to
47% of my Pentium D processor for about 5.5 minutes. This is greatly improved with PGP
9.5.x.

Some people report that a mounted PGP Virtual Disk volume does
not show as a drive in Windows Explorer. If experiencing this,
try this work around: use Ctrl-Alt-Delete to bring up
the Windows Task Manager, End the Explorer.exe process, and then reopen
Windows Explorer. Once when this happened to me, and this work
around did not work, I logged out and logged back in, and was
unpleasantly surprised to find that my previously cached PGP
passphrases were still cached.

If being bothered by having to enter your passphrase for sending
an email, even though the email is not using PGP in any way, be aware
that it is the Opportunistic Policy that causes this irritating
problem. One way to resolve it is to cache your passphrase. My way is
to disable the Opportunistic Policy, and replace it with a similar
policy (No Sign), but which omits the Sign action - it only encrypts
outgoing email. PGP 9.0.3
fixes this.

The PGPtray - Check for Updates had
originally worked well for me, even when using a Whole Disk Encrypted
machine. However, there have been some difficulties, such as with
the PGP Messaging
Accounts; at least twice I have found it necessary to delete (and then
re-create) one or more of the previously set up accounts - at least
once the email just no longer could be downloaded; and at least once
PGP was still downloading the email, but was no longer using SSL to
protect the email POP server password. Once, with PGP 9.0.x, it
was
necessary to download the updated PGP version from the original
download URL, and to install it from this newly downloaded installation
file.

If having Windows Hibernation
difficulties after installing PGP 9.0.x, see this PGP
Forum
thread.

On a few occasions, I have noticed
that when I have just added a key to my keyring (via either the email
proxy or Current Window usage) that the first email to that address
will not be encrypted by the PGP email proxy.

Periodically, and especially when
bringing my laptop out of standby, the email proxy use would prevent me
from being able to download email until rebooting. I seem to have
finally resolved this by opening System in the Control Panel, going to
the Hardware tab, selecting Device Manager, expanding Network Adapters,
right clicking on the network adapter, selecting Properties, going to
the Power Management tab, and removing the check for "Allow the
computer to turn off this device to save power."

An ongoing issue that had kept me
going back to using PGP 8.1 on my desktop is that at least daily the
PGP 9.0.x PGP Desktop would refuse to open. The best work around
I found for this was to place a shortcut for PGPdesk.exe in my
Startup folder and then to never close PGP Desktop. Since I kept
accidentally closing PGP Desktop because of it being on my task bar, I
started minimizing it to the Windows XP notification area (system
tray) with the help of Actual
Window Minimizer. I
have not experienced this since PGP 9.6.x.

PGP 10 Annoyances?

At least through 10.0.2 (the current version as of this writing),
PGP 10.x will not install and/or work properly if the My Documents
folder is not in the default location and the PGP keyrings are set to
be in this folder. There is a fix for this, but to obtain
it you must have a PGP support account.

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:

Public key sizes up to 4096 bits, which far exceeds the 3000 bit
"equivalency" for the traditional underlying 128
bit symmetric encryption.

You generate your own public/private key pair(s).

You can have multiple keys for different uses, and can replace a
key whenever desired.

It uses established and peer reviewed encryption algorithms.

PGP 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) is available for peer
review.

It is the de facto email encryption standard, with a large user
base.

It is free for personal (non-commercial) use.

You can securely communicate with users of other operating
systems, and with any email address.

All PGP encryption functions take place on your own computer,
with your private key(s) residing only on your computer.

PGP is public key encryption that does not require the
transmission of a secret passphrase (as in conventional encryption).

It allows conventional encryption if that is desired; it also
allows creation of a Self Decrypting Archive which lets you send
conventionally encrypted files to users of the same operating system
(32
bit Windows versions are compatible with each other) who don't have PGP
installed.

It includes use of digital signatures that assure that the
message/file
is not altered, and is from who it is suppose to be from.

There are official and third party plug-ins for popular email
programs that make it easy to use. The newer PGP 9.x and 10.x
Email Proxy is
nearly completely automatic/transparent and can be used by nearly any
email client.

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

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:

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:

Someone must have made this alteration to your public key, and
to
have distributed this altered key.

The person encrypting to you must be using this altered version
of your public key.

The person encrypting to you must have the unauthorized ADK on
their keyring.

The person who added the unauthorized ADK to your public key
must
somehow obtain the message/file being encrypted to you.

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

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.

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:

The recipient takes no action in regards to the received
“gibberish.”

The recipient does not include the “gibberish” in any outgoing
response.

The recipient encrypts his outgoing response to the original
sender (as long as the recipient is not fooled into encrypting the
"gibberish" to the interceptor's key).

The interceptor fails to intercept the plaintext response to the
original sender.

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:

The resultant 2**69 hash operations would still be significantly
greater security than offered by the 2**64 hash operations of MD5.

This attack applies to digital signatures, but has nothing to do
with the security of PGP's encryption. It is as secure as it ever
was.

This attack has nothing to do with forging the signature of
another PGP user.

Any email or file you have signed remains valid, and this attack
will not allow any undetected change to something that has been signed
by your PGP key (but see below).

Where the concern might be valid is if someone possessing a vast
amount of computing power (such as the NSA) wants to produce two
differing documents that hash to the same value (a birthday
attack). This could
possibly lead to a contract being submitted to you with one set of
conditions that has been properly signed; and the sender later
presenting a contract with a different set of conditions that has the
same hash value. The result would be that when taking such a
signed document to court, it is not possible to determine which signed
document is valid and enforceable. However, even this should be
easily avoided by your never signing such a contract (prepared by
someone else) until you have made some unpredictable minor alteration
to it.

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.

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.

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:

RSA 512 bits 3
lines

RSA
1024
5
lines

RSA 2047/2048 7 lines

RSA
3100 10 lines

RSA
4096 13 lines

RSA
8192 23 lines

RSA
16K 45 lines

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.

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:

The PGP 5.x Exchange/Outlook plug-ins should not be used with
Outlook 98. With the Outlook 98 beta versions, it was confirmed
that sending an encrypted HTML message would sometimes result in an
unencrypted HTML copy of the message also being sent.

PGP
7.0 Outlook Plug-in Flaw: "there appears to be a bug that causes
PGP
7.0 Outlook Plug-in running on Outlook 98 connected to an Exchange
Server to automatically save decrypted messages as decrypted when the
recipient chooses to reply to a PGP encrypted message. This occurs only
when the user has the PGP Mail option to "Automatically decrypt/verify
when opening messages" checked, and "Always use Secure Viewer when
decrypting" is not checked." This is reported to affect PGP 7.0
through 7.1, but to be corrected as of PGP 7.1.1.

PGP
Outlook plugin has major security hole: "A malicious e-mail can
create a buffer overrun in Network Associates' PGP plugin for MS
Outlook
on Windows, which in turn can be used to run arbitrary code with the
user's level of privilege." This applies to PGP versions 7.0.3
and
7.0.4; NAI released a hotfix.

A Remotely
Exploitable Buffer Overflow exists for Windows PGP 7.1.x users of
the Outlook plug-in. The NAI released
PGPhotfix_OutlookLFN_20020828.zip took care of this.

It is reported:
“Whenever the Outlook (with PGP integrated into it) client crashes it
will core dump its memory content into a file (drwtsn32.log), this file
has been found to contain the password used by the encrypting user in
plain text.”

With Outlook 2003 (with PGP 8.0.3 & 8.1), outgoing
encrypted messages may actually be sent in plaintext unless "Convert to
plain text before using PGP" is set Outlook 2003.

OUTLOOK EXPRESS:

Sometimes when using Outlook Express 5.0 and having installed
PGP
6.5.x with the OE plug-in, the PGP icons do not appear on the editor
task bar, and therefore you cannot use the plug-in to sign and/or
encrypt email messages. This problem is caused by too many icons
(buttons) being on the task bar, and therefore some simply cannot be
seen. It might be possible to rectify this problem by enlarging
the Outlook Express editor window (pulling the windows corners, or
maximizing OE windows) or using a higher screen resolution. I'm told:

"The cure is to go to View - Edit Taskbar *in the editor window* and a
sort of table appears and one can shift icons from and to the taskbar
as
one likes. Mostly the job is done by removing only the two s/mime
icons. The taskbar will shrink sufficiently so the PGP icons will
be shown even when 'big' icons are selected as choice. Similarly
if someone selects the small icons, the problem is generally solved,
the
new PGP icons will appear next to the s/mime one."

I'm told that
the PGP 6.0.2 plug-in for Outlook Express works with Outlook Express 4,
but not Outlook Express 5.

Clearsigned messages may not verify due to line wrapping in the
Reader window. Try right clicking in the message window and
de-selecting Wrap Long Lines; or go to Tools-Options-Reader Settings,
and set Right Margin for Wrapping and Reformatting to something large
(I
use 90).

I'm not sure it is still necessary, but in recent versions, some
encryption would fail if Tools-Options-Sending Mail was not set for
Send
Enclosures Instead of Attachments.

To assure proper line wrapping, you should go to
Tools-Options-Message Settings, and set Use Exact Character Measurement
for Right Margin.

If using PGP 6.0.2ckt builds 6 or 7, it is necessary to use the QDPGP plug-ins
intended for PGP 6.5.x, rather than those designated for
6.0.x.

If you need to verify a PGP/MIME clearsigned message, first
right
click on the unopened message, select Message Properties, and de-select
Is a Valid MIME Message.

CAUTION: I'm told that if PGP
plug-in users have entered their PGP passphrase through Pegasus Mail's
built-in passphrase dialog, and have checked the "Encrypt" box in the
message editor window, and then save the message to disk, that both the
message and the passphrase are written to disk as plain text. It
seems likely that under these conditions, that the "Automatically save
messages in progress" Options-General setting would have the same
effect.

With the QDPGP
plug-in for PGP 7.x: "One potential problem with
the 2.65 version is that it relies on a certain function in the updated
SHELL32.DLL. The original win95 or NT4 (without the shell integration
of
IE4) version of SHELL32.DLL lacks this and windows will not load the
plug-in DLL if it cannot find the function." This appears related
to the PGP 7.x minimum system requirement of "Windows 95B (OSR2),
Windows 98, Windows Millennium, Windows NT 4.0 with Service Pack 4 or
later, Windows 2000, or Windows 2000 with Service Pack 1."

Pegasus Mail 4.x (but not prior versions) are unable to properly
use
PGP's Current Window usage (but the signed and/or encrypted message can
be
manually pasted back).

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.

For maximum security, the asymmetric encryption strength should
be greater than the underlying symmetric encryption. The 4096 bit
public key is much larger than the 3000 bits considered equivalent to
128 bit symmetric encryption.

Traditional v3 RSA keys use MD5 for the hash in creating digital
signatures,
and
there is some
evidence that it might be possible to forge a message
substitute for one that was signed using MD5. DH/DSS keys use
the more secure SHA1
for the signature hash.

DH/DSS keys produce a smaller message digest that is less likely
to be annoying to others (especially so for people who do not use PGP)
when used for clearsigning messages.

If only using one key, this may be the best choice for
balancing security and backward compatibility.

4096/2048 RSA:

In PGP 7.1-8.1, these v4 RSA keys will use SHA1 for the hash when
signing. This lets you have a higher security level of digital
signatures, because it lets you use the better SHA1 hash with
keys larger than the maximum
1024
bit signing key used with DH/DSS keys.

In PGP 9.x and 10.x, these v4 RSA keys default to using the even
stronger
256 bit SHA2 hash; PGP 8.1 (but not earlier versions) can verify such
signatures. PGP 9.x also allows use of SHA2-384 and SHA2-512 for
v4 RSA keys (as well as MD5, RIPEMD-160, and SHA1), but the larger SHA2
options offer no backwards compatibility.

For best backwards
compatibility, the v4 RSA signing key should not be larger than 2048
bits - PGP 6.x versions cannot use RSA keys larger than 2048
bits. Additionally, the signature block of RSA keys larger
than 2048 bits is annoyingly large when clearsigning; and since the
SHA1 signing hash (used in PGP 7.1 through 8.1) is 160 bits, a larger
signing key is of questionable
benefit (due to birthday attacks reducing this signature hash to an
effective 80 bits).

To have a 4096/2048 bit RSA key in PGP versions 7.x and 8.x:

Generate a 2048/2048 bit RSA key.

Right click on the key in PGPkeys, and select Key Properties.

On the Subkeys tab, click the New button (Add button in PGP 9.x
and 10.x);
and generate a new 4096
bit subkey.

Then click on the original subkey and click the Remove button.

2048/2048 RSA:

This is the default key in PGP 9.x and 10.x.

The above 4096/2048 RSA advantages apply, except that the smaller
2048 bit encryption key allows it to be used on devices with limited
power, such as smartcards and BlackBerrys.

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.

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.

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

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 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:

To format a PGPdisk volume NTFS, you must be using an
adminstrator account in either Windows 2000 or Windows XP.

To have Read Only access to a PGPdisk volume, you must NOT have
it formatted NTFS. Read Only access is necessary for opening a
PGPdisk volume from a CD, and during the short grace period after the
PGP Workgroup Desktop license expires.

On an NTFS drive, you can mount the PGPdisk volume as a folder
instead of a drive, if you wish to. But, make sure you do NOT
have any files in the folder (it must be empty), and make sure you do
NOT simultaneously open the PGPdisk volume as both a folder and a
drive. When mounted as a folder, you may not be able to delete
folders it contains, but this can be resolved by holding down the Shift
key when hitting the Delete key (this makes deletions bypass the
Recycle Bin) for the folder deletion.

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.