| typedef struct DIGEST_CTX_s* DIGEST_CTX |
| typedef enum pgpArmor_e pgpArmor |
| typedef enum pgpArmorKey_e pgpArmorKey |
| typedef enum pgpCompressAlgo_e pgpCompressAlgo |
9.3.
Compression Algorithms
ID Algorithm
-- ---------
0 - Uncompressed
1 - ZIP (RFC 1951)
2 - ZLIB (RFC 1950)
100 to 110 - Private/Experimental algorithm.
Implementations MUST implement uncompressed data. Implementations SHOULD implement ZIP. Implementations MAY implement ZLIB.
| typedef struct pgpDigParams_s* pgpDigParams |
| typedef enum pgpHashAlgo_e pgpHashAlgo |
9.4.
Hash Algorithms
ID Algorithm Text Name
-- --------- ---- ----
1 - MD5 "MD5"
2 - SHA-1 "SHA1"
3 - RIPE-MD/160 "RIPEMD160"
4 - Reserved for double-width SHA (experimental)
5 - MD2 "MD2"
6 - Reserved for TIGER/192 "TIGER192"
7 - Reserved for HAVAL (5 pass, 160-bit)
"HAVAL-5-160"
100 to 110 - Private/Experimental algorithm.
Implementations MUST implement SHA-1. Implementations SHOULD implement MD5.
| typedef union pgpPktKey_u pgpPktKey |
5.5.3.
Secret Key Packet Formats
The Secret Key and Secret Subkey packets contain all the data of the Public Key and Public Subkey packets, with additional algorithm- specific secret key data appended, in encrypted form.
The packet contains:
Algorithm Specific Fields for RSA secret keys:
Algorithm Specific Fields for DSA secret keys:
Algorithm Specific Fields for Elgamal secret keys:
Secret MPI values can be encrypted using a passphrase. If a string- to-key specifier is given, that describes the algorithm for converting the passphrase to a key, else a simple MD5 hash of the passphrase is used. Implementations SHOULD use a string-to-key specifier; the simple hash is for backward compatibility. The cipher for encrypting the MPIs is specified in the secret key packet.
Encryption/decryption of the secret data is done in CFB mode using the key created from the passphrase and the Initial Vector from the packet. A different mode is used with V3 keys (which are only RSA) than with other key formats. With V3 keys, the MPI bit count prefix (i.e., the first two octets) is not encrypted. Only the MPI non- prefix data is encrypted. Furthermore, the CFB state is resynchronized at the beginning of each new MPI value, so that the CFB block boundary is aligned with the start of the MPI data.
With V4 keys, a simpler method is used. All secret MPI values are encrypted in CFB mode, including the MPI bitcount prefix.
The 16-bit checksum that follows the algorithm-specific portion is the algebraic sum, mod 65536, of the plaintext of all the algorithm- specific octets (including MPI prefix and data). With V3 keys, the checksum is stored in the clear. With V4 keys, the checksum is encrypted like the algorithm-specific data. This value is used to check that the passphrase was correct.
| typedef struct pgpPktKeyV3_s * pgpPktKeyV3 |
5.5.1.
Key Packet Variants
5.5.1.1. Public Key Packet (Tag 6)
A Public Key packet starts a series of packets that forms an OpenPGP key (sometimes called an OpenPGP certificate).
5.5.1.2. Public Subkey Packet (Tag 14)
A Public Subkey packet (tag 14) has exactly the same format as a Public Key packet, but denotes a subkey. One or more subkeys may be associated with a top-level key. By convention, the top-level key provides signature services, and the subkeys provide encryption services.
Note: in PGP 2.6.x, tag 14 was intended to indicate a comment packet. This tag was selected for reuse because no previous version of PGP ever emitted comment packets but they did properly ignore them. Public Subkey packets are ignored by PGP 2.6.x and do not cause it to fail, providing a limited degree of backward compatibility.
5.5.1.3. Secret Key Packet (Tag 5)
A Secret Key packet contains all the information that is found in a Public Key packet, including the public key material, but also includes the secret key material after all the public key fields.
5.5.1.4. Secret Subkey Packet (Tag 7)
A Secret Subkey packet (tag 7) is the subkey analog of the Secret Key packet, and has exactly the same format.
5.5.2. Public Key Packet Formats
There are two versions of key-material packets. Version 3 packets were first generated by PGP 2.6. Version 2 packets are identical in format to Version 3 packets, but are generated by PGP 2.5 or before. V2 packets are deprecated and they MUST NOT be generated. PGP 5.0 introduced version 4 packets, with new fields and semantics. PGP 2.6.x will not accept key-material packets with versions greater than 3.
OpenPGP implementations SHOULD create keys with version 4 format. An implementation MAY generate a V3 key to ensure interoperability with old software; note, however, that V4 keys correct some security deficiencies in V3 keys. These deficiencies are described below. An implementation MUST NOT create a V3 key with a public key algorithm other than RSA.
A version 3 public key or public subkey packet contains:
V3 keys SHOULD only be used for backward compatibility because of three weaknesses in them. First, it is relatively easy to construct a V3 key that has the same key ID as any other key because the key ID is simply the low 64 bits of the public modulus. Secondly, because the fingerprint of a V3 key hashes the key material, but not its length, which increases the opportunity for fingerprint collisions. Third, there are minor weaknesses in the MD5 hash algorithm that make developers prefer other algorithms. See below for a fuller discussion of key IDs and fingerprints.
| typedef struct pgpPktKeyV4_s * pgpPktKeyV4 |
The version 4 format is similar to the version 3 format except for the absence of a validity period.
This has been moved to the signature packet. In addition, fingerprints of version 4 keys are calculated differently from version 3 keys, as described in section "Enhanced Key Formats."
A version 4 packet contains:
Algorithm Specific Fields for RSA public keys:
Algorithm Specific Fields for DSA public keys:
Algorithm Specific Fields for Elgamal public keys:
| typedef struct pgpPktOnepass_s * pgpPktOnepass |
5.4.
One-Pass Signature Packets (Tag 4)
The One-Pass Signature packet precedes the signed data and contains enough information to allow the receiver to begin calculating any hashes needed to verify the signature. It allows the Signature Packet to be placed at the end of the message, so that the signer can compute the entire signed message in one pass.
A One-Pass Signature does not interoperate with PGP 2.6.x or earlier.
The body of this packet consists of:
Note that if a message contains more than one one-pass signature, then the signature packets bracket the message; that is, the first signature packet after the message corresponds to the last one-pass packet and the final signature packet corresponds to the first one- pass packet.
| typedef struct pgpPktPubkey_s pgpPktPubkey |
5.1.
Public-Key Encrypted Session Key Packets (Tag 1)
A Public-Key Encrypted Session Key packet holds the session key used to encrypt a message. Zero or more Encrypted Session Key packets (either Public-Key or Symmetric-Key) may precede a Symmetrically Encrypted Data Packet, which holds an encrypted message. The message is encrypted with the session key, and the session key is itself encrypted and stored in the Encrypted Session Key packet(s). The Symmetrically Encrypted Data Packet is preceded by one Public-Key Encrypted Session Key packet for each OpenPGP key to which the message is encrypted. The recipient of the message finds a session key that is encrypted to their public key, decrypts the session key, and then uses the session key to decrypt the message.
The body of this packet consists of:
Algorithm Specific Fields for RSA encryption
Algorithm Specific Fields for Elgamal encryption:
| typedef union pgpPktSig_u * pgpPktSig |
5.2.
Signature Packet (Tag 2)
A signature packet describes a binding between some public key and some data. The most common signatures are a signature of a file or a block of text, and a signature that is a certification of a user ID.
Two versions of signature packets are defined. Version 3 provides basic signature information, while version 4 provides an expandable format with subpackets that can specify more information about the signature. PGP 2.6.x only accepts version 3 signatures.
Implementations MUST accept V3 signatures. Implementations SHOULD generate V4 signatures. Implementations MAY generate a V3 signature that can be verified by PGP 2.6.x.
Note that if an implementation is creating an encrypted and signed message that is encrypted to a V3 key, it is reasonable to create a V3 signature.
| typedef struct pgpPktSigV3_s * pgpPktSigV3 |
5.2.2.
Version 3 Signature Packet Format
The body of a version 3 Signature Packet contains:
Algorithm Specific Fields for RSA signatures:
Algorithm Specific Fields for DSA signatures:
| typedef struct pgpPktSigV4_s * pgpPktSigV4 |
5.2.3.
Version 4 Signature Packet Format
The body of a version 4 Signature Packet contains:
| typedef enum pgpPubkeyAlgo_e pgpPubkeyAlgo |
9.1.
Public Key Algorithms
ID Algorithm
-- ---------
1 - RSA (Encrypt or Sign)
2 - RSA Encrypt-Only
3 - RSA Sign-Only
16 - Elgamal (Encrypt-Only), see [ELGAMAL]
17 - DSA (Digital Signature Standard)
18 - Reserved for Elliptic Curve
19 - Reserved for ECDSA
20 - Elgamal (Encrypt or Sign)
21 - Reserved for Diffie-Hellman (X9.42,
as defined for IETF-S/MIME)
100 to 110 - Private/Experimental algorithm.
Implementations MUST implement DSA for signatures, and Elgamal for encryption. Implementations SHOULD implement RSA keys. Implementations MAY implement any other algorithm.
| typedef enum pgpSigType_e pgpSigType |
5.2.1.
Signature Types
There are a number of possible meanings for a signature, which are specified in a signature type octet in any given signature.
| typedef enum pgpSubType_e pgpSubType |
5.2.3.1.
Signature Subpacket Specification
The subpacket fields consist of zero or more signature subpackets. Each set of subpackets is preceded by a two-octet scalar count of the length of the set of subpackets.
Each subpacket consists of a subpacket header and a body. The header consists of:
The length includes the type octet but not this length. Its format is similar to the "new" format packet header lengths, but cannot have partial body lengths. That is:
if the 1st octet < 192, then
lengthOfLength = 1
subpacketLen = 1st_octet
if the 1st octet >= 192 and < 255, then
lengthOfLength = 2
subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
if the 1st octet = 255, then
lengthOfLength = 5
subpacket length = [four-octet scalar starting at 2nd_octet]
The value of the subpacket type octet may be:
2 = signature creation time
3 = signature expiration time
4 = exportable certification
5 = trust signature
6 = regular expression
7 = revocable
9 = key expiration time
10 = placeholder for backward compatibility
11 = preferred symmetric algorithms
12 = revocation key
16 = issuer key ID
20 = notation data
21 = preferred hash algorithms
22 = preferred compression algorithms
23 = key server preferences
24 = preferred key server
25 = primary user id
26 = policy URL
27 = key flags
28 = signer's user id
29 = reason for revocation
100 to 110 = internal or user-defined
An implementation SHOULD ignore any subpacket of a type that it does not recognize.
Bit 7 of the subpacket type is the "critical" bit. If set, it denotes that the subpacket is one that is critical for the evaluator of the signature to recognize. If a subpacket is encountered that is marked critical but is unknown to the evaluating software, the evaluator SHOULD consider the signature to be in error.
| typedef enum pgpSymkeyAlgo_e pgpSymkeyAlgo |
9.2.
Symmetric Key Algorithms
ID Algorithm
-- ---------
0 - Plaintext or unencrypted data
1 - IDEA [IDEA]
2 - Triple-DES (DES-EDE, as per spec -
168 bit key derived from 192)
3 - CAST5 (128 bit key, as per RFC 2144)
4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH]
5 - SAFER-SK128 (13 rounds) [SAFER]
6 - Reserved for DES/SK
7 - Reserved for AES with 128-bit key
8 - Reserved for AES with 192-bit key
9 - Reserved for AES with 256-bit key
100 to 110 - Private/Experimental algorithm.
Implementations MUST implement Triple-DES. Implementations SHOULD implement IDEA and CAST5. Implementations MAY implement any other algorithm.
4.3.
Packet Tags
The packet tag denotes what type of packet the body holds. Note that old format headers can only have tags less than 16, whereas new format headers can have tags as great as 63.
| typedef struct pgpValTbl_s * pgpValTbl |
| typedef enum rpmDigestFlags_e rpmDigestFlags |
Bit(s) to control digest operation.
| enum pgpArmor_e |
| enum pgpArmorKey_e |
| enum pgpCompressAlgo_e |
9.3.
Compression Algorithms
ID Algorithm
-- ---------
0 - Uncompressed
1 - ZIP (RFC 1951)
2 - ZLIB (RFC 1950)
100 to 110 - Private/Experimental algorithm.
Implementations MUST implement uncompressed data. Implementations SHOULD implement ZIP. Implementations MAY implement ZLIB.
| enum pgpHashAlgo_e |
9.4.
Hash Algorithms
ID Algorithm Text Name
-- --------- ---- ----
1 - MD5 "MD5"
2 - SHA-1 "SHA1"
3 - RIPE-MD/160 "RIPEMD160"
4 - Reserved for double-width SHA (experimental)
5 - MD2 "MD2"
6 - Reserved for TIGER/192 "TIGER192"
7 - Reserved for HAVAL (5 pass, 160-bit)
"HAVAL-5-160"
100 to 110 - Private/Experimental algorithm.
Implementations MUST implement SHA-1. Implementations SHOULD implement MD5.
| enum pgpPubkeyAlgo_e |
9.1.
Public Key Algorithms
ID Algorithm
-- ---------
1 - RSA (Encrypt or Sign)
2 - RSA Encrypt-Only
3 - RSA Sign-Only
16 - Elgamal (Encrypt-Only), see [ELGAMAL]
17 - DSA (Digital Signature Standard)
18 - Reserved for Elliptic Curve
19 - Reserved for ECDSA
20 - Elgamal (Encrypt or Sign)
21 - Reserved for Diffie-Hellman (X9.42,
as defined for IETF-S/MIME)
100 to 110 - Private/Experimental algorithm.
Implementations MUST implement DSA for signatures, and Elgamal for encryption. Implementations SHOULD implement RSA keys. Implementations MAY implement any other algorithm.
| enum pgpSigType_e |
5.2.1.
Signature Types
There are a number of possible meanings for a signature, which are specified in a signature type octet in any given signature.
| enum pgpSubType_e |
5.2.3.1.
Signature Subpacket Specification
The subpacket fields consist of zero or more signature subpackets. Each set of subpackets is preceded by a two-octet scalar count of the length of the set of subpackets.
Each subpacket consists of a subpacket header and a body. The header consists of:
The length includes the type octet but not this length. Its format is similar to the "new" format packet header lengths, but cannot have partial body lengths. That is:
if the 1st octet < 192, then
lengthOfLength = 1
subpacketLen = 1st_octet
if the 1st octet >= 192 and < 255, then
lengthOfLength = 2
subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
if the 1st octet = 255, then
lengthOfLength = 5
subpacket length = [four-octet scalar starting at 2nd_octet]
The value of the subpacket type octet may be:
2 = signature creation time
3 = signature expiration time
4 = exportable certification
5 = trust signature
6 = regular expression
7 = revocable
9 = key expiration time
10 = placeholder for backward compatibility
11 = preferred symmetric algorithms
12 = revocation key
16 = issuer key ID
20 = notation data
21 = preferred hash algorithms
22 = preferred compression algorithms
23 = key server preferences
24 = preferred key server
25 = primary user id
26 = policy URL
27 = key flags
28 = signer's user id
29 = reason for revocation
100 to 110 = internal or user-defined
An implementation SHOULD ignore any subpacket of a type that it does not recognize.
Bit 7 of the subpacket type is the "critical" bit. If set, it denotes that the subpacket is one that is critical for the evaluator of the signature to recognize. If a subpacket is encountered that is marked critical but is unknown to the evaluating software, the evaluator SHOULD consider the signature to be in error.
| enum pgpSymkeyAlgo_e |
9.2.
Symmetric Key Algorithms
ID Algorithm
-- ---------
0 - Plaintext or unencrypted data
1 - IDEA [IDEA]
2 - Triple-DES (DES-EDE, as per spec -
168 bit key derived from 192)
3 - CAST5 (128 bit key, as per RFC 2144)
4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH]
5 - SAFER-SK128 (13 rounds) [SAFER]
6 - Reserved for DES/SK
7 - Reserved for AES with 128-bit key
8 - Reserved for AES with 192-bit key
9 - Reserved for AES with 256-bit key
100 to 110 - Private/Experimental algorithm.
Implementations MUST implement Triple-DES. Implementations SHOULD implement IDEA and CAST5. Implementations MAY implement any other algorithm.
| enum pgpTag_e |
4.3.
Packet Tags
The packet tag denotes what type of packet the body holds. Note that old format headers can only have tags less than 16, whereas new format headers can have tags as great as 63.
| enum rpmDigestFlags_e |
| char* pgpArmorWrap | ( | int | atype, | |
| const unsigned char * | s, | |||
| size_t | ns | |||
| ) |
Wrap a OpenPGP packets in ascii armor for transport.
| atype | type of armor | |
| s | binary pkt data | |
| ns | binary pkt data length |
| void pgpCleanDig | ( | pgpDig | dig | ) |
Release (malloc'd) data from container.
| dig | container |
| int pgpExtractPubkeyFingerprint | ( | const char * | b64pkt, | |
| pgpKeyID_t | keyid | |||
| ) |
Extract OpenPGP public key fingerprint from base64 encoded packet.
| b64pkt | base64 encoded openpgp packet |
| keyid | public key fingerprint |
Destroy a container for parsed OpenPGP packates.
| dig | container |
| static unsigned int pgpGrab | ( | const uint8_t * | s, | |
| size_t | nbytes | |||
| ) | [inline, static] |
| char* pgpHexStr | ( | const uint8_t * | p, | |
| size_t | plen | |||
| ) |
Return hex formatted representation of bytes.
| p | bytes | |
| plen | no. of bytes |
| static size_t pgpLen | ( | const uint8_t * | s, | |
| size_t * | lenp | |||
| ) | [inline, static] |
| pgpDig pgpNewDig | ( | void | ) |
Create a container for parsed OpenPGP packates.
| int pgpPrtPkts | ( | const uint8_t * | pkts, | |
| size_t | pktlen, | |||
| pgpDig | dig, | |||
| int | printing | |||
| ) |
Print/parse a OpenPGP packet(s).
| pkts | OpenPGP packet(s) | |
| pktlen | OpenPGP packet(s) length (no. of bytes) |
| dig | parsed output of signature/pubkey packet parameters |
| printing | should packets be printed? |
| int pgpPubkeyFingerprint | ( | const uint8_t * | pkt, | |
| size_t | pktlen, | |||
| pgpKeyID_t | keyid | |||
| ) |
Calculate OpenPGP public key fingerprint.
| pkt | OpenPGP packet (i.e. PGPTAG_PUBLIC_KEY) | |
| pktlen | OpenPGP packet length (no. of bytes) |
| keyid | public key fingerprint |
| pgpArmor pgpReadPkts | ( | const char * | fn, | |
| uint8_t ** | pkt, | |||
| size_t * | pktlen | |||
| ) |
Parse armored OpenPGP packets from a file.
| fn | file name |
| pkt | dearmored OpenPGP packet(s) (malloced) | |
| pktlen | dearmored OpenPGP packet(s) length in bytes |
| DIGEST_CTX rpmDigestDup | ( | DIGEST_CTX | octx | ) |
Duplicate a digest context.
| octx | existing digest context |
| int rpmDigestFinal | ( | DIGEST_CTX | ctx, | |
| void ** | datap, | |||
| size_t * | lenp, | |||
| int | asAscii | |||
| ) |
Return digest and destroy context.
Final wrapup - pad to 64-byte boundary with the bit pattern 1 0* (64-bit count of bits processed, MSB-first)
| ctx | digest context |
| datap | address of returned digest | |
| lenp | address of digest length |
| asAscii | return digest as ascii string? |
| DIGEST_CTX rpmDigestInit | ( | pgpHashAlgo | hashalgo, | |
| rpmDigestFlags | flags | |||
| ) |
Initialize digest.
Set bit count to 0 and buffer to mysterious initialization constants.
| hashalgo | type of digest | |
| flags | bit(s) to control digest operation |
| size_t rpmDigestLength | ( | pgpHashAlgo | hashalgo | ) |
Obtain digest length in bytes.
| hashalgo | type of digest |
| int rpmDigestUpdate | ( | DIGEST_CTX | ctx, | |
| const void * | data, | |||
| size_t | len | |||
| ) |
Update context with next plain text buffer.
| ctx | digest context | |
| data | next data buffer | |
| len | no. bytes of data |
| int rpmFreeCrypto | ( | void | ) |
Shutdown cryptography.
| int rpmInitCrypto | ( | void | ) |
Perform cryptography initialization.
It must be called before any cryptography can be used within rpm. It's not normally necessary to call it directly as it's called in general rpm initialization routines.
1.5.7.1