[Lake] Re: Request for standardized lightweight quantum-resistant key exchange (on behalf LAKE WG)

赵运磊 <ylzhao@fudan.edu.cn> Fri, 18 September 2026 02:54 UTC

Received: from azure-sdnproxy.icoremail.net (azure-sdnproxy.icoremail.net [13.75.44.102]) by mx.ietf.org (Postfix) with ESMTP id 7D5EC31 for <lake@ietf.org>; Fri, 18 Sep 2026 02:54:29 +0000 (UTC)
Authentication-Results: mx.ietf.org; dkim=pass header.d=fudan.edu.cn header.s=dkim header.b="E3Oydrh/"; dmarc=pass (policy=quarantine) header.from=fudan.edu.cn; spf=pass (mx.ietf.org: domain of ylzhao@fudan.edu.cn designates 13.75.44.102 as permitted sender) smtp.mailfrom=ylzhao@fudan.edu.cn
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fudan.edu.cn; s=dkim; h=Received:Date:From:To:Cc:Subject: In-Reply-To:References:Content-Type:MIME-Version:Message-ID; bh=0dooujZrDNVQZt1+qCoxtM1+RZseLVreWZuwAkhiX5c=; b=E3Oydrh/g5pRU 87Zsrcqi+B+ISW0AenIUba9eA/MOOGvo6yNehbK/WAsJnvQh4P8H5SkWHhWzCYn4 pKm4KQEP7DtgqZSM4nuxrN++P+fqz/V2pGrF8jUoZNi0D7H4XeSUXnVJoYe1Kpic hpmP1IknyBAT04q5fYlsRxgcWHNI+A=
Received: from ylzhao$fudan.edu.cn ( [10.162.226.32] ) by ajax-webmail-web1 (Coremail) ; Fri, 18 Sep 2026 10:54:13 +0800 (GMT+08:00)
X-Originating-IP: [10.162.226.32]
Date: Fri, 18 Sep 2026 10:54:13 +0800
X-CM-HeaderCharset: UTF-8
From: 赵运磊 <ylzhao@fudan.edu.cn>
To: 赵运磊 <ylzhao=40fudan.edu.cn@dmarc.ietf.org>
X-Priority: 3
X-Mailer: Coremail Webmail Server Version 2025.3-cmXT6 build 20260604(1daa70ad) Copyright (c) 2002-2026 www.mailtech.cn fudan.edu.cn
In-Reply-To: <75322d2f.c774.1a0b1ccdb6d.Coremail.ylzhao@fudan.edu.cn>
References: <CAD2CPUGyFPq5Uq5rdb=zHcv_Su96vJXWv17maCVYMo4kRQoLKg@mail.gmail.com> <499787c.bae1.1a0ad771c20.Coremail.ylzhao@fudan.edu.cn> <AS4PR07MB8825751F246FCA596D025E4389B82@AS4PR07MB8825.eurprd07.prod.outlook.com> <2dd8d873.c035.1a0aec614c2.Coremail.ylzhao@fudan.edu.cn> <75322d2f.c774.1a0b1ccdb6d.Coremail.ylzhao@fudan.edu.cn>
X-CM-CTRLMSGS: =?B?SrVu6ziH6nJ5xwDR7hwMki1N8jM=
Content-Type: multipart/alternative; boundary="----=_Part_236786_1771388277.1789700053703"
MIME-Version: 1.0
Message-ID: <6efb2fe0.c5b7.1a0b26f9ac7.Coremail.ylzhao@fudan.edu.cn>
X-Coremail-Locale: zh_TW
X-CM-TRANSID: MwUFCgBHl0bVp6xq+u9QAA--.21535W
X-CM-SenderInfo: x1o2xtnr6i3vldqovvfxof0/1tbiBBIOB2qr2gFBHQAAsZ
X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU=
X-Spamd-Bar: /
Message-ID-Hash: OABQEHGWALTZKFHN5FYWNZMZ7FECQ5TK
X-Message-ID-Hash: OABQEHGWALTZKFHN5FYWNZMZ7FECQ5TK
X-MailFrom: ylzhao@fudan.edu.cn
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, lake <lake@ietf.org>, CFRG <cfrg@irtf.org>
X-Mailman-Version: 3.3.10
Precedence: list
Subject: [Lake] Re: Request for standardized lightweight quantum-resistant key exchange (on behalf LAKE WG)
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/eZ2o5jM2Q0xhkCDdINg_GQv4WMA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Owner: <mailto:lake-owner@ietf.org>
List-Post: <mailto:lake@ietf.org>
List-Subscribe: <mailto:lake-join@ietf.org>
List-Unsubscribe: <mailto:lake-leave@ietf.org>

