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

[John Mattsson <[e-mail]>]

One difference is that Mothma-Ed25519-ML-DSA-65 requires retaining SHA-2, whereas Silithium (which I assume can be used with edwards25519) can be implemented using only SHA-3. If people plan to use hybrids long-term, that is an advantage for Silithium.

I think both would be acceptable, for example in SSH. The main issue with both is that they are not standardized yet, while there is an urgent need to migrate long-lived authentication keys.

>For purposes of obtaining ECC+PQ SUF-CMA assuming PQ SUF-CMA---and in
>particular stopping the argument that one should retreat from ECC+PQ to
>solo PQ to achieve SUF-CMA---it suffices to follow the suggestion of
>
>    https://pqcrypto.eu.org/deliverables/d2.5.pdf#subsection.3.3
>
>to sign with ECC and then sign the message-signature pair with PQ.

I am not aware of any system moving from ECC+PQ to standalone PQ. Current migration paths are from standalone ECC/RSA to either standalone PQ or ECC+PQ hybrids.

I do not find that recommendation in your 2015 document. Section 3.3 appears to recommend both P + Q and P o Q constructions. While it also mentions Q o P, it states that these variants have the same basic security properties, with differences mainly in performance characteristics.

 "WP2’s recommendation is, rather than simply replacing a pre-quantum signature system P with a post-quantum signature Q, to replace P with P + Q."

 "Another recommended alternative that fits better with a signed-message interface (see Section 3.2) is to use P o Q: a P o Q signed message is the result of first using Q to sign the original message, and then using P to sign the Q-signed message."

 "There are many obvious variants involving signatures on hashes, signatures on randomized hashes, Q o P , etc., with slightly different performance properties but the same basic security property"

The first discussion I am aware of that Q o P preserves the SUF-CMA property of Q is:
https://mailarchive.ietf.org/arch/msg/pqc/She2XoyCWl9paHP8GvLUdciRGYE/

Cheers,
John Preuß Mattsson

From: D. J. Bernstein <[e-mail]>
Date: Thursday, 16 July 2026 at 07:12
To: [e-mail] <[e-mail]>
Subject: [CFRG] Re: Silithium - A Compact, Efficient and Non-separable Hybrid Signature

Mothma has the big advantage of using PQ signatures _and_ ECC signatures
as black boxes. Silithium uses the PQ signature as a black box but needs
new ECC-signing code. Is there a compensating advantage of Silithium? (I
don't find it plausible that 2452 bytes vs. 2484 bytes matters.)

For purposes of obtaining ECC+PQ SUF-CMA assuming PQ SUF-CMA---and in
particular stopping the argument that one should retreat from ECC+PQ to
solo PQ to achieve SUF-CMA---it suffices to follow the suggestion of

    https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpqcrypto.eu.org%2Fdeliverables%2Fd2.5.pdf%23subsection.3.3&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C9ff94596d72d40047e9308dee2f8c4aa%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639197755245854007%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ny1UrabORVGu3ZyeijA9uItA3ZqnjUyMN2U3Z%2FndptI%3D&reserved=0<https://pqcrypto.eu.org/deliverables/d2.5.pdf#subsection.3.3>

to sign with ECC and then sign the message-signature pair with PQ. This
also has a benefit far beyond protocols that need SUF-CMA: it simplifies
the use of signed-message APIs, which are safer than detached-signature
APIs. Mothma does this, plus randomization for more obscure properties.

The main argument I've noticed for unwrapping an ECC identification
protocol to insert a PQ signature is to aim for achieving ECC+PQ SUF-CMA
not just in the above scenario of the PQ part achieving SUF-CMA but also
in a further scenario, namely when the ECC part achieves SUF-CMA while
the PQ part fails to do so. But this is a smaller benefit that has to be
compared to the costs that the unwrapping imposes on implementors and
auditors. Anyway, my understanding is that Silithium doesn't aim for
this extra feature to begin with.

---D. J. Bernstein


===== NOTICES =====

IETF BCP 78, "Rights Contributors Provide to the IETF Trust", Section 5
(normative), "Rights in Contributions", provides a modification right
"unless explicitly disallowed in the notices contained in a Contribution
(in the form specified by the Legend Instructions)".

The official language from IETF's "Legend Instructions" for the
situation that "the Contributor does not wish to allow modifications nor
to allow publication as an RFC" is as follows: "This document may not be
modified, and derivative works of it may not be created, and it may not
be published except as an Internet-Draft."
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.ietf.org%2Fwp-content%2Fuploads%2FCorrected-TLP-5.0-legal-provsions.pdf&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C9ff94596d72d40047e9308dee2f8c4aa%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639197755245880488%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=SWxTIiejV6eCaRLPY%2FeNlebFBylNGHT1p43xjgzff5k%3D&reserved=0<https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf>>

The same language is used in, e.g., RFC 5831. The same language hereby
applies to this document. This is not disclaiming or limiting the
applicability of IETF policies; it is strictly following IETF policies.

IESG claims that the "explicitly disallowed" provision in BCP 78 is
limited to the examples in Section 3 in BCP 78. That is incorrect. BCP
78 states that Section 5, "Rights in Contributions", is normative, while
Section 3, "Exposition of Why These Procedures Are the Way They Are", is
informative. The opt-out provision in the normative text is clear, and
cannot be limited by an informative section. BCP 78 does not give IESG
any authority to issue changes or purported clarifications of the rules.

Rationale for exercising the BCP 78 opt-out provision: I'm fine with
redistribution of copies of this document. The issue is instead with
modification, such as (1) IESG's May 2025 posting of an IESG-mangled
version of an appeal that I had filed and (2) IETF management selling
IETF mailing-list text to AI companies. This goes far beyond what
copyright law allows as fair use (such as giving quotes for purposes of
commentary). When I complained about the mangled document, the IETF
Executive Director responded not by apologizing but instead by asserting
that IETF management had the power to do whatever it wanted.

_______________________________________________
CFRG mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]