Hi there,
I would like to ask whether Bouncy Castle would consider supporting the six additional SLH-DSA parameter sets specified in the NIST FIPS SP 800-230: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-230.ipd.pdf
The current status of the draft at this moment I'm writing to you is published on 13th April 2026 and it already received comments: https://csrc.nist.gov/files/pubs/sp/800/230/ipd/docs/sp800-230_ipd_comments_received.pdf
The draft explicitly positions the sets for "sign-once, verify-many" scenarios. There is no final version yet, so this is meant as a tracking request. I would very appreciate if it can be implemented, since we need this limited signature counts version for many PKI applications. I find one of the comments published in the document I've included the link here is that one from MTG AG would be relevant for us. We would probably use the 2^16 signature count limit (this is a request from MTG AG to NIST) as well as the 2^24 signature count limit for our prototypes.
Use case: Smartcard-based identity credentials
Signatures are produced offline in HSMs, stored on a memory-constrained card and verified off-card by a reader. The card never signs, so the slower signing path is irrelevant. What binds now is how many bytes the signature occupies in card memory. The saving multiplies accordingly, where a card carries more than one signature (e.g., a signed data object + signer's certificate).
The higher security categories 3 and 5 are where this matters most.
At category 3 "SLH-DSA-{SHA2, SHAKE}-192-24" with signature size of 7,752 bytes the result is workable on current cards.
At category 5 "SLH-DSA-{SHA2, SHAKE}-256-24" with signature size of 14,944 bytes remains a hard fit, since two stored signatures would need a space of almost 30 KB.
I know that NIST does not have object identifiers for these parameters sets yet. The existing twelve SLH-DSA OIDs occupy sigAlgs 20-31 in the NIST CSOR. So this is about the lightweight API only, not JCA registration and not the OID mapping tables. As I understand it, BC already ships algorithms reachable only through the lightweight API, so the precedent seems to fit.
On naming:
- If these were added before the final SP is published, would you name them in a way that marks the draft status?
- If the final document changes any parameter values and the names stay the same, two applications requesting the same name across a version bump would silently compute different things, whereas a draft-marked name gives a clean failure at instantiation.
I would then like to know:
- Would these parameter sets be in scope once SP 800-230 is finalized and published?
- If there is interest earlier, would a lightweight-API-only addition under a draft-marked name be acceptable?
- How much work would this actually be at your end? From the outside, it looks like additional parameter instances rather than new algorithm code, but I personally don't know whether the current design allow sets to be added that way, and lg_w = 2 in particular is not exercised by any the twelve FIPS 205 sets, which all use lg_w = 4, so the WOTS+ chain and base-2^(lg_w) handling may have path that have never run at w = 4.
Thanks very much in advance :-)
Hi there,
I would like to ask whether Bouncy Castle would consider supporting the six additional SLH-DSA parameter sets specified in the NIST FIPS SP 800-230: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-230.ipd.pdf
The current status of the draft at this moment I'm writing to you is published on 13th April 2026 and it already received comments: https://csrc.nist.gov/files/pubs/sp/800/230/ipd/docs/sp800-230_ipd_comments_received.pdf
The draft explicitly positions the sets for "sign-once, verify-many" scenarios. There is no final version yet, so this is meant as a tracking request. I would very appreciate if it can be implemented, since we need this limited signature counts version for many PKI applications. I find one of the comments published in the document I've included the link here is that one from MTG AG would be relevant for us. We would probably use the 2^16 signature count limit (this is a request from MTG AG to NIST) as well as the 2^24 signature count limit for our prototypes.
Use case: Smartcard-based identity credentials
Signatures are produced offline in HSMs, stored on a memory-constrained card and verified off-card by a reader. The card never signs, so the slower signing path is irrelevant. What binds now is how many bytes the signature occupies in card memory. The saving multiplies accordingly, where a card carries more than one signature (e.g., a signed data object + signer's certificate).
The higher security categories 3 and 5 are where this matters most.
At category 3 "SLH-DSA-{SHA2, SHAKE}-192-24" with signature size of 7,752 bytes the result is workable on current cards.
At category 5 "SLH-DSA-{SHA2, SHAKE}-256-24" with signature size of 14,944 bytes remains a hard fit, since two stored signatures would need a space of almost 30 KB.
I know that NIST does not have object identifiers for these parameters sets yet. The existing twelve SLH-DSA OIDs occupy sigAlgs 20-31 in the NIST CSOR. So this is about the lightweight API only, not JCA registration and not the OID mapping tables. As I understand it, BC already ships algorithms reachable only through the lightweight API, so the precedent seems to fit.
On naming:
I would then like to know:
Thanks very much in advance :-)