Hacker News Reader

Comment by comex | Hacker News Reader

The introduction says that HPKE is different from the “traditional combination” of “encrypt the symmetric key with the public key”, but it doesn’t explain why it’s better. Does anyone know?

View on HN

For those kind of basic questions it is much better to start with the blog post than the RFC: https://blog.cloudflare.com/hybrid-public-key-encryption

I passed CompTIA Security+ but that wasn't enough to let me answer this question from the blog post. Is this sentence describing the traditional way?

> A key transport protocol is similar to a key exchange algorithm in that the sender, Alice, generates a random symmetric key and then encrypts it under the receiver’s public key. Upon successful decryption, both parties then share this secret key.

Isn't the following just describing how everyday PKE works?

> The general paradigm here is called "hybrid public-key encryption" because it combines a non-interactive key exchange based on public-key cryptography for establishing a shared secret, and a symmetric encryption scheme for the actual encryption.

It feels like the blog post is not principally concerned with explaining the benefits of HPKE, because everyone is already using it, but rather just proposing a standard for the many ways people are doing it.

The point is: if you are combining asymmetric and symmetric encryption primitives by hand, there are lots of different ways to do it, and it is easy to make the wrong choices and introduce security weaknesses as a result. So the idea is you should give developers a precooked solution that already does that. And that exists - e.g. in NaCl and libsodium, and BouncyCastle has some similar Java APIs. The problem is that different libraries do it in mutually incompatible ways. So the point of HPKE is to define a standard way of doing that which any library can implement, so if one end of the communication wants to use libsodium in C or C++ and the other end wants to use BouncyCastle in Java, it will just work (once the respective libraries implement HPKE, etc)

I don't think anyone has any illusions that WireGuard is going to adopt this. :)

WireGuard is something sufficiently high profile that if there is a weakness it is likely to be found.

The real benefit of this is the long tail of obscure applications whose weaknesses no one is looking at - until eventually, some bad actor does.

Does that certificate cover advanced cryptography?

No. No certificate does.

I know. :) So why would he think he'd be able to understand it just based on having that cert? That was my point...

I read the post, it doesn't answer the question other than there are too many existing standards/we don't like them, let's create another one https://xkcd.com/927/

Replacing working cryptographic standards is expected from an NSA front.

From the Cloudflare article:

> A paper by Martinez et al. provides a thorough and technical comparison of these different standards. The key points are that all these existing schemes have shortcomings. They either rely on outdated or not-commonly-used primitives such as RIPEMD and CMAC-AES, lack accommodations for moving to modern primitives (e.g., AEAD algorithms), lack proofs of IND-CCA2 security, or, importantly, fail to provide test vectors and interoperable implementations

For more thorough analysis of one of its novelties namely authenticated mode you can check this paper:

Analysing the HPKE Standard:

https://link.springer.com/chapter/10.1007/978-3-030-77870-5_...

It’s not actually much different. The main reason to use this is because it’s the standardized version of that concept and has been analyzed by people. All the smaller cryptographic detailed like domain separation, proper key derivation, weak key rejection etc. have been worked out for you. So it’s a plug and play solution that previously didn’t exist.

Was wondering the same. Some more motivation can be found in this[1] referenced article.

From what I can gather it seems to me this work tries to unify and generalize several existing hybrid public key encryption standards, which all apparently have various issues, mostly stemming from using outdated primitives and no extensibility.

So this work tries to introduce extesibility in a secure way, while also ensuring interoperability. The motivation seems to be able to use HPKE in IETF standards.

Another benefit over previous standards seems to be the addition of authenticated modes, where the sender authenticates itself to the recipient.

[1]: https://eprint.iacr.org/2020/243

HPKE has many modes but essentially you don't encrypt a symmetric key with a public key, you combine a public and a private key to derive a symmetric key instead. There's more to it like mixing in a secret or another key to authenticate the encryption implicitly at the same time (vs. explicitly using a signing key to e.g. sign a hash). Not a deep expert but in my understanding HPKE codifies existing approaches that are e.g. pioneered by Signal and others before them into an RFC so they become interoperable, which is also the goal with the MLS (message layer security) that is also relying on HPKE (but where efficient key agreement/rotation for groups of people is the main challenge in my understanding, so it focuses more on tree-based approaches for key derivation).

It's a formalization of one-way asymmetrically encrypted message delivery, rooted in the standard ECC technique of doing an EDH exchange on the sender side and sending the receiver enough information to replicate it, that has been generalized to support pre-shared keys (for instance, as a PQC stopgap), PQC algorithms like ML-KEM, and (presumably) RSA-KEM.

It's a subset of what Noise defines, standardized and further parameterized.

The point of the RFC is to level up (and make consistent) future cryptographic designs from the IETF. It's not something you'd use directly.

See "Hybrid encryption and the KEM/DEM paradigm":

https://neilmadden.blog/2021/01/22/hybrid-encryption-and-the...

tl;dr: resistance to padding attacks, better support for non-RSA cryptosystems

Reply on news.ycombinator.com