User:Singpolyma/OpenPGP

Packet Headers
The first octet of a packet gives information about the type of packet. The leftmost bit (octet & 0x80) is always set to 1. The second bit (octet & 0x40) is set to 1 for "new" format packets. This document describes only "new" format packets. If you wish to also be compatible with "old" format (used for simple data by many popular implementations for compatibility with old versions of PGP) please see RFC4880 section 4.2.1.

Packet Tag
The remaining bits (octet & 0x3f) form the "packet tag" or type specifier. There is a list of possible numbers, and what type they specify the packet to be, in RFC4880 section 4.3.

Packet Length
The next octets are the packet length specifier. If the first such octet is a number less than 192, it literally encodes the number of octets in the packet body.

If the first length-specifying octet is greater than 223 and less than 255, it encodes a partial body length. This means that the body will have (1 << (octet & 0x1f)) octets followed by another set of octets specifying the size of the next segment (see RFC4880 section 4.2.2.4).

If the first length-specifying octet is greater than 191 and less than 224, then read in a second octet as well, and the number of octets in the packet body is literally (((1st_octet - 192) << 8) + (2nd_octet) + 192).

If the first length-specifying octet is equal to 255, then read in the next four octets. These four octets make up an unsigned big-endian integer literally encoding the number of octets in the packet body.

One Pass Signature Packet
In order to simplify signature calculation, it may be useful to put a packet before the data packets to be signed which specifies some attributes of the signature so that things like the hash may be calculated as the decoder reads the subsequent data. This packet type is described briefly in RFC4880 section 5.4.

Signature Packet
The first octet of a signature packet literally encodes the version number for the data format of this signature packet. This document only describes version 4 signatures. If you wish to also be compatible with older versions, see RFC4880 section 5.2.2.

The second octet of a signature packet encodes a type specifier. A list of valid type specifier's is in RFC4880 section 5.2.1. When signing a text file (with line endings normalized to ) the type is 0x01. When signing a binary blob, the type is 0x00.

The third octet is a number specifying the public-key algorithm used for the signature. A list of values and their meanings can be found in RFC4880 section 9.1. An RSA key that can encrypt or sign is 0x01. An RSA key that can only sign is 0x03. According to RFC4880 section 13.5 the sign-only and encrypt-only specifiers are deprecated, just know they all mean "RSA".

The fourth octet is a number specifying the hash algorithm. A list of values and their meanings can be found in RFC4880 section 9.4. SHA256 is 0x08. SHA512 is 0x0a.

The fifth and sixth octets encode an unsigned big-endian integer specifying the length in octets of the "hashed" subpackets to follow (attributes which are signed).

After the data of the "hashed" subpackets comes two octets encoding an unsigned big-endian integer specifying the length in octets of the "unhashed" subpackets to follow (attributes which are not signed).

After the data of the "unhashed" subpackets comes two octets encoding the left 16 bits of the signed hash value.

Finally comes two octets encoding an unsigned big-endian integer that is the length in bits of a set of octets that form a (often very large) big-endian number (see RFC4880 section 3.2 for more on "Multiprecision Integers") that is the signature. This value is algorithm-specific.

From RFC4880: "The concatenation of the data being signed and the signature data from the version number through the hashed subpacket data (inclusive) is hashed. The resulting hash value is what is signed.  The left 16 bits of the hash are included in the Signature packet to provide a quick test to reject some invalid signatures."

Subpacket Format
The first 1, 2, or 5 octets encode the length is the same way as for packet length, except that partial body lengths are not allowed. This means that two-octet lengths may use the full range from 191 to 254 (inclusive) instead of just 224 to 254.

The first octet of the body is a type specifier. A list of values and their meanings can be found in RFC4880 section 5.2.3.1. From RFC4880: "An implementation SHOULD ignore any subpacket of a type that it does not recognize.". Some interesting values:


 * 0x02 = Signature Creation Time
 * 0x03 = Signature Expiration Time
 * 0x07 = Revocable
 * 0x10 = Issuer
 * 0x14 = Notation Data
 * 0x18 = Preferred Key Server
 * 0x1a = Policy URI
 * 0x1c = Signer's User ID

The data encoded in the body of each subpacket type is quite briefly explained in RFC4880 section 5.2.3.4 and following.

Computing Signatures
The way that signatures themselves should be computed is specified in RFC4880 section 5.2.4.

Compressed Data
Compressed data packets are briefly described in RFC4880 section 5.6. They contain compressed literal data packets.

Compression algorithm specifier values are listed in section 9.3.

Literal Data
Literal data packets (the body of the message to be signed or encrypted). These packets are briefly described in RFC4880 5.9.

Message Format
There is a good overview of OpenPGP messages (that is, sequences of packets) for different purposes in RFC4880 section 11.3.

Key Material
Key material packets are defined in RFC4880 section 5.5.

There is useful information about Key IDs and fingerprints in section 12.2.

Security Considerations
You should read RFC4880 section 14.