SPHINCS+ over Blake3

[Oscar Smith]

From https://sphincs.org/, it looks like SPHINCS+ only supports SHA2, SHA3 and Haraka as the base hashing functions. Is there a reason why Blake2/Blake3 aren't supported? From what I've seen, the Blake family is a lot faster than the SHA family.

[Arne Padmos]

Why not BlaKE12? https://blake12.org/

More seriously, because they're not NIST approved hash functions. Of course, you can plug in whatever hash function or XOF you want if you want to roll your own non-standard crypto. Also, note that the places where SLH-DSA will likely be primarily used, i.e. for firmware signing, SHA3 will likely offer superior performance in hardware to SHA2, BLAKE, BLAKE2, BLAKE3, Bao, etc.

A more pertinent question to ask is why there isn't an Ascon-based variant of SLH-DSA as NIST IR 8528 doesn't include specific rationale for dropping Ascon-Sign out of the signature on-ramp. As such it's unclear if the objection is to Ascon-Sign specifically or to the general idea of an Ascon-based parameter set (whether using Ascon-Hash256, Ascon-XOF128, Ascon-CXOF128, or a purpose-specific Ascon-p-based mode).

[Oscar Smith]

> More seriously, because they're not NIST approved hash functions

If Blake3 is a better hash function than existing SHA options, NIST should approve it (and this seems like as good a place as any to ask that to happen).

> SHA3 will likely offer superior performance in hardware to SHA2, BLAKE, BLAKE2, BLAKE3, Bao, etc.

