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

james hughes hughejp at me.com
Wed Oct 12 19:37:55 EDT 2016


> On Oct 11, 2016, at 8:36 PM, Peter Gutmann <pgut001 at cs.auckland.ac.nz> wrote:
> 
> james hughes <hughejp at me.com> writes:
> 
>> The problem is not the algorithm, it is the improper standardization of 
>> random parameters and the inflexibility of the protocols to allow these 
>> parameters to to be used as designed.
> 
> I'm not sure if it's really that bad.  IPsec has predefined groups,
> CMS / SMIME uses the X9.42/DSA format but then no-one uses DH in S/MIME
> anyway, SSH had predefined groups but switched to the server-specifies-the-
> group, but many use e.g. the RFC 3526 parameters which you can check for
> and fastpath, and TLS has the TLS-LTS draft which fixes the problem there.
> 
> So the problem areas are really SSH with unknown-provenance negotiated 
> parameters and TLS without TLS-LTS with the same thing.  However even there 
> the potential attack seems a bit unclear, someone would have to convince a 
> server operator to adopt booby-trapped parameters.  Sure, you may be able to 
> do that, but then you can probably also persuade them to install this little 
> server-side plugin that optimises performance or something, don't bother
> scanning it with your AV, it's perfectly legit.

Agree… Constant group: bad. unknown-provenance negotiated parameters: bad. 

I am guessing that there are 2 problems/solutions… 

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. 

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…


More information about the cryptography mailing list