I do not believe that Müller is correct - we do not intend use the Kyber CPA
public key encryption interface, but instead the Kyber CCA KEM interface. And,
with that interface, the server does contribute to the shared secret:
The shared secret that Kyber KEM (round 3) generates on success is:
KDF( G( m || H(pk)) || H(c) )
where:
- m is the hash of a value that the server selects
- pk is the public key selected by the client
- c is the server's keyshare
- H is SHA3-256, G is SHA3-512, KDF - SHAKE-256
Note that this formula includes a value (pk) that is selected solely by the
client; hence we cannot say that this value contains only values selected by
the server.
(reference: algorithms 8, 9 of the round 3 Kyber submission)
[Minor note: I believe that for the final FIPS version of Kyber, H(pk) will be
replaced by pk - this does not change this argument]
Now, our proposal is not specific to Kyber; it could be used with other key
exchange mechanisms that do not share this property. That property could be
introduced by using a stronger shared secret combiner (which, for example, may
include key shares from both sides into the key derivation function) - that was
suggested in Yokohoma and (I believe) is still under consideration by the
working group.
Müller also goes on to suggest a two round key exchange - I do not believe that
introducing such a change to the existing TLS protocol would be warranted.
> -----Original Message-----
> From: Stephan Müller <smuel...@chronox.de>
> Sent: Monday, June 19, 2023 4:24 AM
> To: TLS List <tls@ietf.org>; dsteb...@uwaterloo.ca; Scott Fluhrer (sfluhrer)
> <sfluh...@cisco.com>; shay.gue...@gmail.com
> Subject: CRYSTALS Kyber and TLS
>
> Hi,
>
> Post-quantum computing cryptographic algorithms are designed and
> available for use. Considering that the Kyber algorithm is going to be
> mandated by US authorities in the future as a complete replacement for
> asymmetric key exchange and agreement, a proposal integrating Kyber into
> TLS is specified with [1].
>
> This proposal, however, has one central shortcoming: only the TLS server
> contributes to the security strength of the shared secret generated by Kyber.
> This shortcoming can be solved with a slightly improved approach where the
> client and the server both independent of each other contribute to the
> security of the communication channel where the channel even retains its
> security when one side has insufficient entropy.
>
> The entire analysis and the suggested proposal to address the outlined issue
> is provided with [2]. I would like to share this proposal to contribute to the
> discussion how Kyber can be applied to TLS.
>
> [1] https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-06.txt
>
> [2] http://www.chronox.de/papers/TLS_and_Kyber_analysis.pdf
>
> Ciao
> Stephan
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
