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