Re: [Cfrg] Security proofs v DH backdoors

[Peter Gutmann <[e-mail]>]

Hanno Böck <[e-mail]> writes:

>Can you elaborate what brittleness you mean?

Uh, faults, as I said in my original message.  Any data corruption, bit-flips,
RNG faults, anything, and you end up leaking the private key.

>So your general idea here is that there are situations where people are
>constrained not to use ECC with another curve, but they *can* use DH with
>another parameter set?

They've been using DH forever, and will continue to do so.  They won't move to
an entirely new and/or extremely brittle algorithm class (and, in the case of
TLS 1.3/2.0, an entirely new protocol).

>Would it satisfy the needs of people if there simply was some kind of
>document (could be an RFC, but maybe also just an errata) saying that the DH
>parameters from 7919 may be used outside TLS? (not sure if this has to be
>explicitly stated, but if it helps people, why not?)

Uh, that's exactly the question I asked in my post...

I think it's more of a political than technical problem.  If you (meaning the
server) can generate your own parameters you're fine, if you're an industry
body you can mandate whatever it is you feel comfortable mandating, so it's
mostly a case of asking who would want/need standard parameter sets, and what
would it take to keep them happy about how they're generated?  Look at the
Brainpool curves for an example, one group of people regard them as perfectly
good NUMS values, another group regards them as having too much scope for
manipulation.  So it's a case of how far down the rabbit hole do you want to
go for generation?

Peter.