chrysn
commented
8 months ago As a side note, this is an implementation of the crypto traits that could easily go up to crates.io, contributing to the #98 effort in that users could then start using edhoc-rs from crates.io components alone (if they choose to go with the rustcyrpto backed).
Relatedly, I don't think that this will be the implementation to end it all -- embedded users may prefer to use something hardware accelerated, while std users may prefer the assurances that can eventually come with the hacspec ones. But it's useful on embedded as a bridgehead tool, as a reference implementation, and possibly when we come to the point of enabling varied algorithms (as all relevant ones are easily available in this style).
malishav
As it says on the tin -- this adds software based crypto backends. The added implementation is no_std itself, but using it with the out-of-thin-air constructor that the edhoc_crypto crate uses requires std (because it takes a random source from there).
There is one FIXME that I think warrants wider attention: When we get public keys passed in, who is responsible for checking that they are valid points on the curve? (So far I'm unwrapping here, which is perfectly OK if we place the responsibility in a different place, eg. in the application). This demarcation of responsibilities may well be expressed in the type system -- BytesP256ElemLen could state in its documentation that instances are always valid points (but it may make sense to use distinguished types here for "contains a public key" etc). Speaking of type system: This implementation would profit a lot if our HKDF extracts and private keys were not byte arrays but opaque types defined by the implementation. PSA will sooner or later make similar demands once people want to keep keys in a secure element. At any rate, I think those are for later.