AEAD seq shouldn't be a uint64

[rozbb]

This is a small nit, but the seq field in the AEAD should not be fixed to 64 bits, as below

https://github.com/cisco/go-hpke/blob/0928fb5495e4ba9218aaff9619332beac0b64ed4/hpke.go#L192

Rather, it should a bytestring with size equal to that of the AEAD's nonce. XChaCha20, for example, has 24-byte nonces, which are not representable with any primitive integer type.

Open question: does the seq increment function have to be constant-time? I do not have a constant-time implementation right now.

[dmcardle]

We also opted to use uint64 in BoringSSL. It does feel a little wrong to diverge from the spec, but it's unlikely to matter in real life.

Let's say we have a 10 GHz CPU and each HPKE operation takes 1 clock cycle. That's 1e10 HPKE operations per second. (2**64 / 1e10) seconds ≈ 58 years before we hit the max uint64 value.

Maybe that's not an astronomically long time, but it's longer than we expect one HPKE context to live. I'm curious what others think.

[bifurcation]

I agree with @dmcardle here. As long as the nonce formation complies with the draft, it's OK if we don't support the whole space of nonces. And since we have checking for wrapping, we fail safe if we do exhaust the space we support.

[chris-wood]

Agreed. Closing.