IETF Logo Mail Archive

[TLS] Re: FW: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt

"D. J. Bernstein" <djb@cr.yp.to> Mon, 10 March 2025 13:26 UTC

Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 05ADD993F5F for <tls@mail2.ietf.org>; Mon, 10 Mar 2025 06:26:00 -0700 (PDT)
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 AwC3KVMgD0er for <tls@mail2.ietf.org>; Mon, 10 Mar 2025 06:25:59 -0700 (PDT)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by mail2.ietf.org (Postfix) with SMTP id 36B37993F55 for <tls@ietf.org>; Mon, 10 Mar 2025 06:25:59 -0700 (PDT)
Received: (qmail 10483 invoked by uid 1010); 10 Mar 2025 13:25:58 -0000
Received: from unknown (unknown) by unknown with QMTP; 10 Mar 2025 13:25:58 -0000
Received: (qmail 377121 invoked by uid 1000); 10 Mar 2025 13:25:47 -0000
Date: Mon, 10 Mar 2025 13:25:47 -0000
Message-ID: <20250310132547.377120.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: tls@ietf.org
Mail-Followup-To: tls@ietf.org
In-Reply-To: <LO2P123MB70510AFFBB46844E256C0A06BCD62@LO2P123MB7051.GBRP123.PROD.OUTLOOK.COM>
Message-ID-Hash: M5XLQBFYALTOMQ6RW7CV2JXHAA2TLU2V
X-Message-ID-Hash: M5XLQBFYALTOMQ6RW7CV2JXHAA2TLU2V
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-tls.ietf.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: [TLS] Re: FW: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/4fbPxgPZv9GLAAixXqMrj7PKqpQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

Peter C writes:
> In ML-KEM, Bob derives b deterministically from m and H(ek).
> If Bob tried to reuse b with a different public key, then the
> re-encryption check would fail during decapsulation.

That check doesn't affect processing of valid ciphertexts, so it often
won't be tested, so some implementations will get it wrong (even if they
aren't actively suppressing code that doesn't seem necessary), exactly
the same way that we keep finding code that fails to check signatures.

Again, I'm not saying any of this is safe. I'm just pointing out some of
the possibilities that can be triggered by (1) implementors pursuing
speed and (2) code having bugs.

---D. J. Bernstein

v2.29.0 | Report a Bug | By Email | System Status