Overview

hpke-ng is a Rust implementation of Hybrid Public Key Encryption, the cryptographic scheme standardized in RFC 9180 that composes a Key Encapsulation Mechanism (KEM), a Key Derivation Function (KDF), and an Authenticated Encryption with Associated Data (AEAD) cipher into a single, modular construction for public-key encryption of arbitrary-length plaintexts. The design is crypto-agile, in the sense that protocol designers can swap primitives (e.g. X25519 → a post-quantum KEM) without rewriting the surrounding code — which makes HPKE the building block underneath modern protocols like Messaging Layer Security (MLS), TLS Encrypted Client Hello, and the post-quantum extensions to Signal’s X3DH.

hpke-ng was a joint project between Nadim Kobeissi and Daniel Dia (me!).

Below are the pull requests I have submitted, with links to the diffs and a short note on what each one changes.

Pull Requests

  • #3 (Merged)Refactor authenticated DHKEM paths to eliminate intermediate heap allocation.
  • #4 (Merged)Expand test coverage for auth KEM paths and context sequence number boundaries.
  • #6 (Merged)Expand test coverage: compile-fail invariants and nonce derivation correctness.
  • #7 (Merged)Expand comparative benchmarks to three-way hpke-ng vs hpke-rs vs rust-hpke suite.
  • #8 (Merged)Add rust-hpke X-Wing benchmarks (via v0.14.0-pre.2) and update README coverage.
  • #9 (Merged)Add rust-hpke to X25519 + ChaCha20-Poly1305 export benchmark.
  • #10 (Merged)Expand standalone bench suite to mirror comparative.rs and add rust-hpke memory footprint to README.
  • #13 (Merged)Lift mode bytes into the type system and stack-allocate the base nonce.
  • #14 (Merged)Lock compile-fail type-system invariants for mode tags and sealed supertrait.
  • #15 (Merged)Distinguish wrong-length IKM from rejection-sampling exhaustion in ML-KEM derive_key_pair.
  • #16 (Closed)Add MlKem768P256 (ML-KEM-768 + P-256) hybrid KEM.

← Back to Academia


Tags: