Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Tuesday October 11 2016, @10:01PM   Printer-friendly
from the unless-you-trust-the-NSA dept.

Crypto Needs More Transparency, Researchers Warn

Researchers with at the French Institute for Research in Computer Science and Automation (INRIA) and the University of Pennsylvania have called for security standards-setters to publish the seeds for the prime numbers on which their standards rely.

The boffins also demonstrated again that 1,024-bit primes can no longer be considered secure, by publishing an attack using "special number field sieve" (SNFS) mathematics to show that an attacker could create a prime that looks secure, but isn't.

Since the research is bound to get conspiracists over-excited, it's worth noting: their paper doesn't claim that any of the cryptographic primes it mentions have been back-doored, only that they can no longer be considered secure.

"There are opaque, standardised 1024-bit and 2048-bit primes in wide use today that cannot be properly verified", the paper states.

Joshua Fried and Nadia Heninger (University of Pennsylvania) worked with Pierrick Gaudry and Emmanuel Thomé (INRIA at the University of Lorraine) on the paper, here.

They call for 2,048-bit keys to be based on "standardised primes" using published seeds, because too many crypto schemes don't provide any way to verify that the seeds aren't somehow back-doored.

NSA Could Put Undetectable "Trapdoors" in Millions of Crypto Keys

Researchers have devised a way to place undetectable backdoors in the cryptographic keys that protect websites, virtual private networks, and Internet servers. The feat allows hackers to passively decrypt hundreds of millions of encrypted communications as well as cryptographically impersonate key owners.

The technique is notable because it puts a backdoor—or in the parlance of cryptographers, a "trapdoor"—in 1,024-bit keys used in the Diffie-Hellman key exchange. Diffie-Hellman significantly raises the burden on eavesdroppers because it regularly changes the encryption key protecting an ongoing communication. Attackers who are aware of the trapdoor have everything they need to decrypt Diffie-Hellman-protected communications over extended periods of time, often measured in years. Knowledgeable attackers can also forge cryptographic signatures that are based on the widely used digital signature algorithm.

As with all public key encryption, the security of the Diffie-Hellman protocol is based on number-theoretic computations involving prime numbers so large that the problems are prohibitively hard for attackers to solve. The parties are able to conceal secrets within the results of these computations. A special prime devised by the researchers, however, contains certain invisible properties that make the secret parameters unusually susceptible to discovery. The researchers were able to break one of these weakened 1,024-bit primes in slightly more than two months using an academic computing cluster of 2,000 to 3,000 CPUs.


Original Submission #1Original Submission #2

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Informative) by stormwyrm on Wednesday October 12 2016, @03:09AM

    by stormwyrm (717) on Wednesday October 12 2016, @03:09AM (#413243) Journal

    There are fixed DH parameters out there that everyone uses but it is very much possible to generate your own. I use such self-generated Diffie-Hellman parameters for all of my OpenVPN installations. The following OpenSSL command suffices:

    openssl dhparam -out dh.pem 4096

    This will produce a random 4096-bit prime number p, setting the Galois field Zp to use and a generator g ∈ Zp for use with Diffie-Hellman key exchanges. Both the server and the client must have the dh.pem file. Generating new parameters is expensive though (the above command can take several minutes to complete even on a modern CPU) and as such it is not feasible to generate new sets of parameters for every new connection on the fly and negotiate them with the peer as part of the protocol. So it is necessary to have some standard parameters for general use that have been proven not to have trap doors. Based on the article it seems it is possible to create a field and generator that have properties that will make the discrete logarithm problem (the security of DH is based on the difficulty of solving this problem) easier to solve if one knows a secret property (trap door) in those parameters. I'd be even more wary of standard parameters based on elliptic curve fields which are seeing plenty of wide use these days. The mathematics of those is still murkier.

    --
    Numquam ponenda est pluralitas sine necessitate.
    Starting Score:    1  point
    Moderation   +2  
       Informative=2, Total=2
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 2) by NCommander on Friday October 14 2016, @06:11PM

    by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Friday October 14 2016, @06:11PM (#414393) Homepage Journal

    The latency actually is dependent on how much entropy is available (/dev/random). On a VPS with poor entropy, this process can take literal hours.

    --
    Still always moving