Just notice that LAKE has four-message variant described in Section 6.3, where Initiator sends its public-key certificate in plain in the first message. In comparison, AFS-KEX does not need to send Initiator's public-key certificate in the first round, which is sent in the third round. 




Best regards

Yunlei 







-----原始郵件-----
發件人:赵运磊 <ylzhao=40fudan.edu.cn@dmarc.ietf.org>
發送時間:2026-09-18 07:56:27 (星期五)

收件人: 赵运磊 <ylzhao=40fudan.edu.cn@dmarc.ietf.org>
抄送: "John Mattsson" <john.mattsson=40ericsson.com@dmarc.ietf.org>, lake <lake@ietf.org>, CFRG <cfrg@irtf.org>
主題: [Lake] Re: Request for standardized lightweight quantum-resistant key exchange (on behalf LAKE WG)




Dear John Preuß:

Thanks again for kind reference. I made a study of draft-ietf-lake-authkem-edhoc-00, as well as the original RFC 9528, Ephemeral Diffie-Hellman Over COSE (EDHOC). I am actually not familiar with this area.

 

Before presenting my thoughts, I first quote some statements in RFC9528.

“Important    characteristics in constrained environments are the number of round trips and protocol message sizes, which (if kept low) can contribute to good performance by enabling transport over a small number of radio frames, reducing latency due to fragmentation, duty cycles,    etc.  Another important criterion is code size, which may be    prohibitively large for certain deployments due to device   capabilities or network load during firmware updates.”

 

“A typical setting is when one of the endpoints is constrained or in a constrained network and the other endpoint is a node on the Internet (such as a mobile phone). “

 

I think our AFS-KEX well suitable for lightweight KEM-based authentication and key exchange for EDHOC. It can be easily transformed into an LAKE protocol following the paradigm described in draft-ietf-lake-authkem-edhoc-00. I would make some brief comparisons between AFS-KEX based LAKE (referred to as LAKE-AFS) and the current KEM-based LAKE (referred to as LAKE-KEM). 

 

1.      LAKE-KEM is based on the traditional FSXY structure, exchanging three KEM ciphertexts with asymmetric computation. It suffers from the KCI-type attack: if the key encapsulated SS_I or SS_R is exposed, an attacker can impersonate Responder or Initiator respectively. This KCI-type attack is particular relevant for EDHOC, as it runs for constraint IoT devices. Note that SS_I or SS_R can be pre-computed and kept for relatively long period for online authentication efficiency, which may be beneficial for constrained IoT scenarios.

2.      LAKE-AFS runs in four rounds, while LAKE-KEM runs in five rounds.

3.      LAKE-AFS exchanges two KEM ciphertexts, while three KEM ciphertexts for LAKE-KEM. That means LAKE-AFS is both more compact and more efficient than AFS-KEM, which is desirable for constrained IoT devices.

4.      AFS-KEX enjoys computational symmetry, while AKE protocols of FSXY structure are not. Computational symmetry is particularly desirable for constrained IoT devices, as Initiator and Responder can use the same code/circuit and thus essentially reduce code/circuit size.

5.      AFS-KEX was indeed designed for identity hiding. Unlike ECDH where Initiator (Alice) and Responder (Bob) use the same group and generator, for ML-KEM Alice and Bot use independent public-key matrix generated from random seeds \rho_A and \rho_B respectively.  If \rho_A=\rho_B,then AFS-KEX already supports identity hiding. For identity hiding of AFS-KEX based IKE, only \rho_A and \rho_B need to be encrypted with the encryption key $EK$. Within the structure of LAKE-KEM, \rho_B can be encrypted in the second messages. Only \rho_A is sent in plain the first message. This is the only privacy disadvantage of LAKE-AFS, as far as I can see. All other security properties of LAKE-KEM are also held by LAKE-AFS, actually even stronger security satisfied by LAKE-AFS.

 

