Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HPKE base mode support or ephemeral-static ECDH API #300

Closed
ctz opened this issue Dec 18, 2023 · 4 comments
Closed

HPKE base mode support or ephemeral-static ECDH API #300

ctz opened this issue Dec 18, 2023 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@ctz
Copy link
Contributor

ctz commented Dec 18, 2023

Problem:

Over in rustls, we'd like to implement Encrypted Client Hello. This uses HPKE "Base" mode. We've defined traits to generalise over this use, and would like to implement these traits on top of aws-lc-rs. HPKE is a pretty straightforward construction and I think the existing AEAD and HKDF APIs can be reused for this. Unfortunately the ECDH API cannot, because it only supports ephemeral-ephemeral key exchange -- the server key in ECH is static.

Solution:

I think there are two possible solutions:

  1. aws-lc-rs exposes HPKE base mode as a first-class API, and we use this directly.
  2. aws-lc-rs exposes an ephemeral-static ECDH API (and we do the glueing-together and known-answer testing in rustls.)

For reference these have issues/PRs in ring:

  1. Base Mode HPKE briansmith/ring#1462
  2. X25519 (and/or ECDH in general) with static keys briansmith/ring#331
@justsmth justsmth added the enhancement New feature or request label Dec 18, 2023
@justsmth justsmth self-assigned this Dec 19, 2023
@justsmth
Copy link
Contributor

justsmth commented Dec 19, 2023

Seeing as AWS-LC has API to support HPKE, we'll pursue "option 1" and provide a first-class API for HPKE.

@justsmth
Copy link
Contributor

A PR for "option 2" is here: #302

@justsmth
Copy link
Contributor

Hi @ctz -- as of aws-lc-rs v1.6.0 we support agreement with non-ephemeral keys. Does this resolve this issue for you?

@justsmth justsmth closed this as completed Feb 9, 2024
@cpu
Copy link
Contributor

cpu commented May 31, 2024

👋 Hi folks,

Just wanted to report back that we implemented HPKE in Rustls using the non-ephemeral key agreement support added in 1.6.0+ - thanks again!

In case it's interesting I also bumped into a challenge w.r.t the HKDF API: in short, the *ring* inspired API is fairly tightly coupled to the TLS 1.3 use-case in which the PRK extracted using the HKDF extract step can only be used directly for an expand (via the returned Prk's Prk::expand fn) - the extracted PRK is opaque/inaccessible to the caller.

In RFC 9180 there's one place (In Section 5.1, while computing the key_schedule_context) where one has to extract two PRKs, concatenate them along with the HPKE mode, and then use the produced concatenated value in a couple HKDF expands:

  psk_id_hash = LabeledExtract("", "psk_id_hash", psk_id)
  info_hash = LabeledExtract("", "info_hash", info)
  key_schedule_context = concat(mode, psk_id_hash, info_hash)
  <snipped>
  key = LabeledExpand(secret, "key", key_schedule_context, Nk)

The existing HKDF API doesn't allow access to extract PRKs for this purpose, and so we had to implement this using our in-crate HKDF-Using-HMAC algorithms instead of using the native AWS HKDF algorithms.

There's no change required from our end, I think we're happy with the arrangement we landed on. I just wanted to share this in case it was helpful for considering future API adjustments.

Thanks again for your support!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants