add FromStr representations of kdf, kem, and aead #40
Conversation
jbr
force-pushed
the
from-str-implementations
branch
from
ab72e07
to
018fe22
Compare
src/kdf.rs
Outdated
| fn from_str(s: &str) -> Result<Self, Self::Err> { | ||
| match &*s.to_lowercase() { | ||
| #[cfg(feature = "kdf-sha256")] | ||
| "sha256" | "sha-256" => Ok(Self::Sha256), |
There was a problem hiding this comment.
We may want to include the "HKDF-" prefix in these identifiers for completeness and future-proofing. See RFC9180, Table 3.
There was a problem hiding this comment.
added a second commit (869c6d8) that handles hkdf-sha256 and HkdfSha256
There was a problem hiding this comment.
Should we require the prefix?
There was a problem hiding this comment.
I think accepting either is probably fine.
src/kem.rs
Outdated
| Ok(Self::DhP256HkdfSha256) | ||
| } | ||
| #[cfg(feature = "kem-x25519-hkdf-sha256")] | ||
| "x25519hkdfsha256" | "x25519-hkdf-sha256" | "dhkem(x25519, hkdf-sha256)" => { |
There was a problem hiding this comment.
nit: the shorter nicknames for this and the P-256-based KEM are inconsistent on whether they include "dh-"
There was a problem hiding this comment.
What's your suggested resolution to this?
There was a problem hiding this comment.
I'd recommend dropping "dh" from "dhp256hkdfsha256". (I think it would be unusual to abbreviate DHKEM to DH, and more natural to omit the DHKEM part altogether)
There was a problem hiding this comment.
I wonder if it's worth raising this with the backing crate as well. I just cargo-culted the naming from hpke::kem::DhP256HkdfSha256
There was a problem hiding this comment.
addressed in eab5053 — i also added versions that don't label the kdf, so p256-sha256 and x25519-sha256. let me know if that's somehow inaccurate or if there are other uses of sha256 as part of these kems other than hkdf
No description provided.