Add KEM combiner which is IND-CCA2 robust

[david415]

This KEM combiner is not IND-CCA secure: https://github.com/cloudflare/circl/blob/4da78653064e14884ee3bc3eba208268e1b0f843/kem/hybrid/hybrid.go#L259

According to this paper https://link.springer.com/chapter/10.1007/978-3-319-76578-5_7 the solution is a KEM combiner which uses a split key PRF function.

[bwesterb]

These hybrids were added for use in TLS 1.3, where simple concatenation is sufficient for IND-CCA2 robustness of the combined protocol (because the transcript hash mixes in the ciphertexts.)

Outside of TLS 1.3, such as with HPKE, the situation still isn't clear cut: it depends on which KEMs are combined. Both the current version of Kyber and DHKEM hash in the ciphertext, so the simple concatenation in hpke/hybridkem is still IND-CCA2 robust. (This is not the case for those in kem/hybrid when used on their own.)

Kyber will probably stop hashing in the ciphertext in the final version.

We should properly document this in the code.

What do you need for your application?

[david415]

The Katzenpost mix network project thus far has two uses for KEMs:

1. PQNoise https://github.com/katzenpost/katzenpost/blob/main/core/wire/session.go
2. KEM Sphinx https://github.com/katzenpost/katzenpost/blob/main/core/sphinx/kemsphinx.go

I'd guess that the Noise hash object might get us IND-CCA2 security like you mentioned with TLS. However for the Sphinx nested encrypted packet, it would require the KEM to be IND-CCA2.

Also... I recently wrote a NIKE to KEM adapter:

https://github.com/katzenpost/katzenpost/blob/use_new_ctidh_types/core/crypto/kem/adapter/kem.go

it could probably use some code review, if you like:

https://github.com/katzenpost/katzenpost/pull/253

[david415]

And here's how I add the split PRF KEM combiner: https://github.com/katzenpost/katzenpost/commit/9088d6b6e939b77d33b8a3aa4b433199fe12e37d

...which has not be code reviewed... but the unit tests pass ;-)

I guess I could make a pull request for circl to have this code if other developers were interested in using hybrid KEMs that are IND-CCA2 secure... which probably means that they would use these KEMs for a use case that does not include TLS or Noise.

[bwesterb]

...which has not be code reviewed

I don't think that's implemented correctly: it doesn't mix in the ciphertexts at all. Also, AES is not a PRF — it's a PRP.

I would simply go for H(ss1 || ss2 || ct1 || ct2), given all of them are fixed length, which is IND-CCA2 robust in QROM.

[david415]

Thanks for the correction!