2

Many tutorials about how to mitigate the Logjam recommend regenerating Diffie-Hellman moduli. This is a resource intensive operation, especially for high-bit groups.

This made me think if it made sense to build a small service offering moduli files for download, regenerated weekly or so. OpenSSH offers a way to check the safety of the generated primes with the -T option of the ssh-keygen util, so a user should be able to verify that the primes are safe. This takes significantly less time than generating a lot of candidates and and checking for safe primes in those.

Now my question is: is this procedure actually sufficient to verify that a foreign moduli file has not been "backdoored" somehow? Could an attacker put specially crafted values in there, enabling them to break the key exchange, without a user noticing?

Community
  • 1
tarleb
  • 1,200
  • 9
  • 22
  • 1
    Related question: 2014-04-19, [*What are the OpenSSL standard Diffie Hellmann parameters (primes)?*](https://security.stackexchange.com/questions/56214/what-are-the-openssl-standard-diffie-hellmann-parameters-primes) – StackzOfZtuff Jan 13 '16 at 10:22
  • Related question: 2011-07-13, [*Where do I get prime numbers for Diffie-Hellman? Can I use them twice?*](https://security.stackexchange.com/questions/5263/where-do-i-get-prime-numbers-for-diffie-hellman-can-i-use-them-twice) – StackzOfZtuff Jan 13 '16 at 10:26
  • Related question: 2013-08-27, [*Diffie-Hellman: choosing wrong generator “g” parameter and its implications of practical attacks*](https://crypto.stackexchange.com/questions/10025/diffie-hellman-choosing-wrong-generator-g-parameter-and-its-implications-of-p) – StackzOfZtuff Jan 13 '16 at 10:27

2 Answers2

1

Thanks to @StackzOfZtuff for the linked articles. Using those, this is what I've pieced together by now:

The generated parameters can probably be trusted as long as they are regenerated frequently. For a higher security, one would have to check for reused parameters, which could be a sign that something fishy is going on. It's still safer to generate parameters on ones own machine.

As the name suggests, safe primes work well when generating DH groups, as they guarantee a certain size of the resulting group. So deliberately bad primes, resulting in reduced group sizes, are not a problem with the scheme described in the question.

The one possible attack I see is that the generating entity could chose specific groups and precompute as much as possible to solve the discrete logarithm problem using the natural field sieve. This would make it a lot simpler for an attacker to break any DH using that group. Naturally, the precomputation step is computationally expensive, so the attacker would want to reuse any broken group as much as possible. This could be detected by keeping track of previous groups.

Instead of doing checks for recurring groups, just calculating one's own parameters is probably simpler. Using DH parameters generated by others, without any nothing-up-my-sleeves guarantees, requires some trust in the entity providing those new groups, regardless of whether the underlying primes are safe or not.

tarleb
  • 1,200
  • 9
  • 22
0

Apart from the risks that the groups DH parameters could potentially be manipulated, this also makes no sense if you evaluate the costs for an attacker.

If you assume that someone with a lot of computing power targets directly your service, hopefully you won't use any parameters you just downloaded somewhere.

If you fear a less specific targeting, like the NSA probably won't target you, but if it isn't too expensive to check your traffic, they might look just to make sure you are not a CommuTerrorist, then this would increase the risk. If you generate parameters only you use, they can only snoop your data. If you use parameters which 10000 people use because they automatically change them weekly, you just made breaking this parameters 10000 times more worthy for the attacker.

So if you assume x people use your weekly changed parameters, the incentive for someone to break them is about the same as breaking parameters only you use but change only each x weeks.

So simply use your own parameters and change them not weekly.

Josef
  • 5,933
  • 26
  • 34