LibrePGP Enhancements and Updates
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.
To clearly identify the specification, we assign these version numbers:
- LibrePGP 0.8.2 (described by draft-koch-openpgp-2015-rfc4880bis-02)
- LibrePGP 0.9.0 (described by draft-koch-librepgp-00
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.
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
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,
firstname.lastname@example.org is her
canonical address, but she also receives mail under the address
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
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
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.
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.
Table of Contents
- 1. Overview
- 2. Versions
- 3. List of Changes
- 3.1 Inclusion of related RFCs
- 3.2 Algorithm Requirements
- 3.3 Longer Fingerprint Format
- 3.4 Support for more ECC Curves
- 3.5 Support for Post-Quantum Encryption
- 3.6 Support for the OCB Encryption Mode
- 3.7 New Version 5 Signature Format
- 3.8 New Key Usage Flags
- 3.9 New Signature Subpackets
- 3.9.1 Issuer Fingerprint Signature Subpacket
- 3.9.2 Intended Recipient Signature Subpacket
- 3.9.3 Attested Certifications Signature Subpacket
- 3.9.4 Key Block Signature Subpacket
- 3.9.5 Added Literal Data Meta Hash Subpacket
- 3.9.6 Trust Alias Subpacket
- 3.10 Other Changes
- 3.11 Deprecations