[Lake] Re: Question: PQ Variant of EDHOC-PSK

[John Mattsson <[e-mail]>]

Hi Clement,

You can already see the ECDH part of EDHOC with signature and PSK authentication as a KEM.

Instead of

G_XY = X25519( Y, G_X ) = X25519( X, G_Y )

You get

G_XY, G_Y = ENCAPS( G_X )
G_XY = DECAPS( X, G_Y )

ENCAPS( G_X ) {
  G_Y, Y = KEYGEN()
  RETURN X25519( Y, G_X ), G_Y
}

DECAPS( X, G_Y ) {
  RETURN X25519( X, G_Y )
}

This is already a compliant way to implement EDHOC-PSK using ECDH. Wrapping the X25519 function in ENCAPS and DECAPS functions seems to just limit the attack surface. Moreover, modern KEMs like ML-KEM provide significantly stronger security properties than the raw ECDH-based KEM above.

Cheers,
John Preuß Mattsson

From: Clement Papon <[e-mail]>
Date: Wednesday, 4 March 2026 at 14:29
To: John Mattsson <[e-mail]>
Cc: lake <[e-mail]>, cristina.onete <[e-mail]>
Subject: RE: Question: PQ Variant of EDHOC-PSK

You don't often get email from [e-mail]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

Dear John,



Thank you for your response!

Yes it does seem that it is the same idea. I have been reading several drafts on Post-Quantum EDHOC recently and likely mixed up a few of the different proposals — apologies for that.

I won’t be physically present in Shenzhen, but I will be presenting a draft remotely. Perhaps we could take the opportunity to discuss this further over a video call.



Regarding EDHOC-PSK, I have had some discussions with Elsa Lopez-Perez about formally verifying the security of the protocol. It could be interesting to extend this work to analyze the protocol when using a KEM, even if this would only provide security guarantees in the classical (non-post-quantum) model.



Best regards,



Clément Papon



________________________________
De: "John Mattsson" <[e-mail]>
À: "Clement Papon" <[e-mail]>, "undefined" <[e-mail]>
Cc: "cristina.onete" <[e-mail]>
Envoyé: mardi 3 mars 2026 17:41
Objet: Re: Question: PQ Variant of EDHOC-PSK

Hi Clement,


Great that you are interested in EDHOC and its post-quantum security!



I think what you describe is more or less exactly what is described in https://datatracker.ietf.org/doc/draft-spm-lake-pqsuites/



You can find all drafts related to LAKE here:

https://datatracker.ietf.org/wg/lake/documents/



And to answer your question, no, I don’t think there are any further considerations. If you use a modern ephemeral KEM like ML-KEM it is a drop-in replacement for ECDHE in EDHOC with signature and PSK authentication.



Will you be in Shenzen? if you are we should meet and discuss.



Cheers,

John Preuß Mattsson



From: Clement Papon <[e-mail]>
Date: Tuesday, 3 March 2026 at 17:22
To: [e-mail] <[e-mail]>
Cc: cristina.onete <[e-mail]>
Subject: [Lake] Question: PQ Variant of EDHOC-PSK


You don't often get email from [e-mail]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>


Hello,



I am a second-year Ph.D. student in cryptography at XLIM (Limoges, France), and I have recently worked on topics related to EDHOC and its security.



I am currently thinking about a post-quantum version of the EDHOC-PSK protocol and I am writing to you because I wanted to know if my approach is compatible with the current state of drafts from the LAKE working group.



In essence, the idea is to replace the ephemeral Diffie-Hellman elements in EDHOC-PSK with an ephemeral KEM, while keeping the rest of the protocol and key schedule unchanged, except for deriving PRK_2e from the KEM shared secret (see more details below).



Do you think my approach fits within the existing drafts, or would there be aspects that require further development?



Thank you in advance for your feedback and consideration.



Best regards,





Clément Papon



Detail of the proposal:



As a starting point, I consider the original EDHOC-PSK protocol and replace the ephemeral Diffie-Hellman key exchange by an ephemeral KEM. The idea is as follows:



The Initiator generates a KEM key pair and sends the public key in message_1 instead of g^x.

The Responder encapsulates using this public key, obtaining a shared secret and a ciphertext, and sends the ciphertext in message_2 instead of g^y.

The Initiator decapsulates and recovers the shared secret.



In the key derivation schedule, PRK_2e is derived from this shared secret instead of g^xy, and the transcript hash TH_2 computation, g^y is replaced by the ciphertext.



A schematic version is attached.