Different versions of PGP show considerably different reactions when being confronted with public keys which have been subsequently manipulated. Especially a subsequent contamination of a public key with another person's key will not be noticed and rejected if you use newer versions of PGP, but will be used to produce encrypted messages which can be read in plaintext by everyone who has the secret key corresponding to the key which was smuggled into the original one. This manipulation will not be detected when using some newer versions of PGP and will not be noticed until users are going to have a detailed look at the bytes of the manipulated keys. This study helps to understand this threat, to find out experimentally how a specific version of PGP reacts, and to avoid being cheated with manipulated keys.
The Curse of Additional Decryption Keys
Since Diffie-Hellman/ElGamal-keys have been introduced with PGP-5.x in 1997
the valuation of PGP became more and more complex. Not only new
cryptographic methods, different ciphers for encryption and a new
digital signature standard (DSS) with a different public key cryptosystem
had come up whose security and reliability had to be compared to the
already well-known RSA-keys which brought some confusion about necessary
key lengths but also
NAIs engagement with the
key recovery alliance (KRA)
and the introduction of Additional Decryption Keys (ADKs) for data recovery
by a third party - sometimes called Corporate Message Recovery (CMR) -
made it extremely difficult for most users to decide which version of PGP
they should use to ensure safe performance and to avoid unwanted
side-effects.
Additional Decryption Keys had got into the center of criticism because
they are linked to a user's public key in a way that every attempt to use
the user's public key for encryption would result in an additional
encryption of the plaintext using the ADK. Therefore no access to the
user's secret key was needed to recover the plaintext by decrypting
the message with the ADK, a key which was clearly meant not to be in
control of the user.
Criticism has focussed on the fact that the link between a user's
key and a third-party-ADK creates a perfect means of surveillance
of the user's encrypted communication and data, which would effectively
result in third-party-access to plaintext as had been pursued previously
by key escrow. Same effect but presented to the user in a nicer way.
If you do not find anything wrong with ADKs or even if you are happy
with this new feature of data recovery
the substantial analysis of the risks of third party encryption
done by some eleven experts in cryptography might spark some doubts
concerning ADKs.
But if you consider Additional Decryption Keys as a serious threat to
privacy - as I do - you might have asked yourself or others some of the
following questions without coming to satisfying conclusions:
How can you be sure? You are confronted with different key-formats
and you will probably not know all the implications or you will not have the
knowledge in matters of cryptography and coding to judge for yourself.
Whose expertise would you trust?
Is NAI's (or Zimmermann's) assessment on the matter trustworthy after all
the confusion they had helped to create with the new versions?
There always is the hope a newer version of PGP will correct flaws and
problems of older versions but how can you be sure the newer one does not
create more problems by replacing well-approved components by fashionable
ones?
Trust in the latest version can be deceptive as long as you have no
evidence.
But what could possibly serve as a source of evidence for a sound valuation
you are looking for so desperately?
The obvious answer would be: A competent and trustworthy expert
with a good reputation both in the field of cryptography and as a
privacy activist should scrutinize the source code of the latest
version of PGP and should sign it after all doubts concerning trap-doors
and malfunction have been destroyed by thorough analysis.
Although I think it to be possible to find such persons I doubt that
they could do what you expect because their judgement would have to
include the valuation of the cryptographic quality of a complex
software system whose source code had been growing rapidly the
current release reaching a couple of megabytes. No expert who wishes to
be taken seriously would expose himself to the risk of having missed
some detail or having misinterpreted some functionality relevant to the
security of the whole complex system. So we cannot expect someone
to play this part which clearly shows the curse of ADKs again.
On the other hand we cannot just ignore the dangling threat of surveillance
ADKs have imposed on PGP simply by putting blind trust into every new
version of PGP.
The Experimental Approach
What else can we do?
As someone with some experience in natural sciences I would like to suggest
to take the scientific approach to the problem and simply put different
versions of PGP to the test how they deal with manipulated public keys
to show a way out of the uncertainty of the present situation.
Not what somebody says they will do but rather what they really do should
be the base for a reliable decision on PGP.
I know all results of experimental research only show some detail and
great care should be taken when generalizing these facts.
I know as well - as David Hume would put it - that every generalization
is false. But to find out how different versions of PGP really react to
experiments designed according to a scientific analysis to me seems
to be a way out of the disaster.
At least the experimental approach provides the user with a method,
This I hope is more than most of the users of PGP are having at the moment.
Key-Experiments: A Summary of the Results
Additional Decryption Keys have been justified especially by
Jon Callas, Chief Scientist of Pretty Good Privacy Inc.
as a solution for data recovery which will help to prevent government
regulation on cryptography. Mr. Callas emphasized his point that
an ethically built data recovery software must be surveillance-surely and
must be an »opt-in«-system. Linking ADKs to a user's
private key should not be possible without the user's consent and in
full control of the user, an option you can use if you like and which will
require your consent to be active. Furthermore ADKs were designed
for use within a closed group of individuals, i.e. in a company and will not
affect the use of user's keys who do not wish to benefit from ADKs.
But the results of my experiments with manipulated PGP-keys clearly show
the alarming truth, that this appeasement is completely untrue, because
many users who don't have consented to the use of ADKs simply have no
reliable means to protect their keys against subsequent manipulations
which contaminate their keys with working ADKs. To have your key
ADKed without your knowledge requires no »opting-in«.
And this for sure should never have happened.
To suit the impatient reader I would like to summarize some of the essential
results of my experiments and the conclusions which follow inevitably
from these experiments before I go into greater detail.
The following chapters will give detailed information on how
signatures and keys are built and will describe the experiments I have
performed in some detail.
If you like to continue directly with the comprehensive
discussion of the consequences you can
skip the following chapters.
Understanding Keys and Signatures
To understand how Additional Decryption Keys actually work and how
public keys can be manipulated to hold new ADKs I have to take you
into some details about the way PGP stores its information in a
public key block. But at first we have to consider the differences between
the new format in which those information is stored and the classic old one.
Because of the fact that you can only find little information about the
structure of PGP-keys
the document that describes the OpenPGP-standard published as
RFC-2440 was of great help for me even if it contains not a single
sentence which deals with ADKs.
When PGP-5.x was introduced the way keys were stored and signatures were made
changed dramatically. The new format internally became known as Version-4,
while the classic old format, PGP-2.6x had already used, was called
Version-3, strange but so it is.
As you might know with PGP-5.x (Version-4 format) the following new features
came up:
Therefore a RSA-key will have a different fingerprint and a different
Key-ID in both formats even if the essential key-material,
the modulus and the encryption numbers are identical.
You can think of all information in a public key block as stored in
a sequence of packets of data. Every packet consists of one byte which
defines the type of the packet followed by an information on the length
of the packet (2 bytes) followed by the rest of the data.
If you look at the packets which define the key-material the differences
between Version-4 and Version-3 key-packets are not too impressive.
Both start with the byte 153, which indicates a public-key-packet.
Version-4-subkeys would start with 185. The next two bytes define the length
of the whole packet in bytes and the third shows the version-number.
The following four bytes give a number that indicates the key's
time of creation measured in seconds since 1.1.1970. Version-3-keys
then have two bytes which indicate the expiration time in days after
creation and these two bytes are missing in the Version-4-format.
The next byte gives the public key algorithm which can be RSA=1 for both
and ElGamal=16 or DSS=17 for Version-4-keys. The rest of bytes hold
"the essential key-material" which is two Multi-Precision-Integers for
RSA and with Version-4-keys two, three, or four respectively.
A Multi-Precision-Integer is a very long number with the length in bits
stored in the first two bytes followed by all the bits that make up the
entire number.
As you can see a classic Version-3-RSA-key can easily be transformed
to Version-4-format by deleting the expiration time, changing the version
byte to 4 and decrementing the lower length bytes by two. Voila.
A more dramatic change had been introduced in the field of signatures.
The new signature-format is not only much more complex than the old
signatures but at the same time it has become much more "open",
unfortunately open for abuse as well.
Let me summarize some of the more important changes in the
V-4-signature-format:
But have a look at the following comparison:
As you can see Version-3 or classic signatures have no complicated design,
after the usual byte 137 or 136 which identifies a signature and the packet
length they contain a block of data comprising the version number and 5 bytes
of data , the type of the signature, that means whether it signs a text
or a key or a key with a user-ID, and the creation time.
This block of 7 bytes will be hashed together with the data to be signed and
will be protected by the signature. The rest of the signature-packet is
the signer's key-ID, the public-key-algorithm and hash-algorithm, which
always is RSA and MD5, and the first 16 bits of the 128-bit hashvalue
which is encrypted with the signer's secret key and stored as a MPI at the
end of the packet.
Version-4 keys have a similar structure starting with a 4 byte block
including type and algorithms but without creation time. This block is
hashed with the signature. Following this block there is a field of
data with variable length containing any number of signature-subpackets
which can hold a vast variety of additional information. Usually the
creation time is included as a subpacket of type 02. All those subpackets
are hashed as well and every information placed here is protected by
the signature.
Another field of information which also can hold any number of
signature-subpackets follows the first field. But unlike the first field
all information in the second will not be hashed and therefore
nothing stored here is protected by the signature. That clearly means,
that data in this field, I call it the NON-HASHED FIELD of a signature,
can be changed without any change of the validity of the signature.
Changes in the first field will inevitably result in a corrupt signature,
but changes in the second will not.
The rest of the V4-signature-packet simply holds 2 bytes of the hashvalue
which now might be created using SHA1 instead of MD5 and one (RSA) or more
MPIs (DSS) for the encrypted signature data.
Looking for the Additional Decryption Key
Where would an Additional Decryption Key be stored?
Before I started to analyse the bytes of a public key block I suspected
it to be part of the "key" in one way or another. But as we now know,
where should it hide? Even V4-key-packets can only be expanded at the end
of the packet where MPIs are stored. V3-key packets have a fixed length with
only one MPI at the end.
To answer this question I would like to refer to the fact that as early as
1997 Kai Raven had drawn the attention of the public to the existence of
Corporate Message Recovery Keys (CMRK) in his excellent
PGP manual for beginners published in German. He presented a
file to download with two keys, one containing an ADK called
"CMR User" and the corresponding public key "Little Brother".
I would like to invite you to have a closer look at the bytes of the first
key which contains an ADK. Here it is , don't be startled, I will
unveil all the mystery in a second :
May I take you to the bare bone, bytes 355 to 455 of the self-signature
packet, in detail:
The first one has length 5 (in green) and subpacket-type 2 (in brown), which
is the signature creation time stored in the following 4 bytes as usual.
By the way the time is (((((52*256)+77)*256)+70)*256)+30 = 877479454
seconds since January 1st 1970.
The second subpacket is 23 bytes long and of type 10, as you might remember
the OpenPGP-draft states "placeholder for backward compatibility", following
some 22 bytes of information. The first one 128 makes sure, that the ADK
which is stored here will be "required", not only "welcome", to be used
the second one 17 states that the ADK is a DSS-key and the following
20 bytes hold the fingerprint of the ADK to use:
The last 4 byte subpacket of type 11 holds the preferred algorithms for
symmetric encryption.
To complete our analysis, the next bytes are the NON-HASHED subpackets
with only one 9 byte long packet of type 16 which holds the 8 bytes of the
signer's key-ID, that is 34A46056EE4230E3. Note, that only the last 4 bytes
appear as the key-ID 0xEE4230E3. The following last two packets hold
a 160-bit MPI each, which makes up the encrypted hashvalue, called
signature-r and signature-s.
After having located the ADK in the self-signature we now can use it to
encrypt a text for the user
"CMR User" which we can analyse with GnuPG.
How to Manipulate Keys
After fiddling with bytes and packets it is now time to get the bigger
picture into view again. Is it possible to manipulate keys in a way
so that new ADKs can be placed into them after the user has signed the key?
What will be the answers to the questions I have mentioned earlier?
And how can they be found with the experimental approach?
Let me give you a brief outline of the way I hope to get satisfying
answers through experiments with manipulated keys.
Before I started I had to create a key-editor, a simple tool to replace
a specific byte in a key, to delete and insert some bytes into a key.
Starting with the key I have got from Kai Raven (key-A) I created a
sequence of variations of this key. At first I made little changes to
the creation time, to the fingerprint of the ADK (key-A1)
to see if PGP did really take notice of the manipulations.
The obvious method for getting your own ADK into an existing one would be to
overwrite the whole fingerprint of the existing ADK with your own
ADK-fingerprint (key-A2).
I created a DH-key (key-C) "control" for that purpose serving as my own ADK
with "key-C" as the passphrase for the secret key.
Do not say that cannot work because the signature is destroyed. I had to
prove if it really does not work.
A more sophisticated method would be to try to transfer the ADK-subpacket
from the hashed field to the unhashed one still in the self-signature
(key-A3) and then to replace the old ADK for "Little Brother" with my new one
for "control" (key-A4).
When I found this working I was horrified and created a new DH-key (key-B)
for "Billy Clean" without an ADK in the self-signature in order to see if I
could contaminate this clean key with my "control"-ADK as well (key-B1).
The next keys (key-B2 and key-B3) should prove whether or not such an
ADK can successfully be placed into a signature of a certification
authority.
So I had to create a DH-key for my "Test-CA" (key-G) with the passphrase -
yes you guessed it - "key-G".
The next test was to try to contaminate an old-style RSA-key with my new
ADK "control". This gave rise to another sequence of keys starting with
a new RSA-key for user "Eddie Clean" (key-E) which was an old fashioned
key in V3-format with a V3-self-signature. This key mutated to key-F, which
holds exactly the same key-material (i.e. n and e), but was transformed
into V4-format still having the V3-self-signature. But because of the new
format, key-F has a new key-ID and a new longer fingerprint. To get this
transformation done I had to make the passphrase for key-E (and for key-F
as well) empty, because Version-4-secret keys do encrypt the passphrase
differently, which took me the best part of a day to find out.
The key-F1 was created from key-F by deleting the old key-ID "Eddie" and
adding "Freddie Clean" subsequently signing the keys with a lovely
V4-signature. Now this key has a correct self-signature and is stored in
V4-format still without any ADKs. Applying the same method of contamination
I managed to add my DH-ADK "control" to that key (key-F2), but suspecting
that this might not work because of cross-community-keys I created a
V4-RSA-ADK called "datarecovery" (key-D) with an empty passphrase for
the secret key in the same way I had produced key-F.
So key-F3 would have this new RSA-ADK added but still got the
algorithm-information of 16=DSS in it which I changed to 1=RSA in key-F4.
And after having performed intense tests on different versions of PGP
with these keys the answers to the questions I mentioned did actually
become clear to me but not in the way I was expecting.
The Keys for Experiments
To guard you through the experiments I will supply you with a detailed
summary of all the keys I have created and their manipulated variations
designed for the experiments. Each line provides two links one to a
readable and of course printable description and one to the key itself.
You can also use
this file containing all the keys and their documentation.
The Candidates for the Test
I have selected the following versions of PGP for the tests, most of
them compiled from the source code on SuSE-Linux.
Running the Experiments
Because of the fact that this chapter contains all the experimental data
I have collected, it is full of details and should be read as the
records of the experiments.
I have tried to present the data as readable as possible
leaving the interpretation of the experimental results to the next
chapter.
I will present the experiments in chronological order.
And you can find the fingerprints of
all binary data produced during the
experiments in this file.
Key-F
No ADKs were shown and the
cryptograms use one single encrypted
session-key only.
Removing the ADK from the recipient list gives rise to the following
warning:
It is easy to see why a satisfying answer to those questions is extremely
difficult to achieve.
Is the absence of a warning
proof of the fact that everything was going the way you wanted it?
And would you be regarded as an old-fashioned
anachronist blind to the future of modern cryptography
exposing yourself to becoming a laughing stock?
Where to find the ADK
When I started analysing the bytes of a public key which already had
an ADK I found the ADK sitting in the self-signature. It is a piece
of information of only 24 bytes the last 20 bytes holding the
fingerprint of a DSS/DH-master-key.
This key produced a cryptogram which comprised a second packet
with the session-key encrypted with the subkey of the DSS/DH-key
whose fingerprint was in the ADK.
Placing new ADKs into Diffie-Hellman/DSS-Keys
After having created my own DSS/DH-key for use as ADK I created a
similar subpacket of information with the fingerprint of my ADK and
placed it in the original key outside the data which was included in
the signature and got a cryptogram which was readable using my
ADK's secret key. I then found that every new DH-key being created
without ADKs could be contaminated with ADKs in the same way.
Transformation of RSA-keys
To apply the same test to RSA-keys I had to create a user's RSA-key
with the new type of self-signature which turned out to be somewhat
complicated but in the end showed that even RSA-keys when stored in
the new format are easy targets for subsequent contamination with ADKs.
Conclusions
So the following conclusions are inevitable :
whatever that means
0 1 2 3 4 5 6 7 8 9
0 : 153 1 66 4 52 77 70 30 17 3
10 : 0 208 110 105 167 56 168 248 25 85
20 : 51 185 141 4 40 211 238 226 54 148
30 : 172 29 236 121 194 253 56 249 84 2
40 : 247 82 40 41 43 251 221 124 45 186
50 : 73 152 122 36 203 219 54 8 235 33
60 : 131 80 5 88 239 186 186 252 25 169
70 : 229 144 250 251 164 23 184 179 122 112
80 : 61 248 223 108 220 33 180 250 145 17
90 : 46 189 114 9 143 253 135 167 97 74
100 : 120 142 235 35 98 104 207 0 160 255
110 : 164 105 123 98 12 109 92 210 78 33
120 : 223 148 171 233 166 145 243 66 229 3
130 : 0 175 68 6 231 162 65 44 19 93
140 : 141 202 124 191 56 233 48 113 190 93
150 : 243 97 3 55 182 245 181 60 224 43
160 : 236 74 42 127 190 192 58 128 89 191
170 : 199 34 165 244 22 251 132 61 48 155
180 : 239 220 44 124 155 42 185 44 201 228
190 : 212 128 134 30 194 159 62 37 232 49
200 : 196 163 251 241 88 98 52 141 201 215
210 : 71 244 4 0 166 200 98 113 195 24
220 : 41 87 60 56 154 252 100 3 0 151
230 : 80 120 105 31 80 47 69 47 120 36
240 : 203 172 144 176 78 225 92 57 71 199
250 : 94 126 151 21 95 69 241 166 238 192
260 : 129 62 88 186 101 111 243 124 59 225
270 : 245 134 19 243 27 103 87 82 237 77
280 : 221 7 8 115 143 7 164 33 127 111
290 : 15 141 241 228 53 165 99 32 66 64
300 : 12 246 214 222 54 33 78 230 138 124
310 : 19 128 18 236 232 203 179 228 214 144
320 : 245 101 8 77 10 180 28 67 77 82
330 : 32 85 115 101 114 32 60 115 110 111
340 : 111 112 101 100 64 108 111 99 97 108
350 : 104 111 115 116 62 136 99 4 16 17
360 : 2 0 35 5 2 52 77 70 30 23
370 : 10 128 17 38 165 102 122 151 212 112
380 : 24 27 24 43 21 214 49 71 118 182
390 : 112 225 208 4 11 3 1 2 0 10
400 : 9 16 52 164 96 86 238 66 48 227
410 : 216 255 0 160 138 116 238 85 15 190
420 : 92 25 233 49 164 13 75 190 67 131
430 : 57 166 224 30 0 160 186 50 232 251
440 : 6 243 116 201 62 127 23 12 197 224
450 : 110 132 183 160 145 213 136 70 4 16
460 : 17 2 0 6 5 2 52 77 72 93
470 : 0 10 9 16 214 49 71 118 182 112
480 : 225 208 245 210 0 158 45 156 245 91
490 : 207 216 81 91 217 144 172 14 142 155
500 : 226 34 8 157 125 17 0 158 53 57
510 : 128 28 213 252 169 63 20 30 99 108
520 : 148 86 167 199 221 233 166 4 185 0
530 : 205 4 52 77 70 42 16 3 0 240
540 : 8 91 147 80 78 79 222 192 30 139
550 : 40 213 68 86 9 23 144 6 51 170
560 : 227 253 23 34 90 211 75 105 40 216
570 : 132 68 41 31 98 250 38 254 153 177
580 : 130 100 0 246 49 164 11 22 188 191
590 : 239 56 126 36 94 141 119 173 241 238
600 : 54 132 10 100 211 170 95 66 181 213
610 : 46 166 32 123 163 198 96 140 38 65
620 : 103 43 220 233 98 219 24 130 92 219
630 : 208 189 184 172 133 0 2 2 3 0
640 : 154 54 140 196 55 36 25 23 165 20
650 : 73 20 116 146 226 245 197 193 33 232
660 : 120 163 84 246 17 204 186 102 217 220
670 : 253 148 95 170 44 113 27 171 59 8
680 : 2 102 41 58 158 178 166 250 110 118
690 : 17 219 150 135 222 206 193 66 44 113
700 : 62 151 40 75 62 147 37 73 165 167
710 : 101 232 5 240 146 254 159 228 143 250
720 : 179 41 220 204 90 148 145 138 32 32
730 : 91 36 102 25 87 243 136 70 4 24
740 : 17 2 0 6 5 2 52 77 70 42
750 : 0 10 9 16 52 164 96 86 238 66
760 : 48 227 114 226 0 160 161 180 188 226
770 : 178 60 139 95 117 117 194 74 217 8
780 : 231 254 240 142 156 67 0 160 159 251
790 : 117 86 3 156 180 204 37 162 137 181
800 : 176 132 9 0 145 235 55 202
Roughly speaking the key consists of six different packets, each beginning
with an identifier-byte (in red) followed by two bytes which give the length
(in blue) of the following data (in black).
I have found it a great help to use GnuPG as a packet-analysing-tool,
because if you invoke GnuPG as
the result
speaks for itself:
"gpg --list-packets key-A"
:public key packet:
version 4, algo 17, created 877479454, expires 0
pkey[0]: [768 bits]
pkey[1]: [160 bits]
pkey[2]: [768 bits]
pkey[3]: [768 bits]
:user ID packet: "CMR User
As you can see the ADK is sitting in the self-signature in a subpacket
of type 10 called (additional recipient request (ARR)) in the first field
of subpackets which are hashed and therefore are protected by the
self-signature.
350 : 136 99 4 16 17
360 : 2
--------------------------------------------------
0 35 | 5 2 52 77 70 30 | 23 HASHED subpackets
370 : 10 128 17 38 165 102 122 151 212 112
380 : 24 27 24 43 21 214 49 71 118 182
390 : 112 225 208 | 4 11 3 1 2
---------------------------------------------
---------
0 10 NON-HASHED subpackets
400 : 9 16 52 164 96 86 238 66 48 227
---------
410 : 216 255 2 leftmost bytes of hashvalue
0 160 138 116 238 85 15 190 MPI signature-r
420 : 92 25 233 49 164 13 75 190 67 131
430 : 57 166 224 30
0 160 186 50 232 251 MPI signature-s
440 : 6 243 116 201 62 127 23 12 197 224
450 : 110 132 183 160 145 213
You see a version number 4 (357) and a signature-type 16 (358) which
means this signature signs a key and a user-ID followed by 17=DSS and
2=SHA1, the used algorithms. After that the first field of hashed
subpackets begins carrying 3 subpackets of a total of 35 bytes.
DECIMAL : 38 165 102 122 151 212 112 24 27 24 43 21 214 49 71 118 182 112 225 208
HEXADECIMAL: 26 A5 66 7A 97 D4 70 18 1B 18 2B 15 D6 31 47 76 B6 70 E1 D0
This is the reference to Little Brother's signing key, as you may see from
the reference in the chapter "The Keys for Experiments"
below.
gpg: encrypted with 768-bit ELG-E key, ID FF2BBFFD, created 1997-10-22
"Little Brother
Because of the fact, that we do not have any secret keys for both keys
we are not able to decrypt the message, but as you see there is
an additional packet which encrypts the session key used for encryption
to the key-ID 0xFF2BBFFD which is the ElGamal-key bound as subkey to
Little Brother's master-signing-key, whose fingerprint was stored in the
ADK-subpacket originally. So "Little Brother", who has the secret key
will be able to read the plaintext of the message, as well as "CMR User"
who will use his key 0x183FBE34 to decrypt the message.
Original Keys
pub 768D/EE4230E3 1997-10-22 CMR User
Manipulated Keys
DH-Keys
key-A "CMR-User"
key-B "Billy Clean"
RSA-Keys
key-F
"Eddie Clean" transformed to V4-format with old
V3-self-signature
(md5=73bbb87b8c77debcf9de3b9d49902892)
found at
ftp://ftp.pca.dfn.de/pub/pgp/pgpi/2.x/src/pgp263is.tar.gz
(md5=7a01203f0053aa78a781367461d52187)
found at
ftp://ftp.de.pgpi.org/pub/pgp/5.0/unix/pgp50i-unix-src.tar.gz
(md5=e3e8d17d44027969258677de6be42fb1)
found at
ftp://ftp.de.pgpi.org/pub/pgp/5.5/5.5.3i/win/english/pgp553i-win95nt.exe
(md5=5519b32991622a2a59bc7ccafca08786)
found at
ftp://ftp.nl.pgpi.org/pub/pgp/6.5/6.5.1int/PGPfreeware651int.exe
(md5=14ce577afd03d56cba5d8ee59b9580ed)
found at
ftp://ftp.de.pgpi.org/pub/pgp/gnupg/gnupg-1.0.1.tar.gz
PGP-2.6.3ia (PGP-Classic) UNIX
Importing the original keys
key-A, key-B, key-C, key-D
Pretty Good Privacy(tm) 2.6.3ia - Public-key encryption for the masses.
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-03-04
International version - not for use in the USA. Does not use RSAREF.
Current time: 2000/08/13 10:21 GMT
File contains key(s). Contents follow...
Unsupported packet format - you need a newer version of PGP for this file.
Key ring: 'key-A'
Type Bits/KeyID Date User ID
Unsupported packet format - you need a newer version of PGP for this file.
pub? 2108/00000000 CMR User
Key-E
Key ring: 'key-E'
Type Bits/KeyID Date User ID
pub 1024/FD40B97D 2000/08/04 Eddie Clean (Testkey RSA)
sig FD40B97D Eddie Clean (Testkey RSA)
1 matching key found.
[ ... ]
No keys found in 'key-E.pgp'.
Keyring add error.
Renaming the file "key-E" to "key-E.pgp" helps to get this RSA-key added
correctly.
Key ring: 'key-F'
Type Bits/KeyID Date User ID
Unsupported packet format - you need a newer version of PGP for this file.
pub? 2108/00000000 Eddie Clean (Testkey RSA)
sig FD40B97D (Unknown signator, can't be checked)
[ ... ]
Keyring add error.
Manipulated Diffie-Hellman/DSS keys
All keys, key-A1 to key-A5 and key-B1 to key-B3, were treated in the same
way as key-A above.
Manipulated RSA keys
All keys, key-F1 to key-F4, were treated in the same way as key-A above.
Creating RSA keys
Type Bits/KeyID Date User ID
pub 1024/B93E2FD1 2000/08/13 PGP-classic RSA-key (Testkey)
Key fingerprint = 6C 49 5B 5E A3 98 AF 57 74 0E E9 27 BC 5C 06 C7
sig B93E2FD1 PGP-classic RSA-key (Testkey)
:public key packet:
version 3, algo 1, created 966162683, expires 0
pkey[0]: [1024 bits]
pkey[1]: [5 bits]
:user ID packet: "PGP-classic RSA-key (Testkey)"
:signature packet: algo 1, keyid 2AB82B66B93E2FD1
version 3, created 966162683, md5len 5, sigclass 10
digest algo 1, begin of digest 87 99
data: [1024 bits]
Signing keys
PGP-Classic creates Version-3 signatures and self-signatures.
PGP-5.0i UNIX
Importing the original keys
All keys were successfully imported, but key-F could only be imported when
key-E was deleted previously.
Type Bits KeyID Created Expires Algorithm Use
sec 1024 0x149C79AB 2000-07-31 ---------- DSS Sign & Encrypt
f20 Fingerprint20 = 2E3C C603 91E1 3246 7DCF C722 9B80 46D9 149C 79AB
sub 1024 0x11EE9145 2000-07-31 ---------- Diffie-Hellman
f20 Fingerprint20 = 6056 4847 D108 559E 1DF5 A933 3462 E99C 11EE 9145
uid Billy Clean (Testkey DSS)
SIG 0x149C79AB 2000-07-31 Billy Clean (Testkey DSS)
pub 768 0xEE4230E3 1997-10-22 ---------- DSS Sign & Encrypt
f20 Fingerprint20 = EC79 A170 8BAE 60A1 3CAC C517 34A4 6056 EE42 30E3
sub 768 0x183FBE34 1997-10-22 ---------- Diffie-Hellman
f20 Fingerprint20 = 527D AF1C E9F0 B5FA 2427 0B6F 5974 B0A8 183F BE34
uid CMR User
Manipulated Diffie-Hellman/DSS keys
When encrypting a text for user "CMR User" (key-A) a warning is
displayed and the resulting
cryptogram
contains only one encrypted session-key for "CMR User".
WARNING: 2 matches were found for recipient CMR.
This may not be what you intended.
they encrypt to one key without any ADK-warning.
The cryptogram
contains only one session-key.
Manipulated RSA keys
While encrypting no warning is given and the
cryptogram
contains only one encrypted session-key.
Creating keys
DH-key
Type Bits KeyID Created Expires Algorithm Use
sec+ 1024 0xDD4CDABB 2000-08-13 ---------- DSS Sign & Encrypt
f20 Fingerprint20 = E33E 523F 3E86 A0F5 04E5 0917 D39D 4F15 DD4C DABB
sub 1024 0x830CB1B8 2000-08-13 ---------- Diffie-Hellman
f20 Fingerprint20 = 35F6 823E C6E9 3658 3593 B305 0271 5010 830C B1B8
uid unix50-DH-key (testkey)
SIG 0xDD4CDABB 2000-08-13 unix50-DH-key (testkey)
RSA-key
sec+ 1024 0xD2C9E78B 2000-08-13 ---------- RSA Sign & Encrypt
f16 Fingerprint16 = 2E 9C 13 6F 74 6B 23 4A 34 D1 45 51 2C 97 E7 CF
uid unix50-rsa (testkey)
SIG 0xD2C9E78B 2000-08-13 unix50-rsa (testkey)
Signing keys
DH-keys
are signed with V4-self-signatures and
RSA-keys
have V3-self-signatures.
DH-key
:public key packet:
version 4, algo 17, created 966172928, expires 0
pkey[0]: [1024 bits]
pkey[1]: [160 bits]
pkey[2]: [1024 bits]
pkey[3]: [1024 bits]
:user ID packet: "unix50-DH-key (testkey)"
:signature packet: algo 17, keyid D39D4F15DD4CDABB
version 4, created 966172928, md5len 0, sigclass 10
digest algo 2, begin of digest b7 1c
hashed subpkt 2 len 5 (sig created 2000-08-13)
hashed subpkt 11 len 4 (pref-sym-algos: 3 1 2)
subpkt 16 len 9 (issuer key ID D39D4F15DD4CDABB)
data: [160 bits]
data: [160 bits]
:public sub key packet:
version 4, algo 16, created 966172944, expires 0
pkey[0]: [1024 bits]
pkey[1]: [2 bits]
pkey[2]: [1022 bits]
:signature packet: algo 17, keyid D39D4F15DD4CDABB
version 3, created 966172944, md5len 5, sigclass 18
digest algo 2, begin of digest cd 49
data: [158 bits]
data: [160 bits]
RSA-key
:public key packet:
version 3, algo 1, created 966172807, expires 0
pkey[0]: [1024 bits]
pkey[1]: [5 bits]
:user ID packet: "unix50-rsa (testkey)"
:signature packet: algo 1, keyid 23D90AE3D2C9E78B
version 3, created 966172807, md5len 5, sigclass 10
digest algo 1, begin of digest 2e 4a
data: [1022 bits]
PGP-5.5.3i WINDOWS
Importing the original keys
All keys were imported correctly except the following:
key-D
This V4-RSA-key has key-ID 0x2EED54F3 with a 16 byte fingerprint.
The self-signature with key-ID 0xA7CE4BF5 consequently is "unknown signer".
Manipulated Diffie-Hellman/DSS keys
While importing key-A an ADK is signalized with a red dot with
the key-properties naming it correctly as "Little Brother".
During encryption both keys for "CMR" and "Little Brother" are used
resulting in a
cryptogram
with two encrypted session-keys.
No ADK is displayed in the key-properties menu. Encryption results in
a cryptogram with one single session-key used.
:marker packet:
50 47 50
:pubkey enc packet: version 3, algo 16, keyid F747A70F2930391C
data: [2048 bits]
data: [2048 bits]
:pubkey enc packet: version 3, algo 16, keyid 5974B0A8183FBE34
data: [767 bits]
data: [767 bits]
:pubkey enc packet: version 3, algo 16, keyid 0C287D40FF2BBFFD
data: [768 bits]
data: [766 bits]
:encrypted data packet:
length: 40
:marker packet:
50 47 50
:pubkey enc packet: version 3, algo 16, keyid F747A70F2930391C
data: [2042 bits]
data: [2045 bits]
:pubkey enc packet: version 3, algo 16, keyid 3462E99C11EE9145
data: [1024 bits]
data: [1024 bits]
:encrypted data packet:
length: 40
This cryptogram can be decrypted with key-C's secret key ("control") !
The cryptogram
uses the key of the owner only.
Manipulated RSA keys
Eddies self-signature is "corrupt". Encryption produces one session-key.
Creating and signing keys
This version creates DH/DSS-keys with V4-self-signatures and
RSA-keys
with V3-self-signatures.
:public key packet:
version 3, algo 1, created 965648727, expires 0
pkey[0]: [1024 bits]
pkey[1]: [5 bits]
:user ID packet: "testkey Windows"
:signature packet: algo 1, keyid D6EA3B1E83FEC32B
version 3, created 965648727, md5len 5, sigclass 10
digest algo 1, begin of digest d0 f8
data: [1024 bits]
PGP-6.5.1i WINDOWS
Importing the original keys
All keys were imported correctly, but some strange display for key-D
should be noted :
key-D
This V4-RSA-key has now a correct key-ID 0xA7CE4BF5 but it shows a
f16-fingerprint, which actually consists of the first 128 bit of the original
160 bit fingerprint :
f16 = 3AA9 B31D 6D93 FD10 F835 D042 8613 D5BF.
If you append the key-ID A7CE 4BF5 in your mind you have the correct
fingerprint for that V4-RSA key.
The self-signature with key-ID 0xA7CE4BF5 now is correct.
Manipulated Diffie-Hellman/DSS keys
This version handles key-A in the same way as PGP-553i. Encryption
is performed with both keys including the ADK and leaving a cryptogram
with two encrypted session-keys.
No ADK is displayed in the key-properties menu. Encryption results in
a cryptogram with one single session-key used.
This cryptogram can be decrypted with key-C's secret key
("control") !
The cryptogram
uses the owner's key only.
Manipulated RSA keys
The cryptogram can be decrypted with both keys!
Removing the Additional Decryption Key "control" from the recipient list
may violate the policy established for other keys in the recipient list.
The user Freddie Clean has a missing ADK. Contact the owner of the key
to obtain the ADK.
Both RSA-keys can decrypt the message!
:pubkey enc packet: version 3, algo 1, keyid 8613D5BFA7CE4BF5
data: [1022 bits]
:pubkey enc packet: version 3, algo 1, keyid 4F74526E80054131
data: [1024 bits]
:encrypted data packet:
length: 39
:compressed packet: algo=1
:literal data packet:
mode b, created 2852126720, name="text",
raw data: 13 bytes
Creating and signing keys
DH-key
DH-keys are created and signed in V4-format.
RSA-key
RSA-keys
are created in V3-format and have a V3-self-signature.
Even signing a key with a V4-RSA-key results in a V3-signature.
GnuPG-1.0.1 UNIX
Importing the original keys
All keys were imported (see chapter
"The Keys for Experiments"
for reference) except key-F which was rejected because of "missing
self-signature".
Manipulated Diffie-Hellman/DSS keys
Encrypting a text for "CMR user" with key-A results in a
cryptogram
with only one session-key. No ADK-warning is displayed during encryption.
Encryption goes on without ADK-warning and produces
one encrypted
session-key.
Manipulated RSA keys
gpg: RSA keys are deprecated; please consider creating a new key and use this key
in the future
Creating keys
GnuPG generates DH/DSS-keys
but does not genarate RSA keys.
Signing keys
DH-keys have V4-signatures and V4-self-signatures.
This key is key-D "datarecovery"
edited with GnuPG to change the user-ID and to create a new self-signature,
which is Version-4 on RSA keys!
RSA-key "datarecovery"
:public key packet:
version 4, algo 1, created 965568184, expires 0
pkey[0]: [1024 bits]
pkey[1]: [5 bits]
:user ID packet: "NEW UID FROM GPG"
:signature packet: algo 1, keyid 8613D5BFA7CE4BF5
version 4, created 966237357, md5len 0, sigclass 13
digest algo 1, begin of digest 88 a9
hashed subpkt 2 len 5 (sig created 2000-08-14)
hashed subpkt 11 len 4 (pref-sym-algos: 10 4 3)
hashed subpkt 21 len 3 (pref-hash-algos: 3 2)
hashed subpkt 22 len 3 (pref-zip-algos: 2 1)
hashed subpkt 23 len 2 (key server preferences)
subpkt 16 len 9 (issuer key ID 8613D5BFA7CE4BF5)
data: [1024 bits]
This document is signed digitally with PGP.