
Research on how to backdoor Diffie-Hellman - fanf2
https://github.com/mimoo/Diffie-Hellman_Backdoor
======
tptacek
This is a lot more interesting than I thought it would be from the title.

Obviously, anyone can trivially generate "backdoored" Diffie-Hellman
parameters; for instance, just use a bogus generator that locks the algorithm
into a tiny subgroup. No matter what private keys Alice or Bob generate, the
DH computation will be predictable.

This writer wants to do something cooler: generate NOBUS parameters, in the
fashion of Dual_EC DRBG, so that the parameter's authors can predict DH
computations but (without Significant effort) nobody else can.

Several of the methods the writer is playing with involve DH parameters for
which they can use Pohlig-Hellman to recover secrets. Pohlig-Hellman breaks DH
when its victims are unfortunate enough to be in a group with a smooth order
--- that is (I'm butchering this), when the group order factors into small
primes. It works by collecting samples from the target for each factor of the
group; each leaks a bit of the key modulo that factor. You knit the samples
together with CRT.

David wrote this up well here:
[https://www.cryptologie.net/article/196/pohlig-hellman-
algor...](https://www.cryptologie.net/article/196/pohlig-hellman-algorithm/)

Obligatory plug: a fun version of this attack is the kick-off problem on Sean
Devlin's very excellent Set 8 of the Cryptopals challenges. Set 8 isn't on the
website, but you can mail him (finding him is an exercise for the reader) to
get a copy (on the honor system, like the other challenges were before we
published). Set 8 builds this attack to an extremely useful attack on Elliptic
Curve Diffie-Hellman.

~~~
cperciva
_Several of the methods the writer is playing with involve DH parameters for
which they can use Pohlig-Hellman to recover secrets. Pohlig-Hellman breaks DH
when its victims are unfortunate enough to be in a group with a smooth order
--- that is (I 'm butchering this), when the group order factors into small
primes. It works by collecting samples from the target for each factor of the
group; each leaks a bit of the key modulo that factor. You knit the samples
together with CRT._

I'm not entirely sure how this gets you NOBUS parameters though. You can find
any small prime factors of the group order using ECM, so if you're relying on
those to let you run Pohlig-Hellman then everybody else can do it too.

(But in any case, you should be locking down your DH implementations to use a
fixed nothing-up-my-sleeve group, so even if this is a backdoor it would be a
backdoor with flashing neon lights around it.)

~~~
pbsd
The idea is to hide the factorization of the group order by using a composite
modulus, e.g., p = q . r, where q and r are kept secret. Now the order
(q-1)(r-1) is safely protected from ECM (though not from Pollard's p-1, if the
order is smooth enough). Better yet, make it p = q . r . s and make each of q,
r, and s be safe primes, using index calculus instead of Pohlig-Hellman to
find the logs quickly. Yes, I agree that this is as glaring a backdoor as it
gets.

For what it's worth, the author missed that interpreting the modulus bytes as
16-bit words in little-endian order does get us a prime, though still not a
safe one.

~~~
tptacek
I feel like maybe Colin is missing the point a little. Obviously it's a
terrible backdoor simply by dint of targeting conventional DH.

But it's a really fun exercise!

~~~
baby
> targeting conventional DH

this is targeting ephemeral diffie-hellman. So this would work on any
library/private product where you can "hey guys, we should start using
2048bits for DHE, let me suggest this one". This would not work on DH/RSA/...
because people usually generate their own parameters for these.

If this remark was pointed at the fact that ECDHE > DHE: I'm not taking the
point of view of an implementer trying to implement "new" crypto, I'm trying
to take the point of view of a backdoorer (?) trying to push this backdoor in
various products/libraries. And it seems like most still use DHE (some stats
are in the logjam paper, but I'll do some stats myself out of scans.io when I
get time)

------
yeukhon
I am always interested in knowing how cryptographers come up with these big
big big big numbers?

[https://github.com/mimoo/Diffie-
Hellman_Backdoor/blob/master...](https://github.com/mimoo/Diffie-
Hellman_Backdoor/blob/master/attack/1024_backdoored_params)

They appear to be mysterious, magic numbers in every single crypto
implementation. And many are written in byte form. I mean how can people
comprehend them?

~~~
tptacek
People generate large primes using programs designed to do that, and maybe
generators/primitive roots for those primes using a CAS like Sage or
Octave/Matlab. The same goes for ECC crypto, with a lot of extra
testing/filtering to find "nice" constants.

A lot of the other giant numbers you see in cryptosystems are random numbers
derived from other constants.

Sometimes there are things to learn by studying the numbers themselves. For
instance, the prime field in Curve25519 is a special prime with (bit-level)
characteristics that make it especially nice to do math on with general-
purpose computers. Other times, the numbers are, for instance, just giant
random primes, and aren't themselves very interesting.

~~~
yeukhon
I see. Thank you, tptacek.

> People generate large primes using programs designed to do that

Do you mind to name one such program?

~~~
tptacek
Well, anything that does RSA, right?

An easy way to do this yourself is to jump into a Ruby IRB and do
"OpenSSL::BN.generate_prime(512).to_s".

~~~
dunham
If I remember right, this generates a number that is probably prime. :)

~~~
Filligree
For values of "probably" that are effectively "certainly", yes.

------
egonschiele
"This repo contains some research I'm currently doing on how to bakdoor
Diffie-Hellman". Is this a working backdoor, or a work-in-progress?

~~~
noobie
It works.

[https://youtu.be/W8vBm6oXlEM](https://youtu.be/W8vBm6oXlEM)

