[CFRG] Re: Silithium - A Compact, Efficient and Non-separable Hybrid Signature

[John Mattsson <[e-mail]>]

Hi Morgane,

Thanks for the overview of the options.

>The main difference between Silithium and Edilithium is the nonce generation procedure, which is purely random in the first scheme, whereas it's a hash of the private key and the message in the second scheme.

I strongly prefer hedged constructions. Purely random nonce generation has led to major vulnerabilities in the past, whether due to implementation errors or weak RNGs. At the same time, deterministic signatures can be vulnerable to side-channel attacks, and some practitioners have stated that they would never deploy deterministic algorithms in their devices for that reason. I therefore think NIST made the right choice by making both ML-DSA and FN-DSA hedged by default. I think new signatures specifications should be hedged.

>As currenlty described, Edilithium is tighlty coupled with EdDSA specification and (for the Ed25519 variant) uses SHA512 internally for the key generation, which as I understand is something you'd like to avoid.

>We could consider the following options regarding Ed25519 & SIlithium:
>1. Edilithium-25519 with original EdDSA hash functions (use SHA512 internally)
>2. Edilithium-25519 with modified hash functions (replace SHA512 by e.g. SHAKE128)
>3. Silithium-44 with Curve25519 instead of P-256

Yes, I would like to phase out SHA-2 over the long term. I think all new specifications should use SHA-3 and XOFs. If the hybrid use case is only intended as a short-term transitional mechanism, I think option 1 is reasonable. If the use case is intended to be long-term, I would prefer Silithium-44.

Cheers,
John Preuß Mattsson

From: Morgane Guerreau <[e-mail]>
Date: Sunday, 19 July 2026 at 13:48
To: John Mattsson <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: Silithium - A Compact, Efficient and Non-separable Hybrid Signature

Hi John,

>One question is whether this construction could be instantiated with the CFRG curves. A lot of people (including Ericsson) prefer 25519 and 448 for new systems, as they offer better performance, stronger practical security, and broader global trust.

The original paper [1] describes a variant of Silithium with Ed448 nicknamed "Edilithium" (see Annex C), and it's not yet described in the paper but we also have a version with Ed25519.
The main difference between Silithium and Edilithium is the nonce generation procedure, which is purely random in the first scheme, whereas it's a hash of the private key and the message in the second scheme.

As currenlty described, Edilithium is tighlty coupled with EdDSA specification and (for the Ed25519 variant) uses SHA512 internally for the key generation, which as I understand is something you'd like to avoid.

We could consider the following options regarding Ed25519 & SIlithium:
1. Edilithium-25519 with original EdDSA hash functions (use SHA512 internally)
2. Edilithium-25519 with modified hash functions (replace SHA512 by e.g. SHAKE128)
3. Silithium-44 with Curve25519 instead of P-256

I currently have a working implementation for option 1 and the three Silithium instanciations described in the I-D (with NIST curves).
Option 2 will be a bit less straightforward to implement, because we won't be able to rely on existing Ed25519 keygen functions.
I don't foresee any technical problem for option 3.

The Ed448 variant is less of a problem as it already uses SHAKE256 everywhere, but I assume we'll align with the Ed25519 one.

Let me know which option would be most suitable for your use-cases.

Kind regards,
Morgane Guerreau

[1] https://eprint.iacr.org/2025/2059.pdf