Crypto: add encodings for ChaCha variants

[gilles-peskine-arm]

Add algorithm encodings for XChaCha20, XChaCha20-Poly1305, and a list of Salsa variants to be defined. These algorithms aren't currently implemented in Mbed TLS, which is why they weren't included in the original list, but it makes sense to have an encoding for them. They have been requested in Mbed TLS (XSalsa, XChaCha).

Note that we don't want to support every single algorithm that someone somewhere have thought of. Only algorithms that either correspond to current best practice and have some traction (used by at least one popular protocol or software), or that are no longer best practice but are still widely used.

[athoelke]

Definitions

XChaCha20 and poly1305 variant is defined in the IETF (expired) draft.

The difference to ChaCha20 (Bernstein, 2008) and ChaCha20 (IETF, 2018), is that:

• XChaCha20 takes a 192-bit nonce/IV and 64-bit counter
• XChaCha20-Poly1305 takes a192-bit nonce

XChaCha20 has the same 256-bit key size and format as ChaCha20.

API proposal

The current API supports implementation of both the original Bernstein definition (64-bit nonce, 64-bit counter), and the IETF definition (96-bit nonce, 32-bit counter) using a single key type, one algorithm identifier for the stream cipher, and one algorithm identifier for AEAD. The precise algorithm is selected based on the size of IV provided to the API. See the explanation in the Crypto API for ChaCha20 and ChaCha20-Poly1305.

Option A

This could be extended to support XChaCha20 by supporting some additional IV/nonce sizes.

For a cipher operation, using PSA_ALG_STREAM_CIPHER with PSA_KEY_TYPE_CHACHA20:

• A call to psa_cipher_set_iv() with a 24-byte IV will select the XChaCha20 variant, uses the provided IV as the nonce, and sets the counter to 0.
• A call to psa_cipher_set_iv() with a 32-byte IV will select the XChaCha20 variant, uses the first 8 bytes of the IV as the counter value (encoded as little-endian), and uses the remaining 24 bytes as the nonce

Note that psa_cipher_encrypt(), psa_cipher_decrypt(), or psa_cipher_generate_iv() will [continue to] use the IETF ChaCha20 variant.

For AEAD operation, using PSA_ALG_CHACHA20_POLY1305 with PSA_KEY_TYPE_CHACHA20:

• A call to psa_aead_encrypt(), psa_aead_decrypt(), or psa_aead_set_nonce() with a 24-byte nonce will select the XChaCha20-Poly1305 variant.

Note that psa_aead_generate_nonce() will [continue to] use the IETF ChaCha20-Poly1305 variant.

Option B

If it is essential to enable access to the XChaCha20 variants via the single-part cipher functions (AEAD already provides this in option A), we would either have to define a separate algorithm for XChaCha20, or define a separate key type for XChaCha20. It is not obvious which of these would be most appropriate, if we do not expect that Option A is sufficient.

[gilles-peskine-arm]

A single algorithm doesn't work for XChacha20: psa_cipher_decrypt wouldn't know how to parse its input. All cipher algorithms must encode the IV length.

For AEAD it would work, but it feels a bit fragile.

For a feature availability interface (which we may add in the future, and some implementations may already offer in a proprietary way), applications need to be able to query “is XChacha20 supported?” separately from “is Chacha20 supported?”. I'd expect such an interface to be able to depend on the key type, the key size and the algorithm but probably not also on the IV/nonce size.

So I don't think option A is viable.

[athoelke]

Although we kind-of get away with this for the variants of ChaCha20, this mostly works because use of the original variant is uncommon, and we only require support for, and default to, the IETF variant.

Superficially, XChaCha20 is somewhat similar - hence the obvious Option A proposal.

So, we need to explore Option B: my initial opinion is that a new key type is preferable for XChaCha20, as opposed to new algorithms with the same key type. Rationale: the XChaCha20 variant processes the key and nonce into a subkey for use in the IETF ChaCha20 algorithm - so although the key size is the same, it is not used in the same way as a ChaCha20 key. This approach maintains use of PSA_ALG_STREAM_CIPHER. However, I assume that we would want a new PSA_ALG_XCHACHA20_POLY1305 to reduce surprises when using XChaCha20 vs ChaCha20?

[gilles-peskine-arm]

The two variants of chacha20 are essentially identical: it's just a minor tweak to the IV generation when encrypting. Xchacha20 requires a bit more effort, so we can't reasonably expect implementations of chacha20 to always support xchacha20. This also goes for the corresponding AEAD ciphers. So for a feature query API, it should be possible to express “chacha20-poly1305: yes; xchacha20-poly1305: no”.

[athoelke]

So for a feature query API, it should be possible to express “chacha20-poly1305: yes; xchacha20-poly1305: no”.

Does this same consideration apply for the ciphers? As PSA_ALG_STREAM_CIPHER and PSA_KEY_TYPE_XCHACHA20 are both shared with other algorithms, there is no unique distinguisher for the XChaCha20 cipher. Or will we just presume that if XChaCha20-Poly1305 is supported,, then the cipher will be as well?

[athoelke]

Let's fill out the option B idea:

Option B

Define a new key type — PSA_KEY_TYPE_XCHACHA20 — for XChaCha20 and XChaCha-Poly1305, based on the PSA_KEY_TYPE_CHACHA20 definition, but referring to the XChaCha20 algorithms. Allocate an appropriate value for this key type.

Add an XChaCha20 section the the documentation for PSA_ALG_STREAM_CIPHER. This will be similar to the description of the ChaCha20 cipher, but without the complication of the two variants. However, this will still need to provide clarity for how the nonce and counter are set, as per option A:

PSA_CIPHER_IV_LENGTH(PSA_KEY_TYPE_XCHACHA20, PSA_ALG_STREAM_CIPHER) evaluates to 24.

When using a PSA_KEY_TYPE_XCHACHA20 key with PSA_ALG_STREAM_CIPHER, the nonce and initial counter values are provided using the initialization vector (IV) functions in the following ways:

• A call to psa_cipher_encrypt() will generate a random 24-byte nonce, and set the counter value to zero. The random nonce is output as a 24-byte IV value in the output.
• A call to psa_cipher_decrypt() will use first 24 bytes of the input buffer as the nonce and set the counter value to zero.
• A call to psa_cipher_generate_iv() on a multi-part cipher operation will generate and return a random 24-byte nonce and set the counter value to zero.
• A call to psa_cipher_set_iv() on a multi-part cipher operation can support the following IV sizes:
  • 24 bytes: the provided IV is used as the nonce, and the counter value is set to zero.
  • 32 bytes: the first 8 bytes of the IV are used as the counter value (encoded as little-endian), and the remaining 24 bytes is used as the nonce.

Other sizes of IV are not valid.

Define a new algorithm — PSA_ALG_XCHACHA20_POLY1305 — based on the existing PSA_ALG_CHACHA20_POLY1305 definition. This only needs to describe the use of a 24-byte nonce, and will repeat the recommendation to only support 16-byte tags.