Diffie-Hellman Key Agreement Method
Extracted elements (28)
partyAInfo is required in Static-Static mode because ZZ is identical for every message exchanged between the same pair of static keys; varying partyAInfo is the only mechanism to produce distinct KEKs per message without changing key material.
The algorithm OID of the CEK-wrapping algorithm is bound into OtherInfo (KeySpecificInfo) so that the derived KEK is cryptographically tied to its intended use, preventing key material from being repurposed for a different wrapping algorithm.
The X9.42-derived group parameter generation algorithm was chosen because its construction (p=qj+1, g of order q) enables third-party verification of correct and random parameter generation, protecting against parameters with special structure.
ZZ is the only source of secret entropy in the KM computation. Even if more bits than ZZ are generated, the effective key space is bounded by the size of ZZ and the security level of p and q. This is why a larger m is advisable when symmetric ciphers stronger than DES are used.
In CMS (RFC 2630), the recipient's key is identified by RecipientIdentifier pointing to the recipient's certificate, while the sender's public key is carried in OriginatorIdentifierOrKey either by certificate reference or inline public key inclusion.
The OtherInfo ASN.1 structure uses EXPLICIT tagging throughout. In ASN.1, EXPLICIT tagging is the default unless IMPLICIT is explicitly specified, so no IMPLICIT qualifier appears in the OtherInfo and KeySpecificInfo definitions.
Agents SHOULD generate domain parameters (g, p, q) using the algorithm derived from FIPS-186 and X9.42 described in Section 2.2.1, which allows correctness verification by a third party.
All implementations MUST implement Ephemeral-Static mode, where the recipient holds a static certified key pair and the sender generates a fresh key pair per message.
If partyAInfo is provided, it MUST contain exactly 512 bits. In CMS it is encoded as an OCTET STRING in the UserKeyingMaterial field.
Implementations MAY implement Static-Static mode. When doing so, both originator and recipient SHOULD perform the Section 2.1.5 public key validation or verify that their CA has validated the keys, to prevent small subgroup attacks.
In Ephemeral-Static mode, if the same ephemeral sender key is reused for multiple messages (e.g., cached for performance), a separate partyAInfo MUST be used for each message.
In Ephemeral-Static mode, the recipient SHOULD perform the public key check of Section 2.1.5 to resist small subgroup attacks. The check MAY be omitted if an opponent cannot determine decryption success or failure.
In Static-Static mode, partyAInfo MUST be used and MUST be different for each message to ensure distinct KEKs, since both sender and recipient static keys are fixed and ZZ is the same for every message.
Leading zeros in ZZ MUST be preserved so that ZZ occupies as many octets as p. For example, if p is 1024 bits, ZZ must be 128 bytes long.
Public key validation MAY be performed by verifying that y lies within [2, p-1] and that y^q mod p == 1. This prevents small subgroup attacks on the sender's key pair.
The subgroup order q MUST be at least 160 bits in length (m >= 160), and p must be a minimum of 512 bits. The private key x MUST be randomly generated in the interval [2, q-2].
Generator g is derived from the group parameters by computing g = h^j mod p, where j = (p-1)/q and h is any integer with 1 < h < p-1. If g == 1, a new h is chosen.
Group parameter generation for p and q uses an iterative SHA-1-based algorithm seeded with an arbitrary bit string SEED of length >= m. The algorithm sets q by computing U mod 2^m with the most-significant and least-significant bits forced to 1, then derives p = X - (X mod 2q) + 1.
Group parameter validation uses the j and validationParms elements from the PKIX ASN.1 DH key structure: verify p=qj+1 to confirm X9.42 criteria, and re-run the FIPS-186 p,q generation procedure with the embedded seed and counter to confirm random generation.
Standard KEK lengths: 3-key 3DES requires 192 bits, RC2-128 requires 128 bits, and RC2-40 requires 40 bits. RC2 effective key lengths equal real key lengths.
suppPubInfo encodes the length of the generated KEK in bits as a 32-bit network-byte-order number; for 3DES this is 00 00 00 C0 (192 bits), for RC2-128 it is 00 00 00 80.
The KEK is formed by taking the left n-most bytes of the concatenated KM blocks. For 3DES (192 bits) two SHA-1 invocations are needed; for RC2-128 (128 bits) and RC2-40 (40 bits), one invocation suffices.
The shared secret ZZ is computed as ZZ = g^(xb*xa) mod p, with each party performing ZZ = (yb^xa) mod p = (ya^xb) mod p. Group parameters require p=qj+1 where q is a large prime, and g=h^((p-1)/q) mod p with order q.
All security depends on the secrecy of private keying material. Disclosure of either party's private key compromises all messages sent or received under that key; loss of the private key renders messages unreadable.
Security level depends on three factors: symmetric key length (2^l for l-bit key), size of prime q (2^{m/2} level), and size of prime p (subexponential in bit size). A balanced design should equalize all three levels; overall security is limited by the weakest factor.
Static Diffie-Hellman keys are vulnerable to small subgroup attacks [LAW98]. This affects both sides in Static-Static mode and the receiver in Ephemeral-Static mode. Mitigations include public key validation per Section 2.1.5 or using key generation methods resistant to this attack [LL97].
Keying material is derived as KM = H(ZZ || OtherInfo), where OtherInfo is the DER encoding of a SEQUENCE containing KeySpecificInfo (algorithm OID + 4-byte counter), optional partyAInfo OCTET STRING, and suppPubInfo OCTET STRING. EXPLICIT tagging is used.
KeySpecificInfo is a SEQUENCE containing the algorithm OID of the CEK wrapping algorithm and a 4-byte counter (OCTET STRING SIZE 4) in network byte order, with initial value 00 00 00 01, incremented for each KM block.