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

"D. J. Bernstein" <djb@cr.yp.to> Wed, 22 July 2026 16:02 UTC

Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
X-Original-To: cfrg@mail2.ietf.org
Delivered-To: cfrg@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id EBF2311C7DAFE for <cfrg@mail2.ietf.org>; Wed, 22 Jul 2026 09:02:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1784736169; bh=HNigrIDrxHB1RYYvlW/SDOE2MHapwCLlAMtWmPh33o8=; h=Date:From:To:Subject:In-Reply-To; b=W61G/hwtTngDa0Ee6kbF2htEAeF+aZXyXEDifsIaTDgsgLOCkApHp+1FIg6UHFQnV hpMti2M+C51cocNXnLWlfPqIPy8bQdNUU0IAAFgQQO13XSpDhRq1lbtpjP+Z7Gsgna 7Rb6la0tCzxgfUyXpaY00xlnqb/0BzomsYS0nCNM=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36rTULIFALcM for <cfrg@mail2.ietf.org>; Wed, 22 Jul 2026 09:02:49 -0700 (PDT)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by mail2.ietf.org (Postfix) with SMTP id DB36611C7DA6D for <cfrg@irtf.org>; Wed, 22 Jul 2026 09:02:22 -0700 (PDT)
Received: (qmail 2699257 invoked by uid 1010); 22 Jul 2026 16:02:22 -0000
Received: from unknown (unknown) by unknown with QMTP; 22 Jul 2026 16:02:22 -0000
Received: (qmail 1372589 invoked by uid 1000); 22 Jul 2026 16:02:10 -0000
Date: Wed, 22 Jul 2026 16:02:10 -0000
Message-ID: <20260722160210.1372587.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: cfrg@irtf.org
Mail-Followup-To: cfrg@irtf.org
In-Reply-To: <AS4PR07MB88256F0039FB5B01653464BC89C12@AS4PR07MB8825.eurprd07.prod.outlook.com>
Message-ID-Hash: PGVEDDFE2CEBPUEEBPB2LAPBWUDWQ5M4
X-Message-ID-Hash: PGVEDDFE2CEBPUEEBPB2LAPBWUDWQ5M4
X-MailFrom: djb-dsn2-1406711340.7506@cr.yp.to
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cfrg.irtf.org-0; header-match-cfrg.irtf.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [CFRG] Re: Silithium - A Compact, Efficient and Non-separable Hybrid Signature
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/1jIISDrVpuCLIlWS01CO0EIONkg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Owner: <mailto:cfrg-owner@irtf.org>
List-Post: <mailto:cfrg@irtf.org>
List-Subscribe: <mailto:cfrg-join@irtf.org>
List-Unsubscribe: <mailto:cfrg-leave@irtf.org>

Sorry, I really don't understand how to reconcile the following two
statements: (12 July 2026) "securing the randomness should be done by
the application and not the algorithm"; (22 July 2026) "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".

---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://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.