Reference implementation for SPHINCS+ based on latest NIST FIPS drafts

[D P]

Dear SPHINCS+ team,

Can you please share any updated reference implementation based on the latest NIST FIPS draft proposals? They don't seem to be in the Github repository for SPHINCS+

https://github.com/sphincs/sphincsplus

We are evaluating using SPHINCS+ as an breakglass option for a specific blockchain use-case, hence this updated reference implementation would be very helpful.

[Scott Fluhrer (sfluhrer)]

The implementation that matches the draft FIPS 205 is in the consistent-basew branch.

 

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/4b585061-445c-4833-9ab2-b27ca12b6af7n%40list.nist.gov.

[D P]

Thanks Scott! This is helpful.

We have a naive question; since part of the seed is placed into the public-key, is it safe to pass in a randombytes seed obtained directly from the operating system's entropy pool (such as /dev/random)? Or is it suggested to pass only a derived seed created by passing the original seed to an XOF/ChaCha20? We are asking since part of the seed is exposed via the public-key and it means exposing some of the underlying entropy pool details.

/*
 * Generates an SPX key pair given a seed of length
 * Format sk: [SK_SEED || SK_PRF || PUB_SEED || root]
 * Format pk: [PUB_SEED || root]
 */
int crypto_sign_seed_keypair(unsigned char *pk, unsigned char *sk,
                             const unsigned char *seed)
{
    spx_ctx ctx;

    /* Initialize SK_SEED, SK_PRF and PUB_SEED from seed. */
    memcpy(sk, seed, CRYPTO_SEEDBYTES);

    memcpy(pk, sk + 2*SPX_N, SPX_N);

[Scott Fluhrer (sfluhrer)]

We assume that the randomness used to generate the private key is from a cryptographically secure random bit generator, for example, one of the 800-90A generators (of an appropriate security strength).  With such a generator, it doesn’t matter if we expose some of the output; it is computationally infeasible to recover the remaining unexposed part.

[D P]

Thanks for the details Scott.

[Suzumi Nagata]

Hi, I'm revisiting this thread to ask if there were any updates on this matter.

From what I looked into the official repo, the branch is still not merged into master. Do anyone know if there is some kind of plan or fork with a reference implementation that fully matches the final FIPS 205?

Best Regards,
Suzumi

[Celi, Christopher T. (Fed)]

FYI https://github.com/usnistgov/ACVP-Server/tree/master/gen-val/src/crypto/src/NIST.CVP.ACVTS.Libraries.Crypto/SLHDSA is the implementation the NIST Cryptographic Algorithm Validation Program uses to generate tests for validation testing. Written in C#, not optimized for speed or security. It is meant to be readable with the standard.

Thanks,

Chris Celi

CAVP Program Manager

From: pqc-...@list.nist.gov <pqc-...@list.nist.gov> on behalf of Suzumi Nagata <suzum...@gmail.com>
Date: Wednesday, February 11, 2026 at 10:45 AM
To: pqc-forum <pqc-...@list.nist.gov>
Cc: D P <dogepr...@gmail.com>, Scott Fluhrer (sfluhrer) <sflu...@cisco.com>
Subject: [EXTERNAL] Re: [pqc-forum] Reference implementation for SPHINCS+ based on latest NIST FIPS drafts

You don't often get email from suzum...@gmail.com. Learn why this is important

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/c6ae202d-87e9-4540-976d-2c80313e382cn%40list.nist.gov.

[Scott Fluhrer (sfluhrer)]

The main branch of my "parallel Sphincs" implementation https://github.com/sphincs/parallel-sphincsplus implements FIPS 205 fully (and while it hasn't undergone full ACVP testing, its self tests compares the generated public/private keys and signatures to public/private keys and signatures extracted from NIST's published test vectors).

Of course, I can't claim this as a "reference" implementation, as it is a specifically ISA and AVX2 based implementation (and so is not quite as generally applicable as a true reference implementation would be).

---

From: Suzumi Nagata <suzum...@gmail.com>
Sent: Wednesday, February 11, 2026 10:42 AM
To: pqc-forum <pqc-...@list.nist.gov>
Cc: D P <dogepr...@gmail.com>; Scott Fluhrer (sfluhrer) <sflu...@cisco.com>

[Suzumi Nagata]

Thank you very much for the suggestions!

I didn't know that there was a CAVP implementation source available. I'll check these implementations out!

Best Regards, 

On Wed, Feb 11, 2026 at 1:19 PM Stephan Mueller <smue...@chronox.de> wrote:

Am Mittwoch, 11. Februar 2026, 17:10:30 Mitteleuropäische Normalzeit schrieb
'Scott Fluhrer (sfluhrer)' via pqc-forum:

Hi,

> The main branch of my "parallel Sphincs" implementation
> https://github.com/sphincs/parallel-sphincsplus implements FIPS 205 fully
> (and while it hasn't undergone full ACVP testing, its self tests compares
> the generated public/private keys and signatures to public/private keys and
> signatures extracted from NIST's published test vectors).
>
> Of course, I can't claim this as a "reference" implementation, as it is a
> specifically ISA and AVX2 based implementation (and so is not quite as
> generally applicable as a true reference implementation would be).

An implementation that went through ACVP testing and has ACVP certificates is
available at [1] with C, AVX2 and ARMv8 implementations.

[1] https://leancrypto.org

Ciao
Stephan

[Stephan Mueller]

Am Mittwoch, 11. Februar 2026, 17:10:30 Mitteleuropäische Normalzeit schrieb
'Scott Fluhrer (sfluhrer)' via pqc-forum:

Hi,

> The main branch of my "parallel Sphincs" implementation
> https://github.com/sphincs/parallel-sphincsplus implements FIPS 205 fully
> (and while it hasn't undergone full ACVP testing, its self tests compares
> the generated public/private keys and signatures to public/private keys and
> signatures extracted from NIST's published test vectors).
>
> Of course, I can't claim this as a "reference" implementation, as it is a
> specifically ISA and AVX2 based implementation (and so is not quite as
> generally applicable as a true reference implementation would be).