diff options
| -rw-r--r-- | talpid-tunnel-config-client/proto/ephemeralpeer.proto | 7 |
1 files changed, 4 insertions, 3 deletions
diff --git a/talpid-tunnel-config-client/proto/ephemeralpeer.proto b/talpid-tunnel-config-client/proto/ephemeralpeer.proto index 5ab45a7284..b60e8654e8 100644 --- a/talpid-tunnel-config-client/proto/ephemeralpeer.proto +++ b/talpid-tunnel-config-client/proto/ephemeralpeer.proto @@ -44,12 +44,13 @@ message EphemeralPeerRequestV1 { DaitaRequestV2 daita_v2 = 5; } -// The v1 request supports these three algorithms. +// The v1 request supports these four algorithms. // The algorithms can appear soletary or mixed. Kyber1024 and ML-KEM-1024 cannot be used in the // same request as they are just different versions of the same kem. // - "Classic-McEliece-460896f", but explicitly identified as "Classic-McEliece-460896f-round3" // - "Kyber1024", this is round3 of the Kyber KEM // - "ML-KEM-1024". This is the standardized version of ML-KEM (FIPS 203) at the highest strength +// - "HQC-256". This is the standardized version of HQC at the highest strength message PostQuantumRequestV1 { repeated KemPubkeyV1 kem_pubkeys = 1; } message KemPubkeyV1 { @@ -110,8 +111,8 @@ message EphemeralPeerResponseV1 { // the entropy in the PSK is uniformly distributed. The actual keys used for encrypting the // data channel will have uniformly distributed entropy anyway, thanks to the HKDF. // - // If we later want to support another type of KEM that produce longer or shorter output, - // we can hash that secret into a 32 byte hash before proceeding to the XOR step. + // KEMs that produce shared secrets of other lengths than 32 bytes, should hash the shared + // secret with sha256 to generate the 32 bytes used in the the XOR step. // // Mixing with XOR (A = B ^ C) is fine since nothing about A is revealed even if one of B or C // is known. Both B *and* C must be known to compute any bit in A. This means all involved |