Do you have a benchmark for this? From what I can tell, there is no commercially available platform on which Sha3 outperforms Blake2b/Blake3. On both x86 and aarch64 platforms Blake3 is ~3-4x faster than Sha3 across for all sizes (e.g. https://kerkour.com/fast-secure-hash-function-sha256-sha512-sha3-blake3).

Furthermore, even if the gap can be closed by dedicated hardware, spending silicon area just to match the performance of BLAKE3 seems like a poor utilization of silicon that could instead be used to improve the vector units of the CPU which would improve BLAKE3 speeds as well as the speed of every other vectorized function the CPU performs. (not to mention that relying on hardware for speed means significantly compromising on agility. If If we need to switch to a different hash function in software, that can be done in minutes, while switching to a different hash function in hardware takes years).

[Simon Hoerder]

Hi,

> On 16 Oct 2025, at 21:24, Oscar Smith <oscard...@gmail.com> wrote:
>
> > More seriously, because they're not NIST approved hash functions

>
> If Blake3 is a better hash function than existing SHA options, NIST should approve it (and this seems like as good a place as any to ask that to happen).

God, please no. We have enough different symmetric crypto functions to support in HW as it is. The effort for verification, certification and, where necessary, countermeasures against physical attacks is high enough as it is.

The only thing that is missing among NIST basic crypto standards is a decent low-latency block cipher + mode of operation with optional authentication for memory encryption. And maybe a SP800 that enables usage of SHAKE as clean & simple DRBG. (Threshold crypto is a different topic that would lead too far astray in this context.)

> > SHA3 will likely offer superior performance in hardware to SHA2, BLAKE, BLAKE2, BLAKE3, Bao, etc.
>
> Do you have a benchmark for this? From what I can tell, there is no commercially available platform on which Sha3 outperforms Blake2b/Blake3. On both x86 and aarch64 platforms Blake3 is ~3-4x faster than Sha3 across for all sizes (e.g. https://kerkour.com/fast-secure-hash-function-sha256-sha512-sha3-blake3).

I doubt you find commercial chips with a HW accelerator for Blake. Most HW accelerators are still limited to SHA2; SHA3 accelerators are only recently becoming popular due to PQC. But make no mistake: SHA3/SHAKE is fast in HW accelerators. The bigger challenges are to provide input data fast enough or to reduce area if area happens to be your main concern.

Best,
Simon

[Arne Padmos]

Due to network effects, standards are arguably more valuable the less there are of them. So adding yet another hash function to the list of approved NIST hash functions needs very clear motivation. Also, a key reason for BLAKE3's performance is cutting the number of rounds from 14 in BLAKE to 10 in BLAKE2 to 7 in BLAKE3 (for 256 bit digests). An important reason for picking Keccak as SHA3 is that it provides a very big security margin and that it's performance profile is quite different from the SHA2 family, i.e. acceptable in software and great in hardware.

As to benchmarks, this is from the final round report of the SHA3 competition (https://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7896.pdf#page=55):

> Of the five finalists, BLAKE and Skein are designed with multiple modular addition operations, while Keccak, Grøstl and JH are not. Not surprisingly, of these five algorithms, BLAKE and Skein have the best throughput on general-purpose computers, while Keccak, Grøstl and JH usually give better throughput/area performance on hardware implementations. SHA-2 also uses modular addition, but with more non-linear bitwise operations, and requires fewer adder circuits than either BLAKE or Skein.

Of course, those benchmarks might not reflect specific usage in SLH-DSA, but the results from https://eprint.iacr.org/2024/367.pdf indicate that 'The SHA2 parameter sets have approximately half of the speed of SHAKE parameter sets.' In other words, BLAKE3 is unlikely to be better performance than the SHAKE-based parameters.

As to the relevance of hardware: SHA3 is also used in ML-KEM. A suggestion to use the TurboSHAKE variant instead of SHAKE was rejected during ML-KEM standardisation discussions. Even if SHAKE is twice as slow as TurboSHAKE, the X25519MLKEM768 hybrid KEM of TLS 1.3 is now used in a significant portion of global Internet traffic and the sky is not falling. Some of those TLS clients will have SHA3 acceleration (e.g. Armv8.4-A and up) but many won't and the performance is acceptable. Is it 'too much crypto' (https://eprint.iacr.org/2019/1492.pdf)? Probably. Is it practically relevant and do the upsides of parameter proliferation outweigh the benefits? Probably not.

Where SLH-DSA will likely be most relevant, i.e. for a root of trust, hardware implementations will be critical. Also, note that BLAKE3 would only support a level 1 parameter set and the jury is still out on whether level 1 parameters will be included in the list of agreed cryptographic mechanisms in the EU (for CRA, NIS2, etc.), or if that will be level 3 and up only.

[Arne Padmos]

> The only thing that is missing among NIST basic crypto standards is a decent low-latency block cipher + mode of operation with optional authentication for memory encryption. And maybe a SP800 that enables usage of SHAKE as clean & simple DRBG. (Threshold crypto is a different topic that would lead too far astray in this context.)

The good news is that XDRBG (or something very similar) will likely be included in a revision of NIST SP 800-90A. See the pre-draft call for comments at https://csrc.nist.gov/pubs/sp/800/90/a/r2/iprd for additional details.

I would argue that a SHAKE-based AEAD is also still missing (the Accordion mode effort of NIST doesn't seem like it'll help fill that gap). One could also argue that for specific use cases an Ascon-based SLH-DSA parameter set would be useful. More generally, it would be great if there were a secure protocol design framework that provides appropriate guard rails and which prevents engineers from having to cobble together secure channels from lower-level primitives when building application-layer protocols.

As to low-latency block ciphers and the main use case of memory encryption, isn't NIST standardisation of those much less relevant as these implementations are self-contained and don't need to interoperate?

[Simon Hoerder]

Hi again,

> On 16 Oct 2025, at 22:25, Arne Padmos <goo...@arnepadmos.com> wrote:
> […]

> As to low-latency block ciphers and the main use case of memory encryption, isn't NIST standardisation of those much less relevant as these implementations are self-contained and don't need to interoperate?

[…]

In principle yes but in many cases it’s preferable to pick algorithms that can go through NIST CAVP certification just in case [some of] the end customers require it. Even if end customers don’t go through NIST CAVP, the easy availability of those test vectors does provide a lot of confidence to customers that there’s no nasty functionality issues hiding in a chip. It doesn’t guarantee absence of security issues, of course. But it’s a very important testability / functional confidence milestone.

Best,
Simon

[Arne Padmos]

On Thursday, 16 October 2025 at 22:50:21 UTC+2 Simon Hoerder wrote:

> As to low-latency block ciphers and the main use case of memory encryption, isn't NIST standardisation of those much less relevant as these implementations are self-contained and don't need to interoperate? 

In principle yes but in many cases it’s preferable to pick algorithms that can go through NIST CAVP certification just in case [some of] the end customers require it. Even if end customers don’t go through NIST CAVP, the easy availability of those test vectors does provide a lot of confidence to customers that there’s no nasty functionality issues hiding in a chip. It doesn’t guarantee absence of security issues, of course. But it’s a very important testability / functional confidence milestone.

Sure. I'm not saying it would not fill a hole in NIST's crypto standards, just that given the key role of interoperability being played by these standards other things on the backlog should probably get priority.

[John Mattsson]

Hi,

First, don’t use SPHINCS+, use the standardized version, SLH-DSA (FIPS 205). The SHA-2-based variants of SPHINCS+ had vulnerabilities that were addressed in the standardized version. In fact, SPHINCS+/SLH-DSA serves as a good example of why you should not use SHA-2, it is difficult to use securely, and achieving strong security often requires overly complex designs.

 

Oscar Smith wrote:

>https://kerkour.com/fast-secure-hash-function-sha256-sha512-sha3-blake3

 

That is not a good comparison, as it omits SHAKE (FIPS 202), TurboSHAKE, and KangarooTwelve (RFC 9861), which are the SHA-3/Keccak variants you should use. The Keccak team has published recent performance results at keccak.team/2025/rfc9861.html

 

While BLAKE2 is standardized and endorsed by the CFRG in RFC 7693, BLAKE3 is not. If you prefer a faster hash function outside of NIST’s approved suite, I would recommend RFC 9861.

 

Simon Hoerder and Arne Padmos wrote:

>And maybe a SP800 that enables usage of SHAKE as clean & simple DRBG

>I would argue that a SHAKE-based AEAD is also still missing

 

Yes please.

 

Cheers,

John

 

--
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 visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/2e3ef411-e7a8-4669-b874-693c0c07730cn%40list.nist.gov.

[John Mattsson]

Hi Daniel,

 

Sydney Antonov pointed out that one of the security properties relied upon by SPHINCS+ can be broken in the SPHINCS+-SHA-256 v.3 variant [1].

 

    "SPHINCS+ relies on the distinct-function, multi-target second-preimage

    resistance (DM-SPR) of the underlying keyed hash function. This

    property can be broken for SHA-256(key||message) (which is used by

    SPHINCS+-SHA-256)"

 

Ray Perlner, John Kelsey, and David Cooper extended Antonov’s technique and demonstrated that it, in fact, produces a complete forgery attack [2].

 

The attack is possible because SHA-2 does not behave like a random oracle as it should, unlike SHA-3.

 

Sections 11.1 and 11.2 of FIPS 205 [3] illustrate the simplicity of SLH-DSA when used with SHAKE compared to its complexity when used with SHA-2.

 

Cheers,

John

 

[1] https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/FVItvyRea28/m/mGaRi5iZBwAJ

[2] https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=935143

[3] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf

 

From: Daniel Apon <dapon....@gmail.com>
Date: Friday, 17 October 2025 at 20:10
To: John Mattsson <john.m...@ericsson.com>
Cc: Arne Padmos <goo...@arnepadmos.com>, pqc-forum <pqc-...@list.nist.gov>, Simon Hoerder <si...@hoerder.net>
Subject: Re: [pqc-forum] Re: SPHINCS+ over Blake3

" In fact, SPHINCS+/SLH-DSA serves as a good example of why you should not use SHA-2, it is difficult to use securely, and achieving strong security often requires overly complex designs."

John, would you be willing to recite the basics of this material here? (I probably agree with you!) For the sake of the broader audience on SHA-2 vs [other choices]

Cheers,
--Daniel

 

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/GVXPR07MB96782E84B613B6F6C6ED48D889F6A%40GVXPR07MB9678.eurprd07.prod.outlook.com.