franziskuskiefer / hpke-rs

Pure Rust implementation of HPKE (https://www.rfc-editor.org/rfc/rfc9180.html)

HPKE

An implementation of HPKE (RFC 9180) with flexible crypto backends.

From the RFC:

This scheme provides a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one which authenticates possession of a pre-shared key, and two optional ones which authenticate possession of a KEM private key.

Supported HPKE modes

• Base
• PSK
• Auth
• AuthPSK

Supported cipher suites

KEM

• DH KEM x25519
• DH KEM P256

AEAD

• AES GCM 128
• AES GCM 256
• ChaCha20 Poly1305
• Exporter only

KDF

• HKDF SHA-256
• HKDF SHA-384
• HKDF SHA-512

Crypto Backends

This crate does not implement the cryptographic primitives itself. Instead it expects an implementation of the HpkeCrypto trait.

hpke-rs's Issues

Test failures on GitHub macOS actions

See:

https://github.com/ctz/rustls/runs/2522332833

This unwrap is failing on GitHub's macOS CI, but not on my local Mac. The tests pass on Linux and Windows in CI.

https://github.com/grafica/rustls/blob/083073b14cbd2c838b4fcb00100252ed9ff7dbe4/rustls/src/ech_key.rs#L252

consider removing `Hpke`'s internal `RwLock`

hpke_rs::Hpke wraps its internal PRNG in a RwLock. I assume this to make its methods work with just access to a shared reference (&self) and to keep the type Send and Sync.

an alternative is to remove the internal RwLock and make Hpke's methods require a mutable reference. the end user then can wrap the whole Hpke object in a Arc<RwLock>, or Arc<Mutex>, or RefCell (if they don't need Send / Sync-ness) depending on their application requirements so it makes the API more flexible.

the internal RwLock prevents the crate from being no-std compatible so removing it clears the path towards no-std support

Typo in test_hpke_kat.rs

typo in test vector struct: "HpkeTestVecor"

Bump evercrypt to 0.0.4

Use `zeroize` for private key material

Add support for P-521

the KAT from test_vectors.json is failing for P-521 (for every configuration).
I implemented P-521 support (on swift) and the unit test (which is passing) with the following configuration (from the draft 08):
Mode: Base
DHKEM(P-521, HKDF-SHA512), HKDF-SHA512, AES-256-GCM.

Every other configuration is passing except the ones for P-521.

Any chance P-521 being implemented soon so you can validate this issue?

Add Support for P384 and P521

P384 and P521 are not supported by evercrypt yet. But it would be nice to support them here through some other implementation.

please make new crates.io releases

thanks for getting all those no-std-support PRs merged so quickly! could I further trouble you by asking for new releases of the hpke-rs, hpke-rs-crypto and hpke-rs-rust-crypto crates on crates.io?

Implement exporter only interface

See cfrg/draft-irtf-cfrg-hpke#193

Track cargo fuzz issue

cargo fuzz is broken with the latest rust nightly

rust-fuzz/cargo-fuzz#276

Add proper error handling

use x25519-dalek instead of -ng version?

the latest version of x25519-dalek-ng (v1.1.1) does not compile to a no-std target like thumbv7em-none-eabihf because it doesn't disable the default features of its rand dependency and that brings in a dependency on libstd due to its opt-out "std" feature. I can certainly send a fix for that but given that the repository / crate has not been updated / released since early 2021, it's possible that the fix never makes it into a release.

would it be possible to use x25519-dalek instead of the -ng one? the former has proper no-std support and seems to be more actively maintained.

`getrandom`'s "js" feature should not be enabled in libraries

getrandom's docs state:

This feature should only be enabled for binary, test, or benchmark crates. Library crates should generally not enable this feature, leaving such a decision to users of their library. Also, libraries should not introduce their own js features just to enable getrandom’s js feature.

currently the hpke-rs-crypto, hpke-rs-evercrypt and hpke-rs-rust-crypto libraries are enabling the "js" feature. if the feature is desired to, for example, run benchmarks on wasm32-unknown-unknown then the getrandom dependency should be moved under the dev-dependecies section so that only benchmark binaries see it.

Introduce version numbers

This would be helpful in general, but especially when introducing breaking API changes.

Bad comparison cause Kem Error.cryptoError for P256

File: dh_kem.rs
lines: 35~37
Code:

if dh.len() <= 32 {
    return Err(Error::CryptoError);
}

from Section 4. DH-Based KEM: P256 dh secret is 32 bytes long.

Handle randomness properly

We either relies on the crypto provider to generate randomness or uses rand::rngs::OsRng for generating randomness. The latter is cryptographically secure but not ideal because it taps into the OS entropy source directly, which might block or return bad entropy when queried too rapidly.

This issue tracks changes to how we handle randomness.

switched function parameters

in file dh_kem.rs, line 137 on function encaps I believe self.derive_key_pair is receiving the parameters in the wrong order.
Specifically:

(l.137) let (pk_e, sk_e) = self.derive_key_pair(&get_random_vec(self.get_secret_len()), suite_id);

function signature:

(l. 101) fn derive_key_pair(&self, suite_id: &[u8], ikm: &[u8]) -> (PublicKey, PrivateKey)

KemTrait's function signature (key.rs):

(l. 79) fn derive_key_pair(&self, suite_id: &[u8], ikm: &[u8]) -> (PublicKey, PrivateKey);

swapped formatter

I believe the formatter implementation is swapped in HPKEPrivateKey (lines 659 ~ 675)

#[cfg(feature = "hazmat")]
impl std::fmt::Debug for HPKEPrivateKey {
...
     .field("value", &"***")

...


#[cfg(not(feature = "hazmat"))]
impl std::fmt::Debug for HPKEPrivateKey {
...
   .field("value", &self.value)