Skip to content

Refactoring to support future methods#406

Open
ElsaLopez133 wants to merge 5 commits intolake-rs:mainfrom
ElsaLopez133:refactor-multi-method-support
Open

Refactoring to support future methods#406
ElsaLopez133 wants to merge 5 commits intolake-rs:mainfrom
ElsaLopez133:refactor-multi-method-support

Conversation

@ElsaLopez133
Copy link
Contributor

@ElsaLopez133 ElsaLopez133 commented Feb 23, 2026

Refactoring current code to add additional methods in the future (PSK)

  1. Added method-specific states (ProcessingM2StatStat, ProcessingM3StatStat), that diverge from PSK, to avoid using Option<> variables.
  2. Included method in some states to be able to match on it.
  3. Included helper functions to avoid Hax errors (DirectAndMut) (r_verify_message_3_statstat, i_verify_message_2_statsat)

@ElsaLopez133 ElsaLopez133 force-pushed the refactor-multi-method-support branch 2 times, most recently from 7204516 to af4dbe6 Compare February 23, 2026 11:51
@ElsaLopez133 ElsaLopez133 force-pushed the refactor-multi-method-support branch from af4dbe6 to 97097f9 Compare February 23, 2026 11:55
For each function we match on state and create method-specific
fiunctions. For example, we have r_prepare_message_2 and we
match based on emthod to either use t_prepare_message_2_statstat
or r_prepare_message_2_psk
@ElsaLopez133 ElsaLopez133 marked this pull request as ready for review February 23, 2026 15:53
Copy link
Contributor

@WilliamTakeshi WilliamTakeshi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything looks great to me.

Just a suggestion for the next PR (that you probably know). create a file for StatStat and one for PSK to organize it better the functions foo_statstat and foo_psk

Approved 🚀

lib/src/edhoc.rs Outdated

Ok((
WaitM3 {
method: state.method,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will always be StatStat I think

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will be in that function yes. For PSK it will use a diffrerent r_prepare_message_2_psk, and state.method will be then EDHOCMethod::PSK

lib/src/edhoc.rs Outdated
let state = ProcessedM2 {
// FIXME
// We need the method for next step. Since we are in the branch of StatStat,
// we can add EDHOCMethod::StatStat
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont think we need this FIXME, I think we MUST pass the method around for some messages.

@ElsaLopez133 ElsaLopez133 force-pushed the refactor-multi-method-support branch 2 times, most recently from 9976f2b to f54f4df Compare February 23, 2026 16:52
@ElsaLopez133 ElsaLopez133 force-pushed the refactor-multi-method-support branch from f54f4df to 69792a9 Compare February 23, 2026 17:01
Comment on lines 518 to 534
#[derive(Debug)]
pub enum ProcessingM2 {
StatStat(ProcessingM2StatStat), // PSK(PProcessingM2PSK) // To be added later
}
#[derive(Debug)]
#[repr(C)]
pub struct ProcessingM2 {
pub struct ProcessingM2StatStat {
pub mac_2: BytesMac2,
pub prk_2e: BytesHashLen,
pub th_2: BytesHashLen,
pub x: BytesP256ElemLen,
pub g_y: BytesP256ElemLen,
pub plaintext_2: BufferPlaintext2,
pub c_r: ConnId,
pub id_cred_r: IdCred,
pub ead_2: EadItems,
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes all the state of ProcessingM2 & co dependent on the method, rather than (as in the last call) just the parts that differ in other methods. Which of those fields are actually different in PSK?

I'd have expected something more like

#[derive(Debug)]
pub struct ProcessingM2 {
    pub method_specifics: ProcessingM2MethodSpecifics,
    pub prk_2e: BytesHashLen,
    pub th_2: BytesHashLen,
    pub x: BytesP256ElemLen,
    pub g_y: BytesP256ElemLen,
    pub plaintext_2: BufferPlaintext2,
    pub c_r: ConnId,
    pub ead_2: EadItems,
    
}
pub enum ProcessingM2MethodSpecifics {
    StatStat {
        pub mac_2: BytesMac2,
        pub id_cred_r: IdCred,
    },
    // PSK, -- is empty, but in other stages it might have fields that StatStat has not.
}

so that the 90% of the code that would be duplicated can still reach for the common items.

@ElsaLopez133 ElsaLopez133 force-pushed the refactor-multi-method-support branch 2 times, most recently from a18f9ce to a5de4f7 Compare February 24, 2026 08:55
We avoid repetition of shared-values among methods
This affects ProcessingM2 and ProcessingM3
@ElsaLopez133 ElsaLopez133 force-pushed the refactor-multi-method-support branch from a5de4f7 to 35820e5 Compare February 24, 2026 09:10
pub struct ProcessingM3 {
pub mac_3: BytesMac3,
pub method_specifics: ProcessingM3MethodSpecifics,
pub method: EDHOCMethod,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you don't need both method_specifics and method, since method_specifics already tell you which method you are in. Just match against method_specifics

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants