Open Hub
Open Hub

 Settings

1
I Use This!
Very High Activity

Commits : Listings

Analyzed 1 day ago. based on code collected 2 days ago.
Nov 06, 2025 — Nov 06, 2026
Commit Message Contributor Files Modified Lines Added Lines Removed Code Location Date
Merge the ISO/IEC 18033-2 FrodoKEM and Classic McEliece javax.crypto.KEM (KEMSpi) support.
David Hook
More... 3 months ago
Reproduce a JournalingSecureRandom encryption session by regenerating the content IV from the replayed randomness rather than reusing the first encryption's AlgorithmIdentifier, now that setSecureRandom drives the IV and it is recorded in the transcript.
David Hook
More... 3 months ago
Bring the KEM release note in line with the SM9 spec validation as reviewed: SM9 does not take the shared KTSParameterSpec validation - its own GM/T 0044.4 KDF sizes the secret to the request, so the satisfiability bound does not apply and a non-whole-byte size stays legal - but the checks that carry over now run in KEM.SM9-KEM itself, rejecting a missing key algorithm name or a non-positive key size at construction with the declared InvalidAlgorithmParameterException rather than a NullPointerException or the key generator's IllegalArgumentException escaping the KEM operations.
gefeili
More... 3 months ago
Address the remainder of the KdfUtil review. SM9 refuses a non-positive key size at construction with the declared InvalidAlgorithmParameterException, where it escaped newEncapsulator as the generator's own IllegalArgumentException - only positivity, since unlike the other KEMs SM9's KDF produces any requested bit length, so a size that is not a whole number of bytes is a legitimate GM/T 0044.4 request. The three per-family slice tests drive the encapsulator through a non-zero window as well as the decapsulator - both sides are one line into the shared helper, but each SPI's from/to wiring is its own code. KdfUtil gains the class javadoc a four-method public toolkit was missing, naming the intended resolveKemSpec / resolveAlgorithm / makeSecretKey sequence; makeKeyBytes' erase note now says the erase covers the failure paths, which its finally always did; makeSecretKey's range-check note no longer claims the erase depends on it; WrapUtil's clamp carries the pointer to the refuse-don't-clamp convention so the three sites that share the rule all cite each other; and the dead commented-out privateKey fields are gone from the three older decapsulators.
gefeili
More... 3 months ago
Address the review of the KdfUtil KEM helpers. makeSecretKey promised the passed in secret was erased on every exit, but its argument-check throws sat before the erasing try/finally, so a null algorithm name left a live session secret in the caller's buffer - and that path was reachable through the provider: SM9 is the one KEM that does not route its spec through resolveKemSpec, a KTSParameterSpec built with a null algorithm name is constructible, and the JDK's default "Generic" request is then substituted with the null and hit the NPE after the secret had been extracted. The checks now sit inside the try, whose finally clears the secret on every exit including those throws, and SM9KEMSpi rejects a spec with no key algorithm name at construction with the declared InvalidAlgorithmParameterException, as resolveKemSpec does for every other family. Cover the helpers directly in a new KdfUtilTest - the provider's own services pre-validate everything they pass in, so the guards and the erase-on-failure contract are reachable only by an outside caller and no provider-driven test can exercise them - and add the null-name spec rejection to SM9KEM17Test on both the encapsulate and decapsulate paths.
gefeili
More... 3 months ago
Share the KEM secret-key derivation as KdfUtil.makeSecretKey, retiring the identical derive-slice-clear tail every javax.crypto.KEM encapsulator and decapsulator carried - twenty call sites across ten families collapse to one line each. The helper is public like resolveKemSpec and resolveAlgorithm beside it, since its callers sit in two package trees, so it is written for a caller outside the provider as well: the passed in secret is erased on every exit including the failure paths, matching the contract makeKeyBytes has always stated in the same class, the requested range is validated before deriving so an out-of-range request cannot reach SecretKeySpec after the secret is gone, and the null checks and range check are spelled out rather than using java.util.Objects, which is newer than the tree's source floor. resolveKemSpec now also rejects a session key size that is not a positive whole number of bytes, which the provider's own callers always pass but an outside caller might not. Add a per-family slice test to the NTRU LPRime, NTRU+ and SMAUG-T tests: breaking makeSecretKey's slicing was caught by only one of the ten families' tests, since a helper that ignores the range still hands both sides the same bytes and a test comparing them to each other cannot see it - the new cases assert the length and that distinct windows differ.
gefeili
More... 3 months ago
Refuse a KEM KeyGenerator request for more key bits than the mechanism's session key when no KDF is configured, where KdfUtil.makeKeyBytes previously overran the shared secret and threw ArrayIndexOutOfBoundsException out of KeyGenerator.generateKey() - the conventional 256 bit request for FrodoKEM's 976 parameter sets, whose session key is 192 bits, and any request above 256 bits for ML-KEM, Classic McEliece and the composite KEMs, whose session keys are 256 bits. These services take a KEMGenerateSpec or KEMExtractSpec rather than a KTSParameterSpec and so never pass through resolveKemSpec, where the javax.crypto.KEM specs are now validated up front, so the check sits in makeKeyBytes itself and covers them along with any future caller of it. The request is refused rather than quietly met at the shorter length, as a caller that asked for a 256 bit AES key and was handed a 192 bit one has no way of telling, while the Cipher and KTS key wrapping paths go on clamping - there the requested size is only an upper bound on a wrapping key both parties derive the same way from the same secret.
gefeili
More... 3 months ago
Address the code review of the NTRU LPRime, NTRU+ and SMAUG-T KEM support, in three groups.
gefeili
More... 3 months ago
Build NTRUPlusEngine's SHAKE instance per call rather than holding one in a field, the same change already made here for FrodoKEMEngine and which CMCEEngine had all along. It is reached that way through NTRUPlusKEMExtractor, which builds one engine in its constructor and keeps it: four threads extracting through a single extractor returned 7 of 96 shared secrets that silently did not match the sender's, and threw IllegalStateException "attempt to absorb with odd length queue". Encapsulation was unaffected, since NTRUPlusKEMGenerator builds an engine per call. The digest was already reached only through the two shake256 wrappers, whose bodies are the digest operation and nothing else, so this is one field removed and two locals added - no signature or call site changes. Single-threaded results are unchanged: the reference vectors are byte-identical, verified by reverting the change and watching NTRUPlusTest still pass while NTRUPlusConcurrencyTest fails, and likewise for FrodoKEMVectorTest against the FrodoKEM change of the previous commit. Registers NTRUPlusTest in the pqc AllTests suite while adding NTRUPlusConcurrencyTest alongside it: the only reference to NTRUPlusTest was its own main method, so the NTRU+ reference vectors had never run under the core test task at all, and they are what gates byte-identity for this change.
gefeili
More... 3 months ago
Require an MLS X.509 credential's end-entity certificate to certify the LeafNode signature key, so a leaf carrying one party's certificate while signed by an unrelated key is no longer accepted under that party's identity through KeyPackage.verify and the Group leaf-validation path.
David Hook
More... 3 months ago
Add javax.crypto.KEM support for NTRU LPRime, NTRU+ and SMAUG-T, which completes the BCPQC KEMs - each already had Cipher, KeyGenerator, KeyFactory and KeyPairGenerator services and only the KEM one was missing. NTRU LPRime gets a family level KEM.NTRULPRIME matching the SNTRU Prime service registered beside it in the same class, whose absence was the only difference between the two; NTRU+ and SMAUG-T get a family service plus one parameter-set locked service each, mirroring their other registrations. The SPIs share KdfUtil.resolveKemSpec and resolveAlgorithm rather than repeating the spec validation, and NTRULPRimeParameters and SmaugTParameters gain a getEncapsulationLength() so the encapsulating side derives the size from the same place the extractor does instead of repeating the expression or reaching for a package private engine.
gefeili
More... 3 months ago
Initialise the content AlgorithmParameterGenerator with the caller's SecureRandom on the general path in JceCMSContentEncryptorBuilder, not only for RC2, so setSecureRandom drives the IV/nonce for AES-GCM and every other content-encryption algorithm.
David Hook
More... 3 months ago
Route the remaining ten javax.crypto.KEM encapsulators and decapsulators - ML-KEM, SM9, NTRU, NTRU Prime and HQC - through KdfUtil.resolveAlgorithm, which the FrodoKEM and Classic McEliece ones already use, retiring the last copies of a fourteen line block that was identical in all of them. Behaviour is unchanged, exception text included. Add SM9KEM17Test.testAlgorithmReconciliation while doing so: SM9 was the one family whose tests could not detect the block being broken, since testKEM passes a null spec and both sides then agree on "Generic" whatever the rule does, so the shared method is now guarded on the encapsulate and decapsulate paths of all seven families.
gefeili
More... 3 months ago
Merge branch 'claude/wonderful-hugle-71a149' into kem-generic-algorithm-helper
gefeili
More... 3 months ago
Build FrodoKEMEngine's SHAKE instance per call rather than holding one in a field, as CMCEEngine already does, so that an engine reached concurrently no longer produces wrong results. It is reached that way through FrodoKEMExtractor, which holds one engine for its lifetime: two threads extracting through a single extractor interleaved the digest's absorb and squeeze phases, so extractSecret returned shared secrets that silently did not match the sender's, or threw IllegalStateException "attempt to absorb while squeezing". Encapsulation was unaffected, since FrodoKEMGenerator builds an engine per call. Single-threaded results are unchanged and the reference KAT vectors are byte-identical.
gefeili
More... 3 months ago
Address the code review of the FrodoKEM and Classic McEliece KEM support. Build the FrodoKEMExtractor per decapsulation rather than caching it, as FrodoKEMCipherSpi.engineUnwrap already does: it holds one FrodoKEMEngine whose SHAKE digest is mutable, so a shared KEM.Decapsulator - the use javax.crypto.KEM documents as safe, and which this class' own header comment quotes - returned wrong shared secrets and threw "attempt to absorb while squeezing" past its DecapsulateException contract, measured at 31 of 320 concurrent decapsulations. Complete the spec validation, which caught only a non-positive key size: a size below eight bits passed it and produced a zero-length secret key, since makeKeyBytes rounds the byte count up while secretSize() rounds it down and SecretKeySpec's own empty-key check therefore never fired; a size that was not a whole number of bytes silently delivered fewer bits than were asked for; a size within seven of Integer.MAX_VALUE overflowed the rounding up; a KDF identifier the provider cannot service, and an absent key algorithm name, both escaped as undeclared unchecked exceptions from encapsulate. Share the validation and the algorithm-name reconciliation as KdfUtil.resolveKemSpec and resolveAlgorithm instead of a copy per KEM, and hoist the encapsulation length into the constructor rather than rebuilding an engine per call. Cover each of these, the decapsulator's own algorithm reconciliation and the range and null guards - none of which any test reached - and assert all sixteen and all eight parameter-set locked services resolve to their own class and agree with their object identifier, which needs no key generation.
gefeili
More... 3 months ago
Destroy the SecretWithEncapsulation in the ML-KEM, HQC, NTRU, NTRU Prime and SM9 javax.crypto.KEM encapsulators once the encapsulation and shared secret have been taken from it, as the sibling Cipher services and the ISO FrodoKEM and Classic McEliece encapsulators already do - getEncapsulation() and getSecret() hand back clones, so KdfUtil clearing the secret clone left the mechanism's own session key live in the heap for the lifetime of the KEM.Encapsulator.
gefeili
More... 3 months ago
Address review of the FrodoKEM and Classic McEliece KEMSpi support: destroy the SecretWithEncapsulation once the encapsulation and shared secret have been taken from it, as the ISO FrodoKEMCipherSpi already does in the same package - getEncapsulation() and getSecret() hand back clones, so KdfUtil clearing the secret clone left the mechanism's own session key live in the heap for the object's lifetime - and refuse a KTSParameterSpec whose key size is zero or negative, which KTSParameterSpec does not check itself and which otherwise surfaced as an undeclared IllegalArgumentException or IndexOutOfBoundsException out of encapsulate()/decapsulate() instead of an InvalidAlgorithmParameterException from the spec validation.
gefeili
More... 3 months ago
Add javax.crypto.KEM support for the ISO/IEC 18033-2 FrodoKEM and Classic McEliece KEMs, which had Cipher, KeyGenerator and KeyFactory services but no KEMSpi, as ML-KEM and SM9 do - jdk17 MR-jar KEMSpi/Encapsulator/Decapsulator trios modelled on the ML-KEM ones, registered by the standard BC provider behind SpiUtil.hasKEM() as a family service plus one parameter-set locked service per set with the usual OID aliases. Unlike ML-KEM, FrodoKEM's session key size follows the parameter set (192 bits for the 976 sets, 256 for the 1344 sets), so the no-KDF secret size is taken from the key rather than assumed to be 256, and a KDF-less spec asking for more bits than the set produces is refused with an InvalidAlgorithmParameterException naming the set and both sizes rather than quietly shortened the way WrapUtil clamps a KEK - javax.crypto.KEM validates encapsulate()'s range against secretSize(), so that size has to be honest.
gefeili
More... 3 months ago
Drop the round 3 Classic McEliece arc from PqcUnmappedAlgorithmOidTest's dispatch-arc list, as its factory branch went with the deprecated implementation - the declared mceliece OIDs deliberately no longer decode, like the frodokem ones.
David Hook
More... 3 months ago
Repair the BCPQC KeyStoreTest and register it in AllTests so it actually runs: store the stateful XMSSMT root key only after its last certificate signature, as BKS and BCFKS snapshot the encoding at setKeyEntry time, and assert the reloaded keystore rather than querying the in-memory one again.
David Hook
More... 3 months ago
Remove the deprecated NIST round 3 Classic McEliece under pqc.crypto.cmce and its BCPQC provider support, as was done for FrodoKEM, along with the deprecated getPublicKey/getPrivateKey accessors on the ISO/IEC 18033-2 FrodoKEM and CMCE parameter classes, and carry the useful coverage from the removed tests over to the ISO implementations - the non-AES wrap algorithms, KeyFactory lookup by OID, getKeySpec and key-equality round trips, and the parameter-set locked Cipher and KeyGenerator services.
David Hook
More... 3 months ago
Make every BCPQC key report an algorithm name its provider registers - SNTRUPrime keys had the sibling NTRULPRime name, BIKE and CMCE keys their parameter-set name against family-only registrations (their parameter-set locked ciphers now check the key's own parameter set), and SPHINCS-256 is now an alias of SPHINCS256 - sweeping every registered KeyPairGenerator for the KeyFactory round trip by the key's own name.
David Hook
More... 3 months ago
Allow an SM9 key-exchange user key to be rebuilt from its encoding and the master public key, through SM9EncPrivateKeyParameters.fromEncodedExchangeKey and an exchangeKey flag on SM9EncUserPrivateKeySpec, so an exchange party served by the KGC no longer needs the master private key.
David Hook
More... 3 months ago
Check that the BCPQC signature services refuse setParameter the same way at every stage of a signature's life and stay usable afterwards, sweeping every registered service as well as one per family, relates to github #2396.
David Hook
More... 3 months ago
Check that re-setting a signature context or the PSS parameters clears the cached AlgorithmParameters, and move SignatureSetParameterTest to the jcajce provider test package as it uses nothing from BCPQC, relates to github #2396.
David Hook
More... 3 months ago
Allow the ML-DSA and SLH-DSA signature context to be set before initSign/initVerify as well as after, rather than dereferencing the absent key, relates to github #2396.
David Hook
More... 3 months ago
Accept a pure ML-DSA key on the HashML-DSA signature path for its own parameter set, and bind the parameter-set specific SLH-DSA signature services to their parameter sets so the same rule applies there, relates to github #2397.
David Hook
More... 3 months ago
Sweep the parameter-set specific PQC KeyFactories for acceptance of their own parameter set and rejection of every other one in their family, sharing the family table with the KeyPairGenerator sweep.
David Hook
More... 3 months ago
Have the parameter-set specific PQC KeyPairGenerators generate for the parameter set named by the algorithm and refuse to be re-pointed at another, settle on one algorithm name spelling for SLH-DSA, Falcon, SMAUG-T and NTRU+ with the previous spellings kept as aliases, and remove the SPHINCS+ and Kyber provider classes that neither provider registered.
David Hook
More... 3 months ago