Refactoring to support future methods#406
Conversation
7204516 to
af4dbe6
Compare
af4dbe6 to
97097f9
Compare
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
lib/src/edhoc.rs
Outdated
|
|
||
| Ok(( | ||
| WaitM3 { | ||
| method: state.method, |
There was a problem hiding this comment.
This will always be StatStat I think
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
I dont think we need this FIXME, I think we MUST pass the method around for some messages.
9976f2b to
f54f4df
Compare
f54f4df to
69792a9
Compare
| #[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, | ||
| } |
There was a problem hiding this comment.
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.
a18f9ce to
a5de4f7
Compare
We avoid repetition of shared-values among methods This affects ProcessingM2 and ProcessingM3
a5de4f7 to
35820e5
Compare
| pub struct ProcessingM3 { | ||
| pub mac_3: BytesMac3, | ||
| pub method_specifics: ProcessingM3MethodSpecifics, | ||
| pub method: EDHOCMethod, |
There was a problem hiding this comment.
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
Refactoring current code to add additional methods in the future (PSK)
methodin some states to be able to match on it.r_verify_message_3_statstat,i_verify_message_2_statsat)