Relaynet Cryptographic Algorithms, Version 1

  • Id: RS-018.
  • Status: Working draft.
  • Type: Implementation.


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.

Table of contents

  1. Introduction
  2. RSA Key Constraints
  3. Required and Recommended Algorithms
    1. Cryptographic Hash Functions
    2. Key Exchange Algorithms
    3. Symmetric Ciphers
    4. Asymmetric Ciphers
    5. Digital Signature Algorithms
  4. 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.

RSA Key Constraints

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 explicitly required or recommended in this document, unless the implementer has a very strong cryptographic background and very strong reasons to use other algorithms.

Cryptographic Hash Functions

Implementations MUST support SHA-256 (OID 2.16.840. and they SHOULD also support SHA-384 (OID 2.16.840. and SHA-512 (OID 2.16.840. They MUST NOT support MD5 or SHA-1 for security reasons.

Key Exchange Algorithms

Implementations MUST support Diffie-Hellman (DH; OID 1.2.840.113549.1.3.1) with the 2048-bit MODP Group, and they SHOULD also support DH with the 3072-bit and the 4096-bit MODP Group. 6144-bit and 8192-bit MODP groups MAY be supported. DH groups under 2048 bits MUST NOT be supported.

Implementations SHOULD also support Elliptic Curve Diffie-Hellman (ECDH) with X25519 (OID, and they MAY support ECDH with X448 (OID

Symmetric Ciphers

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 2.16.840.
  • AES-192-KW (recommended, OID 2.16.840.
  • AES-256-KW (recommended, OID 2.16.840.
  • AES-128-GCM (required, OID 2.16.840.
  • AES-192-GCM (recommended, OID 2.16.840.
  • AES-256-GCM (recommended, OID 2.16.840.

Asymmetric Ciphers

Implementations MUST support RSA-OAEP (OID 1.2.840.113549.1.1.7). They SHOULD also support Curve25519 (OID, and they MAY support Curve448 (OID

Note that per Relaynet Core and the Channel Session Protocol, asymmetric encryption would only be used in the endpoint channel when the Channel Session Protocol cannot be used.

Digital Signature Algorithms

Implementations MUST support RSA-PSS (OID 1.2.840.113549.1.1.10). They SHOULD also support Ed25519 EdDSA keys (OID, and they MAY support Ed448 EdDSA keys (OID

Algorithm Selection

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.