cisco / go-hpke Goto Github PK

... for less verbose test code. See https://godoc.org/github.com/stretchr/testify/require.

Section 7.1.3 states that DH results MUST be rejected if they are the point at infinity. Currently (including the current PR), this check is only implemented for X25519. There should be a similar check for X448 and the NIST curves.

A suggestion for the P-curves: I actually don't explicitly check for the point at infinity in rust-hpke. Instead, I mandate that all private keys be in the range (0,p-1] (a pretty standard requirement), and that received pubkeys not be the point at infinity (already mandated by the spec). The combination of these two requirements means that sk * pk cannot be the point at infinity, since pk has order p and sk is not 0 mod p.

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

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.

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?