If you have access to an uncompromised signing key, you can fix a
compromised CSRNG generically without having to change the protocol. [1]
Best,
Dennis
[1] https://datatracker.ietf.org/doc/html/rfc8937
On 19/06/2023 16:41, Bas Westerbaan wrote:
I do have to add to Thom's remarks that KEMTLS (a.k.a. AuthKEM) offers
an advantage here. If the private key of the leaf cert is not
compromised (for instance when it was generated elsewhere), then the
attacker Stephan describes cannot learn the shared secret.
On Mon, Jun 19, 2023 at 5:02 PM Thom Wiggers <t...@thomwiggers.nl> wrote:
Hi all,
The attack that is described by Stephan is something that we
considered while we were initially designing KEMTLS (in the
papers, we also covered the ephemeral key exchange). I'll quickly
write what we were thinking of and why we did not choose to do
anything similar to what Stephan proposes.
I will be correcting for the misunderstanding in the document put
forward by Stephan, which suggests that Kyber is an asymmetric
encryption scheme. Encapsulation and Decapsulation should not be
confused with encryption and decryption, which are not part of the
public API of Kyber and will not be part of the NIST standard as
far as I'm aware.
I believe we can summarize the argument as follows: in the
straightforward replacement of ECDH by a KEM, the client generates
a keypair and the server (through the encapsulate operation)
computes a shared secret and a ciphertext. If either the secret
key or the shared secret are made public, for example, due to an
implementation flaw of either keygen or encapsulation, then the
ephemeral handshake key is no longer secret.
Bas correctly points out that this is not different from ECDH,
where compromise of one of the two exponents leads to shared
secret computation, but that in itself shouldn't necessarily be a
reason not to investigate if we can do better.
But, in my view, the proposed defense and the argument put forward
assumes that the flaw that affects encapsulation does not affect
the key generation (or vice versa); in particular, in the scenario
of the broken server-side random number generator it seems
far-fetched that the busted random number generator or
implementation flaw affecting encapsulation won't *also* affect
the keygen (or in other scenarios such as side-channel
vulnerabilities, decapsulate) operation of the server. This, in my
view, makes the additional security offered by the additional key
exchange very marginal.
The reason why we were investigating this issue was a bit
different: having two KEM key exchanges gives the server more
control to ensure that there will be at least one
freshly-generated KEM keypair in the mix. This could improve the
forward secrecy for handshakes (modeled via secret key exposure)
in which the client just re-uses the ephemeral keypair every
single time. But we also saw this as not significant enough to
suffer the additional, significant transmission requirement of
another full Kyber key exchange. Hopefully, we now have enough
experience with evaluating implementations of TLS to find and fix
these sorts of key-reuse flaws more easily, earlier, and in
automated ways [1]. And again, this is the same situation with
ECDH today.
Cheers,
Thom Wiggers
PQShield
[1] see e.g. https://github.com/tls-attacker/TLS-Scanner. Relying
on implementers not to make mistakes is a dangerous game, but I do
believe that it needs to factor into the cost/benefit analysis.
PS: for marketing reasons I oppose comparisons between the
post-quantum KEM schemes (which are primitives that easily can be
used in fully ephemeral ways) and RSA key wrapping (which pretty
much exclusively refers to the much-derided non-forward-secure RSA
transport in TLS-old). ;-)
Op ma 19 jun 2023 om 16:01 schreef Stephan Mueller
<smuel...@chronox.de>:
Am Montag, 19. Juni 2023, 15:56:57 CEST schrieb Scott Fluhrer
(sfluhrer):
Hi Scott,
> 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)
My concern is that the security strength cannot depend on the
pk, because the
PK is sent in clear over the wire. Thus it cannot contain
entropy. Thus,
entropy only comes from the message m in your listing which is
a random number
that is generated by the server. Further, c depends on m and
thus does not add
any entropy either.
Ciao
Stephan
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
