The comp.security.pgp FAQ
- 4.1 Which key size should I use?
- 4.2 Why does PGP take so long to add new keys to my key ring?
- 4.3 How can I extract multiple keys into a single armored file?
- 4.4 I tried encrypting the same message to the same address two times and got completely different outputs. Why is this?
- 4.5 How do I specify which key to use when an individual has 2 or public keys and the very same user ID on each, or when 2 different users have the same name?
- 4.6 What does the message "Unknown signator, can't be checked" mean?
- 4.7 How do I get PGP to display the trust parameters on a key?
- 4.8 How can I make my key available via finger?
- 4.9 Should I put my key in my .signature?
- 4.10 Can a public key be forged?
- 4.11 How do I detect a forged key?
4.1 Which key size should I use?
PGP gives you three choices for key size: 512, 768, or 1024 bits. You
can also specify the number of bits your key should have if you don't
like any of those numbers. The larger the key, the more secure the
RSA portion of the encryption is. The only place where the key size
makes a large change in the running time of the program is during key
generation. A 1024 bit key can take 8 times longer to generate than a
384 bit key. Fortunately, this is a one time process that doesn't need
to be repeated unless you wish to generate another key pair.
During encryption, only the RSA portion of the encryption process is affected
by key size. The RSA portion is only used for encrypting the session
key used by the IDEA. The main body of the message is totally
unaffected by the choice of RSA key size. So unless you have a very
good reason for doing otherwise, select the 1024 bit key size. Using
currently available algorithms for factoring, the 384 and 512 bit keys
are just not far enough out of reach to be good choices.
If you are using MIT PGP 2.6.2, ViaCrypt PGP 2.7.1, or PGP 2.6.3i, you
can specify key sizes greater than 1024 bits; the upper limit for
these programs is 2048 bits. Remember that you have to tell PGP how
big you want your key if you want it to be bigger than 1024 bits.
Generating a key this long will take you quite a while; however, this
is, as noted above, a one-time process. Remember that other people
running other versions of PGP may not be able to handle your large
There is a small bug in some versions of MIT PGP 2.6.2, which will
actually create a 2047 bits key when you ask for a 2048 bits one.
4.2 Why does PGP take so long to add new keys to my key ring?
The time required to check signatures and add keys to your public key
ring tends to grow as the square of the size of your existing public
key ring. This can reach extreme proportions, especially if you are
trying to add the entire public keyring you retrieved from a keyserver
(see question 8.1
) to your own keyring.
In this case, it might be faster to rename your public keyring to something
else, then name the keyserver's keyring "pubring.pgp" and add your
own keyring to the big one. There is a danger to this, though; the
trust parameters to your old keys will be lost, and you will be using
the trust parameters from this big keyring.
4.3 How can I extract multiple keys into a single armored file?
A number of people have more than one public key that they would like
to make available. One way of doing this is executing the "-kxa"
command for each key you wish to extract from the key ring into
separate armored files, then appending all the individual files into a
single long file with multiple armored blocks. This is not as
convenient as having all of your keys in a single armored block.
Unfortunately, the present version of PGP does not allow you to do
this directly. Fortunately, there is an indirect way to do it.
pgp -kx uid1 extract
pgp -kx uid2 extract
pgp -kx uid3 extract
This puts all three keys into extract.pgp. To get an ascii amored
pgp -a extract.pgp
You get an extract.asc. Someone who does a
pgp extract and has
either file processes all three keys simultaneously.
A Unix script to perform the extraction with a single command would be
for name in name1 name2 name3 ... ; do
pgp -kx $name /tmp/keys.pgp <keyring>
An equivalent DOS command would be:
for %a in (name1 name2 name3 ...) do pgp -kx %a keys.pgp <keyring>
4.4 I tried encrypting the same message to the same address two times and got completely different outputs. Why is this?
Every time you run PGP, a different session key is generated. This
session key is used as the key for IDEA. As a result, the entire
header and body of the message changes. You will never see the same
output twice, no matter how many times you encrypt the same message to
the same address. This adds to the overall security of PGP.
To generate this random session key, PGP will try to use information from
a file called 'randseed.bin'. If this file does not exist, or for some
reason isn't random enough, you are asked to type in some random keystrokes
which will then be used as a "seed" for the random number generator.
4.5 How do I specify which key to use when an individual has 2 or public keys and the very same user ID on each, or when 2 different users have the same name?
Instead of specifying the user's name in the ID field of the PGP
command, you can use the key ID number. The format is 0xNNNNNNNN where
NNNNNNNN is the user's 8 character key ID number. It should be noted
that you don't need to enter the entire ID number, a few consecutive
digits from anywhere in the ID should do the trick. The key ID shows
up directly after the key size when you do
pgp -kv userid
Be careful: If
you enter "0x123", you will be matching key IDs 0x12393764,
0x64931237, or 0x96412373. Any key ID that contains "123" anywhere in
it will produce a match. They don't need to be the starting
characters of the key ID. You will recognize that this is the format
for entering hex numbers in the C programming language. For example,
any of the following commands could be used to encrypt a file to my
pgp -e <filename> "Arnoud Engelfriet"
pgp -e <filename> firstname.lastname@example.org
pgp -e <filename> 0x416A1A35
This same method of key identification can be used in the config.txt
file in the "MyName" variable to specify exactly which of the keys in
the secret key ring should be used for encrypting a message.
4.6 What does the message "Unknown signator, can't be checked" mean?
It means that the key used to create that signature does not exist in
your public keyring. If at sometime in the future, you happen to add that
key to your public keyring, then the signature line will read normally. It
is completely harmless to leave these non-checkable signatures in your
public keyring. They neither add to nor take away from the validity of the
key in question.
4.7 How do I get PGP to display the trust parameters on a key?
You can only do this when you run the -kc option by itself on the
entire database. The parameters will not be shown if you give a
specific ID on the command line. The correct command is:
pgp -kc smith will not show the trust parameters for
4.8 How can I make my key available via finger?
The first step is always to extract the key to an ASCII-armored text
. After that, it depends on what type of computer
you want your key to be available on. Check the documentation for
that computer and/or its networking software.
Many computers running a Unix flavor will read information to be
displayed via finger from a file in each user's home directory called
".plan". If your computer supports this, you can put your public key
in this file. Make sure the file is world-readable, use
644 .plan if other people can't get at your plan. The home
directory also has to be accessible. Use
chmod +x . in
your home directory to do this.
Contact your system administrator if you have further problems with
4.9 Should I put my key in my .signature?
No. Although it is important to spread your key as far as possible, it
is a lot better to send it to a keyserver (see 8.1
to make it available via finger (see 4.8
), or perhaps as
a link off your WWW homepage. This way, people who need your key will
be able to get it, and you don't send it out to a lot of uninterested
people every time you mail or post something.
Additionally, keep in mind a snooper reading your outgoing mail can
easily change the public key in there with his own fake key. Then he
can still read the messages sent to you. If the other party gets your
key from a different location with a different method, it is a lot harder
for that snooper to change the keys. (Note that signing the message
containing the key will not help; the snooper can easily re-sign the
message with his key).
4.10 Can a public key be forged?
There are four components in a public key, each of which has its own
weaknesses. The four components are user IDs
, key IDs
and the key fingerprint
The user ID
It is quite easy to create a fake user ID. If a user ID on a key is
changed, and the key is then added to another keyring, the changed user
ID will be seen as a new user ID and so it gets added to the ones
already present. This implies that an unsigned user ID should never
be trusted. Question 6.3
discusses this in more detail.
The key ID
It is possible to create a key with a chosen key ID.
Paul Leyland <email@example.com> explains:
A PGP key ID is just the bottom 64 bits of the public modulus (but
only the bottom 32 bits are displayed with
pgp -kv). It
is easy to select two primes which when multiplied together have a
specific set of low-order bits.
This makes it possible to create a fake key with the same key ID as
an existing one. The fingerprint will still be different, though.
By the way, this attack is sometimes referred to as a DEADBEEF attack.
This term originates from an example key with key ID 0xDEADBEEF which
was created to demonstrate that this was possible.
There are currently no methods to create a fake signature for a user
ID on someone's key. To create a signature for a user ID, you need
the signatory's secret key. A signature actually signs a hash of the
user ID it applies to, so you can't copy a signature from one user ID to
another or modify a signed user ID without invalidating the signature.
The key fingerprint
Yes, it is possible to create a public key with the same fingerprint
as an existing one, thanks to a design misfeature in PGP.
The fake key will not be of the same length, so
it should be easy to detect. Usually such keys have odd key lengths.
Paul Leyland provided the following technical explanation:
Inside a PGP key, the public modulus and encryption exponent are
each represented as the size of the quantity in bits, followed by
the bits of the quantity itself. The key fingerprint, displayed by
pgp -kvc, is the MD5 hash of the bits, but NOT of the lengths.
By transferring low-order bits from the modulus to the high-order
portion of the exponent and altering the two lengths accordingly, it
is possible to create a new key with exactly the same fingerprint.
4.11 How do I detect a forged key?
As explained in question 4.10
, each component of the public
key can be faked. It is, however, not
possible to create a
fake key for which all the components match.
For this reason, you should always verify that key ID, fingerprint,
and key size correspond when you are about to use someone's
key. And when you sign a user ID, make sure it is signed by the key's
Similarly, if you want to provide information about your key, include
key ID, fingerprint and key size.
Table of Contents |
About this FAQ |
Copyright © 1996 by Arnoud Engelfriet.
Last updated: 22 Oct 1998.
Comments, additions and suggestions can be sent to <firstname.lastname@example.org>.
This FAQ was generated by Orb v1.3 for OS/2.