org.bouncycastle.pqc.crypto.test

Class XMSSPromotionCompatibilityTest

java.lang.Object

junit.framework.Assert

junit.framework.TestCase

org.bouncycastle.pqc.crypto.test.XMSSPromotionCompatibilityTest

All Implemented Interfaces:

junit.framework.Test

public class XMSSPromotionCompatibilityTest
extends junit.framework.TestCase

The XMSS / XMSS^MT implementation under org.bouncycastle.crypto is a copy of the deprecated org.bouncycastle.pqc.crypto.xmss one, so the two must agree byte for byte on every encoding and each must verify what the other signed. This test pins that down over the parameter-set matrix, and is the guard against the copy drifting from the original while both ship.

Constructor Summary

Constructors

Constructor and Description
XMSSPromotionCompatibilityTest()

Method Summary

Modifier and Type	Method and Description
void	testParametersWithRandomAcceptedForSigning() The JCA layer wraps the private key in a ParametersWithRandom whenever a SecureRandom is supplied - XMSSSignatureSpi.engineInitSign(PrivateKey, SecureRandom) does - so all four signers have to accept the wrapper.
void	testSignaturesMatchAtEveryIndexOfAKey() Every index a key can reach, not only its first.
void	testStandardParameterSetEncodingMatches() A standard RFC 8391 parameter set, which is encoded in the RFC 9802 form (id-alg-xmss-hashsig with the 4-octet parameter-set OID ahead of the raw key) rather than the legacy XMSSKeyParams one - a different branch of both key factories.
void	testStreamingRoundTrip() The promoted signers implement org.bouncycastle.crypto.Signer rather than the pqc StateAwareMessageSigner, so a message streamed in through update() must sign and verify, and the buffer must be consumed by each operation rather than carried into the next.
void	testXMSSKeysAndSignaturesMatchAcrossImplementations() The same seed drives both implementations, so a matching pair of keys must come out with identical X.509 / PKCS#8 encodings, and each side must verify the other's signature.
void	testXMSSMTKeysAndSignaturesMatchAcrossImplementations()

Methods inherited from class junit.framework.TestCase

assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertFalse, assertFalse, assertNotNull, assertNotNull, assertNotSame, assertNotSame, assertNull, assertNull, assertSame, assertSame, assertTrue, assertTrue, countTestCases, createResult, fail, fail, failNotEquals, failNotSame, failSame, format, getName, run, run, runBare, runTest, setName, setUp, tearDown, toString

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait

Constructor Detail

XMSSPromotionCompatibilityTest

public XMSSPromotionCompatibilityTest()

Method Detail

testXMSSKeysAndSignaturesMatchAcrossImplementations

public void testXMSSKeysAndSignaturesMatchAcrossImplementations()
                                                         throws java.lang.Exception

The same seed drives both implementations, so a matching pair of keys must come out with identical X.509 / PKCS#8 encodings, and each side must verify the other's signature. The tree height is kept small: it does not change any encoding rule, only how long the tree takes to build.

Throws:

java.lang.Exception

testStandardParameterSetEncodingMatches

public void testStandardParameterSetEncodingMatches()
                                             throws java.lang.Exception

A standard RFC 8391 parameter set, which is encoded in the RFC 9802 form (id-alg-xmss-hashsig with the 4-octet parameter-set OID ahead of the raw key) rather than the legacy XMSSKeyParams one - a different branch of both key factories.

It is also the only branch that carries the raw private key layout, the legacy one building its ASN.1 structure out of the key's own fields instead, so this is where that layout is compared byte for byte against the deprecated copy - and it therefore has to reach both families. The XMSS^MT cases elsewhere in this class are non-standard heights and take the legacy branch, so before XMSSMT-SHA2_20/2_256 was added here nothing in the tree compared an XMSS^MT raw encoding at all: a build whose XMSS^MT index field was one byte wider than it should be passed every case of this class. That set was left out as too slow, which its key is not - a height 10 tree per side, the same shape as the XMSS cases above it - so what it skips is the signing and cross-verification half of checkXMSSMT, whose first signature at this height costs as much again as the key does and which the h=4/d=2 sets of testXMSSMTKeysAndSignaturesMatchAcrossImplementations() already cover.

Throws:

java.lang.Exception

testXMSSMTKeysAndSignaturesMatchAcrossImplementations

public void testXMSSMTKeysAndSignaturesMatchAcrossImplementations()
                                                           throws java.lang.Exception

Throws:

java.lang.Exception

testSignaturesMatchAtEveryIndexOfAKey

public void testSignaturesMatchAtEveryIndexOfAKey()
                                           throws java.lang.Exception

Every index a key can reach, not only its first.

The two implementations agreeing at index 0 says nothing about the idx_sig field of the H_msg key - r || root || toByte(idx_sig, n) of RFC 8391 sec. 4.1.9 and 4.2.7 - because at index 0 that field is all zeros whatever is done with it, and every other case above signs exactly once. Where those bytes sit, and how many of them there are, shows only once the index is non-zero, and a sign-then-verify round trip cannot show it either: both directions of one implementation build the key the same way, so they agree with each other while disagreeing with the other implementation. Comparing the two at every index is what pins it, and it walks the BDS traversal state through every shape it takes on the way.

Throws:

java.lang.Exception

testStreamingRoundTrip

public void testStreamingRoundTrip()
                            throws java.lang.Exception

The promoted signers implement org.bouncycastle.crypto.Signer rather than the pqc StateAwareMessageSigner, so a message streamed in through update() must sign and verify, and the buffer must be consumed by each operation rather than carried into the next. That the streamed signature is byte-identical to the deprecated signer's one-shot output is asserted by checkXMSS / checkXMSSMT below.

Throws:

java.lang.Exception

testParametersWithRandomAcceptedForSigning

public void testParametersWithRandomAcceptedForSigning()
                                                throws java.lang.Exception

The JCA layer wraps the private key in a ParametersWithRandom whenever a SecureRandom is supplied - XMSSSignatureSpi.engineInitSign(PrivateKey, SecureRandom) does - so all four signers have to accept the wrapper. XMSS derives its randomizer from the key (r = PRF(SK_PRF, toByte(idx, 32)), RFC 8391 sec. 4.1.9 / 4.2.7), so the supplied random has nothing to drive: the signature must come out byte-identical to the one signed without the wrapper, which is what says the random was discarded rather than mixed in.

Throws:

java.lang.Exception