Bifroest Mr. Tines MacCTC CTCjava Manual Pages
Bifroest Mr. Tines CTC Home CTClib MacCTC CTCjava Manual

PGP5 - New Formats

At the time of originally writing this page, there was no documentation available on PGP formats. Since the PGP Inc. have released a document of their own.

Whereas I have every reason to believe that the following information is accurate, I cannot give any guarantee that it is so. The main changes are as follows:-

CTB Revision

PGP2.x packets all start with a Cipher Type Byte(CTB). Whereas PGP5 does not use the term CTB any more the concept of a Tag/Length/Value record remains and the first byte still identifys the type.

2.3 defines bit-6 as reversed  and always '0'. PGP5 defines the CTB to have a different format if bit-6 is '1'. The new format is as follows:-

Bit 7:
Always 1, which designates this as a CTB
Bit 6:
Always 1, indicates new style CTB
Bits 5-0:
CTB type field, specifies type of packet that follows

Note that the new style CTB has shifted the type field 2-bit to the right and increased it to 6-bits. Accordingly the CTB nolonger includes the length-of-length  information. It also allows 64 rather than 16 types.

Length Field

As the new-style CTB byte no longer includes length -of-length  information this is encoded instead into the top bits of first length byte, as follows:-

Bit-7 '0':
Packet length in the range 0-127; bits 6-0 contain the length (as the other bit is zero the byte contains the length)
Bits 7-6 '10':
Packet length in the range 128-191; bits 5-0 contain the (length - 128); effectively the byte contains the length.
Bits 7-5 '110':
Packet length in the range 192-8383; bits 4-0 and all of the next byte (big-endian) contains (length - 192).
Bits 7-5 '111':
The packet length is an exact power of 2; bits 4-0 are the binary exponent.

CTB type values

PGP5.0 supports most of the old type values are a number of new ones are defined. I have yet to precisely determine precisely what any of these are used for. The new ones are:-

3
ConvESK; ESK (?Encrypted Session Key?) is the new designation of what was previously called PKE (Public-Key Encrypted data)
4
1PASSSIG; an new signature packe
7
SECSUBKEY; secret sub-key
14
PUBSUBKEY; public sub-key
16
COMMENT; N.B. The Comment packet previously had a value of 14 but has been displaced by PUBSUBKEY.

Version Byte

Some CTB record types (largely those associated with Public Key Encryption) have a version byte as the first byte of the record body. The meaning of versions bytes is as follows:-

2
PGP2.5 and earlier
3
PGP2.6
4
PGP3.0 and later

All other values are undefined. The value defines the precise details of the format of the following packet. CTC1.0 does not accept packets except with versions 2 or 3. PGP5.0 writes some packets at version 3 and some at version 4.

Note that the changes due to version byte are not necessarily related to the changes due to change in algorithm. Version 2/3 defined that the precise data contents of a packet was algorithm byte dependent and only defines the format for RSA. Accordingly different public-key algorithm format can be accomodated with version 2/3 packets.

I ascribe to version, only those changes that explicitly break the Version 2/3 packet definition.

Key Certificate packets

These are packets of type 5 & 6 in Version 2/3, which are respectively Secret and Public key certificates. The public-key format is a truncated variant of the Secret key format differing only in omitting the secret-key data.

In addition Version 4 has packet types 7 & 14 which are Secret and Public sub-key certificates respectively. These seem (although this remains to be confirmed) the same format at types 5 & 6 respectively.

The changes are as follows:

The Version 3 validity field (bytes 7 & 8) is omitted.
I suspect that there has to be more to it than this but at the moment I cannot find anything. It is possible, for example, that the encryption of secret-key has subtly changed.

Signature packets

The signature packet has been considerably extended and complicated.
Offset Length Meaning
0 1 Version byte (=4)
1 1 Signature type (included in hash) (nested flag)
2 1 PK algorithm (1 = RSA) (included in hash)
3 1 Hash algorithm (1 = MD5) (included in hash)
4 2 Length of extra material included in hash (=y)
6 y Subpackets (hashed)
6+y 2 Length of extra material not included in hash (=z)
8+y z Subpackets (unhashed)
8+y+z 2 First 2 bytes of message digest (16-bit checksum)
10+y+z 2+w MPI of PK-signed integer

Note that this is a significant change from the Version 2/3 format.

The sub-packet structure is new and replaces an number of fields in the old format. It is also much more general. The sub-packets are a Tag/Length/Value structure be much simpler than the CTB structure. The structure is:-
Offset Size Name Description
0 1 Length (N) Number of bytes in record excluding length field, but including type field
1 1 Type Enumation value indicating significance of record
2 N-1 Contents Record data according to the type of the record.

The following type of sub-packet are currently defined (although the comments indicate that they are not all implemented yet):-

1
VERSION
2
CREATION,
3
EXPIRATION,
9
KEY_CAPABILITIES
10
KEY_EXPIRATION,
11
KEY_RECOVERY_KEY,
12
PREFERRED_ALGS,
16
KEYID
17
USERID,
18
URL,
19
FINGER

The precise use, validity etc. of each value and which can legitimately be in the hashed or unhashed portion of the SKE record is not yet clear.

New Algorithms

PGP5.0 includes the following extra algorithm byte values and corresponding ciphers:-

Symmetric Ciphers

2
3DES
3
CAST5

Public Key Ciphers

2
RSA Encrypt-only (already supported by CTC1.0)
3
RSA Sign-only (already supported by CTC1.0)
16
El Gamal/Diffie-Hellman
17
DSA (Digital Signature Algorithm)

Message Digests

2
SHA (already supported by CTC1.0 but with a different byte value)
3
160-bit RIPE

webmaster@bifroest.demon.co.uk