Open Hub
Open Hub

 Settings

1
I Use This!
Very High Activity

Commits : Listings

Analyzed about 19 hours 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
Drop the thirteen bare super() calls the promoted XMSS classes write out: every one is its constructor's first statement in a class that extends nothing, so it is exactly the call javac inserts where it is absent - the twenty-five class files these thirteen sources produce come out byte-identical - and spelling it out only sends the reader looking for the superclass it is supposed to be reaching. The super(...) calls that do carry an argument are untouched: XMSSSignature.Builder's super(params) into XMSSReducedSignature.Builder, the three address builders' super(TYPE), and the super(builder) each address and signature constructor makes.
gefeili
More... 2 months ago
Drop XMSSSignature.Builder.withSignature's own null check now that XMSSEngine guards ahead of it, and say in the two comments that cited it what the decode actually does with a null: the builder is package-private and its one caller is XMSSEngine.verifySignature, which raises NullPointerException("signature == null") before entering the try, so the check could no longer fire - and while it stood it read as the reason XMSS^MT's builder was missing one, when in fact neither needs one and the engine owns the answer for both families. What the decode does with a null is dereference the array to check its length against the size the parameters fix, and that NullPointerException is exactly what the catch turning a malformed signature into false cannot tell from a bad encoding, which is why the guard has to sit above the try rather than inside it.
gefeili
More... 2 months ago
Move the null-signature check out of the XMSS and XMSS^MT signers and down onto XMSSEngine's two verify methods, so that the class the package's javadoc calls its one public entry point answers an absent argument the way the signers above it already did: verifySignature reported it as a signature that failed to verify, because the NullPointerException the signature builder raises for a null falls into the catch that turns a malformed signature into false and nothing there can tell the two apart, and verifyMTSignature did not reach that catch at all - XMSSMTSignature's builder reads a null as a request for its set-the-fields branch rather than for a decode, so what came back was a signature carrying no reduced signatures and the layer-0 lookup below the catch left IndexOutOfBoundsException: Index 0 out of bounds for length 0 out of a public method. Both now raise NullPointerException("signature == null") ahead of the decode, which is what a caller coming through either signer was already getting, so nothing changes for them; the existing test asserts the engine as well, since with the check moved the signers are no longer where a regression would show.
gefeili
More... 2 months ago
Replace XMSSUtil's copyBytesAtOffset and extractBytesAtOffset with System.arraycopy and Arrays.copyOfRange, and check the private key's fixed head where the deleted bound check was the only thing looking at the length: the two helpers guarded a null source and destination, a negative offset or length and an out-of-range range, and at every one of the thirty call sites the caller had already fixed the array and the range. The seven encode sites allocate the destination at a total they compute from n, len and the height and then write fields of that same size, so none of the four can fire - and the one that could have mattered, a field shorter than its slot, was never covered anyway, since the check is on src.length + offset and a short source just under-writes. The decode sites all check the whole encoding first - the public keys against n + n or 4 + n + n, the signatures and the reduced signature against the fixed size RFC 8391 sec. 4.1.8 gives them - with one exception: XMSSPrivateKeyParameters and XMSSMTPrivateKeyParameters carried the size check commented out, because only the head of a private key is fixed and the serialized BDS state after it is not, so nothing on the way in from PrivateKeyFactory looked at the length at all and the helper's range check was doing the work. Left as it was, a truncated key would have taken zero-filled bytes for its public seed and root from copyOfRange, which pads rather than throws, and then left an ArrayIndexOutOfBoundsException or an Arrays.getLength "132 > 100" out of a public decode entry point. The head is checked instead, which is one message for every truncation and also bounds the index read above it.
gefeili
More... 2 months ago
Give WOTSPlus something to read now that the Winternitz parameter is no longer a field with a getter: dropping WOTSPlusParameters.getWinternitzParameter() left eight calls to it in WOTSPlus - the chain length in getPublicKey and getPublicKeyFromSignature, the upper bound chain() checks, and the base and the two log2 terms of the base-w conversion - so core did not compile. The constant is back as a package-private static final that WOTSPlusParameters derives len1, len2 and its OID lookup from and WOTSPlus reads directly, which is one definition for the package and still no accessor for a value RFC 8391 sec. 5 fixes at 16.
gefeili
More... 2 months ago
Remove unnecessary code
gefeili
More... 2 months ago
Delete the WOTS+ private key class and the two explicit super() calls beside it: nothing in the library ever builds a WOTSPlusPrivateKeyParameters - a WOTS+ secret key is never materialised as the len-by-n array it carries, expandSecretKeySeed deriving one chain's seed at a time from the seed the key does hold - so its only caller was the test holding the three classes that carry such an array to the same four rejection messages, and two of those are left. WOTSPlusPublicKeyParameters and WOTSPlusSignature opened their constructors with super(), which names Object.
gefeili
More... 2 months ago
Drop the ten null checks in the promoted XMSS code that stand immediately above an unconditional dereference of the same reference: a constructor's params before params.getTreeDigestSize(), an imported seed before its length, a builder's params before the field it names, a private convertToBaseW's digest before its own length. Each converts a NullPointerException into a NullPointerException, so what it buys is a message and one stack frame, and none of them is reachable from outside the package. The checks that hold something stay - the ones whose helper below is null-tolerant and would answer wrongly rather than throw (Arrays.clone returns null, Arrays.areEqual(null, null) is true, a null name concatenates to "null" and misses the map), and the ones on a public builder that store the reference and dereference it much later, in another class.
gefeili
More... 2 months ago
Remove unusded code
gefeili
More... 2 months ago
Drop the thirteen null checks in the XMSS WOTS+ and BDS internals that turn a NullPointerException into a NullPointerException: each sits on a private method or on a package-private member of a package-private class, so nothing outside the package can reach it, and each dereferences what it guards a few statements later, leaving only the message and a stack frame to tell the two apart - and it was never really an invariant, since getWOTSPlusSecretKey takes the same OTSHashAddress with no check at all. Two were dead on their own terms as well: XMSSAddress.toByteArray() builds a fresh byte[32] and returns it, so chain's test of it can never fire and allocated an array per recursion level only to discard it, and chain's startHash arrives either from expandSecretKeySeed or from a WOTSPlusSignature whose constructor has already refused null elements. The two signature checks in XMSSSigner and XMSSMTSigner stay: those are the public lightweight verify boundary, where a missing argument is the caller's mistake rather than a signature that failed to verify.
gefeili
More... 2 months ago
Remove unnecessary check
gefeili
More... 2 months ago
Remove unnecessary check
gefeili
More... 2 months 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... 2 months 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... 2 months ago
Add back null check in BDSStateMap.readObject
gefeili
More... 2 months 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... 2 months ago
Remove unnecessary code
gefeili
More... 2 months ago
Remove BDSStateCodec.MAX_TREE_HEIGHT
gefeili
More... 2 months 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... 2 months 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... 2 months 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... 2 months 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... 2 months 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... 2 months 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... 2 months 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... 2 months 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... 2 months 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... 2 months ago
Remove unnecessary import. Remove unnecessary local variables
gefeili
More... 2 months ago
Merge branch 'main' into xmss-promote-crypto-signers-pick
gefeili
More... 2 months 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... 2 months ago