(Please ignore the "Move crypto operations" commit, this is just based on #127).
In the high level API (edhoc.rs is left for later, turned out to work easily that way), passing the initiator by &mut is replaced by passing it by value, and receiving a new object with different APIs in return. This ensures at build time that functions are only called when suitable -- previously this would have the low-level implementation's checks at runtime. As a side effect, the Copy+Clone derives (that could easily be used to break EDHOC's security) could be removed, obsoleting #114 bit by bit.
In order to make this practical, the C API is removed; it may later be reintroduced using higher level abstractions.
Current state: So far this only alters the initiator, not the responder. It also doesn't change API too much. Seeing whether this breaks anything that I did not test; next steps (maybe right in this PR) is typestating the responder.
(Please ignore the "Move crypto operations" commit, this is just based on #127).
In the high level API (edhoc.rs is left for later, turned out to work easily that way), passing the initiator by &mut is replaced by passing it by value, and receiving a new object with different APIs in return. This ensures at build time that functions are only called when suitable -- previously this would have the low-level implementation's checks at runtime. As a side effect, the Copy+Clone derives (that could easily be used to break EDHOC's security) could be removed, obsoleting #114 bit by bit.
This picks up discussion from around https://github.com/openwsn-berkeley/edhoc-rs/issues/99#issuecomment-1748436544.
In order to make this practical, the C API is removed; it may later be reintroduced using higher level abstractions.
Current state: So far this only alters the initiator, not the responder. It also doesn't change API too much. Seeing whether this breaks anything that I did not test; next steps (maybe right in this PR) is typestating the responder.