Possible crypto backdoor in RFC-2631 Diffie-Hellman Key Agreement Method

Peter Gutmann pgut001 at cs.auckland.ac.nz
Sun Sep 6 00:56:07 PDT 2015


Georgi Guninski <guninski at guninski.com> writes:

>On Sat, Sep 05, 2015 at 11:45:07AM +0000, Peter Gutmann wrote:
>> The real question though is, why would anyone use parameters they didn't
>> generate themselves?  All DSA implementations I've seen (apart from some
>
>What about MITM in DH -- where do you get the keys from in this case?

Whose DH?  There are three major users of this on the public Internet, IPsec,
TLS, and SSH, all of which have the server provide the DH values.  MITM'ing
yourself isn't much of an achievement.

I haven't seen anything about this (so far) that doesn't class it as a purely
certificational weakness.  Consider the following equivalent of the flaw, but
for RSA:

  I stand up a TLS server and provision it with a cert where the server-auth
  key has exponent 1.

There is nothing in any spec that I can immediately think of that says that
you have to reject keys with e=1 (e.g. RFC 3447 just says it's "a positive
integer").  Most implementation were quite happy to accept e=1 keys until
maybe two years ago when there was some bad publicity about them which forced
vendors to fix the problem, but before that no-one bothered rejecting such
obviously invalid keys.  Use of e=1 keys was even a documented Windows
"feature" to allow plaintext key export while still being FIPS 140 compliant
[0].

This isn't any deliberately-inserted backdoor in the RFC, it's just sloppy
wording.  In any case though if I configure my server with a key I know to be
broken then any problems I encounter are my own fault.

The reductio ad absurdam form of this is that I stand up a TLS server which
serves the private key to anyone that connects to it (or puts it in the SSH
banner, or whatever).  OK, so I've proven that I can backdoor myself.  I can't
see how a third-party attacker can do anything though (for DH, RSA, or just
straight publish-the-key) unless I help them do it.

Peter.

[0] Where "FIPS" = "Farcical Information Processing Security".



More information about the cypherpunks mailing list