Repository navigation
Import the first private key from a PEM file, and tighten random-source and ML-KEM input checks - #222
Merged
Merged
Conversation
…KEM input checks - A key file is no longer read as its first PEM object. `openssl ecparam -genkey` writes EC PARAMETERS ahead of the key and cert+key bundles lead with the chain, so the portable import failed where the Windows overlay did not. The blocks are now framed without being parsed, the first private key is chosen, and only that block (headers included, so legacy encrypted keys still decrypt) goes through the PEM reader. - The portable RSASSA-PKCS1-v1_5 handshake verifier sets StrictDigestInfo, so a DigestInfo without the NULL parameters is not accepted (RFC 8017 9.2). - The bridge that serves an injected random source to the crypto backend checks the span it fills and refuses a source that returns fewer bytes than asked. - ML-KEM-768 encapsulation keys are checked for coefficients below q (FIPS 203 7.2) in the named group, so the check holds for every backend; the native facet previously left it to the OS import. - The native PKCS#12 key replaces the portable one only when both parsers chose the same public key.
Take the handshake verifier's StrictDigestInfo call, its test and the vector out of this change; the strict check will come back as part of a wider one.
Xor-el
changed the title
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
1 participant
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.
The portable key import read only the first PEM object, so
openssl ecparam -genkeyoutput (EC PARAMETERS, then the key) and cert+key bundles failed with a misleading malformed-key error while the Windows overlay imported them. The blocks are now framed without being parsed, the first private key is picked, and only that block (with its RFC 1421 headers, so legacy encrypted keys still decrypt) is parsed. Objects ahead of the key, including types the reader has no parser for, are never judged.Also: the random-source bridge range-checks the span it fills and refuses a short read from an injected source instead of copying past it; ML-KEM-768 encapsulation keys are checked for coefficients below q in the named group (FIPS 203 7.2), so a backend that only checks the length no longer lets one through (the native facet left it to the OS import); and the native PKCS#12 key is adopted only when it has the same public key as the portable parse.
Test data comes from openssl and lives in
ImportKeys.txt(an EC key file with its parameters, and one with an unrecognised block ahead of the key). The ML-KEM test runs against the default provider and a test provider whose KEM checks only the length, and fails if the group's own check is removed. Each change has a test that fails without it. FPC x64 and i386 1439/0, Delphi Win32 OK, BoGo hard gate in portable and native-crypto modes and the fuzzer smoke clean.