The method is a combination of an ECC DiffieHellman method to establish a shared secret, a key derivation method to process the shared secret into a derived key, and a key wrapping method that uses the derived key to protect a session key used to encrypt a message.¶
The OnePass DiffieHellman method C(1, 1, ECC CDH) [SP80056A] MUST be implemented with the following restrictions: the ECC CDH primitive employed by this method is modified to always assume the cofactor is 1, the KDF specified in Section 12.4 is used, and the KDF parameters specified below are used.¶
The KDF parameters are encoded as a concatenation of the following 5 variablelength and fixedlength fields, which are compatible with the definition of the OtherInfo bitstring [SP80056A]:¶

A variablelength field containing a curve OID, which is formatted as follows:¶
 A oneoctet size of the following field,¶
 The octets representing a curve OID defined in Section 9.2;¶
 A oneoctet public key algorithm ID defined in Section 9.1;¶

A variablelength field containing KDF parameters, which are identical to the corresponding field in the ECDH public key, and are formatted as follows:¶
 A oneoctet size of the following fields; values 0 and 0xFF are reserved for future extensions,¶
 A oneoctet value 0x01, reserved for future extensions,¶
 A oneoctet hash function ID used with the KDF,¶
 A oneoctet algorithm ID for the symmetric algorithm used to wrap the symmetric key for message encryption; see Section 12.5 for details;¶
 20 octets representing the UTF8 encoding of the string
Anonymous Sender
, which is the octet sequence 41 6E 6F 6E 79 6D 6F 75 73 20 53 65 6E 64 65 72 20 20 20 20;¶
 A variablelength field containing the fingerprint of the recipient encryption subkey identifying the key material that is needed for decryption.
For version 4 keys, this field is 20 octets.
For version 6 keys, this field is 32 octets.¶
The size in octets of the KDF parameters sequence, defined above, for encrypting to a v4 key is either 54 for curve NIST P256, 51 for curves NIST P384 and NIST P521, 55 for curves brainpoolP256r1, brainpoolP384r1 and brainpoolP512r1, or 56 for Curve25519Legacy.
For encrypting to a v6 key, the size of the sequence is either 66 for curve NIST P256, 63 for curves NIST P384 and NIST P521, or 67 for curves brainpoolP256r1, brainpoolP384r1 and brainpoolP512r1.¶
The key wrapping method is described in [RFC3394].
The KDF produces a symmetric key that is used as a keyencryption key (KEK) as specified in [RFC3394].
Refer to Section 12.5.1 for the details regarding the choice of the KEK algorithm, which SHOULD be one of the three AES algorithms.
Key wrapping and unwrapping is performed with the default initial value of [RFC3394].¶
The input to the key wrapping method is the plaintext described in Section 5.1, "PublicKey Encrypted Session Key Packets (Tag 1)", with a twooctet checksum appended (equal to the sum of the preceding octets, modulo 65536), and then padded using the method described in [PKCS5] to an 8octet granularity.¶
For example, in a v3 PublicKey Encrypted Session Key packet, the following AES256 session key, in which 32 octets are denoted from k0 to k31, is composed to form the following 40 octet sequence:¶
09 k0 k1 ... k31 s0 s1 05 05 05 05 05
¶
The octets s0 and s1 above denote the checksum of the session key octets.
This encoding allows the sender to obfuscate the size of the symmetric encryption key used to encrypt the data.
For example, assuming that an AES algorithm is used for the session key, the sender MAY use 21, 13, and 5 octets of padding for AES128, AES192, and AES256, respectively, to provide the same number of octets, 40 total, as an input to the key wrapping method.¶
In a v6 PublicKey Encrypted Session Key packet, the symmetric algorithm is not included, as described in Section 5.1.
For example, an AES256 session key would be composed as follows:¶
k0 k1 ... k31 s0 s1 06 06 06 06 06 06
¶
The octets k0 to k31 above again denote the session key, and the octets s0 and s1 denote the checksum.
In this case, assuming that an AES algorithm is used for the session key, the sender MAY use 22, 14, and 6 octets of padding for AES128, AES192, and AES256, respectively, to provide the same number of octets, 40 total, as an input to the key wrapping method.¶
The output of the method consists of two fields.
The first field is the MPI containing the ephemeral key used to establish the shared secret.
The second field is composed of the following two subfields:¶
 One octet encoding the size in octets of the result of the key wrapping method; the value 255 is reserved for future extensions;¶
 Up to 254 octets representing the result of the key wrapping method, applied to the 8octet padded session key, as described above.¶
Note that for session key sizes 128, 192, and 256 bits, the size of the result of the key wrapping method is, respectively, 32, 40, and 48 octets, unless size obfuscation is used.¶
For convenience, the synopsis of the encoding method is given below; however, this section, [SP80056A], and [RFC3394] are the normative sources of the definition.¶
 Obtain the authenticated recipient public key R¶
 Generate an ephemeral key pair {v, V=vG}¶
 Compute the shared point S = vR;¶
 m = symm_alg_ID  session key  checksum  pkcs5_padding;¶
 curve_OID_len = (octet)len(curve_OID);¶
 Param = curve_OID_len  curve_OID  public_key_alg_ID  03  01  KDF_hash_ID  KEK_alg_ID for AESKeyWrap 
Anonymous Sender
 recipient_fingerprint;¶
 Z_len = the key size for the KEK_alg_ID used with AESKeyWrap¶
 Compute Z = KDF( S, Z_len, Param );¶
 Compute C = AESKeyWrap( Z, m ) as per [RFC3394]¶
 VB = convert point V to the octet string¶
 Output (MPI(VB)  len(C)  C).¶
The decryption is the inverse of the method given.
Note that the recipient obtains the shared secret by calculating¶
S = rV = rvG, where (r,R) is the recipient's key pair.
¶
ECDH keys have a hash algorithm parameter for key derivation and a symmetric algorithm for key encapsulation.¶
For v6 keys, the following algorithms MUST be used depending on the curve.
An implementation MUST NOT generate a v6 ECDH key over any listed curve that uses different KDF or KEK parameters.
An implementation MUST NOT encrypt any message to a v6 ECDH key over a listed curve that announces a different KDF or KEK parameter.¶
For v4 keys, the following algorithms SHOULD be used depending on the curve.
An implementation SHOULD only use an AES algorithm as a KEK algorithm.¶
Table 30:
ECDH KDF and KEK parameters
Curve 
Hash algorithm 
Symmetric algorithm 
NIST P256 
SHA2256 
AES128 
NIST P384 
SHA2384 
AES192 
NIST P521 
SHA2512 
AES256 
brainpoolP256r1 
SHA2256 
AES128 
brainpoolP384r1 
SHA2384 
AES192 
brainpoolP512r1 
SHA2512 
AES256 
Curve25519 
SHA2256 
AES128 