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.
Oct 03, 2025 — Oct 03, 2026
Commit Message Contributor Files Modified Lines Added Lines Removed Code Location Date
Remove unnecessary check
gefeili
More... about 1 month ago
Put the promoted XMSS helper classes' members back to the visibilities the classes they were promoted from carry: XMSSVerifierUtil, BDSTreeHash and WOTSPlus are themselves package-private, so the public the promotion put on twenty-five of their members reaches nobody - it sits on a type no compilation unit outside org.bouncycastle.crypto.signers.xmss can name, and the only other unit naming them at all is WOTSPlusTests, in that same package in the test tree. This is what 33b3435ed8 did for KeyedHashFunctions and what the change ahead of it did for XMSSNodeUtil's two methods; it undoes the promotion's widening and stops there, so BDSTreeHash.getTailNode stays public and its clone goes back to protected, both being what the legacy copy has, and WOTSPlus's six getters go back to protected rather than the whole way to package-private. BDSTreeHash is Serializable and declares its own serialVersionUID, so the default computation - which folds in the modifiers of every non-private method and would otherwise have changed under this - never comes into it and a stored state still reads back.
gefeili
More... about 1 month ago
Drop XMSSNodeUtil's five null checks, record in the javadoc the precondition nothing checks, and put the two methods back to package-private: each null check stands one or two lines above an unconditional dereference of the same reference - publicKey.toByteArray(), and address.getLayerAddress() through withTreeHeight - so it does not prevent the NullPointerException, it relabels it, on a package-private class whose message reaches nobody outside the package. All ten call sites are in-package, and lTree's four pass a WOTSPlusPublicKeyParameters an unconditional return new has just produced together with an address a builder has just built; replacing the checks with counters and running the core XMSS suites and the prov XMSS/XMSS^MT provider suites, 129 tests, recorded 24,758 lTree and 1,669,546 randomizeHash calls and hit none of the five. What is not checked is that lTree walks a len taken from wotsPlus while the array it indexes comes from publicKey - a key from another parameter set runs off the end of that array, or leaves its tail unread - so the javadoc says so, and says where randomizeHash's nodes are checked instead, since unlike the addresses they can arrive by deserialization rather than from the walk that built them: BDS.readObject refuses a stream carrying null collections or entries, BDS.validate walks every node a state holds, and nextAuthenticationPath names the one it fetches by index. The equal-height check stays, being the algorithm's own rule that only two nodes of the same height are ever hashed together rather than an argument test. The promotion had widened both methods to public, as it had KeyedHashFunctions'.
gefeili
More... about 1 month ago
Add back null check in BDSStateMap.readObject
gefeili
More... about 1 month ago
Drop WOTSPlus.checkMessageDigest and have wotsSign check the WOTS+ instance's own n: it was a third copy of a check XMSSEngine.wotsSign and XMSSVerifierUtil.getRootNodeFromSignature already make with the same message text, and WOTSPlus is a package-private final class with no caller that does not pass one of them first. wotsSign was checking the XMSSParameters it was handed rather than the n khf and chain actually use - the two agree only because every call site pairs them through newWOTSPlus(params), nothing in the signature ties them - and once it asks the instance instead, the params argument is dead and the XMSSMTParameters overload with it. Both surviving checks still reject 31 and 33 bytes with the same IllegalArgumentException; the reason the check is documented where it stands rather than dropped is that convertToBaseW faults a digest that is too short but silently truncates one that is too long, so a direct sign() of a 33-byte digest now returns the 32-byte prefix's signature byte for byte. The prov PQC provider suite and the core XMSS suites, 450 tests, behave the same before and after, including the one CraftedLegacyStateTests failure, which predates this and reproduces at HEAD.
gefeili
More... about 1 month ago
Remove unnecessary code
gefeili
More... about 1 month ago
Remove BDSStateCodec.MAX_TREE_HEIGHT
gefeili
More... about 1 month ago
Delete XMSSUtil.getDigestSize(Digest) and let its two callers ask the digest themselves: the two special cases in it - SHAKE128 is 32 bytes, SHAKE256 is 64 - date from 532df00751 in 2017, when SHAKEDigest had no getDigestSize() of its own and inherited KeccakDigest's fixedOutputLength / 8, which for a SHAKE is the wrong divisor and gave 16 and 32. Peter's df50de2ec6 gave SHAKEDigest fixedOutputLength / 4 in 2021, so ever since, both branches have returned exactly the value they were written to correct, leaving a null check and a delegate wearing the name of the method it delegates to. Both callers already hold a DigestUtil.getDigest(...), which throws rather than return null, so nothing is lost with the check. For each of the five digest OIDs this package can build, the deleted body and the plain call agree, and so does the n of all 21 parameter sets - the nine SP 800-208 truncated ones pin n explicitly and never reached this method at all - with the core XMSS suites and the prov PQC provider suite, 523 tests, green either way. Also takes the redundant explicit super() out of XMSSNode's constructor.
gefeili
More... about 1 month ago
Drop KeyedHashFunctions' seven argument-length checks and record in the class javadoc what actually holds those lengths up: they do matter - RFC 8391 sec. 4.1.2 fixes them and the concatenation coreDigest hashes carries no length prefix, so a wrong one hashes to something else rather than being caught - but the class is package-private and final with a single construction site, so all fifteen call sites are in-package and every argument is either freshly allocated at the size wanted, a return value of one of these functions, or key material a key parameters class has already pinned to n. Replacing the seven throws with counters and running the core XMSS suites and the prov PQC provider suite, 523 tests, hit none of them. The javadoc also says what coreDigest's last branch rests on, since nothing checks that either: digestSize no larger than the underlying digest's own output, which the WOTSPlusOid table fixes rather than any test in this class, and which failing would leave the tail of the result zero rather than throw. The four functions and the constructor go back to package-private - the promotion widened them to public, which the class's own visibility never made visible to anyone.
gefeili
More... about 1 month ago
Rename XMSSEngine.rollState to getNextBDSStateMap now that it hands the advanced state back rather than applying it to the map it is given: "roll" says the argument moves, which is the reading that made the old shape dangerous in the first place, and the single-tree method that does exactly this to a BDS has been called getNextBDSState all along - both now forward to a getNextState on the state they were handed and return what comes back. The name is new on this branch and has never been released, so nothing outside it can be calling the old one.
gefeili
More... about 1 month ago
Have the XMSS^MT key roll its traversal state by replacement, as the XMSS key already does, rather than advancing the state map it holds: XMSSEngine.rollState has to be public - the key parameters class is in another package - so a holder could take a live key's state map off getBDSState() and move it out from under the index the key still reported, and a key whose two records of its position disagree signs again under a one-time key it has already spent, against RFC 8391 sec. 1.1. Handing back the advanced state instead leaves the caller with a map of its own and the key untouched, and makes the key assign both records or neither - a walk that fails part way now leaves it on the index it was already on, where advancing in place left a half-advanced state under an index that had not moved - so the two checks this was costing every signature, one at the top of generateMTSignature and one inside rollState itself, have nothing left to catch.
gefeili
More... about 1 month ago
Say why the tail-node merge in BDSTreeHash.update still steps the hash tree address up a level when nothing reads the result: it is the third step of the same climb the loop above it makes - parent, hash, then name the level above - and being the last climb, its bookkeeping has no reader, so an IDE reports the assignment as dead and the obvious tidy-up is to drop it. That would leave the two merges differing by a line for a reason the page does not give, and take the code away from the unconditional increment that closes the loop of RFC 8391 sec. 4.1.6 algorithm 9.
gefeili
More... about 1 month ago
Unwrap a ParametersWithRandom once in the XMSS and XMSS^MT signers' init(), ahead of the branch rather than inside the signing one, the way LMSSigner.init does it: the verification branch cast its argument straight to XMSSPublicKeyParameters / XMSSMTPublicKeyParameters, so a caller that wraps its key once and drives both sides of the lightweight API took a ClassCastException from the half BC's own SPI never reaches - and neither half of either family had a test.
gefeili
More... about 1 month ago
Have BCXMSSPrivateKey.getIndex and BCXMSSMTPrivateKey.getIndex claim the exhaustion check and the index read under the key parameters' own monitor, as BCLMSPrivateKey.getIndex was corrected to: each call is atomic on its own and the pair was not, so a signature taken by another thread between them spends the last usage and the read that follows hands back maxIndex + 1 - the one index past the end of the key, which is what the check above it exists to refuse. No one-time key is reused by this; what it gets wrong is what the key says about itself.
gefeili
More... about 1 month ago
Have the XMSS and XMSS^MT key pair generators report InvalidParameterException from initialize(int, SecureRandom), which is what the JCA specifies there and what the LMS generator was corrected to raise: it extends the IllegalArgumentException they raised before, so a caller catching that still matches, and neither form was under test - the strength-based initialise had no coverage in either suite at all.
gefeili
More... about 1 month ago
Stop the corrupted-state test copying the keep map and the tree hash instances a second time: getKeep() and getTreeHashInstances() hand out copies of their own now, so the wraps here are copies of copies, and a reader taking them for what keeps the corruption the test applies away from the state it was decoded from has the reason wrong - say that in a comment instead, where getRetain() and getStack() beside them are covered by the same sentence.
gefeili
More... about 1 month ago
Remove unnecessary import. Remove unnecessary local variables
gefeili
More... about 1 month ago
Merge branch 'main' into xmss-promote-crypto-signers-pick
gefeili
More... about 1 month ago
Say why the keep map's deserialization check tests its key for null as well, the way the retain loop above it already does: the two loops are the same three lines and the second was written without the sentence explaining that a null key is not merely absent state, TreeMap.get(null) throws in its own right.
gefeili
More... about 1 month ago
Take the BDS state codec's maximum tree height from XMSSParameters.MAX_HEIGHT rather than restating it: the codec allocates against its own copy of the same 30, so the two can drift and the bound a stored state is read back under stop matching the bound the key that owns it was built under.
gefeili
More... about 1 month ago
Decode the whole of an XMSS or XMSS^MT key info inside the try that reports a bad one, keep the cause, and settle the spelling: only the last stage - building the parameter set - was covered, so an algorithm identifier carrying the wrong parameters or none at all was read ahead of it and came back out as IllegalArgumentException or NullPointerException through a method whose signature says a key that will not decode is an IOException. The eight catch sites folded the cause into their own text and dropped it, and four of them called the algorithm XMSSMT where the other four called it XMSS^MT.
gefeili
More... about 1 month ago
Make XMSSEngine.rollState check the traversal state it is given is on the index it is told to advance off, and have the XMSS^MT signer refuse a key whose index and state disagree: rollState is a bare forwarder to the state map's package-private mutator and has to be public - the key parameters class is in another package - so demoting that mutator only moved the door, it did not close it, and every argument is reachable from a live key's getters. The signer is the backstop, since a state moved out from under its key signs again under a one-time key already spent whatever moved it.
gefeili
More... about 1 month ago
Have the XMSS^MT private key builder copy the traversal state it is handed rather than adopt it: a state map is mutable and the key advances it in place, so two keys built from one - which is what getBDSState() feeding withBDSState() gives you, and there is no other way to copy a key through the public API - drove one state while each kept its own index, and signing with either left the other signing again under a one-time key already spent, against RFC 8391 sec. 1.1.
gefeili
More... about 1 month ago
Merge branch 'main' of gitlab.cryptoworkshop.com:root/bc-java
David Hook
More... about 1 month ago
A version 6 OpenPGP certificate is now used only when its primary key carries a valid Direct Key signature, as RFC 9580 sec. 5.2.3.10 requires, rather than falling back to the primary user ID binding the way a version 4 certificate legitimately does, since it is the Direct Key signature that carries a version 6 key's expiration and preferences.
David Hook
More... about 1 month ago
Keep the cause when the XMSS and XMSS^MT key factories refuse a key spec they cannot decode, as the LMS one beside them does: they folded it into their own message text and dropped it, leaving a caller walking getCause() with nothing. Through SecurityExceptions, since the two-argument InvalidKeySpecException constructor is Java 5.
gefeili
More... about 1 month ago
Take the XMSS provider's own tree-digest tables off it: the name to OID one was a second copy of the lightweight implementation's, which is the thing that produces those names, and the OID to digest one beside it was a third copy with no caller at all.
gefeili
More... about 1 month ago
Bring the two XMSS signature classes onto the same field size check as the key parameter classes, and settle the wording: there were six copies of it in two packages saying two different things about the same mistake, so the one implementation now sits behind XMSSEngine where both packages can reach it and XmssFieldUtil goes.
gefeili
More... about 1 month ago
Give the WOTS+ secret key, public key and signature one check for the len-by-n array shape all three are, on the parameters object that defines it: they had a copy each of the same four checks and had drifted, the secret key calling a wrong element count a format problem where the other two called it a size one.
gefeili
More... about 1 month ago
Bring the two XMSS public key parameter classes onto the shared field size check the private ones already use: they kept their own copy of it and had drifted to a different wording, so the same library said two different things about the same mistake.
gefeili
More... about 1 month ago