Please let me know if I have some misunderstandings.

 

Thanks!

Yunlei

 










-----原始郵件-----
發件人:赵运磊 <ylzhao=40fudan.edu.cn@dmarc.ietf.org>
發送時間:2026-09-17 17:50:12 (星期四)

收件人: "John Mattsson" <john.mattsson=40ericsson.com@dmarc.ietf.org>
抄送: 赵运磊 <ylzhao=40fudan.edu.cn@dmarc.ietf.org>, lake <lake@ietf.org>, CFRG <cfrg@irtf.org>
主題: [Lake] Re: Request for standardized lightweight quantum-resistant key exchange (on behalf LAKE WG)




Dear John Preuß:




Thanks for your kind messages and questions. Below, following your messages I provide some quick thoughts, and will provide detailed feedback soon.










-----原始郵件-----
發件人:"John Mattsson" <john.mattsson=40ericsson.com@dmarc.ietf.org>
發送時間:2026-09-17 16:00:01 (星期四)

收件人: 赵运磊 <ylzhao=40fudan.edu.cn@dmarc.ietf.org>, lake <lake@ietf.org>, CFRG <cfrg@irtf.org>
主題: [Lake] Re: Request for standardized lightweight quantum-resistant key exchange (on behalf LAKE WG)



Hi Yunlei,


Please don’t spam so many IETF lists.


LAKE WG has already discussed KEM-based authentication quite extensively for several years and has adopted the following draft.
https://datatracker.ietf.org/doc/draft-ietf-lake-authkem-edhoc/


Given this, it is somewhat surprising that LAKE is not mentioned in your paper. To my knowledge, it is currently the only active standardization effort of KEM-based authentication.


Sorry that I indeed didn't know the related drafts, and joined this mailing list not so far.  I will study the drafts and provide my feedback soon.


>a suggested solution is as follows: First, using ECDH to setup communication encryption key $EK$, due to the MTU limitation of the first two rounds of IKE. Then, using $EK$ to protect the first two rounds of AFS-KEX. Compared to using ML-KEM and MS-DSA, this could reduce about 80% communication bandwidth.


I don't think LAKE is interested in quantum-vulnerable ECDH, and LAKE is not IPsec. Moreover, setting up an encrypted channel and then performing KEM-based authentication is not a new idea.


Yes, using ECDH is tailored for post-quantum IKE, as its first round has MTU limitations. For LAKE, ECDH is really unnecessary and not recommended. 



Could you send an overview explaining whether any of the ideas in your paper could be used to improve the LAKE protocol, and in particular draft-ietf-lake-authkem-edhoc, without changing its underlying assumptions? It would be helpful to understand what is genuinely new and, importantly, what is actually applicable to LAKE.


My high-level understanding is that the main contribution of your paper is to achieve mutually authenticated key exchange with ML-KEM-based authentication using fewer flights, smaller messages, and less computation, by exploiting the additive structure of ML-KEM.


Besides above, AFS-KEX enjoys: (1) Computational symmetry, which is a desirable feature for LAKE as the same code/circuit can be used by both Initiator and Responder; (2) Stronger security against exposure of (pre-computable) states, and could be immune from KCI-type attacks as discussed in our paper.
A few questions:


* Does your approach preserve all the security properties of draft-ietf-lake-authkem-edhoc?
We will make a careful investigation, and provide feedback soon.



* Can it be implemented using a standard ML-KEM API, or does it require access to ML-KEM's internal algebraic structure?
Y
es, as far as I can see, AFS-KEX can be instantiated with the native ML-KEM without any change, and can be implemented with only ML-KEM API.



* Is the approach specific to ML-KEM, or can the same technique be applied to other KEMs?


AFS-KEX can also be instantiated  with HQC and ECDH, by exploiting addition or multiplication homomorphisms. But, as far as we know now, it cannot be instantiated directly with NTRU or MLWR-based KEMs.


