Integrating EDHOC-PSK as EDHOC_METHOD=4 by ElsaLopez133 · Pull Request #399 · lake-rs/lakers

ElsaLopez133 · 2026-01-30T09:54:58Z

This PR introduces an initial implementation of EDHOC-PSK (authentication method 4), following the specification on draft-ietf-lake-edhoc-psk-06.

The implementation is tested on the coap examples in examples/coap/

TODOs:

Python bindings
To run the coap examples under either stat-stat method or psk-psk method, it is necessary to manually change EDHOC_METHOD in shared/lib.rs, which is not ideal. Ideally, when checking if method == EDHOC_METHOD {...} in lib/edhoc.rs, pb fun r_process_message_1, it should check for supported methods.

malishav · 2026-01-30T10:01:48Z

Thanks for providing the PR! Could you go ahead and resolve the conflicts with the main? And feel free to ping us when you feel it's ready for review.

WilliamTakeshi

Thanks for the great work! I don't understand fully the PSK, so maybe some comments here are more me asking questions than providing review.

Also, can you remove old comments? I saw there there is lots of old experiments, older versions of functions as comments, it make a bit harder to read.

WilliamTakeshi · 2026-02-11T13:05:13Z

crypto/lakers-crypto-cryptocell310-sys/src/lib.rs

