Repository navigation
ecdh: accept the X963KDF KDF type - #521
Open
ColtonWilley wants to merge 4 commits into
Open
ColtonWilley wants to merge 4 commits into
ColtonWilley wants to merge 4 commits into
Conversation
OpenSSL's ECDH takes and reports "X963KDF", which CMS and EVP_PKEY_CTX_set_ecdh_kdf_type send. We accepted only "X942KDF-ASN1" (running X9.63), so CMS EC recipients failed. Refused when wolfSSL has no X9.63 KDF. Like the default provider, fail the derive when no KDF output length is set. The test now sets the KDF as CMS does and compares with the default provider.
"X942KDF-ASN1" was mapped onto wc_X963_KDF, deriving a different key than X9.42. wolfCrypt has no X9.42 KDF, so fail closed and drop the unused KDF derive path.
The default provider returns the wrapped/unwrapped length when EVP_CipherUpdate gets a NULL output. CMS key agreement (cms_kari.c) relies on it.
Encrypt/decrypt with an EC recipient across wolfProvider and the default provider (ECDH X9.63 KDF and AES key wrap).
There was a problem hiding this comment.
🟡 Changes recommended
The new AES unwrap size query accepts ciphertext shorter than the minimum required by unpadded key wrap.
1 open issue
What changed in this PR
This PR aligns wolfProvider’s ECDH KDF negotiation with OpenSSL to support CMS encryption and decryption with EC recipients.
Changes:
- Accept and report
X963KDFfor ECDH, and reject unsupported DH KDF types. - Add AES key-wrap output-size queries.
- Update KDF tests and add bidirectional CMS interoperability coverage against the default provider.
| File | Description |
|---|---|
test/unit.h |
Update declarations for DH and CMS tests. |
test/unit.c |
Update test registration and feature guards. |
test/test_ecc.c |
Verify ECDH KDF negotiation and CMS interoperability. |
test/test_dh.c |
Test unsupported KDF rejection and remove obsolete derivation tests. |
src/wp_ecdh_exch.c |
Correct the KDF name and reject zero-length KDF output. |
src/wp_dh_exch.c |
Remove incorrect X9.63 derivation and reject DH KDF requests. |
src/wp_aes_wrap.c |
Add wrap and unwrap output-size queries. |
README.md |
Document ECDH KDF support and DH CMS limitations. |
Review effort: Balanced
Comment on lines
+361
to
+362
| if ((inLen < 2 * KEYWRAP_BLOCK_SIZE) || | ||
| ((inLen % KEYWRAP_BLOCK_SIZE) != 0)) { |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
openssl cmsto an EC certificate failed both ways, including in replace-default mode: CMS sets the ECDH KDF type "X963KDF", which we rejected (we took "X942KDF-ASN1" and ran X9.63), and AES key wrap had no output-size query. ECDH now takes and reports "X963KDF" like the default provider (refused without wolfSSL's X9.63 KDF), and DH refuses "X942KDF-ASN1" instead of silently deriving an X9.63 key, since wolfCrypt has no X9.42 KDF. Covered by a CMS round trip against the default provider.