bifurcation
commented
4 years ago I think that's an OK idea. In addition to your use case, one could also envision an application wanting to keep long-lived contexts, and thus needing to write them to persistent storage. The idea of the isolation in the API is just to keep things private by default, so an explicit "export" operation doesn't seem to violate that constraint.
Couple of thoughts:
- Whatever you do for
DecryptContext, please also do forEncryptContext, just for symmetry. - In a similar vein, please have the serialized version specify whether it is for encryption or decryption
- Likewise, please implement deserialization as well as serialization.
- Have you thought of which of the following approaches you would use?
- Defining serialization in this module
- Providing calling code with a struct that it could then serialize
- On the one hand, I'm not crazy about (2) because it creates some ambiguity between the serializable struct and the real struct, and almost completely eliminates the barriers to accessing context internals.
- On the other hand, (1) forces us to make a decision about which serialization(s) to support, which isn't really the point of this library. If there were a standard serialization, (1) would be a no-brainer, but there isn't. Maybe we should define one?
Net of the above, I think my bid might be to do (1) with a TLS struct as the serialization. At least two consumers of HPKE (TLS/ECH and MLS) will already have TLS syntax encoding and decoding machinery. Something like this would be easy to do with https://github.com/cisco/go-tls-syntax:
enum {
encrypt(0),
decrypt(1),
(255)
} Direction;
struct {
Direction direction;
uint16 aead_id;
opaque key<0..255>;
opaque base_nonce<0..255>;
uint64 seq;
} HPKEContext;
cjpatton
Hi there,
I'm working on a prototype of the Encrypted ClientHello (ECH) extension for TLS and plan to use this implementation of HPKE. The deployment will outsource decryption operations to an RPC server: the RPC request will contain the payload of the ECH extension; and the RPC response will contain the decrypted inner CH. Alternatively, the RPC request might contain the encapsulated key only, and the response might contain the decryption context. This significantly reduces overhead, since the complete ciphertext and plaintext don't need to be transmitted.
I'd like to implement this alternative RPC, but the current implementation of HPKE doesn't support serialization of the decryption context. Would you consider a PR that adds support for this functionality?