[Cryptography] [FORGED] Re: "NSA could put undetectable “trapdoors” in millions of crypto keys"

Mike Hamburg mike at shiftleft.org
Thu Oct 13 14:52:11 EDT 2016


> On Oct 13, 2016, at 2:02 AM, Peter Gutmann <pgut001 at cs.auckland.ac.nz> wrote:
> 
> james hughes <hughejp at me.com> writes:
> 
>> 1) In the protocols, there is no way to blacklist known bad groups or even
>> reject duplicate groups (for some method of determining duplicate groups). No
>> way for the recipient to say “no” to the negotiated parameters other than
>> terminating the connection.
> 
> Right, but then on what basis would the client reject a parameter set?  You'd
> need some not-terribly-heavyweight non-spoofable test that you can apply to
> verify that what the server has sent you isn't booby-trapped, and then a means
> of negotiating the parameters that doesn't devolve into "no, you go first"
> between client and server.  That rapidly gets messy.
> 
>> 2) Another solution is to negotiate parameters. The g and p may be some non-
>> trivial combination of values from both sides, either one being random
>> meaning that the entire group is random…
> 
> You could in theory use the client and server random (which both SSH and TLS
> do) to generate the DH params, but that's an awful lot of CPU burned by both
> sides...
> 
> That's the killer really, how much CPU do you want to burn as a tradeoff for
> feeling a bit safer?  I'm working with systems that in some cases can barely
> do the DH exchange in a reasonable amount of time, so any kind of heavyweight
> checks are out of the question.
> 
> Peter.

You could send the params as a seed S where P = some agreed xof(S).  This at least limits the classes of weak Ps that can arise.  It would even save bandwidth.  But if you aren’t using pre-agreed parameters, you will have to check that P is prime.  This takes several times as long as DH itself.

— Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3693 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20161013/a8246f92/attachment.bin>


More information about the cryptography mailing list