Serialization logic for decryption context? about go-hpke HOT 3 CLOSED

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 for EncryptContext, 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?
  1. Defining serialization in this module
  2. 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;

from go-hpke.

I'd prefer (1) as well, and I'm happy to implement it as you describe. I'll start working on this today. Thanks!

from go-hpke.

Hey @bifurcation, #39 is ready for review.

from go-hpke.