+    fn hkdf_extract_psk(&mut self, salt: &BytesHashLen, ikm: &BytesP256ElemLenPSK) -> BytesHashLen {
+        // TODO
+        // TODO generalize if salt is not provided
+        let output = self.hmac_sha256(&mut ikm.clone()[..], *salt);


Just a small nit: you can write &mut ikm.clone() instead of &mut ikm.clone()[..], since the slice coercion happens automatically.
(just for you to know, don't worry about changing, its fine)

WilliamTakeshi · 2026-02-11T13:07:57Z

crypto/lakers-crypto-psa/src/lib.rs

+    fn hkdf_extract_psk(&mut self, salt: &BytesHashLen, ikm: &BytesP256ElemLenPSK) -> BytesHashLen {
+        // TODO
+        // TODO generalize if salt is not provided
+        let output = self.hmac_sha256(&mut ikm.clone()[..], salt);


Here we are creating extra allocation.

You can just self.hmac_sha256(ikm, salt);. you probably copied from the other example, but the requeriments for this hmac_sha256 are different, so no need to clone or deref

WilliamTakeshi · 2026-02-11T14:47:15Z

lib/src/lib.rs

 }

 impl<'a, Crypto: CryptoTrait> EdhocInitiatorWaitM4<Crypto> {
-    pub fn process_message_4(


here we changing from process_message_4 to parse_message_4 but still a couple places where we still use process_message_4. on examples-nrf52840 for example

WilliamTakeshi · 2026-02-11T14:49:17Z

shared/src/lib.rs

 pub const SUITES_LEN: usize = 9;
 pub const SUPPORTED_SUITES_LEN: usize = 1;
-pub const EDHOC_METHOD: u8 = 3u8; // stat-stat is the only supported method
+pub const EDHOC_METHOD: u8 = 3u8; // stat-stat: 3u8, psk:4u8


remove the unused consts

WilliamTakeshi · 2026-02-11T14:54:33Z

lib/src/edhoc.rs

+    };
    // compute ciphertext_2
-    let plaintext_2 = encode_plaintext_2(c_r, id_cred_r.as_encoded_value(), &mac_2, &ead_2)?;
+    let plaintext_2 = match state.method {


I dont know if its possible, but maybe try transform ProcessingM1::method to be the EDHOCMethod, then it clears lots of future .into() since we only check once in the start of the process. It will give us lots of compiletime guarantees

And the EDHOCError::UnsupportedMethod will happen way earlier in the process

WilliamTakeshi · 2026-02-11T14:56:29Z

shared/src/lib.rs

-#[derive(Debug)]
+#[derive(Debug, Clone)]
 pub struct ProcessingM1 {
+    pub method: u8,


could these u8 parameters be replaced with EDHOCMethod? Using the enum would provide stronger type guarantees and prevent invalid values at compile time.

Same for WaitM2, WaitM3, ProcessingM2, ....

WilliamTakeshi · 2026-02-11T15:17:59Z

shared/src/lib.rs

+        method: u8,
        plaintext_3: &BufferPlaintext3,
-    ) -> Result<(IdCred, BytesMac3, EadItems), EDHOCError> {
+    ) -> Result<(Option<IdCred>, Option<BytesMac3>, EadItems), EDHOCError> {


I’m not sure returning (Option<_>, Option<_>, EadItems) is the best direction.
This makes impossible states representable (e.g. Some(_), None). If method were an enum instead of a u8, the API could encode these invariants more safely and avoid those invalid combinations.

WilliamTakeshi · 2026-02-11T15:23:26Z

shared/src/lib.rs

 }

-#[derive(Debug)]
+#[derive(Clone, Debug)]


Since this represents a protocol state, deriving Clone may not be ideal. We want to model as a object that is meant to move forward, and not duplicated.

Also, this clone is unused. Maybe you added when you were debugging but not its safe to remove?

(same comment for all other states)

WilliamTakeshi · 2026-02-11T15:27:10Z

examples/coap/Cargo.toml

 defmt-or-log = { version = "0.2.1", default-features = false }
 log = { version = "0.4", optional = true }
 defmt = { version = "0.3", optional = true }
+hex = "0.4"


This crate is only used for println! some messages.

instead of
println!("message_2 : 0x{}", encode(message_2.as_slice()));
we can just
println!("message_2 : 0x{:02x?}", message_2);

and its almost the same, without the use of external crates

WilliamTakeshi · 2026-02-11T15:29:40Z

lib/src/lib.rs

+pub const X: [u8; 32] = hex!("09972DFEF1EAAB926EC96E8005FED29F70FFBF4E361C3A061A7ACDB5170C10E5");
+pub const G_X: [u8; 32] = hex!("7EC68102940602AAB548539BF42A35992D957249EB7F1888406D178A04C912DB");
+pub const Y: [u8; 32] = hex!("1E1C8F2DF1AA7110B39F33BA5EA8DCCF31411EB33D4F9A094CF65192D335A7A3");
+pub const G_Y: [u8; 32] = hex!("ED156A6243E0AFEC9EFBAABCE8429D5AD5E4E1C432F76A6EDE8F79247BB97D83");


unused consts, also hex_literal::hex is unused.

I think its safe we remove both and then we can remove the crate from lib/Cargo.toml :)

Remove EDHOC_METHOD ocnstant and replace with a TryFrom Impl of EDHOCMEthod enum

malishav

I went through the PR. It is not ready for merging. In terms of form, there are many leftovers, comments, unusual naming. Please fix those.

In terms of substance, we should discuss whether the integration of another protocol (i.e. PSK) makes sense to be done within the existing functions. If we continue adding other EDHOC methods like this, the code base will simply be unusable. I would propose a discussion with @chrysn @WilliamTakeshi and myself on another way forward. Similarly how we make the distinction on initiator and responder-specific functions, e.g. r_parse_message_3, etc, we should introduce dedicated functions for the PSK method, e.g. method_4_decode_plaintext_2, reusing the auxiliary functions to the extent possible. I am happy to hear other opinions on the best way forward.

malishav · 2026-02-18T09:58:35Z

crypto/lakers-crypto-cryptocell310-sys/src/lib.rs

        output
    }

+    fn hkdf_extract_psk(&mut self, salt: &BytesHashLen, ikm: &BytesP256ElemLenPSK) -> BytesHashLen {


we don't need a new function for this. we need to generalize hkdf_extract and use that. @WilliamTakeshi any proposal how to generalize hkdf_extract to support both uses? This eventually needs to converge with the embedded-call API.

malishav · 2026-02-18T09:59:51Z

crypto/lakers-crypto-psa/src/lib.rs

        output
    }

+    fn hkdf_extract_psk(&mut self, salt: &BytesHashLen, ikm: &BytesP256ElemLenPSK) -> BytesHashLen {


this should not exist, see comment above

malishav · 2026-02-18T10:00:28Z

crypto/lakers-crypto-rustcrypto/src/lib.rs

 use lakers_shared::{
-    BytesCcmIvLen, BytesCcmKeyLen, BytesHashLen, BytesP256ElemLen, Crypto as CryptoTrait,
-    EDHOCError, EDHOCSuite, EdhocBuffer, AES_CCM_TAG_LEN, MAX_SUITES_LEN,
+    BytesCcmIvLen, BytesCcmKeyLen, BytesHashLen, BytesP256ElemLen, BytesP256ElemLenPSK,


Rename BytesP256ElemLenPSK to something that actually makes sense for the PSK.

malishav · 2026-02-18T10:07:37Z

lib/src/lib.rs

-        self.cred_i = Some(cred_i);
+    pub fn set_identity(&mut self, i: Option<BytesP256ElemLen>, cred_i: Credential) {
+        self.i = i;
+        self.cred_i = Some(cred_i.clone());


why .clone()?

malishav · 2026-02-18T10:09:37Z

lib/src/lib.rs

-    pub fn set_identity(&mut self, i: BytesP256ElemLen, cred_i: Credential) {
-        self.i = Some(i);
-        self.cred_i = Some(cred_i);
+    pub fn set_identity(&mut self, i: Option<BytesP256ElemLen>, cred_i: Credential) {


Let's reverse the arguments in set_identity such that cred_i appears first, and i appears last.

malishav · 2026-02-18T10:42:59Z

shared/src/lib.rs

+        }
+        let _ = ciphertext_3a
+            .fill_with_slice(&message_slice[header_len..header_len + ciphertext_3a_len]);
+        // println!("ciphertext_3a: {:?}", ciphertext_3a);


remove commented

malishav · 2026-02-18T10:47:40Z

shared/src/lib.rs

-        let mut mac_2: BytesMac2 = [0x00; MAC_LENGTH_2];

        let mut decoder = CBORDecoder::new(plaintext_2.as_slice());
+        trace!("decoder:{:?}", decoder);


malishav · 2026-02-18T10:55:53Z

shared/src/lib.rs

-        mac_2[..].copy_from_slice(decoder.bytes_sized(MAC_LENGTH_2)?);
+        let (id_cred_r, mac_2) = match method {
+            EDHOCMethod::StatStat => {
+                let input = decoder.any_as_encoded()?;


can you keep the StatStat-related diff the same, i.e. so we know there are no changes to the implementation

malishav · 2026-02-18T10:59:54Z

shared/src/lib.rs

        }
    }

+    pub fn parse_message_3(


Could you comment on the need to introduce this function?

malishav · 2026-02-18T11:04:31Z

shared/src/lib.rs

+    Ok(id_cred)
+}
+
+fn decode_cbor_length(first_byte: u8) -> Result<(usize, usize), EDHOCError> {


don't we have a cbor decoder for this?

chrysn

I've only looked at the API changes so far, and there didn't get all the way through.

Apart from individual comments inline, please split this up a bit; this PR contains some huge commits that touch many places in the code. Those should be split up into workable portions. Sure, adding the method is something that can't really be split up, but ground work such as adding a method field to states can be reviewed and tested better in isolation than at the same time as when it is utilized.

As reworking a PR of that size is a tedious task, and incoming comments might mean that changes are needed anyway, as a first step I suggest you take components where a) you don't expect that they are controversial, and b) they make sense even with out PSK (such as setting the method enum top Copy, Clone and non_exhaustive) and c) the commit history rebases cleanly onto those changes into a dedicated PR.

chrysn · 2026-02-18T10:55:16Z

shared/src/cred.rs

 pub type BufferKid = EdhocBuffer<16>; // variable size, up to 16 bytes
 pub type BufferIdCred = EdhocBuffer<192>; // variable size, can contain either the contents of a BufferCred or a BufferKid
 pub type BytesKeyAES128 = [u8; 16];
+pub type BytesKeyKid = [u8; 4];


Key ID lengths will in general vary, especially for external PSKs. So maybe use an EdhocBuffer<4>?

chrysn · 2026-02-18T10:56:35Z

shared/src/cred_new.rs

It seems this file is not referenced anywhere.

chrysn · 2026-02-18T11:01:06Z

shared/src/crypto.rs

    fn hkdf_extract(&mut self, salt: &BytesHashLen, ikm: &BytesP256ElemLen) -> BytesHashLen;
-    fn aes_ccm_encrypt_tag_8<const N: usize>(
+    fn hkdf_extract_psk(&mut self, salt: &BytesHashLen, ikm: &BytesP256ElemLenPSK) -> BytesHashLen;
+    fn aes_ccm_decrypt_tag_8<const N: usize>(


The changes in sequence make this needlessly hard to review; why is that changed?

I tried to find out through history, but "Fixing th_4 and th_3 in PSK mode" is a way larger single commit than anything should be.

chrysn · 2026-02-18T11:04:53Z

shared/src/lib.rs

 pub const SUPPORTED_SUITES_LEN: usize = 1;
-pub const EDHOC_METHOD: u8 = 3u8; // stat-stat is the only supported method
 pub const P256_ELEM_LEN: usize = 32;
+pub const P256_ELEM_LEN_PSK: usize = 16;


What does that constant mean? (For P256_ELEM_LEN I can somehow figure it out, it's the number of bytes in a P256 scalar, but that logic doesn't take me anywhere here).

chrysn · 2026-02-18T11:05:56Z

shared/src/lib.rs

-#[derive(PartialEq, Debug)]
+#[derive(PartialEq, Debug, Copy, Clone)]
+#[repr(C)]
 pub enum EDHOCMethod {


This would be the perfect time to make this #[non_exhaustive].

chrysn · 2026-02-18T11:20:27Z

shared/src/lib.rs

+
+#[derive(Debug)]
+#[repr(C)]
+pub struct ProcessingM4 {


Adding ProcessingM4 and ProcessedM4 implies to me that there is any but the trivial processing necessary to go from WaitM4 to completed, but the current draft section 3.2 only allows for the credential to be chosen in message 3, so at the time the message 4 comes back, the EDHOC stack should already have all the information needed and not need to call out again to the application.

(I could be missing something, but then that should be in the commit message of the isolated change that adds those states, whereas it's now in a huge single commit).

malishav changed the title ~~Integrating EDHOC-PSK as EDHOC_METHOD=4u8~~ Integrating EDHOC-PSK as EDHOC_METHOD=4 Jan 30, 2026

ElsaLopez133 force-pushed the integrated branch 11 times, most recently from bfd7646 to cc487e1 Compare February 6, 2026 09:47

WilliamTakeshi reviewed Feb 11, 2026

View reviewed changes

ElsaLopez133 force-pushed the integrated branch 5 times, most recently from 61d4749 to ef3e502 Compare February 13, 2026 11:49

ElsaLopez133 and others added 11 commits February 17, 2026 15:08

Integrating PSK into StatStat

d72afa3

coap example for stat-stat

2e2e71e

Modifying EDHOC_METHOD

29f4997

Fixing CoAP examples

37ac664

Removing prints

4d2c923

Fix errors after rebase

3a409f0

Fixing th_4 and th_3 in PSK mode

2a2159e

Fix cargo check

9d19d66

FIXED: Check supported methods in r_process_message_1

2811245

Remove EDHOC_METHOD ocnstant and replace with a TryFrom Impl of EDHOCMEthod enum

Fixing hax

dea7189

mend

32a533b

ElsaLopez133 added 7 commits February 17, 2026 15:08

Changing method: u8 to EDHOCMethod

1d0af2f

Fixing lakers-python/ for new functions

65a7bce

mend

d9b6fbb

Fixing lakers-python/test

eb5f75a

Fixing lakers-c/

aa0703b

Fixing lakers-c/

baac020

Fixinf external_aad for psk and test vectors

70ba372

ElsaLopez133 force-pushed the integrated branch from e6f1030 to 70ba372 Compare February 17, 2026 14:09

Fixing lakers-no-std

a2727d1

ElsaLopez133 force-pushed the integrated branch from 848a05a to a2727d1 Compare February 17, 2026 16:49

malishav requested changes Feb 18, 2026

View reviewed changes

chrysn requested changes Feb 18, 2026

View reviewed changes

chrysn mentioned this pull request Feb 18, 2026

Generalizing EDHOCMethod #403

Merged

Conversation

ElsaLopez133 commented Jan 30, 2026 • edited by malishav Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

malishav commented Jan 30, 2026

Uh oh!

WilliamTakeshi left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

malishav left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chrysn left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

ElsaLopez133 commented Jan 30, 2026 •

edited by malishav

Loading