HPKE

[panva]

Could Hybrid Public Key Encryption (HPKE) [RFC9180] API design be included? Single-Shot for sure, possibly Multi-Shot too?

[twiss]

I think @davidben and @beurdouche were potentially interested in sketching something up for HPKE?

I'd be happy to host that in this spec if it makes sense, especially if it ends up being transferred to the WICG. Or it could also live in a separate spec, of course.

[beurdouche]

Yes, I still think HPKE would be a good addition to webcrypto... : )

[davidben]

HPKE would be a fine addition to the web platform. However, it would not be a good addition to the current WebCrypto API. WebCrypto was designed around condensing everything into a jumble of verbs, which has mostly lead to a very error-prone and dangerous API. (For example, WebCrypto thinks that HKDF and ECDH are both "derive" operations, even though they mean completely different things.) The asynchronicity also does not make much sense for CPU-bound operations.

In addition to just being a bad design, it doesn't fit HPKE in the first place, where you setup a context object, which can then be used for multiple en/decryption operations or an exporter. If we're doing HPKE, we should just design it as a more natural JavaScript API, and set a better pattern for cryptography APIs in the web platform. (From there, I think we should go back and re-expose other cryptographic primitives under the safer API and just abandon the old one.)

[beurdouche]

(From there, I think we should go back and re-expose other cryptographic primitives under the safer API and just abandon the old one.)

As we discussed in the past, I agree with that.

[twiss]

I think everybody would agree that HPKE shouldn't be added to the existing crypto.subtle.* functions. But the WebCrypto API is the entire crypto namespace, and (at least to me) it would make sense to add HPKE under crypto.hpke, for example. Then it doesn't need to share any of the design or anything else with SubtleCrypto.

Also, I agree with your criticisms of Web Crypto, but I don't think we should conflate adding HPKE and overhauling SubtleCrypto. In particular, I think it would be unfortunate if we end up in a situation where certain algorithms are only available via HPKE but not under SubtleCrypto (or an equivalently low-level API), because that would mean developers might reach for HPKE where really they just need ChaCha20-Poly1305 (for example).

In other words, we might still want to overhaul SubtleCrypto but that should be an entirely orthogonal discussion, IMHO (and even that can still be done within the confines of the WebCrypto API, pedantically speaking).

[panva]

@twiss are the decapsulateKey/Bits and encapsulateKey/Bits capable of supporting HPKE?

[twiss]

They could potentially be used as a building block for an implementation in JS. But if we want to include a native implementation, I still think it'd be better to create a high-level API under crypto.hpke, something modeled after section 5 and/or 6 of RFC9180.

[panva]

Having it in subtle (either own apis or part of encap/decap) would make its integration with supports simpler. Unless it would have its own.

[twiss]

I think it'll need its own algorithm suite support detection mechanism. For sure encap/decap are not sufficient for an HPKE API, HPKE does a lot more than that.

Btw, https://github.com/dajiaji/hpke-js is a thing that exists, perhaps its API could serve as inspiration if we want to add a native API.

And, in the meantime I think it would be a good intermediary step to implement the algorithms required/used by HPKE (that haven't been already), such that the JS implementation can become leaner.