As per Relevance of the word exchange, we have this rfc below:
Network Working Group D.
Request for Comments: 1991
Category: Informational W.
Comp-Comm
P.
Boulder Software
August 1996
PGP Message Exchange
Status of This
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
Table of
1. Introduction............................................2
2. PGP Services............................................2
2.1 Digital signature.......................................3
2.2 Confidentiality.........................................3
2.3 Compression.............................................4
2.4 Radix-64 conversion.....................................4
2.4.1 ASCII Armor Formats.....................................5
3. Data Element Formats....................................6
3.1 Byte strings............................................6
3.2 Whole number fields.....................................7
3.3 Multiprecision fields...................................7
3.4 String fields...........................................8
3.5 Time fields.............................................8
4. Common Fields...........................................8
4.1 Packet structure fields.................................8
4.2 Number ID fields.......................................10
4.3 Version fields.........................................10
5. Packets................................................10
5.1 Overview...............................................10
5.2 General Packet Structure...............................11
5.2.1 Message component......................................11
5.2.2 Signature component....................................11
5.2.3 Session key component..................................11
6. PGP Packet Types.......................................12
6.1 Literal data packets...................................12
6.2 Signature packets......................................13
6.2.1 Message-digest-related fields..........................14
6.2.2 Public-key-related fields..............................15
6.2.3 RSA signatures.........................................16
Atkins, et. al. Informational [Page 1]
RFC 1991 PGP Message Exchange Formats August 1996
6.2.4 Miscellaneous fields...................................16
6.3 Compressed data packets................................17
6.4 Conventional-key-encrypted data packets................17
6.4.1 Conventional-encryption type byte......................18
6.5 Public-key-encrypted packets...........................18
6.5.1 RSA-encrypted data encryption key (DEK)................19
6.6 Public-key Packets.....................................19
6.7 User ID packets........................................20
7. Transferable Public Keys...............................20
8. Acknowledgments........................................20
9. Security Considerations................................21
10. Authors' Addresses.....................................21
1.
PGP (Pretty Good Privacy) uses a combination of public-key
conventional encryption to provide security services for
mail messages and data files. These services include
and digital signature. PGP is widely used throughout the
computer community. This document describes the format of "
files", i.e., messages that have been encrypted and/or signed
PGP
PGP was created by Philip Zimmermann and first released, in
1.0, in 1991. Subsequent versions have been designed and
by an all-volunteer collaborative effort under the design guidance
Philip Zimmermann. PGP and Pretty Good Privacy are trademarks
Philip Zimmermann
This document describes versions 2.x of PGP. Specifically,
2.6 and 2.7 conform to this specification. Version 2.3 conforms
this specification with minor differences
A new release of PGP, known as PGP 3.0, is anticipated in 1995.
the maximum extent possible, this version will be upwardly
with version 2.x. At a minimum, PGP 3.0 will be able to read
and signatures produced by version 2.x
2. PGP
PGP provides four services related to the format of messages and
files: digital signature, confidentiality, compression, and radix-64
conversion
Atkins, et. al. Informational [Page 2]
RFC 1991 PGP Message Exchange Formats August 1996
2.1 Digital
The digital signature service involves the use of a hash code,
message digest, algorithm, and a public-key encryption algorithm.
sequence is as follows
-the sender creates a
-the sending PGP generates a hash code of the
-the sending PGP encrypts the hash code using the sender's
-the encrypted hash code is prepended to the
-the receiving PGP decrypts the hash code using the sender's
-the receiving PGP generates a new hash code for the
message and compares it to the decrypted hash code. If the
match, the message is accepted as
Although signatures normally are found attached to the message
file that they sign, this is not always the case: detached
are supported. A detached signature may be stored and
separately from the message it signs. This is useful in
contexts. A user may wish to maintain a separate signature log of
messages sent or received. A detached signature of an
program can detect subsequent virus infection. Finally,
signatures can be used when more than one party must sign a document
such as a legal contract. Each person's signature is independent
therefore is applied only to the document. Otherwise,
would have to be nested, with the second signer signing both
document and the first signature, and so on
2.2
PGP provides confidentiality by encrypting messages to be
or data files to be stored locally using conventional encryption.
PGP, each conventional key is used only once. That is, a new key
generated as a random 128-bit number for each message. Since it is
be used only once, the session key is bound to the message
transmitted with it. To protect the key, it is encrypted with
receiver's public key. The sequence is as follows
-the sender creates a
-the sending PGP generates a random number to be used as a
key for this message
-the sending PGP encrypts the message using the session
-the session key is encrypted using the recipient's public key
prepended to the encrypted
-the receiving PGP decrypts the session key using the recipient'
private
Atkins, et. al. Informational [Page 3]
RFC 1991 PGP Message Exchange Formats August 1996
-the receiving PGP decrypts the message using the session
Both digital signature and confidentiality services may be applied
the same message. First, a signature is generated for the message
prepended to the message. Then, the message plus signature
encrypted using a conventional session key. Finally, the session
is encrypted using public-key encryption and prepended to
encrypted block
2.3
As a default, PGP compresses the message after applying the
but before encryption
2.4 Radix-64
When PGP is used, usually part of the block to be transmitted
encrypted. If only the signature service is used, then the
digest is encrypted (with the sender's private key). If
confidentiality service is used, the message plus signature (
present) are encrypted (with a one-time conventional key). Thus,
or all of the resulting block consists of a stream of arbitrary 8-
bytes. However, many electronic mail systems only permit the use
blocks consisting of ASCII text. To accommodate this restriction,
provides the service of converting the raw 8-bit binary stream to
stream of printable ASCII characters, called ASCII Armor
The scheme used for this purpose is radix-64 conversion. Each
of three bytes of binary data is mapped into 4 ASCII characters.
format also appends a CRC to detect transmission errors.
radix-64 conversion, also called Ascii Armor, is a wrapper around
binary PGP messages, and is used to protect the binary
during transmission over non-binary channels, such as Internet Email
The following table defines the mapping. The characters used are
upper- and lower-case letters, the digits 0 through 9, and
characters + and /. The carriage-return and linefeed
aren't used in the conversion, nor is the tab or any other
that might be altered by the mail system. The result is a text
that is "immune" to the modifications inflicted by mail systems
Atkins, et. al. Informational [Page 4]
RFC 1991 PGP Message Exchange Formats August 1996
6-bit character 6-bit character 6-bit character 6-bit
value encoding value encoding value encoding value
0 A 16 Q 32 g 48
1 B 17 R 33 h 49
2 C 18 S 34 i 50
3 D 19 T 35 j 51
4 E 20 U 36 k 52 0
5 F 21 V 37 l 53 1
6 G 22 W 38 m 54 2
7 H 23 X 39 n 55 3
8 I 24 Y 40 o 56 4
9 J 25 Z 41 p 57 5
1 K 26 a 42 q 58 6
11 L 27 b 43 r 59 7
12 M 28 c 44 s 60 8
13 N 29 d 45 t 61 9
14 O 30 e 46 u 62 +
15 P 31 f 47 v 63 /
(pad) =
It is possible to use PGP to convert any arbitrary file to
Armor. When this is done, PGP tries to compress the data before
is converted to Radix-64.
2.4.1 ASCII Armor
When PGP encodes data into ASCII Armor, it puts specific
around the data, so PGP can reconstruct the data at a future time
PGP tries to inform the user what kind of data is encoded in
ASCII armor through the use of the headers
ASCII Armor is created by concatenating the following data
- An Armor Headerline, appropriate for the type of
- Armor
- A blank
- The ASCII-Armored
- An Armor
- The Armor Tail (which depends on the Armor Headerline).
An Armor Headerline is composed by taking the appropriate
text surrounded by five (5) dashes (-) on either side of
headerline text. The headerline text is chosen based upon the
of data that is being encoded in Armor, and how it is being encoded
Headerline texts include the following strings
BEGIN PGP MESSAGE -- used for signed, encrypted, or compressed
BEGIN PGP PUBLIC KEY BLOCK -- used for transferring public
Atkins, et. al. Informational [Page 5]
RFC 1991 PGP Message Exchange Formats August 1996
BEGIN PGP MESSAGE, PART X/Y -- used for multi-part messages,
the armor is split amongst Y files
and this is the Xth file out of Y
The Armor Headers are pairs of strings that can give the user or
receiving PGP program some information about how to decode or use
message. The Armor Headers are a part of the armor, not a part
the message, and hence should not be used to convey any
information, since they can be changed in transport
The format of an Armor Header is that of a key-value pair,
encoding of RFC-822 headers. PGP should consider
formatted Armor Headers to be corruption of the ASCII Armor.
Keys should be reported to the user, but so long as the RFC-822
formatting is correct, PGP should continue to process the message
Currently defined Armor Header Keys include "Version" and "Comment",
which define the PGP Version used to encode the message and a user
defined comment
The Armor Checksum is a 24-bit CRC converted to four bytes of radix
64 encoding, prepending an equal-sign (=) to the four-byte code.
CRC is computed by using the generator 0x864CFB and an
of 0xB704CE. The accumulation is done on the data before it
converted to radix-64, rather than on the converted data. For
information on CRC functions, the reader is asked to look at
19 of the book "C Programmer's Guide to Serial Communications,"
Joe Campbell
The Armor Tail is composed in the same manner as the
Headerline, except the string "BEGIN" is replaced by the
"END".
3. Data Element
3.1 Byte
The objects considered in this document are all "byte strings."
byte string is a finite sequence of bytes. The concatenation of
string X of length M with byte string Y of length N is a byte
Z of length M + N; the first M bytes of Z are the bytes of X in
same order, and the remaining N bytes of Z are the bytes of Y in
same order
Literal byte strings are written from left to right, with pairs
hex nibbles separated by spaces, enclosed by angle brackets:
instance, <05 ff 07> is a byte string of length 3 whose bytes
numeric values 5, 255, and 7 in that order. All numbers in
document outside angle brackets are written in decimal
Atkins, et. al. Informational [Page 6]
RFC 1991 PGP Message Exchange Formats August 1996
The byte string of length 0 is called "empty" and written <>.
3.2 Whole number
Purpose. A whole number field can represent any nonnegative integer
in a format where the field length is known in advance
Definition. A whole number field is any byte string. It is
in radix-256 MSB-first format. This means that a whole number
of length N with bytes b_0 b_1 ... b_{N-2} b_{N-1} in that order
b_0 * 256^{N-1} + b_1 * 256^{N-2} + ... + b_{N-2} * 256 + b_{N-1}.
Examples. The byte string <00 0D 64 11 00 00> is a valid
number field with value 57513410560. The byte string is a
whole number field with value 255. The byte string <00 00> is
valid whole number field with value 0. The empty byte string <> is
valid whole number field with value 0.
3.3 Multiprecision
Purpose. A multiprecision field can represent any
integer which is not too large. The field length need not be
in advance. Multiprecision fields are designed to waste very
space: a small integer uses a short field
Definition. A multiprecision field is the concatenation of
fields
(a) a whole number field of length 2, with value B
(b) a whole number field, with value V
Field (b) is of length [(B+7)/8], i.e., the greatest integer which
no larger than (B+7)/8. The value of the multiprecision field
defined to be V. V must be between 2^{B-1} and 2^B - 1 inclusive
In other words B must be exactly the number of significant bits in V
Some implementations may limit the possible range of B.
implementor must document which values of B are allowed by
implementation
Examples. The byte string <00 00> is a valid multiprecision
with value 0. The byte string <00 03 05> is a valid
field with value 5. The byte strings <00 03 85> and <00 00 00>
not valid multiprecision fields. The former is invalild because <85>
has 8 significant bits, not 3; the latter is invalid because
second field has too many bytes of data given the value of the
Atkins, et. al. Informational [Page 7]
RFC 1991 PGP Message Exchange Formats August 1996
field. The byte string <00 09 01 ff> is a valid multiprecision
with value 511. The byte string <01 00 80 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07>
a valid multiprecision field with value 2^255 + 7.
3.4 String
Purpose. A string field represents any sequence of bytes of
between 0 and 255 inclusive. The length need not be known
advance. By convention, the content of a string field is
interpreted as ASCII codes when it is displayed
Definition. A string field is the concatenation of the following
(a) a whole number field of length 1, with value L
(b) a byte string of length L
The content of the string field is defined to be field (b).
Examples: <05 48 45 4c 4c 4f> is a valid string field which
normally be displayed as the string HELLO. <00> is a valid
field which would normally be displayed as the empty string. <01 00>
is a valid string field
3.5 Time
Purpose. A time field represents the number of seconds elapsed
1970 Jan 1 00:00:00 GMT. It is compatible with the
representation of times under UNIX
Definition. A time field is a whole number field of length 4,
value V. The time represented by the time field is the one-
interval beginning V seconds after 1970 Jan 1 00:00:00 GMT
4. Common
This section defines fields found in more than one packet format
4.1 Packet structure
Purpose. The packet structure field distinguishes between
types of packets, and indicates the length of packets
Definition. A packet structure field is a byte string of length 1,
2, 3, or 5. Its first byte is the cipher type byte (CTB), with
labeled 76543210, 7 the most significant bit and 0 the
significant bit. As indicated below the length of the
structure field is determined by the CTB
Atkins, et. al. Informational [Page 8]
RFC 1991 PGP Message Exchange Formats August 1996
CTB bits 76 have values listed in the following table
10 - normal
11 - reserved for future experimental
all others -
CTB bits 5432, the "packet type bits", have values listed in
following table
0001 - public-key-encrypted
0010 - signature
0101 - secret-key certificate
0110 - public-key certificate
1000 - compressed data
1001 - conventional-key-encrypted
1011 - literal data
1100 - keyring trust
1101 - user id
1110 - comment packet (*)
all others -
CTB bits 10, the "packet-length length bits", have values listed
the following table
00 - 1-byte packet-length
01 - 2-byte packet-length
10 - 4-byte packet-length
11 - no packet length supplied, unknown packet
As indicated in this table, depending on the packet-length
bits, the remaining 1, 2, 4, or 0 bytes of the packet structure
are a "packet-length field". The packet-length field is a
number field. The value of the packet-length field is defined to
the value of the whole number field
A value of 11 is currently used in one place: on compressed data
That is, a compressed data block currently looks like ,
where , binary 10 1000 11, is an indefinite-length packet.
proper interpretation is "until the end of the enclosing structure",
although it should never appear outermost (where the
structure is a file).
Options marked with an asterisk (*) are not implemented yet;
2.6.2 will never output this packet type
Atkins, et. al. Informational [Page 9]
RFC 1991 PGP Message Exchange Formats August 1996
4.2 Number ID
Purpose. The ID of a whole number is its 64 least significant bits
The ID is a convenient way to distinguish between large numbers
as keys, without having to transmit the number itself. Thus, a
that may be hundreds or thousands of decimal digits in length can
identified with a 64-bit identifier. Two keys may have the same ID
chance or by malice; although the probability that two large
chosen at random would have the same ID is extremely small
Definition. A number ID field is a whole number field of length 8.
The value of the number ID field is defined to be the value of
whole number field
4.3 Version
Many packet types include a version number as the first byte of
body. The format and meaning of the body depend on the
number. More versions of packets, with new version numbers, may
defined in the future. An implementation need not support
version of each packet type. However, the implementor must
which versions of each packet type are supported by
implementation
A version number of 2 or 3 is currently allowed for each
format. New versions will probably be numbered sequentially up
3. For backwards compatibility, implementations will usually
expected to support version N of a packet whenever they
version N+1. Version 255 may be used for experimental purposes
5.
5.1
A packet is a digital envelope with data inside. A PGP file,
definition, is the concatenation of one or more packets. In addition
one or more of the packets in a file may be subject to
transformation using encryption, compression, or radix-64 conversion
A packet is the concatenation of the following
(a) a packet structure field
(b) a byte string of some length N
Byte string (b) is called the "body" of the packet. The value of
packet-length field inside the packet structure field (a) must
N, the length of the body
Atkins, et. al. Informational [Page 10]
RFC 1991 PGP Message Exchange Formats August 1996
Other characteristics of the packet are determined by the type of
packet. See the definitions of particular packet types for
details. The CTB packet-type bits inside the packet structure
indicate the packet type
Note that packets may be nested: one digital envelope may be
inside another. For example, a conventional-key-encrypted
contains a disguised packet, which in turn might be a compressed
packet
5.2 General packet
A pgp file consists of three components: a message component,
signature (optional), and a session key component (optional).
5.2.1 Message
The message component includes the actual data to be stored
transmitted as well as a header that includes control
generated by PGP. The message component consists of a single
data packet
5.2.2 Signature
The signature component is the signature of the message component
formed using a hash code of the message component and the public
of the sending PGP entity. The signature component consists of
single signature packet
If the default option of compression is chosen, then the
consisting of the literal data packet and the signature packet
compressed to form a compressed data packet
5.2.3 Session key
The session key component includes the encrypted session key and
identifier of the recipients public key used by the sender to
the session key. The session key component consists of a
public-key-encrypted packet for each recipient of the message
If compression has been used, then conventional encryption is
to the compressed data packet formed from the compression of
signature packet and the literal data packet. Otherwise,
encryption is applied to the block consisting of the signature
and the literal data packet. In either case, the cyphertext
referred to as a conventional-key-encrypted data packet
Atkins, et. al. Informational [Page 11]
RFC 1991 PGP Message Exchange Formats August 1996
6. PGP Packet
PGP includes the following types of packets
-literal data
-signature
-compressed data
-conventional-key-encrypted data
-public-key-encrypted
-public-key
-User ID
6.1 Literal data
Purpose. A literal data packet is the lowest level of contents of
digital envelope. The data inside a literal data packet is
subject to any further interpretation by PGP
Definition. A literal data packet is the concatenation of
following fields
(a) a packet structure field
(b) a byte, giving a mode
(c) a string field, giving a filename
(d) a time field
(e) a byte string of literal data
Fields (b), (c), and (d) suggest how the data should be written to
file. Byte (b) is either ASCII b <62>, for binary, or ASCII t <74>,
for text. Byte (b) may also take on the value ASCII 1, indicating
machine-local conversion. It is not defined how PGP will convert
across platforms
Field (c) suggests a filename. Field (d) should be the time at
the file was last modified, or the time at which the data packet
created, or 0.
Note that only field (e) of a literal data packet is fed to
message-digest function for the formation of a signature.
exclusion of the other fields ensures that detached signatures
exactly the same as attached signatures prefixed to the message
Detached signatures are calculated on a separate file that has
of the literal data packet header fields
Atkins, et. al. Informational [Page 12]
RFC 1991 PGP Message Exchange Formats August 1996
6.2 Signature
Purpose. Signatures are attached to data, in such a way that
one entity, called the "writer," can create the signature.
writer must first create a "public key" K and distribute it.
writer keeps certain private data related to K. Only
cooperating with the writer can sign data using K, enveloping
data in a signature packet (also known as a private-key-
packet). Anyone can look through the glass in the envelope
verify that the signature was attached to the data using K. If
data is altered in any way then the verification will fail
Signatures have different meanings. For example, a signature
mean "I wrote this document," or "I received this document."
signature packet includes a "classification" which expresses
meaning
Definition. A signature packet, version 2 or 3, is the
of the following fields
(a) packet structure field (2, 3, or 5 bytes);
(b) version number = 2 or 3 (1 byte);
(c) length of following material included in MD
(1 byte, always the value 5);
(d1) signature classification (1 byte);
(d2) signature time stamp (4 bytes);
(e) key ID for key used for singing (8 bytes);
(f) public-key-cryptosystem (PKC) type (1 byte);
(g) message digest algorithm type (1 byte);
(h) first two bytes of the MD output, used as a
(2 bytes);
(i) a byte string of encrypted data holding the RSA-signed digest
The message digest is taken of the bytes of the file, followed by
bytes of field (d). It was originally intended that the length (c
could vary, but now it seems that it will alwaye remain a
value of 5, and that is the only value that will be accepted. Thus
only the fields (d1) and (d2) will be hashed into the signature
with the main message
Atkins, et. al. Informational [Page 13]
RFC 1991 PGP Message Exchange Formats August 1996
6.2.1 Message-digest-related
The message digest algorithm is specified by the message digest (MD
number of field (g). The following MD numbers are currently defined
1 - MD5 (output length 16)
255 -
More MD numbers may be defined in the future. An implementation
not support every MD number. The implementor must document the
numbers understood by an implementation
A message digest algorithm reads a byte string of any length,
writes a byte string of some fixed length, as indicated in the
above
The input to the message digest algorithm is the concatenation
some "primary input" and some "appended input."
The appended input is specified by field (c), which gives a number
bytes to be taken from the following fields: (d1), (d2), and so on
The current implementation uses the value 5 for this number,
fields (d1) and (d2). Any field not included in the appended
is not "signed" by field (i).
The primary input is determined by the signature classification
(d1). Byte (d1) is one of the following hex numbers, with
meanings
<00> - document signature, binary image ("I wrote this document")
<01> - document signature, canonical text ("I wrote this document")
<10> - public key packet and user ID packet, generic
("I think this key was created by this user, but I won't
how sure I am")
<11> - public key packet and user ID packet, persona
("This key was created by someone who has told me that he
this user") (#)
<12> - public key packet and user ID packet, casual
("This key was created by someone who I believe, after
verification, to be this user") (#)
<13> - public key packet and user ID packet, positive
("This key was created by someone who I believe,
heavy-duty identification such as picture ID, to be
user") (#)
<20> - public key packet, key compromise ("This is my key, and
have revoked it")
Atkins, et. al. Informational [Page 14]
RFC 1991 PGP Message Exchange Formats August 1996
<30> - public key packet and user ID packet, revocation ("I
all my previous statements that this key is related to
user") (*)
<40> - time stamping ("I saw this document") (*)
More classification numbers may be defined in the future to
other meanings of signatures, but only the above numbers may be
with version 2 or version 3 of a signature packet. It should
noted that PGP 2.6.2 has not implemented the packets marked with
asterisk (*), and the packets marked with a hash (#) are not
by PGP 2.6.2.
Signature packets are used in two different contexts. One (
type <00> or <01>) is of text (either the contents of a
packet or a separate file), while types <10> through <1F> appear
in key files, after the keys and user IDs that they sign. Type <20>
appears in key files, after the keys that it signs, and type <30>
also appears after a key/userid combination. Type <40> is intended
be a signature of a signature, as a notary seal on a signed document
The output of the message digest algorithm is a message digest,
hash code. Field i contains the cyphertext produced by encrypting
message digest with the signer's private key. Field h contains
first two bytes of the unencrypted message digest. This enables
recipient to determine if the correct public key was used to
the message digest for authentication, by comparing this
copy of the first two byes with the first two bytes of the
digest. These two bytes also serve as a 16-bit frame check
for the message
6.2.2 Public-key-related
The message digest is signed by encrypting it using the writer'
private key. Field (e) is the ID of the corresponding public key
The public-key-encryption algorithm is specified by the public-
cryptosystem (PKC) number of field (f). The following PKC numbers
currently defined
1 -
255 -
More PKC numbers may be defined in the future. An
need not support every PKC number. The implementor must document
PKC numbers understood by an implementation
Atkins, et. al. Informational [Page 15]
RFC 1991 PGP Message Exchange Formats August 1996
A PKC number identifies both a public-key encryption method and
signature method. Both of these methods are fully defined as part
the definition of the PKC number. Some cryptosystems are usable
for encryption, or only for signatures; if any such PKC numbers
defined in the future, they will be marked appropriately
6.2.3 RSA
An RSA-signed byte string is a multiprecision field that is formed
taking the message digest and filling in an ASN structure, and
encrypting the whole byte string in the RSA key of the signer
PGP versions 2.3 and later encode the MD into a PKCS-format
string, which has the following format
MSB . . .
0 1 (n bytes) 0 ASN(18 bytes) MD(16 bytes
See RFC1423 for an explanation of the meaning of the ASN string.
is the following 18 byte long hex value
<30 20 30 0C 06 08 2A 86 48 86 F7 0D 02 05 05 00 04 10>
Enough bytes of padding are added to make the length of
whole string equal to the number of bytes in the modulus
6.2.4 Miscellaneous
The timestamp field (d2) is analogous to the date box next to
signature box on a form. It represents a time which is
close to the moment that the signature packet was created. However
this is not a requirement. Users may choose to date their
as they wish, just as they do now in handwritten signatures
If an application requires the creation of trusted timestamps
signatures, a detached signature certificate with an
timestamp may be submitted to a trusted timestamp notary service
sign the signature packet with another signature packet, creating
signature of a signature. The notary's signature's timestamp
be used as the trusted "legal" time of the original signature
Atkins, et. al. Informational [Page 16]
RFC 1991 PGP Message Exchange Formats August 1996
6.3 Compressed data
Purpose. A compressed data packet is an envelope which
squeezes its contents into a small space
Definition. A compressed data packet is the concatenation of
following fields
(a) a packet structure field
(b) a byte, giving a compression type
(c) a byte string of compressed data
Byte string (c) is a packet which may be decompressed using
algorithm identified in byte (b). Typically, the data that
compressed consist of a literal data packet or a signature
concatenated to a literal data packet
A compression type selects a compression algorithm for use
compressed data packets. The following compression numbers
currently defined
1 -
255 -
More compression numbers may be defined in the future.
implementation need not support every MD number. The
must document the compression numbers understood by
implementation
6.4 Conventional-key-encrypted data
Purpose. A conventional-key-encrypted data packet is formed
encrypting a block of data with a conventional encryption
using a one-time session key. Typically, the block to be encrypted
a compressed data packet
Definition. A conventional-key-encrypted data packet is
concatenation of the following fields
(a) a packet structure field
(b) a byte string of encrypted data
The plaintext or compressed plaintext that is encrypted to form
(b) is first prepended with 64 bits of random data plus 16 "
check" bits. The random prefix serves to start off the
feedback chaining process with 64 bits of random material;
serves the same function as an initialization vector (IV) for
cipher-block-chaining encryption scheme. The key check prefix
Atkins, et. al. Informational [Page 17]
RFC 1991 PGP Message Exchange Formats August 1996
equal to the last 16 bits of the random prefix. During decryption,
comparison is made to see if the 7th and 8th byte of the
material match the 9th and 10th bytes. If so, then the
session key used for decryption is assumed to be correct
6.4.1 Conventional-encryption type
Purpose. The conventional-encryption type byte is used to
what conventional encryption algorithm is in use. The algorithm
byte will also define how long the conventional encryption key is
based upon the algorithm in use
Definition. A conventional-encryption type byte is a single
which defines the algorithm in use. It is possible that
algorithm in use may require further definition, such as key-length
It is up to the implementor to document the supported key-length
such a situation
1 - IDEA (16-byte key
255 -
6.5 Public-key-encrypted
Purpose. The public-key-encrypted packet is the format for
session key component of a message. The purpose of this packet is
convey the one-time session key used to encrypt the message to
recipient in a secure manner. This is done by encrypting the
key with the recipient's public key, so that only the recipient
recover the session key
Definition. A public-key-encrypted packet, version 2 or 3, is
concatenation of the following fields
(a) a packet structure field
(b) a byte, giving the version number, 2 or 3;
(c) a number ID field, giving the ID of a key
(d) a byte, giving a PKC number
(e) a byte string of encrypted data (DEK).
Byte string (e) represents the value of the session key,
using the reader's public key K, under the cryptosystem identified
byte (d).
The value of field (c) is the ID of K
Note that the packet does not actually identify K: two keys may
the same ID, by chance or by malice. Normally it will be
from the context which key K was used to create the packet.
Atkins, et. al. Informational [Page 18]
RFC 1991 PGP Message Exchange Formats August 1996
sometimes it is not obvious. In this case field (c) is useful. If
for example, a reader has created several keys, and receives
message, then he should attempt to decrypt the message only with
key whose ID matches the value of field (c). If he has
generated two keys with the same ID, then he must attempt to
the message with both keys, but this case is highly unlikely to
by chance
6.5.1 RSA-encrypted data encryption key (DEK
The Data Encryption Key (DEK) is a multiprecision field which
an RSA encrypted byte string. The byte string is a PKCS encoding
the secret key used the encrypt the message, with random padding
each Public-Key encrypted packet
PGP version 2.3 and later encode the DEK into an MPI using
following format
MSB . . .
0 2 RND(n bytes) 0 ALG(1 byte) DEK(k bytes) CSUM(2 bytes
ALG refers to the algorithm byte for the secret key algorithm used
encrypt the data packet. The DEK is the actual Data Encryption Key
and its size is dependent upon the encryption algorithm defined
ALG. For the IDEA encryption algorithm, type byte 1, the DEK is 16
bytes long. CSUM is a 16-bit checksum of the DEK, used to
that the correct Private key was used to decrypt this packet.
checksum is computed by the 16-bit sum of the bytes in the DEK.
is random padding to expand the byte to fill the size of the
Public Key that is used to encrypt the whole byte
6.6 Public Key
Purpose. A public key packet defines an RSA public key
Definition. A public key packet is the concatenation of
following fields
(a) packet structure field (2 or 3 bytes);
(b) version number = 2 or 3 (1 byte);;
(c) time stamp of key creation (4 bytes);
(d) validity period in days (0 means forever) (2 bytes);
(e) public-key-cryptosystem (PKC) type (1 byte);
(f) MPI of RSA public modulus n
(g) MPI of RSA public encryption exponent e
The validity period is always set to 0.
Atkins, et. al. Informational [Page 19]
RFC 1991 PGP Message Exchange Formats August 1996
6.7 User ID
Purpose. A user ID packet identifies a user and is associated with
public or private key
Definition. A user ID packet is the concatenation of the
fields
(a) packet structure field (2 bytes);
(b) User ID string
The User ID string may be any string of printable ASCII characters
However, since the purpose of this packet is to uniquely identify
individual, the usual practice is for the User ID string to
of the user's name followed by an e-mail address for that user,
latter enclosed in angle brackets
7. Transferable Public
Public keys may transferred between PGP users. The essential
of a transferable public key
(a) One public key packet
(b) One or more user ID packets
(c) Zero or more signature
The public key packet occurs first. Each of the following user
packets provides the identity of the owner of this public key.
there are multiple user ID packets, this corresponds to
means of identifying the same unique individual user; for example,
user may enjoy the use of more than one e-mail address, and
a user ID packet for each one. Immediately following each user
packet, there are zero or more signature packets. Each
packet is calculated on the immediately preceding user ID packet
the initial public key packet. The signature serves to certify
corresponding public key and user ID. In effect, the signer
testifying to his or her belief that this public key belongs to
user identified by this user ID
8.
Philip Zimmermann is the creator of PGP 1.0, which is the
of PGP 2.x. Major parts of later versions of PGP have
implemented by an international collaborative effort involving
large number of contributors, under the design guidance of
Zimmermann
Atkins, et. al. Informational [Page 20]
RFC 1991 PGP Message Exchange Formats August 1996
9. Security
Security issues are discussed throughout this memo
10. Authors'
Derek
12 Rindge Ave. #1
Cambridge,
Phone: +1 617 868-4469
EMail: warlord@MIT.
William
Comp-Comm
P. O. Box 2405
Brewster, MA 02631
EMail: stallings@ACM.
Philip
Boulder Software
3021 Eleventh
Boulder, Colorado 80304
Phone: +1-303-541-0140
EMail: prz@acm.
Atkins, et. al. Informational [Page 21]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
