Add Ascon128 AEAD cipher provider implementation #29115
Conversation
…SL tree - Added providers/implementations/ciphers/cipher_ascon128.c - Added providers/implementations/ciphers/cipher_ascon128.h - Added providers/implementations/ciphers/ciphercommon_ascon.c - Added providers/implementations/ciphers/ciphercommon_ascon.h - Updated #include with openssl internal includes - Updated error codes with standard PROV_R_* codes This is beginning of an ongoing migration in openssl#28271 Co-authored-by: @Jcb5272
- Update function names from ossl_cipher_ascon128_* to ascon128_* - Make all functions static, matching the pattern used by fixed-key ciphers - Reorder dispatch table to OpenSSL standard order and remove function declarations from header file. openssl#28271
- Add ascon128 cipher to the build configuration - creating a libcrypto header stub for ascon openssl#28271
- Add ASCON-128 to algorithm registration in defltprov.c, implementations.h, and names.h
- Preserve AEAD tag during context reinitialization for decryption to prevent tag loss when EVP_CipherInit_ex is called after tag is set - Add IV tracking support for get_updated_iv by storing IV in context and implementing OSSL_CIPHER_PARAM_UPDATED_IV - Add key and IV length validation in ascon128_internal_init for better error handling - Improve AAD handling in update function and add null pointer checks for outl parameter - Changes based on patterns used by ChaCha and AES-SIV ciphers
- Replace incorrectly converted test vector with verified official test vector
crypto/ascon/ascon_aead128.c
Outdated
| # include "ascon_internal.h" | ||
|
|
||
| ASCON_API void | ||
| ascon_aead128_encrypt(uint8_t* ciphertext, |
There was a problem hiding this comment.
The notation for internal global functions should be prefixed with ossl_.
(NOTE: This is not necessary for static functions).
crypto/ascon/ascon_aead128.c
Outdated
| size_t tag_len) | ||
| { | ||
| ASCON_ASSERT(plaintext_len == 0 || ciphertext != NULL); | ||
| ASCON_ASSERT(tag_len != 0 || tag != NULL); |
There was a problem hiding this comment.
SP800-232 has minimum AEAD requirements in Section 4.3.
See R4 for minimum tag length.
crypto/ascon/ascon_aead128.c
Outdated
| size_t plaintext_len, | ||
| size_t tag_len) | ||
| { | ||
| ASCON_ASSERT(plaintext_len == 0 || ciphertext != NULL); |
There was a problem hiding this comment.
These asserts are not how we handle errors in OpenSSL.
There was a problem hiding this comment.
I've replaced with ossl_assert in the cleanroom implementation, is there another preferred way for this input validation?
There was a problem hiding this comment.
Try the style guide section on asserts.
As a rule, the preference is for ossl_assert as part of an if statement which returns an error.
crypto/ascon/ascon_aead128.c
Outdated
| size_t plaintext_len, | ||
| size_t tag_len) | ||
| { | ||
| ASCON_ASSERT(plaintext_len == 0 || ciphertext != NULL); |
There was a problem hiding this comment.
potentially the plaintext could be nothing.
crypto/ascon/ascon_aead128.c
Outdated
| ASCON_ASSERT(tag_len != 0 || tag != NULL); | ||
| ASCON_ASSERT(key != NULL); | ||
| ASCON_ASSERT(nonce != NULL); | ||
| ASCON_ASSERT(assoc_data_len == 0 || assoc_data != NULL); |
There was a problem hiding this comment.
associated data should be able to be null I would expect.
There was a problem hiding this comment.
Is this implementation conforming to SP800-232?
Because that is what OpenSSL would need to support.
(In much the same way that for PQ algorithms we implemented the FIPS 203/204/205 standards not dillithium, etc that they were based on).
SP800-232 Section 1 lists 7 differences that should be adhered to.
For example little endian vs big endian.. And it looks like this code is Big Endian..
I think the CLA issue relating to the original authors needs to be sorted before any extensive reviews are done on this
code (otherwise we are just wasting our time)
|
Code Style checks should be fixed if they are relevant.. |
The implementation added to libcrypto is based on the NIST draft, which can account for some differences like big endian vs little endian. Dr. Brumley @bbbrumley is writing a new implementation based on the NIST standard, and will conform to OpenSSL standards. This affects all of the files in crypto/ascon. With this change in mind should I continue to make changes based on the reviews for the crypto implementation or wait for an update from BBB, and focus on the provider changes required? Sorry if I submitted the PR too early, wanted to get it in earlier with such a big diff. |
|
Forgot to include in my initial description, but the original implementation of the provider was written by @romen and @theakifmehmood. They should both have CLAs available. |
I would definitely then suggest focusing on the provider changes. |
|
I've converted it into a draft until the implementation is replaced with a standard version. |
If they havent already done it, the suggestion in |
|
Just wanted to say, thanks so much for the feedback so far @slontis and @paulidale and indeed, thanks @t8m for putting this in draft state. def WIP rn. To note:
Thanks for the initiative @evil-cry |
|
Sounds like a good plan. Would be good to get into 4.0 if we can. Are you planning on XOF and hash also? |
Yes, we are planning to implement XOF and hash as well. A hand with FIPS would be greatly appreciated once we get everything squared away! |
…ation - Update function names, variables, and file names from ascon128_* to ascon_aead128_* - Update build files and algorithm registration from ascon128_* to ascon_aead128_* - Update crypto implementation from ascon128 to ascon128a based on NIST SP800-232 - TODO: Update test vectors based on ascon128a
- Remove redundant ciphercommon_ascon files and inline necessary definitions. - Order struct members by type, remove unnecessary typedef, and use OPENSSL_cleanse for sensitive data. Simplify dupctx() to use struct assignment and remove redundant cleanup. - Remove OSSL_CIPHER_PARAM_AEAD_AAD parameter as AAD is handled via update() when out is NULL.
- Update definitions and function signatures to match provider implementation - Add OPENSSL_cleanse() for secure cleanup of sensitive state, keys, and tags - Add input validation (NULL checks) to all public functions to ensure proper error handling for provider integration.
Add cleanroom implementation of SP 800-232 to libcrypto
Add Ascon128 AEAD cipher provider implementation
This PR adds a complete OpenSSL provider implementation for ASCON-128. The implementation supports both streaming and one-shot encryption/decryption operations with AAD, and follows established provider patterns for stream ciphers in OpenSSL.
Note: the LibAscon implementation added to libcrypto should be considered temporary. @bbbrumley will add a cleanroom implementation of ascon128 in future.
Part of an ongoing issue: #28271
Co-authored by: Dominic Cunningham [email protected]
Co-authored by: Jack Barsa [email protected]
Supervised by: Billy Brumley [email protected]