[CFRG] Re: Taking X-Wing to Independent Stream

"D. J. Bernstein" <djb@cr.yp.to> Fri, 07 March 2025 11:06 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 2AB718C51EE for <cfrg@mail2.ietf.org>; Fri, 7 Mar 2025 03:06:37 -0800 (PST)
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_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_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 1hJ3ERdB7jiX for <cfrg@mail2.ietf.org>; Fri, 7 Mar 2025 03:06:35 -0800 (PST)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by mail2.ietf.org (Postfix) with SMTP id CAE118C51E9 for <cfrg@irtf.org>; Fri, 7 Mar 2025 03:06:35 -0800 (PST)
Received: (qmail 20509 invoked by uid 1010); 7 Mar 2025 11:06:35 -0000
Received: from unknown (unknown) by unknown with QMTP; 7 Mar 2025 11:06:35 -0000
Received: (qmail 148074 invoked by uid 1000); 7 Mar 2025 11:06:23 -0000
Date: Fri, 07 Mar 2025 11:06:23 -0000
Message-ID: <20250307110623.148072.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: <CAEEbLAYOyHKTpLzU4kRiBk+KtvxY9QonAWqT-qD47kMt-EAk-A@mail.gmail.com>
Message-ID-Hash: ZP3IG3F3GV4CBGDDFJ25H3HVLFB4AC4S
X-Message-ID-Hash: ZP3IG3F3GV4CBGDDFJ25H3HVLFB4AC4S
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; 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: Taking X-Wing to Independent Stream
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/ZoXJhgiX8dPEbEaDOHDpYiqEv0A>
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>

Sophie Schmieg writes:
> X-Wing has been well analyzed in academia [1], I don't think there are
> any concerns about the cryptographic correctness that would warrant
> further reviews here.

I have three basic security concerns regarding X-Wing. I don't think the
right way to address these concerns is "further reviews" (and I'm also
puzzled by the word "further"); I think X-Wing (and its descendants in
the hybrid-kems draft) should be eliminated in favor of Chempat.

1. The fact that there's a paper presenting a cryptosystem doesn't mean
the system is "well analyzed". Consider the fact that 33 of the 69
round-1 submissions in 2017 to NIST's competition have been publicly
broken (for details and links see https://cr.yp.to/papers.html#qrcsp)
often the breaks were years after the papers presenting the systems.

"Provably secure" constructions aren't some sort of magical exception to
the importance of review. See, e.g., https://eprint.iacr.org/2020/1578
efficiently breaking NTS-KEM's IND-CCA2 claim by exploiting a flaw in a
simple-sounding proof of security; the proof had appeared two years
before the flaw was pointed out. https://eprint.iacr.org/2019/1336
surveys many more "provable security" failures where proofs were wrong,
or were correct but made stronger assumptions than people realized, or
were correct but provided weaker conclusions than people realized.

X-Wing is a new proposal (https://eprint.iacr.org/2024/039) The
statement of X-Wing's "Theorem 1" includes the word "roughly" without a
definition, violating the mathematical requirement of clarity in theorem
statements; is labeled as being a ROM theorem; and relies on nonstandard
KEM hypotheses such as the hardness of "C2PRI". Even if the theorem can
be replaced by something clear and formally verified, where are the
papers probing the weaknesses in the new hypotheses and conclusions? For
example, looking for lower-cost attacks breaking "C2PRI" for Kyber, or
for lower-cost attacks breaking X-Wing's security claims?

2. NIST's explicit security target for KEMs was IND-CCA2, but the X-Wing
construction obviously needs to assume more than IND-CCA2 to provide the
security properties that X-Wing claims. The X-Wing paper claims merely
that it's safe _using Kyber_ (since Kyber supposedly provides "C2PRI"
etc.). Even if this turns out to survive review, what happens when
people plug in other KEMs?

Trying to address this with documentation (~"use this only for Kyber")
creates higher risks for the user than switching to a combiner that has
fewer sharp edges. The objective here shouldn't be blaming someone else;
the objective should be security.

There are many reasons that people have deployed other KEMs, including
the patent minefield surrounding Kyber, security concerns regarding
Kyber, security concerns regarding Kyber software, and performance
benefits of other options. The tendency of X-Wing to promote Kyber (via
blaming other KEMs for not being able to replace Kyber in X-Wing) seems
coupled to ignoring all of these issues, including the security issues.

3. It's a systemic security problem to be habitually overloading the
people who are reviewing the security of cryptographic constructions and
implementations. _One_ combiner is much less code than a KEM, and
whatever extra risks of screwups it brings are amply justified by the
reduction of damage if the KEM is broken---but this doesn't mean that we
should be casually rolling out more combiners. On the contrary, if we
tolerate a "wild west of hybrids" (to borrow a phrase from a recent
anti-hybrid panel) then we'll have much more hybrid code to worry about,
possibly even more hybrid code than code for all of the deployed KEMs.

It's safest to focus attention on _one_ combiner that works for a wide
range of KEMs and protocols. We already know how to do this: hash the
transcript. Complaints about the cost of hashing long public keys and
long ciphertexts (1) aren't responsive to the security concerns and (2)
are addressed by Chempat, which hashes each of those objects upon
receipt; hashing has negligible cost compared to communication.

I'm not saying Chempat is risk-free. It's worrisome that "Theorem 1" in
https://eprint.iacr.org/2018/024 resorts to the word "roughly", for
example, and that it's hard to find papers putting any real effort into
cryptanalysis. (Chempat needs Theorem 1 and Lemma 6 from that paper.)
But the X-Wing combiner has those risks _plus_ the risks that come from
asking the KEM to satisfy new security hypotheses. This makes review of
X-Wing by itself unnecessarily difficult, and unnecessarily fractures
the combiner ecosystem.

---D. J. Bernstein