- Id: RS-018.
- Status: Working draft.
- Type: Implementation.
- Issue tracking label:
This document specifies the requirements and recommendations for the support and selection of cryptographic algorithms in Relaynet. Every implementation of the Relaynet protocol suite is required to comply with this specification.
- RSA Key Constraints
- Required and Recommended Algorithms
- Algorithm Selection
The primary purpose of this document is to prevent the use of insecure cryptographic algorithms and to limit the set of supported algorithms for interoperability reasons. This specification only requires or recommends algorithms that have no known vulnerabilities, are well supported and are unencumbered by patents.
In each category, exactly one algorithm is required in order to achieve interoperability. Required algorithms are assumed to be secure until at least 2030. Recommended algorithms are assumed to be secure beyond 2030, but are more expensive to run and/or not widely supported.
This document aims to reflect industry best practices as of 2019, and is expected to be replaced eventually to reflect future developments. One change that can be anticipated is the exclusive use of Elliptic Curve Cryptography (ECC) for asymmetric key cryptography once support for the recommended curves is widespread.
Implementations MUST support 2048-bit RSA keys. They SHOULD also support 3072-bit and 4096-bit RSA keys. RSA keys with fewer than 2048 bits MUST NOT be supported.
Each supported algorithm is accompanied with its corresponding Object ID (OID) when available, as required by the Cryptographic Message Syntax (CMS), which is extensively used in Relaynet.
For security and compatibility reasons, Relaynet implementations SHOULD NOT support any algorithm that is not mentioned in this document.
Implementations MUST support SHA-256 (OID
2.16.8220.127.116.11.4.2.1) and they SHOULD also support SHA-384 (OID
2.16.818.104.22.168.4.2.2) and SHA-512 (OID
2.16.822.214.171.124.4.2.3). They MUST NOT support MD5 or SHA-1 for security reasons.
Implementations MUST support AES-128, and they SHOULD also support AES-192 and AES-256. They MUST NOT support DES for security reasons.
More specifically, Key Wrap mode MUST be used when encrypting cryptographic key materials and GCM MUST be used when encrypting payloads. Consequently, the following ciphers are required or recommended:
- AES-128-KW (required, OID
- AES-192-KW (recommended, OID
- AES-256-KW (recommended, OID
- AES-128-GCM (required, OID
- AES-192-GCM (recommended, OID
- AES-256-GCM (recommended, OID
Implementations MUST support RSA-OAEP (OID
1.2.840.1135126.96.36.199). They SHOULD also support Curve25519 (OID
188.8.131.52), and they MAY support Curve448 (OID
Implementations MUST support RSA-PSS (OID
1.2.840.1135184.108.40.206). They SHOULD also support Ed25519 EdDSA keys (OID
220.127.116.11), and they MAY support Ed448 EdDSA keys (OID
Implementations MUST support the Key Derivation Function (KDF) from ANSI X9.63. They SHOULD also support the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) defined by RFC 5869.
Any KDF not mentioned in this specification MAY be used if and only if it is regarded secure for pseudorandom secrets. The use of user-generated secrets (e.g., passwords) is outside the scope of Relaynet and therefore KDFs for such values are not considered in this specification.
For the avoidance of doubt, this document applies to any other algorithm used by the KDF. For example, when using the ANSI X9.63 KDF or HKDF, the hashing function must be allowed by this document.
Implementations MUST support Elliptic Curve Diffie-Hellman (ECDH; OID
18.104.22.168.12) with the NIST P-256 curve (OID
1.2.840.10045.3.1.7). They SHOULD also support the NIST curves P-384 (OID
22.214.171.124.34) and P-521 (OID
Implementations MAY also support the curves X25519 (OID
126.96.36.199) and X448 (OID
Finite field Diffie-Hellman (DH; OID
1.2.840.1135188.8.131.52) MAY also be supported, in which case implementations SHOULD only support DH groups from RFC3526 with at least 2048 bits. DH groups under 2048 bits MUST NOT be supported.
The DH or ECDH shared key MUST NOT be used directly to produce a ciphertext. Instead, the final shared key MUST be derived from a KDF allowed by this document.
Relaynet-compliant software SHOULD default to the required algorithms for interoperability reasons, but they MAY allow systems administrators or advanced end users to use algorithms that offer better security guarantees.