Elliptic Curve Cryptography (ECC) in OpenPGP
obsoleted by
- rfc-9580 — OpenPGP
Extracted elements (25)
Only AES is recommended as the KEK algorithm for ECDH key wrapping because backward compatibility is not a concern for this new format; the KEK is scoped entirely within the ECDH Public-Key Encrypted Session Key Packet, unlike the session key algorithm for message encryption.
The 'Anonymous Sender ' string (20 octets) is included in the KDF Param to bind the shared secret to the OpenPGP usage context and prevent cross-protocol key reuse, while the recipient fingerprint binds the derived key to the specific recipient key material.
The three ECC curves are chosen to correspond to symmetric key sizes of 128, 192, and 256 bits, enabling a compliant application to offer balanced public key security matched to the AES algorithms permitted by RFC 4880, rather than simply increasing RSA key sizes.
A subset of this document's algorithms achieves NSA Suite B compatibility. At 192-bit security: P-384, AES-256, SHA2-384 throughout (KDF, KEK, and message digest). At 128-bit security: additionally P-256, AES-128, and SHA2-256 are allowed.
No changes to the OpenPGP Version 3 Signature Packet format are needed for ECDSA; ECDSA signatures use the existing signature packet format defined in RFC 4880 Section 5.2.2.
A compliant application MUST implement NIST curve P-256, SHOULD implement P-521, and MAY implement P-384. It MUST implement SHA2-256 and AES-128, SHOULD implement SHA2-384, SHA2-512, and AES-256.
A compliant application MUST NOT use a new point encoding format when in doubt that any recipient can support it; the uncompressed format is the only format currently defined.
A Modification Detection Code (MDC) MUST be used any time a symmetric key is protected by ECDH, consistent with RFC 4880 Section 5.13.
Compliant applications MUST support both ECDSA and ECDH public key algorithms.
The Concatenation Key Derivation Function (NIST SP 800-56A Approved Alternative 1) with SHA2-256 or stronger is REQUIRED for EC encryption. The KDF input uses the x-coordinate of the shared point and an OtherInfo Param block.
The ECDH One-Pass DH primitive MUST be implemented with the cofactor assumed to be 1 (i.e., ECC CDH without cofactor multiplication), using the KDF from Section 7.
The zero point (point at infinity) SHALL NOT appear in any data structures defined in this document.
The ECDH method combines One-Pass DH C(1,1,ECC CDH) with cofactor assumed to be 1, the Section 7 KDF, and AES Key Wrap (RFC 3394). The sender generates an ephemeral key pair, derives Z via KDF, wraps the session key with AES Key Wrap, and outputs (MPI(ephemeral point) || len(C) || C).
Three NIST prime-field curves are supported: P-256 (OID 1.2.840.10045.3.1.7), P-384 (OID 1.3.132.0.34), and P-521 (OID 1.3.132.0.35). Each curve is referenced by a DER-derived truncated OID byte sequence called a 'curve OID'.
Two algorithm IDs are assigned in the PGP 'Public Key Algorithms' registry: ID 18 for ECDH public key algorithm (new) and ID 19 for ECDSA public key algorithm (previously designated but unused).
ECC scalar multiplication in ECDSA and ECDH is vulnerable to side channel attacks when the application can be modeled as a decryption or signing oracle (e.g., a network service). Countermeasures include limiting failure counts, time-blinding operations, and eliminating measurable distinctions between EC point addition and doubling.
SHA-1 MUST NOT be used with ECDSA or the KDF in the ECDH method. None of the ECC methods are allowed with deprecated V3 keys. Private keys MUST be protected using only iterated and salted S2K (RFC 4880 Section 3.7.1.3).
Symmetric algorithm key preference lists in OpenPGP keys must be set correctly from key generation to maintain balanced security; mismatched preferences can force use of weaker algorithms. When encrypting to multiple recipients with an unordered intersection of algorithm sets, a compliant application SHOULD choose the stronger algorithm.
Curve OIDs are DER-encoded ASN.1 OID bytes with the leading tag and length octets stripped. P-256 is 8 bytes (2A 86 48 CE 3D 03 01 07), P-384 is 5 bytes (2B 81 04 00 22), P-521 is 5 bytes (2B 81 04 00 23).
EC points are encoded in uncompressed format within an MPI as '04 || x || y', where x and y are big-endian zero-padded to the field size rounded up to 8-bit boundary. Payload sizes are 515 bits for P-256, 771 for P-384, and 1059 for P-521.
ECDH algorithm-specific fields in Public-Key Encrypted Session Key Packet (Tag 1): an MPI of the ephemeral EC point, followed by a 1-octet size and up to 254 octets of the AES Key Wrap output. Value 255 for the size octet is reserved.
ECDH public key algorithm-specific fields extend ECDSA fields by appending a KDF parameters field: 1-octet size + 0x01 (reserved) + 1-octet KDF hash ID + 1-octet KEK symmetric algorithm ID. The ECDH secret key is an MPI of the scalar private key.
ECDSA public key algorithm-specific fields: a variable-length curve OID field (1-octet size + OID bytes, with 0x00 and 0xFF reserved) followed by an MPI of the EC public key point.
The KDF Param field for ECDH is a concatenation of: curve OID (1-octet length + OID bytes), 1-octet public key algorithm ID, KDF parameters (1-octet size + 0x01 + hash ID + KEK alg ID), 20 octets of UTF-8 'Anonymous Sender ', and 20 octets of recipient key fingerprint. Total size is 54 or 51 octets for the three defined curves.
The session key value 'm' fed to AES Key Wrap is encoded as 'symm_alg_ID || session_key || checksum || PKCS#5_padding' padded to 8-byte granularity; PKCS#1.5 padding is explicitly omitted. For AES-256 this results in a 40-octet padded value.