Ascon Algorithm Identifiers

[oberon-sk]

ASCON-128, ASCON-128a, ASCON-HASH and ASCON-HASHA would fit into the PSA Certified API, with just the definition of some key types (for the AEAD) and algorithm Ids needed.

Are you going to define such constants for the PSA Certified API?

Ascon is a family of authenticated encryption and hashing algorithms designed to be lightweight and easy to implement, even with added countermeasures against side-channel attacks. Ascon has been selected as new standard for lightweight cryptography in the NIST Lightweight Cryptography competition (2019–2023). Ascon has also been selected as the primary choice for lightweight authenticated encryption in the final portfolio of the CAESAR competition (2014–2019).

(from https://ascon.iaik.tugraz.at/)

[athoelke]

Yes, this is certainly something that we could add for the next update to the specification.

Based on my understanding of the specifications, for the AEAD algorithms:

• We would need a new symmetric key type, perhaps PSA_KEY_TYPE_ASCON, which only supports a key size of 128.
• We would need two new algorithm identifiers, perhaps PSA_ALG_ASCON_128, and PSA_ALG_ASCON_128A, which are AEAD algorithms that only support a fixed tag length of 128 bits.
• The nonce size macros would report 16 (bytes) for these algorithms.

For the Hash algorithms:

• We would need two new algorithms identifiers, perhaps PSA_ALG_ASCON_HASH and PSA_ALG_ASCON_HASHA, which are HASH algorithms.
• PSA_HASH_LENGTH() would report 32 (bytes), and PSA_HASH_BLOCK_LENGTH() would report 8 (bytes), for both of these algorithms.

Is there any need to support suspending and resuming a hash operation for these algorithms (via the psa_hash_suspend() and psa_hash_resume() and associated macros)?

Just to note, though not requested here: support for XOF algorithms would require new functions in the API, and not just new identifiers.

[oberon-sk]

Yes, this is certainly something that we could add for the next update to the specification.

That would be great, thx!

Based on my understanding of the specifications, for the AEAD algorithms:

• We would need a new symmetric key type, perhaps PSA_KEY_TYPE_ASCON, which only supports a key size of 128.
• We would need two new algorithm identifiers, perhaps PSA_ALG_ASCON_128, and PSA_ALG_ASCON_128A, which are AEAD algorithms that only support a fixed tag length of 128 bits.
• The nonce size macros would report 16 (bytes) for these algorithms.

Correct.

For the Hash algorithms:

• We would need two new algorithms identifiers, perhaps PSA_ALG_ASCON_HASH and PSA_ALG_ASCON_HASHA, which are HASH algorithms.
• PSA_HASH_LENGTH() would report 32 (bytes), and PSA_HASH_BLOCK_LENGTH() would report 8 (bytes), for both of these algorithms.

One correction: PSA_HASH_BLOCK_LENGTH() would be 8 for Ascon-Hash and 16 for Ascon-HashA.

Is there any need to support suspending and resuming a hash operation for these algorithms (via the psa_hash_suspend() and psa_hash_resume() and associated macros)?

We think that this is currently not required.

Just to note, though not requested here: support for XOF algorithms would require new functions in the API, and not just new identifiers.

Yes, that's a different topic that also holds for the SHAKE variant of SHA3 and should not be part of this request.

It would be handy if you could give a heads-up about the constants so we could create a draft implementation that is eventually compliant with the spec.

[athoelke]

• PSA_HASH_LENGTH() would report 32 (bytes), and PSA_HASH_BLOCK_LENGTH() would report 8 (bytes), for both of these algorithms.

One correction: PSA_HASH_BLOCK_LENGTH() would be 8 for Ascon-Hash and 16 for Ascon-HashA.

The description in https://ascon.iaik.tugraz.at/specification.html and the parameters in the NIST submission have rate r = 64 for both Ascon-Hash and Ascon-HashA.

[oberon-sk]

The description in https://ascon.iaik.tugraz.at/specification.html and the parameters in the NIST submission have rate r = 64 for both Ascon-Hash and Ascon-HashA.

You are right, I have looked into the wrong table, thanks!

[athoelke]

Given the status of the NIST standardization, where Ascon has been selected but the details of the NIST standard have not yet been published, it would be preferable to delay finalization of the Crypto API for these algorithms until we have those details. In particular, the specific algorithms that NIST includes, and the parameterizations that are selected.

If we define these too early, there is a risk that the definition we provide is not consistent with the forthcoming NIST standard.

Would be acceptable to delay making a further decision, at least until after the Lightweight Cryptography Workshop on June 21-22 June 2023? (see https://csrc.nist.gov/projects/lightweight-cryptography)

If you need to provide access to these algorithms in your implementation prior to that, you could initially define vendor-specific key types and algorithms for this purpose.

[oberon-sk]

Sounds good, thanks!

[athoelke]

Update following the LWC conference in June.

The conference website has links for all of the presentations over the two days. The final three are specifically relevant to understanding what will be standardized:

• Proposals for Standardization of the Ascon Family: John Preuß Mattsson - Ericsson
• Additional Modes for ASCON: Rhys Weatherley - Southern Storm Software, Pty Ltd
• Open Discussion - Lightweight Cryptography Workshop 2023: Kerry McKay & Meltem Sönmez Turan - NIST

At this point it is not clear which, if any, of the ideas in these presentations might be included in the NIST specifications, and the final presentation suggests a tentative timeline of 'Fall 2023', but might include renaming.

Unless there is a strong need to define an API prior to the NIST documentation, I would propose to wait until then.

[athoelke]

Finally! - NIST has published a public draft for review and comment: https://csrc.nist.gov/pubs/sp/800/232/ipd

This includes not just a definition for an AEAD and a Hash function, but also includes two XOF variants.

I will post more once I have had a chance to review the new specification.

[athoelke]

I think the Ascon AEAD and Hash should be straight-forward:

• For Ascon-AEAD128, we can define draft key and algorithm values):

  #define PSA_KEY_TYPE_ASCON ((psa_key_type_t)0x2008)
  #define PSA_ALG_ASCON_AEAD128 ((psa_algorithm_t)0x05100700)

  The standard Asconkey bit size is 128. We could support the nonce-masking variant by permitting a second key bits size of 256?

  The algorithm id is for the default 128-bit tag. Tag lengths of len = 8n, for 8 <= n <= 16 are permitted, using the macros to construct truncated-tag AEAD algorithm identifiers.

  A 16-byte Nonce is required when using Ascon-AEAD128.

• For Ascon-Hash256, we can define a draft algorithm value:

  #define PSA_ALG_ASCON_HASH256 ((psa_algorithm_t)0x02000020)

  This hash has a [input] block size of 64 bits/8 bytes, and an output size of 128 bits/16 bytes.

For the XOF variants, we haven't yet got a dedicated XOF API, which could also be useful for defining SHAKE128 and SHAKE256 algorithms (not just the specified-output-size hash algorithms such as SHAKE128/256 etc.). In a previous [private] discussion, we tentatively concluded that the KDF API was the best fit for XOF:

• It has the concatenation property where extracting multiple outputs is exactly equivalent to extracting a single larger output.
• We already have an input type which has the concatenation property (the SALT input step).
• It has an interface for extracting the output directly into key objects. XOF algorithms can be used effectively for deriving keys from secret seed values.

The Ascon-CXOF128 XOF has an additional context parameter (0 to 256 bytes in size). This addition adds a further benefit of using of the key derivation API, which already supports multiple inputs.

We could give XOF algorithms their own category, distinct from KDFs, though it is not clear that is particularly beneficial. All XOFs should have the property that the input message can be split into fragments of any size without affecting the result, and that the output can be extracted in fragments of any size without affecting the overall output. For this, I think we want a new input step PSA_KEY_DERIVATION_INPUT_MESSAGE. For the Ascon-CXOF128 context, we can reuse PSA_KEY_DERIVATION_INPUT_CONTEXT, and given the size limit we could either require this to be provided in a single call, or also permit fragmentation?

Then we would have as draft proposed encodings:

#define PSA_ALG_ASCON_XOF128 ((psa_algorithm_t)0x08004200)
#define PSA_ALG_ASCON_CXOF128 ((psa_algorithm_t)0x08004300)

If this is the right approach for XOF functions, then we would also add SHAKE128 and SHAK256 for good measure:

#define PSA_ALG_SHAKE128 ((psa_algorithm_t)0x08004000)
#define PSA_ALG_SHAKE256 ((psa_algorithm_t)0x08004100)

[athoelke]

Note:

The NIST publication is an initial draft, with review open until February 2025. Therefore, any API proposed here, or written up as a pull-request, prior to the final publication of SP 800-232, should be considered BETA, and subject to change in line with changes made to the approved algorithms.