* Are there any additional requirements or assumptions that must be satisfied before initiating the AKE?
No additional requirements or assumptions other than ML-KEM API and MLWE assumptions, as far as I can see.



Cheers,
John Preuß Mattsson


Thanks and best wishes
Yunlei


From: 赵运磊 <ylzhao=40fudan.edu.cn@dmarc.ietf.org>
Date: Thursday, 17 September 2026 at 05:46
To: Renzo Navas <renzoefra@gmail.com>
Cc: cfrg@irtf.org <cfrg@irtf.org>; lake <lake@ietf.org>; pqc@ietf.org <pqc@ietf.org>; cose <cose@ietf.org>; ace <Ace@ietf.org>
Subject: [Lake] Re: Request for standardized lightweight quantum-resistant key exchange (on behalf LAKE WG)


| |
Some people who received this message don't often get email from ylzhao=40fudan.edu.cn@dmarc.ietf.org. Learn why this is important
| |

Dear All:

I am Yunlei from Fudan university, Shanghai. I would draw your kind  attention on our recently published paper:Post-Quantum Internet Key Exchange via Authenticated Forward-Secure KEM (named AFS-KEX), which is available from: https://eprint.iacr.org/2026/1581




In this work, we present a novel AKE construction from KEM without using signature: more compact, more efficient,  more secure against state exposure. We hope this work is applicable to LAKE and post-quantum IKE. 




With a brief study, a suggested solution is as follows: First, using ECDH to setup communication encryption key $EK$, due to the MTU limitation of the first two rounds of IKE. Then, using $EK$ to protect the first two rounds of AFS-KEX. Compared to using ML-KEM and MS-DSA, this could reduce about 80% communication bandwidth.




Best regards

Yunlei 




-----原始郵件-----
發件人: "Renzo Navas" <renzoefra@gmail.com>
發送時間: 2026-09-13 17:52:46 (星期日)
收件人: cfrg@irtf.org
抄送: lake <lake@ietf.org>, pqc@ietf.org, cose <cose@ietf.org>, ace <Ace@ietf.org>
主題: [Lake] Request for standardized lightweight quantum-resistant key exchange (on behalf LAKE WG)




Dear CFRG,


The LAKE working group is chartered to work on a lightweight mutually authenticated key exchange protocol targeting constrained network environments such as NB-IoT, 6TiSCH, LoRaWAN, IEEE 802.15.4, and BLE. The base LAKE/EDHOC protocol (RFC 9528) is now being updated for the post-quantum setting [1].

In March 2026, the LAKE working group formed a post-quantum Design Team (DT) scoped to evaluate the constrained network scenarios where a quantum-resistant variant of LAKE is realistically deployable. DT identified that the resulting large message sizes due to current PQC algorithms are not well suited for the most constrained IoT environments [2]. At the same time, constrained IoT systems also need to migrate to post-quantum cryptography.

LAKE kindly requests CFRG to consider research and specification of lightweight quantum-resistant key exchange algorithms.


1. As shown in the analysis [2], a non-interactive key exchange (NIKE)-based approach to quantum-resistant LAKE could reduce the message size of a mutually authenticated AKE compared to KEM-based approaches, which is particularly beneficial for constrained IoT deployments. In particular, the specification of a lightweight NIKE, such as CTIDH and MIKE, would allow, for example, the deployment of quantum-resistant LAKE in network environments with Maximum Transmission Unit (MTU) of up to 127 bytes (classes S1/S2 [3]).

2. The specification of more optimized KEMs, such as lattice-based KEMs (e.g., BAT and DAWN) would also reduce the message sizes, making quantum-resistant LAKE more efficiently deployable in these constrained settings.

 

LAKE would be happy to provide further input on this topic and to evaluate candidate proposals from a performance point of view. 




Kind regards,




Renzo Navas on behalf of the LAKE WG




P.S.: I cross-post this to some WGs that might be interested in this information.

 

[1] https://datatracker.ietf.org/doc/draft-ietf-lake-pqsuites/

[2] https://datatracker.ietf.org/meeting/126/materials/slides-126-lake-08-pq-edhoc-dt-summary-ietf126presentation-00

[3] https://datatracker.ietf.org/doc/draft-ietf-iotops-7228bis/