Ascon Algorithm Identifiers
oberon-sk opened this issue · comments
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).
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, andPSA_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_HASHandPSA_ALG_ASCON_HASHA, which are HASH algorithms. PSA_HASH_LENGTH()would report 32 (bytes), andPSA_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.
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, andPSA_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_HASHandPSA_ALG_ASCON_HASHA, which are HASH algorithms.PSA_HASH_LENGTH()would report 32 (bytes), andPSA_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()andpsa_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.
PSA_HASH_LENGTH()would report 32 (bytes), andPSA_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.
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!
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.
Sounds good, thanks!
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.