Georgi Guninski <guninski@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".