Open Hub
Open Hub

 Settings

1
I Use This!
Very High Activity

Commits : Listings

Analyzed about 20 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
Composite ML-DSA now primes its component signatures at sign/verify time as well as on the first update, so an empty message no longer produces a signature made with an empty ML-DSA context and default PSS parameters; a context over 255 bytes is rejected rather than silently truncated in M's single length byte per sec. 4.1 of draft-ietf-lamps-pq-composite-sigs; the pre-hash digest is reset in a finally so a rejected signature no longer leaves the object failing every later verify; the caller's SecureRandom now reaches every component from both KeyPairGenerator.initialize(null, random) and Signature.initSign(key, random); the 14 superseded HashMLDSA names are removed from CompositeIndex and the pkix signature-algorithm finder, which advertised names no service backed; and the SupportedKeyClasses/SupportedKeyFormats attributes are published rather than built and dropped.
David Hook
More... about 2 months ago
DTLS record layer now silently discards a record for every fatal alert raised while decoding it except internal_error, rather than only bad_record_mac, so a forged datagram whose body is too short for the cipher (decode_error) or misaligned for a block cipher (decryption_failed) no longer tears down an established association at both ends, per RFC 9147 sec. 4.5.2 and RFC 9146 sec. 6; the redundant bad_record_mac special case in DTLSTransport.receive/receivePending is removed
Peter Dettman
More... 2 months ago
Label the bctls-klog build's BCJSSE provider info string with " (Key Logger)" through a ProviderInfoSuffix seam the klog tree replaces, so that Security.getProvider("BCJSSE").getInfo() distinguishes the key-logging jar from the standard one, which is otherwise identical at the JCA boundary
David Hook
More... 2 months ago
Move to the 1.86 release: gradle/bc-build version properties to 1.86, the BC and BCPQC provider info strings and version doubles across the base, jdk1.1 and jdk1.4 copies, the BCPG armor version stamp (adding the jdk1.3 ArmoredOutputStream overlay to pg's stampVersion list, which had been left behind on the previous version) and the JSSE provider to 1.0.25
David Hook
More... 2 months ago
SM2Signer.getZ() is now protected so a subclass can suppress the Z prefix and sign a caller-supplied pre-hashed e with a NullDigest, relates to github #2429.
David Hook
More... 2 months ago
CertPath validation now reports why a delegated CRL signer was rejected rather than the empty CRL lookup that followed it, relates to github #2427.
David Hook
More... 2 months ago
Add -implicit:none to the compileJava9Java tasks so the module-info compile does not implicitly recompile every baseline class it reaches through the sourcepath
David Hook
More... 2 months ago
Re-attach method's javadoc in HSSTests
Peter Dettman
More... 2 months ago
TSP: distinct exception messages for sign cert v2
Peter Dettman
More... 2 months ago
Use TSPTestUtil instead of CMSTestUtil
Peter Dettman
More... 2 months ago
The seven OpenPGP signature subpackets whose body RFC 9580 defines as a fixed length now all enforce that length where the subpacket is parsed rather than deferring it to an accessor, only Signature Expiration Time having done so, since SignatureSubpacketInputStream.readPacket validated a declared body length for range and for the case where it overran the subpacket area but handed a body whose declared length matched the octets it carried to the constructor whatever that length was, so Signature Creation Time and Key Expiration Time reported a body that was not the four octets of a time field, Exportable Certification, Revocable and Primary User ID a body that was not the single zero or one octet of a flag, and Issuer Key ID one shorter than a key ID, as an unchecked IllegalStateException out of org.bouncycastle.bcpg.sig.Utils or an IllegalArgumentException out of FingerprintUtil.readKeyID when the value was read, which matters because such a body inside a self-signature is content the signer signed over, so a certificate carrying one verified as valid and failed only later in ordinary reader code - PGPPublicKey.getValidSeconds(), PGPSignatureSubpacketVector.getKeyExpirationTime() and isExportable(), OpenPGPCertificate.getExpirationTime(), and the keyserver re-export path PGPPublicKeyRing.encode(out, true), which declares IOException - and the length and flag-value checks now sit as shared statics beside the accessors they protect, with Signature Expiration Time's own check folded into them, a malformed subpacket refused at parse time as a MalformedPacketException the way Features, Trust Signature and Notation Data already were, and the parser's tolerance of a fixed-length field whose declared length overruns the subpacket area preserved, BytesBooleansTest being wired into the openpgp suite it had never been registered in, relates to github #2426.
David Hook
More... 2 months ago
The three java.security.cert.X509CRL accessors no longer let an unchecked exception escape when an indirect CRL carries an entry whose certificateIssuer does not decode to a directoryName, getRevokedCertificates(), getRevokedCertificate(BigInteger) and isRevoked(Certificate) having re-parsed it as GeneralNames.getInstance(...).getNames()[0] in both X509CRLImpl and the deprecated jce.provider.X509CRLObject the registered X509StreamParser.CRL service returns, which also refused the well-formed encoding that names the directoryName after another GeneralName although X509CRLEntryObject read the same CRL correctly, so all six sites now share that sibling's logic, promoted to a package-private static in each of the two packages, and an entry naming no directoryName is treated as having no certificate issuer of its own, which java.security.cert.X509CRLEntry defines as the CRL issuer's, relates to github #2425.
David Hook
More... 2 months ago
org.bouncycastle.openpgp.api.DoubleBufferedInputStream, which no class in the library referenced and whose read() returned the buffered byte unmasked so that every byte from 0x80 upwards came back negative and 0xFF came back as the -1 a caller reads as end of stream, has been removed along with its test rather than repaired, its withholding also being one read of the underlying stream rather than the configured buffer size, and OpenPGPMessageInputStream now documents that what is read from it is not covered by an integrity check until close() has returned, relates to github #2424.
David Hook
More... 2 months ago
The XDH KeyFactory now accepts and returns the JDK's own java.security.spec.XECPublicKeySpec and XECPrivateKeySpec on JDK 11 and later, through the jdk1.11 XDHKeys twin that already produces the XEC-implementing key classes, so an X25519 or X448 key round-trips through the standard spec as an Edwards key has done since the JDK 15 EdEC specs, with the u-coordinate reduced modulo the field prime and encoded little-endian by the conversion an incoming XECPublicKey already went through, RFC 7748 sec. 5 requiring a value at or past the prime to be taken as though it had been reduced.
David Hook
More... 2 months ago
Every classical signer now assembles the signature component s through the constant-time BigIntegers.modMult, modAdd and the new modSubtract rather than BigInteger.multiply and mod, whose cost follows the quotient and which were being handed the signing key, covering ECDSA, SM2, DSA, GOST 3410, ECGOST 3410, DSTU 4145, EC-NR and BIP 340, with the public hash-derived value reduced on the way in wherever it could sit at or past the order, DSAPrivateKeyParameters and GOST3410PrivateKeyParameters now holding x to the [1, q-1] their own parameters imply, and the two GOST signers redrawing a nonce that is zero or at or past the order rather than leaving it to be folded by the reduction that followed.
David Hook
More... 2 months ago
Say what the second half of testInitSignWithSecureRandom covers now that the SPI no longer keeps a random. The comment describes the reason the case was written: the SecureRandom was a field, so a one-argument init after a two-argument one wrapped the key again with the random the first call had left behind, and that second wrap was the sticky path being checked. The field is gone - the random is a method argument, and engineInitSign(PrivateKey) passes null - so there is no stickiness left to check, and the comment sends a reader looking for a field that is not there.
gefeili
More... 2 months ago
Compare the collected key against where it started rather than against a view of itself. testKeyCanBeCollectedAfterAVerificationInit ended on assertEquals of kp.getPrivate() against what getUpdatedPrivateKey() handed back, under the message "the key handed back is not the one the signature advanced" - and the object kp.getPrivate() returns wraps the traversal state the signature advances in place. Measured: its encoding before the signature and after it differ. So both sides of that comparison report the position after the signature whatever the collection did, and the assertion is two views of one mutated key.
gefeili
More... 2 months ago
Wrap the XMSS suite in the BCTestSetup this package already has, rather than in a second copy of it. AllTestsXMSS declared its own - a TestSetup subclass with an empty setUp and an empty tearDown, byte for byte what AllTests declares two files away and in the same package. Of the twenty-one suites here, nineteen already say new AllTests.BCTestSetup(suite), including AllTestsXMSSMT, which is this file's own twin and was written the same week. This one was the outlier.
gefeili
More... 2 months ago
Name the callers the two _Low methods actually have. Both javadocs went in with this branch and both enumerate their callers, which is the useful thing about them and the part that was wrong.
gefeili
More... 2 months ago
Take the single-tree parameters off this key's own parameter set rather than out of a builder field holding the same thing, and drop the null check on that field which nothing could reach. The builder carried an xmss field written in one place, withPrivateKey, from params.getXMSSParameters(); the constructor entered its import branch on privateKey being non-null, which is set by that same method and only by it. So being inside the branch was already the proof the field had been written, and the NullPointerException("xmss == null") above it was unreachable - a guard on the caller having done something the branch it guards cannot be entered without.
gefeili
More... 2 months ago
Refuse a signature index outside the tree in XMSSSignature, as XMSSMTSignature already refuses it. The two builders decode the same field of the same scheme and disagreed about it: the XMSS^MT one reads the index and puts it through XMSSUtil.isIndexValid before going on, and the XMSS one read four bytes as a signed int and used them. So the same library gave two answers to whether an index naming a leaf the tree does not have is a signature that will not decode or one that does not verify - the shape github #2408 was about on the length check three lines above, where XMSSMTSignature had the check and XMSSSignature did not, and this is the other half of the same header.
gefeili
More... 2 months ago
Say that isIndexValid throws for a negative index rather than answering false, which is what its javadoc promised. "true if index is valid false else" is the whole of what the method documented, and the first thing its body does is raise IllegalStateException("index must not be negative") - so the one input a reader would most expect the boolean to cover is the one it does not.
gefeili
More... 2 months ago
Let DigestUtil.getDigest report a null tree digest OID the way getDigestName already reports it. The two are the pair this package turns an OID into something usable through, and they answered the same mistake two different ways: getDigestName looks the OID up with a map get, which takes a null key and falls through to IllegalArgumentException("unrecognized digest oid: null"), while getDigest asked the argument whether it equalled each of five constants and so raised NullPointerException on the first comparison, out of a method on an exported package.
gefeili
More... 2 months ago
Move the last two helpers XMSSTest and XMSSMTTest still hold a copy of each into XMSSTestUtils, which was added for exactly them. That class says at the top what belongs in it - the two suites are twins, every case in one has a counterpart in the other differing only in which parameter set and which key type it names, so a helper with no XMSS-versus-XMSS^MT typing in it goes there rather than once in each - and filled(int) and the DoubleDigest class are both of those and were left behind. Each is byte-identical between the two files: a diff of either pair is empty.
gefeili
More... 2 months ago
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... 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... 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... 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... 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... 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... 2 months ago