Hi Simon,
On 7/13/26 17:54, Simon Josefsson wrote:
John Mattsson <[email protected]> writes:
Redirecting to talk about entropy is unhelpful.
I don't think I mentioned entropy, but entropy is very useful. As
noted, m = H(m, independent entropy), where the entropy comes from any
source other than the attacker-controlled RNG, thwarts a much larger
class of attacks than m = H(m).
I don't think it is helpful to focus on Dual_EC_DRBG except as a
historical example. I think the discussion should focus on
attacker-controlled RNGs in general.
This is a good point -- and we could design a TLS-specific RNG
recommendation that recommends using a per-session randomness source as:
rng = SHAKE(OS-rng, session-specific-symmetric-key ||
full-transcript-of-session)
This over complicates the solution. Your design needs additional
analysis whereas simply restoring Kyber's hash requires effectively none
as it already had three rounds of NIST PQC review. The removal was
poorly motivated, and the modified requirements aren't going to be met
for many deployments.
It is easy to dismiss this class of problem by saying "go fix your PRNG"
but I believe that is naive and suggest people aren't familiar with the
history of compromised RNGs and what kind of attacks they enable.
I strongly agree with your perspective here.
This aspect isn't visible on the wire, so maybe IETF isn't the best
place to develop this in.
Part of the story here is that indeed, maybe the IETF isn't the best
place for this topic.
Cryptography isn't the only reasonable method to obtain security:
defense-in-depth is another strategy. It is one motivation behind
hybrid KEMs, which we fortunately have deployed for good reasons.
It is unfortunate that this `m` oracle issue can actually harm hybrid
constructions.
One way to mitigate this entire class of problems is to do covert
channel analysis. If your protocol enables a covert channel, it has a
problem. The IETF historically haven't worried a lot about covert
channels as a protocol vulnerability, but perhaps it is time to change.
I agree. I have a draft analysis if you are interested in discussing
this topic.
I believe TLS has some concerns in this area (e.g., the 32-byte
client/server 'random' fields), but ML-KEM increases the attack surface.
There are many but you're on the right track. My `dualec demo matrix
--view scenarios` tool has ~11 at the moment. Happy to discuss those
scenarios if that is of interest to you.
Kind regards,
Jacob Appelbaum
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
