LibrePGP Enhancements and Updates

1. Overview

The actual specification of LibrePGP is given by the rfc4880bis document. To help understanding the changes done in LibrePGP compared to the OpenPGP specification RFC-4880 the following text gives a hopefully easier readable, but non-normative description.

Note that almost everything here has been implemented by the majority of OpenPGP implementations. However, some of these implementations plan to follow the forthcoming OpenPGP specification and may create data which is not compatible with LibrePGP and may break existing software deployments and keys.

2. Versions

To clearly identify the specification, we assign these version numbers:

• LibrePGP 0.8.2 (described by the I-D openpgp-2015-rfc4880bis-02)
• LibrePGP 0.9.0 (described by the I-D librepgp-00
• LibrePGP 0.9.2 (described by the I-D librepgp-02

3. List of Changes

This list should be considered as draft and may not cover all changes. This will be fixed over time and newer developments will clearly be marked as such. See the repository for the complete history.

3.1 Inclusion of related RFCs

After the release of RFC4880 in November 2007, two further RFC extending OpenPGP have been released. These changes as well as other errata are part of LibrePGP. In detail these are:

• Errata 2270, 2271, 2242, 3298
• Camellia cipher from RFC-5581
• ECC for OpenPGP from RFC-6637

The majority of implementations have adopted these RFCs and the errata for a long time. In particular ECC for OpenPGP got widespread support in software and hardware.

3.2 Algorithm Requirements

• Marked SHA2-256 as MUST implement
• Marked SHA-1 as SHOULD NOT be used to create messages
• Marked MD5 as SHOULD NOT implement
• Strongly deprecated the decryption of non integrity protected data

3.3 Longer Fingerprint Format

The main reason for introducing v5 keys is the definition of a new fingerprint format. To avoid the use of different fingerprints for the same key, each key format has exactly one standard fingerprint.

The v5 fingerprint is the full SHA2-256 hash of the key packet, computed in a similar way to v4 fingerprint. v5 keyIDs are derived from this fingerprint by taking the most significant octets and not the least significant as with v3 and v4 fingerprints.

A new Feature Flag available on v4 packets can be used to indicate support for v5 keys. This is required to know whether a v5 key signature can be used.

3.4 Support for more ECC Curves

RFC-6637 described only the 3 standard NIST curves, but allowed to add other curves using an Object Identifier (OID) mechanism. LibrePGP explicitly lists a couple of additional curves:

• BrainpoolP256r1, BrainpoolP384r1, and BrainpoolP512r1
• Ed25519 and Curve25519
• Ed488 and X448

The EdDSA algorithm is used with Curve25519 and X448 based signatures. For signatures with Curve25519 a variant of that curve named Ed25519 is used. Because this was introduced and widely deployed before the IETF standardized X25519, it slightly differes from the IETF version.

For Ed25519 and Curve25519, alternative OIDs are specified which SHOULD be used with v5 keys. Their original OIDs are in wide spread use and need to be supported for existing v4 keys.

Ed25519 and Curve25519 with ECDH encryption are SHOULD implement algorithms.

The Ed488 and X488 curves MUST only be used with v5 keys.

3.5 Support for Post-Quantum Encryption

LibrePGP will soon support ML-KEM (aka CRYSTALS-Kyber) to allow for post-quantum security.

3.6 Support for the OCB Encryption Mode

• Added v5 Symmetric-Key Encrypted Session Key packet
• Added OCB encryption of secret keys

3.7 New Version 5 Signature Format

The meta data (file name and date) is now protected. The issuer´s fingerprint MUST be used, and the issuer subpacket MUST NOT be used.

3.8 New Key Usage Flags

• Restricted Encryption key flag
• Timestamping key flag

3.9 New Signature Subpackets

3.9.1 Issuer Fingerprint Signature Subpacket

Signatures SHOULD now include the entire fingerprint of the key issuing the signature and not just the keyID. For backwards compatibility, the issuer subpacket carrying the keyID SHOULD also be included for v4 keys. For the new v5 key, the issuer subpacket MUST NOT be used. Note that this subpacket has been deployed many years ago and is in wide spread use.

3.9.2 Intended Recipient Signature Subpacket

The idea is to bind a signature to its outer encryption. This is one octet with the key version and 20 or 32 octets with the fingerprint.

3.9.3 Attested Certifications Signature Subpacket

This feature finally allows to implement the No-Modify flag in the key server preferences. This is mostly useful to implement the Web-of-Trust along with public keyserver.

3.9.4 Key Block Signature Subpacket

This subpacket allows to convey an entire key along with a data signature. All non necessary packet material should be stripped from that key and the key MUST be capable of encryption. This packet allows switching to to encrypted communication right after having received a signed message.

3.9.5 Added Literal Data Meta Hash Subpacket

This packet MAY be used to protect the meta data from the Literal Data packet in v4 signatures.

Implementers need to support this package if they want to be able to verify future v4 signatures. Adding support should be easy, because v5 signatures require hashing of this meta data anyway.

3.9.6 Trust Alias Subpacket

This subpacket allows a keyholder to state an alias for a mail address in the User ID. This subpacket can be used along with the Trust Signatures and Regular Expression subpacket to handle the common case that mail addresses with and without a subdomain are used. For example, alice@example.org is her canonical address, but she also receives mail under the address alice@lab.example.org.

Implementers need to support this flag if they want to support all kind of trust signatures.

3.10 Other Changes

The Literal Data Packet may now use m instead of t as format character to indicate that the data can be expected to be in MIME format. Implementers SHOULD accept this packet and at minimum consider this to be an alias for b.

New notation data has been specified for use by small device implementations as originally described by draft-atkins-openpgp-device-certificates. Implementers do not need to do anything here.

3.11 Deprecations

The old PGP-2 style Symmetrically Encrypted Data Packet is deprecated, because it has not have integrity checking unless the data is also signed and verified.

Version 3 signatures as created by PGP-2 are deprecated due to their use of the deprecated MD5 algorithm.