search

twiss / webcrypto-modern-algos

Proposal for the addition of various modern algorithms to the Web Cryptography API, as well as feature detection for algorithm support
https://twiss.github.io/webcrypto-modern-algos/
3 stars 0 forks source link

HPKE #2

Open panva opened 2 months ago

panva commented 2 months ago

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

twiss commented 2 months ago

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 commented 2 months ago

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

davidben commented 2 months ago

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 commented 2 months ago

(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 commented 2 months ago

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).