This blog was written as a memo during the development of AnotherHPKE which is a Python implementation of HPKE.
These articles are worth reading.
In-depth blog by Benjamin Lipp
Introductory blog by Dr Franziskus Kiefer
Instead of a protocol, it's an encryption standard that combines the best of symmetric and asymmetric encryption. i.e. the speed of symmetric encryption and the convenience of asymmetric encryption.
The concept of HPKE is not new. Many past standards all have shortcomings and are non-interoperable.
A comparison of the standardized versions of ECIES by Martinez et al.
HPKE, which has been formally verified to be secure, provides a clean and modern choice among those old schemes.
Analysing the HPKE Standard by Joël Alwen et al.
I will explain in a bottom-top sequence.
And it's an over-simplified model. RFC is the most accurate explanation.
RFC 9180 Hybrid Public Key Encryption
To encrypt, you need to provide a key, a nonce, an optional associated data to be authenticated and the data to be encrypted.
To decrypt, you need to provide a key and encrypted data with optional authenticated associated data.
The core part is how to share a common key between sender and receiver securely. And don't forget to share nonce.
To share a key and a nonce between sender and receiver, the best way is using asymmetric encryption.
The naive idea is:
1. On each side, generate an ephemeral public key pair, and exchange the public part.
2. Remember the private key? Calculate a shared secret by using the other side's public key and the generated private key. And save this shared secret in a context instead.
3. In this context, the AEAD key and nonce are derived from the shared secret.
By doing so, each part only needs to operate on the context rather than bug pronr cryptography primitives.
If you go a bit further, you may wonder why using KDF to calculate instead of using DH result.
This is answered by Dr. Franziskus Kiefer who is one of the authors of HPKE.
In short: Using DH only is not provably IND-CCA secure using the Gap Diffie-Hellman assumption.
The usual mitigation is to use a key derivation function to compute the KEM shared secret.
And also there exists another reason: the final KEM shared secret is not "random enough" to be secure.(This is a vague expression)
For more detail, see this.
A Protocol Change Coming From Provable Security Analysis
Glad you to be here. Now from sender side, everything seems fine. But from receiver side, the identity of sender is hard to check.
To solve this issue, HPKE provides three plans: auth mode, PSK mode and auth PSK mode.
PSK mode sounds obsolete: since both sides share a symmetric key already, why bother yourself?
Because it allows to use of a PSK more securely, by mixing in fresh ephemeral keys each time. And, of course, authenticates both parts(both know the symmetric key).
Auth mode authenticates the sender's identity by adding sender's private key, along with the corresponding public key known to the receiver, into the calculation of the shared secret.
Instead of using the sender-provided private key and the receiver's public key directly, it concatenates the result of both.
So that it can provide forward secrecy when the sender's private key leaks.
When coding the PSK parts, I encountered the term "bytes of entropy". e.g.
DeriveKeyPair(ikm): Deterministic algorithm to derive a key pair (skX, pkX) from the byte string ikm, where ikm SHOULD have at least Nsk bytes of entropy (see Section 7.1.3 for discussion).
The PSK MUST have at least 32 bytes of entropy and SHOULD be of length Nh bytes or longer. See Section 9.5 for a more detailed discussion.
At first, I thought it was something to be calculated as "bits of entropy" / 8.
After 2hrs of search, I found this:
Require PSKs to have at least 32 bytes of entropy
This indicates this term refers to 32 bytes that are generated using strong secure CRNG.
You've reached the end of this page. And you may Go to index or visit my friends.
About me and contacts
Except where otherwise noted, this site is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License