
How to Backdoor Diffie-Hellman - baby
http://eprint.iacr.org/2016/644
======
gsmethells
So ... explain like I'm five. :) How can Diffie-Hellman, which has been taught
ad infinitum as a safe method for key exchange, be discussed like it has a
loophole?

~~~
tptacek
Whoah, hold on.

Diffie-Hellman implemented _very carefully_ can be a _one component_ of a
sound crypto protocol that does key exchange.

Both italicized phrases are important:

* It is extremely easy to implement textbook Diffie-Hellman in ways that are gravely insecure. In addition to domain-specific software implementation concerns that you must known about to safely implement number-theoretic crypto, you also have to carefully select parameters. It's parameter selection weaknesses David's paper takes advantage of.

* Diffie-Hellman by itself produces trivially breakable cryptosystems. DH is a building block. To build a safe protocol that uses DH, you need a higher-level construction --- usually, an authenticated key exchange. Check out the Noise protocol framework for more details on what this looks like. As you skim it, try to think about how relaxing or altering any of the constructions in an instantiation of Noise might produce a crypto vulnerability. This stuff is _hard_.

[http://noiseprotocol.org/noise.html](http://noiseprotocol.org/noise.html)

The basic idea of the paper is to explore the different species of [p,g] DH
parameter tuples you can come up with to produce a version of DH whose key
exchanges are cryptographically difficult for randos to break, but easy for
their authors to break. For instance, you can set p = pq for p and q sharing a
bad generator g.

A true cryptographic "NOBUS" DH backdoor is an interesting thing to have: you
can deploy it across the Internet and it will chug along executing key
exchanges that only you, as the author of the parameters for the backdoor, can
break.

~~~
fryguy
To be pedantic, I don't think the Diffie-Hellman is the weak link as it
doesn't specify the group or generator. It just requires that given g^a and
g^b it's hard to determine g^ab. And obviously if your generator is poor the
preconditions to the algorithm don't work. And then as what the post-
conditions for what DHKE provides. It just establishes a shared secret with
the person on the other end of a connection. You have no idea who that other
person is, but you can communicate securely with them (which is why you need
authenticated encryption).

I guess a better wording would be "It's extremely easy to implement textbook
Diffie-Hellman Key Exchange in was that don't satisfy the preconditions of
Diffie-Hellman, and this are gravely insecure."

~~~
sdevlin
Not specifying the group/generator _is_ a weak link, which is what David is
taking advantage of. Curve25519 is a good counterexample of a DH function that
leaves nothing to the imagination.

------
mankash666
The title is suggestive of a vulnerability in the DH key exchange protocol,
which is misleading. Plus the technique described can be used against many
crypto primitives that depend on trustworthy random number generators. Please
consider changing the title to something less click-baity

~~~
baby
Did you actually read the paper?

------
wslh
It can be interesting for some people here the research review we recently
published about ECDSA and ECIES for the secp256k1 elliptic curve (used in
Bitcoin and Ethereum): [http://blog.coinfabrik.com/ecdsa-security-in-bitcoin-
and-eth...](http://blog.coinfabrik.com/ecdsa-security-in-bitcoin-and-ethereum-
a-research-survey/) and [http://blog.coinfabrik.com/some-comments-on-the-
security-of-...](http://blog.coinfabrik.com/some-comments-on-the-security-of-
ecies-with-secp256k1/)

~~~
pbsd
Your survey refers twice, in page 8, to Mike Hamburg as Hamburger. Got a
chuckle out of me, but you should probably fix that.

~~~
wslh
Will correct it very soon! Thanks.

------
dboreham
>"constructions not using nothing-up-my-sleeve numbers"

is that the same as "constructions using something-up-my-sleeve numbers?"

~~~
daeken
Not necessarily. If you can show that you're using nothing-up-my-sleeve
numbers, everyone knows (that part of) your construction is safe. But if you
can't show that you're using them, it doesn't necessarily mean you've
backdoored it.

------
zappo2938
Diffie-Hellman explained to me like I'm 5 using colors. Public Key
Cryptography: Diffie-Hellman Key Exchange
([https://www.youtube.com/watch?v=3QnD2c4Xovk](https://www.youtube.com/watch?v=3QnD2c4Xovk))

------
rocqua
It is mentioned in the article that: "Note that the concept of “ephemeral” is
not defined the same by everyone: the default behavior of OpenSSL, up until
recent versions, has been to generate the ephemeral DH key at boot time and
cache it until reboot, unless specified not to do so."

However, there is no reference. Anyone got any sources cause I'd like to check
this out.

~~~
pbsd
[https://github.com/openssl/openssl/commit/ffaef3f1526ed87a46...](https://github.com/openssl/openssl/commit/ffaef3f1526ed87a46f82fa4924d5b08f2a2e631)

------
NobleSir
For someone whose almost exclusively studied cryptography in cyclic curve
groups rather than cyclic integer groups (coming from an algebraic geometry
background). Maybe someone can explain to me why the modulus isn't always
chosen to be prime for DH? Is there some reason you would ever want to allow
composite modulus in DH?

~~~
rocqua
As far as I know, using a composite modulus is bad. It means that some of the
integers (besides the obvious case of 0) no longer exhibit the group
properties. That said, it only makes it a bit more difficult to find a
generator. I am not sure about the overall security implications.

However, the plan here is too get someone to use your chosen modulus which is
weaker. I'd suppose they are banking on no one checking that the modulus
actually _is_ prime.

~~~
NobleSir
I see - I searched for a while and it seems (if I'm reading correctly) that
right in the RFC from 1999 it says to use / check prime-ness of the modulus:
[http://tools.ietf.org/html/rfc2631](http://tools.ietf.org/html/rfc2631) so
I'm still a bit confused - maybe the point is that it's commonly not done?

