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.