Open Hub
Open Hub

 Settings

1
I Use This!
Very High Activity

Commits : Listings

Analyzed 1 day ago. based on code collected 3 days ago.
Oct 27, 2025 — Oct 27, 2026
Commit Message Contributor Files Modified Lines Added Lines Removed Code Location Date
Build the default parameter set before writing either field in generateKeyPair(), as initialize() already does. The ordering fix went into initialize() because a spec whose height XMSSParameters refuses left this generator naming a tree digest of a parameter set it had just failed to build, while the engine went on holding the one an earlier call succeeded with. The uninitialised branch is the other place both fields are written and it kept the old order, treeDigest first and the parameter set after it.
gefeili
More... about 2 months ago
Stop claiming isSigningCapable() and getUpdatedPrivateKey() cannot disagree, because they do, in the one case that matters. The comment added with the state-machine split says the collection is built on "the same answer isSigningCapable() is built on". It is not: isSigningCapable() asks the signer for a count of usages remaining, this asks whether it holds a key at all, and a signer initialised on a spent key holds one. Measured through the provider on a drained height-4 XMSS signer, isSigningCapable() answers false and getUpdatedPrivateKey() hands a key back from the same object.
gefeili
More... about 2 months ago
Say what getUpdatedPrivateKey() actually leaves behind, which for half the cases is the opposite of what this interface promised. The note said calling it "will effectively disable the Signature object from being used for further signature generation without another call to initSign()". Measured through the provider on a height-4 XMSS key: initSign, update, collect, and isSigningCapable() is still true and sign() returns a 2308-byte signature. The sentence holds for a collection that follows a signature - there the key handed back is the one that signature spent, the object keeps nothing, and a second collection throws - and not for one that precedes it, which is the case the two implementors are written for. Collecting first is how a caller makes the state durable before the one-time key covering it is spent, and the object has to keep one usage for that to mean anything.
gefeili
More... about 2 months ago
Name the callers this copy constructor actually has. The javadoc added a commit ago says it has three and that two of them - extractKeyShard and the withBDSState of both key builders - leave two live keys holding maps built from one map. It has two, getNextState and XMSSMTPrivateKeyParameters.extractKeyShard, and only the second of those is a two-keys case; withBDSState is not among them at all. It reaches this class by another route: it calls withMaxIndex, which builds an empty map and fills it a layer at a time out of BDS.withWOTSDigest, and that is where its copy comes from.
gefeili
More... about 2 months ago
Read and write the upper layers through this map's own accessors in updateState(), as layer zero three lines above it already did. The class says at the top of the file that every read and every write of the map is taken on this object's monitor, and gives the reason - the map is handed out live by getBDSState() and a signature installs states into it as it descends - and then the layer loop names the field directly, twice, while the layer zero block over it goes through get() and put(). Nothing chose that; it is what the loop was when it arrived, and the two spellings sitting that close read as a distinction rather than as the accident they are.
gefeili
More... about 2 months ago
Assert the other half of the cross-check github #2414 added: that a private key whose declared root disagrees with the root inside its traversal state is refused. The index half of that issue is what this class was written for and covers three ways; the root half shipped with no coverage at all. validateRoot is reached from four call sites across the two key classes and by way of BDSStateMap for XMSS^MT, and no test in the tree named the message it raises - with the throw taken out and nothing else changed, every suite here stays green.
gefeili
More... about 2 months ago
Assert that the promoted codec refuses a BDS state whose checksum does not match it, which nothing in this tree did. The check itself came with github #2414 and has tests - over org.bouncycastle.pqc.crypto.xmss, in XMSSStateEncodingTest and XMSSPrivateKeyTest, against that package's own codec. The promotion copied the codec into org.bouncycastle.crypto.signers.xmss and left both behind, so the two implementations of the same eight-byte header, thirty-two-byte trailer and seed binding had one set of tests between them, on the copy this branch is not the one being used.
gefeili
More... about 2 months ago
Hand back the same key when a signer is collected twice with no signature between, rather than sharding the one usage it kept for itself. getUpdatedPrivateKey() on a signer that has not signed rolls its key past the leaf it is keeping and returns the rest, which is the contract; asked a second time it did the same thing again, and by then the key it holds is a one-usage shard, so what it divided was that shard. The second call therefore returned a key reporting nothing remaining. Everything the caller was given the first time survived only in that first return value, and a caller with any reason to collect twice - a store that failed and is retried, a collection written into a finally beside the explicit one, a wrapper that collects defensively before and after - writes the empty one over it.
gefeili
More... about 2 months ago
Exclude the promoted XMSS test package from the jdk1.3 build the way jdk1.4 already does. That build's core/src/test/java fileset carries the file-name exclude **/XMSS*.java and not the directory one, and the twenty-two cases this branch adds are named for what they test rather than for the scheme - AddressTests, WOTSPlusTests, BDSStateSerializationTests, SignerConcurrencyTests and the rest - so not one of them is caught by it. The main tree three filesets above is excluded correctly, **/xmss/**/*.java at the top and crypto/params, crypto/generators and crypto/signers XMSS* below, which is what makes the omission a break rather than a redundancy: staging the tests without the classes they name is a compile error, and the sources they need were deliberately not staged.
gefeili
More... about 2 months ago
Record why the state map copy constructor copies each layer rather than sharing it, which is the reading a review of this class arrives at and the code did not answer. The premise the sharing argument rests on is true and is already written down a file away: a BDS is filled at construction and never written afterwards, the block above its getLive accessors says exactly that, and advancing a layer builds the successor and puts it in the map rather than touching what is there. What it leaves out is the one exception the same block names - markUsed() writes the used mark in place - and what two of this constructor's three callers do with the result. extractKeyShard and the withBDSState of both key builders each leave two live keys holding maps built from one map, so a shared layer zero would be two keys sharing one record of whether the one-time key at that leaf has been spent: the mark one of them made arriving as the other's refusal, and the mark it did not make as the refusal it does not get, which is the direction RFC 8391 sec. 1.1 is about. Only layer zero is ever marked, so the layers above it could be shared as markUsed() is written today - a fact about that method rather than about this one, and worth the copy on the roll path alone. Javadoc only; no allocation moved. The package's AllTests at 102, AllTestsXMSS at 79 including the byte-identity oracle, the provider's XMSSTest at 36 and XMSSMTTest at 32, and checkstyleMain on core.
gefeili
More... about 2 months ago
Say that the BC mappings are a copy of the BCPQC ones on purpose, and that the converters they register are registered twice on purpose, so neither reads as a slip. Both are the shape this provider already has for the neighbours: jcajce.provider.asymmetric.LMS and pqc.jcajce.provider.LMS - the sibling stateful scheme, promoted the same way - are the same thirty lines under two package names, because the two providers keep independent service tables and there is no shared-table mechanism here to reach for; and jcajce.provider.asymmetric.NTRU calls registerOid for the four NTRU OIDs that BouncyCastleProvider.loadPQCKeys() also registers, which is the overlap XMSS now has for its six. The javadoc also records which of the two overlapping registrations survives - loadPQCKeys runs after the mappings and its entry is the one left in the map, the same class either way - and what registerOid does that loadPQCKeys does not, the KeyFactory and KeyPairGenerator OID aliases, so a future reader can see that removing either one loses something. Javadoc only. The provider's XMSSTest at 36 and XMSSMTTest at 32, the core suites at 102 and 79, and checkstyleMain on prov.
gefeili
More... about 2 months ago
State once, on BDSStateMap itself, the fact four comments inside it were each telling. The class had no javadoc at all, and the reason every method here takes this object's monitor - getBDSState() hands the map out live, a signature installs the layer states it builds lazily into the map it is signing with, and an insertion rebalances the TreeMap under anything reading it without the monitor - was written out again on the copy constructor, again in validateRoot, again in validateIndex and again at the engine's lock. So was the second half of it, that holding the monitor for a whole operation rather than once per lookup is what makes an answer coherent rather than merely intact. All of that is now the class javadoc, said once and in the place a reader of any of these methods arrives from. What each method keeps is only its own point: that the copy constructor takes the monitor of the map handed in rather than of the map being built, that validateRoot is the check deciding whether a key is built around the map at all so a torn lookup would decide it, that validateIndex walks under one acquisition rather than one per layer and that its callers all happen to hold the key's monitor without that being a property of the method, and that the engine is the writer the rest of it is about, with the lock order. The two tests that demonstrate the race keep their own descriptions: a test says what it shows. Comments only, no code moved. The package's AllTests at 102, AllTestsXMSS at 79 including the byte-identity oracle, the provider's XMSSTest at 36 and XMSSMTTest at 32, and checkstyleMain on core.
gefeili
More... about 2 months ago
Say why equals() leaves the PKCS#8 attributes out, which the paragraph above it does for the tree digest and nothing did for these. The omission is real and it is not symmetric with the tree digest one: a tree digest that differed would decide nothing because it cannot differ, while attributes can, and they travel into getEncoded(), so two keys equal here can write different bytes. That is the answer this class wants rather than an oversight in it. What a stateful key is asked by equals is whether this is the same key at the same position - RFC 8391 sec. 1.1 is what makes that the question - and a friendlyName a caller attached on the way through a keystore moves neither the secret nor the index. It is also what the siblings do: BCLMSPrivateKey, named in the paragraph above as where this comparison came from, carries attributes the same way and compares only its key parameters, and BCMLDSAPrivateKey compares its parameters' encoding rather than the PKCS#8 the attributes are part of. The last sentence points a caller who does need the encodings to agree at the encodings. Javadoc only, both key classes; the provider's XMSSTest at 36 and XMSSMTTest at 32, the core suites at 102 and 79, and checkstyleMain on prov.
gefeili
More... about 2 months ago
Build the parameter set before writing the tree digest, so an initialize that cannot be satisfied leaves the generator as it was. treeDigest was assigned first and the parameter set constructed after it, and that constructor is where a bad height is refused - XMSSParameters wants [2, MAX_HEIGHT], XMSSMTParameters also wants a layer count that divides the total height and a subtree taller than one leaf - so a refused call left the generator naming the tree digest of the parameter set it had just failed to build. That is only visible when an earlier initialize succeeded, because the refusal leaves initialised set from that call: the next generateKeyPair() then runs on the old engine and labels its key with the new digest, a key whose XMSSKey.getTreeDigest() names a digest it was not generated under. The refusal also arrived as the unchecked IllegalArgumentException the parameter set raises, out of a method whose contract is InvalidAlgorithmParameterException - which DigestUtil.getTreeDigest, one line above, already throws for a tree digest name it does not know - so it goes through SecurityExceptions.invalidAlgorithmParameterException with the message kept and the original attached as the cause. testAFailedInitialiseLeavesTheGeneratorAsItWas in both provider tests initialises, generates, offers a parameter set the constructor refuses, and asserts both the exception type and that the key the generator still makes carries the tree digest of the initialize that worked; against the unfixed code both fail on the unchecked exception. The provider's XMSSTest at 36 and XMSSMTTest at 32, the core suites at 102 and 79, and checkstyleMain on prov.
gefeili
More... about 2 months ago
Ask the signer whether this object can still sign, rather than a field of the SPI's own that goes stale. isSigningCapable() read treeDigest, and getUpdatedPrivateKey() cleared treeDigest on every call whether or not a signature had been made - so an object whose key was collected before it signed reported itself unable to sign while sign() went on working. What the signer does there is hand back the key advanced past the leaf it holds and keep a one-usage shard of that leaf, which is a real key that must still be spendable; only a collection that follows a signature leaves the signer with nothing, and getUsagesRemaining() is 0 for exactly that case. So the capability question is now signing && signer.getUsagesRemaining() != 0, and the collection question is what the signer hands back, with the same IllegalStateException("signature object not in a signing state") when that is null - which is what testKeyExtraction's second collection after a signature still gets. One behaviour widens: a second collection on an object that has not signed now returns the retained shard instead of throwing, which is what the lightweight signer does for a caller reaching past this class, and the two keys cover disjoint leaves rather than the same one. testCollectingWithoutSigningLeavesTheObjectAbleToSign in both provider tests collects without signing, asserts the object says it can sign, signs, verifies that signature against the public key and asserts the object then says it cannot; against the unfixed code both fail on the first of those. The provider's XMSSTest at 35 and XMSSMTTest at 31, the core suites at 102 and 79, and checkstyleMain on core and prov.
gefeili
More... about 2 months ago
Stop a verification init stranding the advanced key inside the signature object. engineInitVerify set treeDigest to null, and getUpdatedPrivateKey() reads that field before it consults the signer at all, so sign then initVerify then collect - the sequence the signer this wraps deliberately supports, its init clearing the public key on a signing init and pointedly not the private one on a verifying one, with a comment saying collecting the advanced state afterwards is legitimate - came back as IllegalStateException("signature object not in a signing state") with the key still sitting inside. The state the null was carrying was "not initialised for signing", which is a different thing from "was never given a private key", and it now has a field of its own: signing is set by each init and is what isSigningCapable() reads first, so an object in the middle of a verification still answers false there while getUpdatedPrivateKey() can reach the key. treeDigest goes back to naming the digest of the key this object holds. testKeyCanBeCollectedAfterAVerificationInit in both provider tests signs, verifies, checks isSigningCapable() is false, and collects the key, asserting it is the one the signature advanced; against the unfixed code both fail on the IllegalStateException. The provider's XMSSTest at 34 and XMSSMTTest at 30, both one up, and the core suites at 102 and 79.
gefeili
More... about 2 months ago
Pass the SecureRandom an initSign was given down as an argument instead of leaving it in a field. engineInitSign(key, random) wrote this.random and then called engineInitSign(key), and nothing ever cleared it, so a Signature object initialised once with a random and later re-initialised with initSign(key) alone went on wrapping the key in ParametersWithRandom with a random that call did not name - a random belonging to a different key and possibly a different caller. Both SPIs now route the two public forms into one private initSigning(key, random), the second passing null, which is the same wrap decision made from what the call actually supplied. Nothing signs differently for it: XMSSSigner.init and XMSSMTSigner.init unwrap ParametersWithRandom and discard the random, because RFC 8391 sec. 4.1.9 derives the randomizer from SK_PRF and the index, so the field could not have changed a signature and no test can see this. What it removes is a piece of per-object state that was already wrong and would have been reached the moment anything read it. The provider's XMSSTest at 33 and XMSSMTTest at 29, and the core suites at 102 and 79.
gefeili
More... about 2 months ago
Adopt the state map withOwnedBDSState is handed, the way the single-tree sibling's overload does, rather than testing a maximum index that cannot differ. The method read maxIndexFor(val) and copied the map when the answer disagreed with the map's own - a defence against the legacy encoding that marks its maximum index with a negative value - but its one caller is extractKeyShard, six lines below, which hands over new BDSStateMap(this.bdsState, getIndex() + usageCount - 1): the copy constructor sets the maximum index to that argument, getIndex() is not negative and validateShardSize has already refused a usageCount below 1, so the two were always equal and the allocating branch never ran. Probed rather than reasoned about: with the branch replaced by a throw the four suites stay green, and with the whole method replaced by one XMSSMTTest reports five errors, so it is on the path and the branch is not. XMSSPrivateKeyParameters.Builder.withOwnedBDSState is the bare assignment this now is, and the resolution the public setter does for a legacy map stays where it was, said in the javadoc so its absence here is deliberate rather than missing. The package's AllTests at 102, AllTestsXMSS at 79 including the byte-identity oracle, the provider's XMSSTest at 33 and XMSSMTTest at 29, and checkstyleMain on core.
gefeili
More... about 2 months ago
Keep one copy of the attributes fixture the twin provider tests round-trip. ATTRIBUTES - a PKCS#9 friendlyName in a DERSet - and the withAttributes / attributesOf pair that put it on a PKCS#8 encoding and read it back were declared in XMSSTest and again in XMSSMTTest, and all three are written in ASN1Set, PrivateKeyInfo and byte arrays with nothing in them that knows which of the two schemes it is serving. They join the other two shared helpers in XMSSTestUtils, and five imports each test no longer needs go with them. The cases keep their own bodies: what testAttributesSurviveSigningAndSharding asserts is that the attributes are still there after an encode, a signature and an extractKeyShard(1) on the key type that test is about, and that a generated key with no origin to take them from invents none. The provider's XMSSTest at 33 and XMSSMTTest at 29, and the core suites at 102 and 79.
gefeili
More... about 2 months ago
Move the deadlock probe's thread into XMSSTestUtils, the second helper the twin provider tests each held a copy of. comparing(one, two, agreed, slot) is written entirely in java.security.PrivateKey and asks nothing of the key beyond equals(), so the twenty-five lines in XMSSTest and the twenty-five in XMSSMTTest were the same lines twice; what differs between the two testEqualsTakesTheTwoKeyMonitorsOneAtATime cases is the parameter set the keys come from, and that stays where it is. The javadoc it gains says what the thread is for - two of them started against the same pair in opposite orders, where nested monitors stop both within a few rounds and neither reaches the write - which the case's own javadoc explains from the other end. The provider's XMSSTest at 33 and XMSSMTTest at 29, and the core suites at 102 and 79.
gefeili
More... about 2 months ago
Put hasLegacyBdsMarker in one place, XMSSTestUtils, rather than a copy in each of the twin provider tests. XMSSTest and XMSSMTTest carried the same twenty lines - a substring search for the class name "org.bouncycastle.pqc.crypto.xmss.BDS" that the Java-serialized state of a pre-promotion key writes in the clear - with nothing in either copy naming the other, and the search has no XMSS-versus-XMSS^MT typing in it at all: it takes a byte array and answers about bytes. The new class sits beside PQCSigUtils, which is where this package already keeps a helper two tests share, and its javadoc says what the marker is and why a fixture that has lost it is no longer the encoding the test means to read. The provider's XMSSTest at 33 and XMSSMTTest at 29, and the core suites at 102 and 79.
gefeili
More... about 2 months ago
Take the leading index off an encoding with Pack.bigEndianToLong_Low, which OneTimeKeyReuseTests in this package already calls for exactly this and which SignerConcurrencyTests had a private loop of its own for. The helper it replaces was the same shift-and-or over the first indexSize bytes, right-aligned into a long, and it stood at the bottom of the file where its javadoc was the only place saying what those bytes are; that sentence moves to the two sites that read a signature, next to the RFC section fixing the width - four bytes for XMSS, ceil(h / 8) for XMSS^MT - which is where the sibling test keeps it. The four call sites read the same widths from the same offsets as before. The package's AllTests at 102, AllTestsXMSS at 79 including the byte-identity oracle, the provider's XMSSTest at 33 and XMSSMTTest at 29.
gefeili
More... about 2 months ago
Read the four magic bytes with Pack.bigEndianToInt rather than four masked comparisons of its own. hasMagic asked the question a byte at a time - shift the constant down, mask, compare, and again - which is the big-endian int decode org.bouncycastle.util.Pack exists to hold, and which the rest of this codec already goes through DataInputStream for. The length guard stays where it was, ahead of the read, because Pack does not carry one. The package's AllTests at 102, AllTestsXMSS at 79 including the byte-identity oracle, the provider's XMSSTest at 33 and XMSSMTTest at 29.
gefeili
More... about 2 months ago
Compare an XMSS^MT public key through getEncoded(), the way the single-tree sibling already does, rather than through the toByteArray() that class deprecates. XMSSMTPublicKeyParameters.toByteArray() carries "@deprecated use getEncoded() - this method will become private", and getEncoded() is a one-line delegation to it, so the bytes equals() and hashCode() see do not move - what changes is that this key stops being one of the callers standing between that method and the private it is headed for. BCXMSSPublicKey compares the same way for the same reason and has to catch the IOException getEncoded() declares but cannot throw on this path; the catch is copied across with its comment so the two read alike. The provider's XMSSMTTest at 29.
gefeili
More... about 2 months ago
Open org.bouncycastle.pqc.jcajce.provider.xmss to java.base, which every provider package the BC provider instantiates from is opened for and this one was not. The package has been exported since it was written, which is what a BCPQC-only package needs, and the line beside it - opens org.bouncycastle.pqc.jcajce.provider.lms to java.base - was added by b52380c27a ("added export to java.base for lms algorithm") at the moment LMS was wired into BouncyCastleProvider's ASYMMETRIC_CIPHERS, which is the step this branch takes for XMSS. Every package listed in that opens block is one the provider names by string and reaches reflectively, and the block is where the newer algorithms all sit; xmss is now in the same position and was the one entry missing. Both descriptors get it, the Gradle-driven jdk1.9 one and the ext-jdk1.9 one the legacy distribution consumes, since those are kept in step by hand. Nothing in this tree exercises it: no test here runs the provider on the module path, so the descriptor is checked by compilation and by the sibling it now matches rather than by a run.
gefeili
More... about 2 months ago
Report the usages a signer's key has left without taking the signer's monitor, which none of the implementations this sits beside takes for it. getUsagesRemaining() reads the private key field and asks the key, and what comes back is a count rather than a reservation: it is out of date the moment a monitor held over it is dropped, because the next signature made on that key - by this signer, or by another one initialised on it - moves it. So a lock here buys the caller a number no more current than the unlocked read gives, at the price of contending with the signature that is making it stale. The field read is of a reference, which cannot tear, and the key's own getUsagesRemaining() takes the key's monitor for the traversal state the count is derived from, which is the read that has two fields to keep together. This is where org.bouncycastle.pqc.crypto.xmss leaves it - neither XMSSSigner.getUsagesRemaining nor the XMSS^MT one is synchronized there - and where the promoted LMS leaves it, LMSPrivateKeyParameters and HSSPrivateKeyParameters both carrying an unsynchronized getUsagesRemaining beside the synchronized getIndex the same class defines. What stays on this signer's monitor is init(), generateSignature() and getUpdatedPrivateKey(), the three that write the private key field or spend the one-time key it names; five sites each, down from seven. The package's AllTests at 102, AllTestsXMSS at 79 including the byte-identity oracle, the provider's XMSSTest at 33 and XMSSMTTest at 29, and checkstyleMain on core.
gefeili
More... about 2 months ago
Verify without taking the signer's monitor, the way the XMSS signers this promotes and LMSSigner both verify. verifySignature() reads the public key and the mode flag, spends no one-time key and advances no traversal state, so there is nothing in it for a monitor to serialize - and the monitor could not serialize the one thing that looks like it needs it, because update() and reset() write the message buffer without taking it, so a lock held over the read alone excludes nothing a caller sharing one signer between threads is already doing. What the signing side takes this monitor for is the private key field, which getUpdatedPrivateKey() reassigns and init() reassigns: that is a field the verification side does not touch, and nothing writes the public key but init(), where a signer re-initialised under a running operation is the caller error it is in every other signer here. So the signing side keeps both monitors and the verification side takes neither, which is also where the two implementations being promoted from left it - org.bouncycastle.pqc.crypto.xmss's XMSSSigner and XMSSMTSigner synchronize on the private key in generateSignature and nowhere near verifySignature - and where the sibling scheme leaves it, LMSSigner and HSSSigner and LMSEngine carrying no synchronized at all between them and every lock LMS takes living inside the key parameters. The reason for the absence goes into the javadoc rather than being left to be rediscovered. The package's AllTests at 102, AllTestsXMSS at 79 including the byte-identity oracle, the provider's XMSSTest at 33 and XMSSMTTest at 29, and checkstyleMain on core.
gefeili
More... about 2 months ago
Drop the AddressTests case asserting the three address types are distinct, which the three layout tests beside it already decide. Each of those asserts the type word of the encoding its own type produces - 0x00 for the OTS hash address the factory builds, 0x01 and 0x02 for the two subtreeAddressOf derives from it - and all three build from the same layer and tree, so the moment those three assertions hold the three encodings differ in bytes 12 to 15 and no pair of them can compare equal. The case had no mutation of its own to catch: a build whose subtreeAddressOf leaves the type word where the fresh array leaves it, which is what makes all three encodings identical and is the one thing this case existed to notice, fails testLTreeAddressLayout and testHashTreeAddressLayout at expected 1 and 2 against 0, so it is refused two tests before reaching this one. The package's AllTests at 102, down from the 103 it ran with the case in.
gefeili
More... about 2 months ago
Let DigestUtil refuse a null tree digest OID rather than checking for one first. The check stood at the top of the two-argument WOTSPlusParameters constructor and nothing in this tree could reach it: XMSSParameters and XMSSMTParameters throw their own NullPointerException("digest == null") before they get as far as XMSSEngine.getWOTSPlusLen, and XmssKeyUtil takes the OID off an AlgorithmIdentifier and puts it through DigestUtil.getDigest before anything reaches BDS.withWOTSDigest. It did not cover its own class either - the one-argument constructor evaluates DigestUtil.getDigest(treeDigest).getDigestSize() in the this(...) argument list, so a null dies inside getDigest before the constructor holding the check is entered, and withWOTSDigest(oid) and withWOTSDigest(oid, size), two overloads of one public method on an exported package, answered the same mistake two different ways. Removing it lets nothing through, because DigestUtil is already what refuses the null on that other path: getDigestName looks the OID up with a HashMap.get, which takes a null key, and reports it as IllegalArgumentException("unrecognized digest oid: null") - the wording it gives every OID it does not know. What that costs is the exception type on the three ways in that did reach the check, and the two constructors still differ from each other, because which of getDigest and getDigestName lies on the path is what decides it rather than a check of ours. The OID lookup below stays, and is not this: it is the only place a security parameter no XMSS parameter set defines is refused, and with it shadowed out new XMSSParameters(4, id_sha256, n) at n = 17, 20, 33 and 64 all generate a key pair, sign and verify with parameterSetOID 0, every node above the digest's own 32 bytes carrying a constant zero tail - the measured n = 64 root ends in 32 of them. ParameterBoundsTests asserts its message across nine sizes and both schemes.
gefeili
More... about 2 months ago
Make an OTS hash address with a static factory on XMSSAddress, and delete OTSHashAddress. It was the last address object - a class holding one int, whose every use was to make one and encode it in the same expression - where an L-tree address and a hash tree address had already become static byte[] on XMSSAddress when the walks stopped holding addresses and started stepping encodings. So the one 32-byte frame RFC 8391 sec. 2.5 defines was laid out across two files, and the split ran through the middle of a single walk: WOTSPlus.getWOTSPlusSecretKey clears the chain address, the hash address and the key-and-mask of the encoding it was handed on three consecutive lines, and had to name the first two out of OTSHashAddress and the third out of XMSSAddress. otsHashAddress(layerAddress, treeAddress, otsAddress) takes what the constructor took and writes the same four words in the same order, the type among them: that word is zero and a fresh array holds zero, but the other two types are written and dropping this one would be a change of its own rather than part of this. The three offsets and otsAddressOf move across, each landing beside the name another type gives the same word - OTS_ADDRESS_OFFSET next to LTREE_ADDRESS_OFFSET, CHAIN_ADDRESS_OFFSET and HASH_ADDRESS_OFFSET next to TREE_HEIGHT_OFFSET and TREE_INDEX_OFFSET - which is the aliasing the RFC has and which a reader could not see while it was split. Two names for one offset here are not a constant written twice, the way the tree height and the tree index were before they were merged: they are what the type word decides between, and each says at its use site which walk is stepping.
gefeili
More... about 2 months ago