How Is the NSA Breaking So Much Crypto? (freedom-to-tinker.com) 217
schwit1 writes: There have been rumors for years that the NSA can decrypt a significant fraction of encrypted Internet traffic. In 2012, James Bamford published an article quoting anonymous former NSA officials stating that the agency had achieved a "computing breakthrough" that gave them "the ability to crack current public encryption." The Snowden documents also hint at some extraordinary capabilities: they show that NSA has built extensive infrastructure to intercept and decrypt VPN traffic and suggest that the agency can decrypt at least some HTTPS and SSH connections on demand.
However, the documents do not explain how these breakthroughs work, and speculation about possible backdoors or broken algorithms has been rampant in the technical community. Yesterday at ACM CCS, one of the leading security research venues, we and twelve coauthors presented a paper that we think solves this technical mystery.
If a client and server are speaking Diffie-Hellman, they first need to agree on a large prime number with a particular form. There seemed to be no reason why everyone couldn't just use the same prime, and, in fact, many applications tend to use standardized or hard-coded primes. But there was a very important detail that got lost in translation between the mathematicians and the practitioners: an adversary can perform a single enormous computation to "crack" a particular prime, then easily break any individual connection that uses that prime.
However, the documents do not explain how these breakthroughs work, and speculation about possible backdoors or broken algorithms has been rampant in the technical community. Yesterday at ACM CCS, one of the leading security research venues, we and twelve coauthors presented a paper that we think solves this technical mystery.
If a client and server are speaking Diffie-Hellman, they first need to agree on a large prime number with a particular form. There seemed to be no reason why everyone couldn't just use the same prime, and, in fact, many applications tend to use standardized or hard-coded primes. But there was a very important detail that got lost in translation between the mathematicians and the practitioners: an adversary can perform a single enormous computation to "crack" a particular prime, then easily break any individual connection that uses that prime.
well, if i told you... (Score:3, Funny)
No one is surprised (Score:5, Insightful)
We've long past the point where we knew RSA, simple Diffie Hellman, Sha-1 and NIST curves need to go in the bin. This is one more nail in the coffin.
The standards I'm working in have gone Ed25519, Curve25519 ECDH, Shake128, AES, etc. 128 bits, sane curves, modern hashes. Rearranging the TLS deck chairs won't help.
Re:No one is surprised (Score:5, Informative)
If you use 2048 bit or 4096 bit RSA and you dont make mistakes in generating the key, RSA is still perfectly fine to use short of a quantum attack (even if the NSA had a classified supercomputer that was more powerful than all the supercomputers on the top 100 list combined filled with custom RSA-cracking ASICs they still can't crack high-strength RSA using any known mathematical formula)
I do agree that TLS needs replacing with a new protocol that only supports the strongest encryption (that means 256 bit AES, at least 2048 bit RSA, ECDH with perfect forward secrecy and SHA2/SHA3 for hashing) and has no mechanism to downgrade to any older protocols or to weaker encryption like MD5, SHA1, RC4 etc.
Re:No one is surprised (Score:5, Informative)
There's no need for a new protocol; TLS allows you to configure servers and clients to restrict the available ciphers. That's why the browser vendors have been able to push out MD5 (and moving on SHA-1), RC4, RSA 2048 bit, etc. No protocol changes were necessary; just remove ciphers from the supported list used to negotiate the connection.
BTW: research indicates that AES256 may in fact be slightly weaker than AES128, in some use cases. Both are still have no practical attacks, even for nation-state level attacks; at this time, there is no evidence that AES256 would be "more secure" in practical terms (i.e. billions of years to break one encrypted message) than AES128. Given that, there is no reason to replace AES128 with AES256, now or in the foreseeable future. Odds are that if some attack vector against AES is found, it will be time to move to a new algorithm, not just more bits/rounds.
Re: (Score:2)
A practical attack like trying to attack a web sever's session key would require that you generate at
Re: (Score:2)
crap, I wondered why I was getting so much odd traffic. Shouldn't have built my server to that spec.
Re: (Score:2)
The AES256 key schedule is not confidence inspiring. I won't be surprised if the attacks on it improve to the point where AES256 is actually worse that AES128, rather than theoretically.
AES256 is only theoretically worse because you can't brute force O(2^128) and you can't brute force O(2^112). So it's a wash.
The attacks on the key schedule are limited to certain uses. But it's a slippery slope.
Re: (Score:3)
Same problem remains. If you keep using the same initial paramter (large prime, elliptic curve, etc) then once that is cracked you have very easy access to what is derived from that parameter. The keys/secrets/whatever still need to be refreshed periodically. Ie, the hardcoded public key may be quite secure for awhile, but over several years it loses security. If the NSA really wants to break your system then they just need to break that one public key, maybe they put their best computers on it for a co
Re: (Score:2)
SHA1 does not need to go into the bin for all applications. For password-hashing it is still fine, if iterated and salted appropriately. Please stop spreading FUD.
Re: (Score:2)
Can you offer a reason to prefer it over a better algorithm with better properties that takes less compute power and has been subject to a rigorous standardization process? E.G. Shake128. I can't.
There are existing deployments by the millions. But wherever there is a choice for new deployments, going with the old thing is the behavior that has led us to where we are today with TLS.
Re: (Score:2)
Re: (Score:3)
That's like saying "IP sucks because it allows telnet!". TLS supports cipher negotiation; there is nothing that says you have to configure your server and/or browser to allow MD5, RC4, 1024-bit RSA, SHA-1, etc.; in fact, those are have been/are being deprecated by browser vendors (and have already been removed from most secure server configs).
Re: (Score:2)
Unfortunately, web sites haven't kept up. If you want to be able to communicate over TLS with the usual crop of web sites, dropping SHA-1 and RC4 is not an option.
It's grim out there in TLS land.
Re: (Score:2)
The recommendation to web site hosts to address the beast attack was to go back to RC4 because the browsers supported it and the servers supported it. The right thing would be to go forward to a decent mode like CCM or GCM, but that would require the browsers to support them and they don't universally support those modes.
E.G.
https://blogs.gnome.org/mcatan... [gnome.org]
https://community.qualys.com/b... [qualys.com]
Re: (Score:2)
Pretty silly comment since TLS is designed to give you control over what ciphers you allow in your implementation.
But it fails in practice because both ends have to agree on something and the required ciphers are determined by the worst best case algorithm out there on the interwebs. Software libraries react accordingly and support RC4, SHA-1, RSA1024 etc. and users have no clue how to select their ciphers.
The spec writers need to step up and define in the standard and protocols how old mechanisms don't just get deprecated, but how they actually go away.
Re: (Score:3)
The problem is that newer is not necessarily better. I don't trust NIST much at the moment thanks to the NSA plants in it, nor do I trust anything with the words "elliptic curve" in it (especially any with "magic" constants).
The old algorithms like RSA and DH are simple in concept, and have withstood the test of time algorithmically. Sure key lengths had to get longer due to Moore's law and some computational improvements, but no serious attacks are exist against them. It's unwise to ditch these methods any sooner than we have to.
I'm afraid in asymmetric signatures and Diffie Hellman, newer certainly is better.
The security of RSA is steadily being chipped away by improvements in index calculus. That is why RSA keys need to be so much longer than ECC keys.
The issue of magic constants is termed 'rigidity' by crypto nerds. I.E. Did the algorithm designer get to choose being multiple possible versions? Or did they have to follow a defined procedure to get to the values in the spec. Rigidity is one of the safecurves criteria and the only
tl;dr they cheated (Score:2)
Posted this a couple of years ago... (Score:5, Insightful)
When the NSA leaks happened, investigates this and promoted this as a possible attack vector.
NOTE - You can generate a new set of moduli like so:
# ssh-keygen -G moduli-2048.candidates -b 2048
# ssh-keygen -T moduli-2048 -f moduli-2048.candidates
Put the results in /etc/ssh/moduli
WARNING: This takes forever. Also, according to man ssh-keygen:
It is important that this file contains moduli of a range of bit lengths and that both ends of a connection share common moduli.
It's not possible to regenerate and share many moduli quickly - hence the reuse of moduli. SSH has support for x25519 algorithms - this definitely means I'll be moving away from pre-computed DH moduli also.
Re:Posted this a couple of years ago... (Score:5, Funny)
Ain't nobody got time for that!
No. It would take you forever. (Score:2)
When you have the ability to create your own money by entering into a computer you have the resources to do it relatively quickly.
Re: (Score:2)
Re:Posted this a couple of years ago... (Score:4, Insightful)
This is probably politically incorrect to say but, whatever you think of NSA .... I'm impressed with the fact that they've assembled a core staff of brilliant mathematicians who do amazing things ... whether you like those things or not.
Re: (Score:2)
Re: (Score:2)
The NSA has several different purposes. One is surveillance in the US, which they should not be doing. One is safeguarding US communications, which they sometimes do and sometimes don't. One is gathering intelligence from other countries, which they should be doing.
Re: (Score:3)
I'm disappointed that those brilliant minds would waste them violating the laws of their own country and attacking their own people. The money is probably good, but they could be using their talents to make us all safer.
Re: (Score:2)
TLS does not. All EC curves in TLS are proposed by NIST, and possibly backdoored. You probably don't want to use EC crypto with HTTPS.
http://slashdot.org/comments.p... [slashdot.org]
Scott Aaronson has an excellent summary (Score:5, Informative)
The necessary question. (Score:5, Insightful)
"...many applications tend to use standardized or hard-coded primes."
If the suggested theory of static primes holds true, during application design, what part of of the definition of random did we not quite understand?
Given the impact, this stands as the golden example of what not to do Ever again.
Re: (Score:2)
An issue is that random typically doesn't mean what it's taken to mean in plain language. True randomness is actually hard since you've got to have some mechanism chugging away spitting out numbers. Understanding how (pseudo) random is defined goes a long way to reducing the reducing the size of the haystack in your search for the needle.
Maybe they're not (Score:5, Insightful)
How Is the NSA Breaking So Much Crypto?
Maybe they're not. They're hardly going to tell you what they can't crack.
Re: (Score:3)
That they aren't nearly as vocal can be construed to mean it doesn't matter to them since they don't need the back doors.
Re: (Score:2)
In that case, the NSA don't ned to crack the crypto, they just need to crack the FBI.
Re: (Score:2)
Crack the FBI, it seems pretty much like both the NSA and CIA have shattered the FBI with purposefully planted agents as well as recruited FBI agents. If anyone needs to crack crypto it is the FBI and they need to crack both the CIA and NSA otherwise democracy in the US is likely to collapse under the corruptive weight of extortion schemes ("we will let you continue to commit crimes as long as you do these things for us").
Re:Maybe they're not (Score:5, Interesting)
Right but if you are really concerned about opsec you'd use two or more layers anyway.
Something like HTTPs or Tor will make your traffic opaque to most parties. They are common protocols that don't attract attention of anyone who isn't already watching you specifically. So they are good choice for an outer layer. We also think if the right cipher suites are selected they are mathematically sound / secure. They should not depend on an obscurity component, aside form the negotiated key that is part of their normal operation.
I might then make up an inner layer. Lots of attacks on the outer layer protocols tend to be downgrade attacks or attacks that cause selection of ciphers the attacker knows how to break. Just using another layer of TLS inside the tunnel might be a fine idea.
Finally a third layer of something with a PSK for the symetric cipher that is a little more obscure but not known to have any problems. obscure means of course not as well testing, perhaps on of the rejected candidate algorithms for AES or a modified version of something existed. This does not have to be mathematically as good its mainly their to frustrate someone with an undisclosed ability to beach the other layers. It will make their tools not work out of the box. If they have the ability to break the other layers chances are they can break this one as well but you will make them work for it. The third level analyst with the metasploit module will some need help! This is will buy you time.
Not quite the same. (Score:5, Insightful)
So, in short, they're not breaking crypto, they are breaking shitty implementations of crypto.
So basically, like using a one-time pad multiple times.
Well, I guess it's time to start sorting the wheat from the chaff and start ditching fixed-prime implementations wholesale.
Re: (Score:3)
What they are really saying is that rubber-on-the-road crypto (see, a car analogy) is very hard. So you're likely to be doing it wrong, whatever it is that you're doing.
Re: (Score:3)
So, in short, they're not breaking crypto, they are breaking shitty implementations of crypto.
No. They are estimating the cost of breaking standardized crypto and pointing out that it is within reach of state agencies.
There are standards that don't suffer these problems and other problems and yet still use pre-defined static primes.
Re: (Score:2)
It's very difficult to actually implement crypto unless you are a highly capable mathematician with a specialism in number theory. That's why the sensible thing is always to use libraries that have been vetted by people who know what they are doing.
What if... (Score:2)
they know what they're doing too well?
Alternatives? (Score:3)
While there are a few alternatives to RSA (though they share some mathematical similarity) i'm not aware of any non-quantum replacement for DH. That obviously makes it a natural candidate for any kind of focussed attack.
I honestly had no idea that most implementations fixed p. It seems obvious in retrospect that this could lead to the creation of a giant LUT
Re: (Score:2)
OLD news (Score:3)
This is the original logjam attack from May this year.
Even the PDF points to the same site:
https://weakdh.org/ [weakdh.org]
Re: (Score:2)
And still pretty much everyone reacted and fixed a whole bunch of things.
So in practice it doesn't really matter.
Anyway, it would have been great if the summary has mentioned it. :-)
Not the only vector (Score:2)
All of your chips and transmission devices also have direct backdoors.
Yes, all of them.
ex post facto (Score:2)
The NSA isn't "breaking crypto".
It was pre-broke for them.
Good thing actually (Score:2)
Re: (Score:2)
Well, for the more-BYOD-than-BYOD sector, what will happen is we'll install a new VPN that is not quite as crusty as our old one which always "just worked" and so never got budgeted for an upgrade, configure it for best practices security, and then weaken it when 10% the must-have clients turn out to be too crummy to deal and don't support installation of a 3rd party client, even if we could get front-row to shoulder the support burden involved in doing that (or doing an on-site CA and dealing with cert ins
The intern's been playing with the CSS again (Score:2)
Anybody else seeing the headline as:
???
Re: (Score:2)
Everyone except the monkey that broke it.
Of course they can decrypt HTTPS (Score:2)
They can MITM anyone they want and they almost certainly have the ability to mint any certificate they wish....
Re: (Score:2)
That's great for targeted interception, but you can't use it for large-scale surveillance. Try that and it won't be long before someone notices the suspicious mismatch of certificate hashes.
no shit (Score:2)
Cryptowall Solution? (Score:2)
I'm certain you've got codebreakers breaking codes. If you're able to do this, and you'd like to establish a shred of good will, would you kindly package it into simple-to-use applications that will allow users to decrypt files held ransom by Cryptowall? You'd be strengthening your image while simultaneously hurting the economy of the sketchy side of the internet.
Warm regards,
Voyager529
Re: (Score:2)
The sketchy side of the internet (in part) supplies them with the tools of their trade. Given all the other sh*t these agencies have been up to, I wouldn't be surprised to find out they were in charge of some ransomware so that they could fund other extra-curricular activities (via suitable layers of third parties, of course).
Another possible option (Score:4, Insightful)
Say you can crack it, even if you can't. Security researchers around the world will try to figure out how you did it, and in the end, show you what to do.
Sort of like Reagan-era Star Wars. Drove the Russians crazy (and broke) trying to replicate non-existent technology because they took our word for it, that we had done it.
Set weak standards (Score:2)
A "computing breakthrough" could just be in cheap storage, fast sorting that allows a collect it all ability after getting plain text.
Nothing much has really changed from the ideas of the 1950's. Set weak junk encryption, get the majority of users accepting a weak standard and then collect it all.
It worked for diplomatic hardware in the 1950-90's. J
1024 DH Keys Are Not Current (Score:2)
The journal article cited addresses Diffie-Hellman (DH) certificates with 1024 bits. For browsers, such certificates are being deprecated. Certification authorities are not supposed to issue intermediate certificates or sign subscriber certificates that have less than 2048 bits, and Mozilla reserves the right to require even larger certificates.
Furthermore, the OpenPGP format allows even larger DH parts of the DH/DSS encryption keys. My own DH/DSS key is 4096/1024. The 4096 is the size of the DH part.
Nothing has been learned (Score:5, Insightful)
In the hacking/spy drama movie Sneakers, there is a scene where Robert Redford's character is confronted with an office door protected by a keypad lock, which cannot be picked. But he needs to get into that office. The lock looks impenetrable. Surely the mission is about to fail.
So he asks his support team for help with the lock. What they tell him is never shown on screen, only Redford mumbling and agreeing to try it.
He takes a couple steps back and KICKS IN THE DOOR. The lock was completely irrelevant, in the end.
The lesson from that scene is extremely powerful when you understand the same lesson applies to ANY problem. When you are faced with a heavily secured door, or an encryption standard, the attack vector is often going to be something other than going through the face of the door or the front end of the encryption. What you'd do is KICK IN THE DOOR. And the TLAs know this and do exactly that. Their people have always kicked in doors while normal people look at the locks and shrug and walk away.
Re: (Score:2)
Don't forget they use social engineering in Sneakers as well, involving Mary McDonnell's character to get past the voiceprint lock of character actor Stephen Tobolosky's character Werner Brandes
"My name is Werner Brandes, my voice is my passport."
Prescient film, underrated in my opinion.
Re: (Score:2)
Prescient film, underrated in my opinion.
Too many secrets.
Re: (Score:2)
Their people have always kicked in doors while normal people look at the locks and shrug and walk away.
Lock are only there to remind honest people that they aren't supposed to be in there.
Re: (Score:2)
The lesson from that scene is extremely powerful when you understand the same lesson applies to ANY problem. When you are faced with a heavily secured door, or an encryption standard, the attack vector is often going to be something other than going through the face of the door or the front end of the encryption. What you'd do is KICK IN THE DOOR. And the TLAs know this and do exactly that. Their people have always kicked in doors while normal people look at the locks and shrug and walk away.
In this case the lock has performed its function: it prevented Redford from effecting a clandestine break-in. It is now obvious to the office owner when he returns that he has been burgled and he can take steps to minimize the damage that will result from it.
In the security business it is accepted that ultimately you cannot prevent a determined attacker from gaining access to a physical location. The best you can do is 1) delay him and 2) force him to leave evidence that he was there.
Re: (Score:2)
Welp, it was nice knowing you guys, I guess
Re: (Score:2)
Locks that are considered up-to-snuff, security-wise, have a tamper-proof CPU with integrated hardware crypto and a coil driver on a ceramic substrate, buried right next to the coil. The coil is wound in a couple of sections to prevent simple "poke and energize" schemes. The magnet wire is bonded directly to the circuitry on the substrate. The power to the locking mechanism is always there. All that's required to unlock the lock is a proper command, sent over a properly encrypted link. It's done for the sam
Covert? (Score:2)
It seems more like overt surveillance now.
SEATEC INDUSTRIES (Score:2)
Re: (Score:2)
Quantum-safe encryption? (Score:5, Interesting)
So it seems to me that every time an encryption-breaking article come up lots of people mention how such-and-such algorithms are (if implemented correctly) provably safe from non-quantum attacks. Considering though that quantum computers are probably somewhere just over the horizon, and the NSA etc. will almost certainly be among the first to get them, possibly years or decades before anyone else even knows they exist, that just doesn't seem very comforting. Especially if you're encrypting something that you would prefer to remain secure indefinitely, instead of just until the Q-codebreaker chews through the recorded backlog.
So my question is, are there any common encryption algorithms capable of withstanding attack by a quantum computer? And if not, why not?
Re: Quantum-safe encryption? (Score:2, Informative)
Yes, there are quantum computer resistant public key crypto algorithms. A quick Google search would have shown you that. Wikipedia has decent summaries of the state of the art, as well.
Re: (Score:2)
So my question is, are there any common encryption algorithms capable of withstanding attack by a quantum computer? And if not, why not?
"...most current symmetric cryptographic algorithms (symmetric ciphers and hash functions) are considered to be relatively secure from attacks by quantum computers."
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
Re: (Score:2)
There are no crypto systems which are provably safe from conventional attacks. It is conceivable that P=NP, and that reasonable algorithms will be found for NP-complete problems. I really doubt it, but nobody can prove otherwise.
Crypto systems are in NP, since given a potential key you can quickly confirm whether it's the correct key or not. It would be nice to prove a system NP-complete, but I haven't heard of one.
Re: (Score:2)
Long story shot. It has not been shown that it is even physically possible to have a quantum co
Re: (Score:2)
Re: (Score:2)
At least read your own references.
Re: (Score:2)
Re: (Score:3)
You are wrong. Precalculating the primes is not simple and it wouldn't help.
The authors of the paper are pre-calculating the number field sieve for the prime group. This allows them to efficiently compute discrete logs over the group.
Re:Um, this is news? (Score:5, Informative)
Apparently you have no clue how many ages of the universe it would take to enumerate the 256-bit primes.
We are nerds here, so lets calculate it. The number of primes less than N is approx ln(N) [wikipedia.org], so the number of primes less than 2^256 = (2^256/256) = 2^248 = 4.5e74. If you computed one prime per plank time, it would take this long: 4.5e77 * 5.4e-44 secs/planckTime / (1.38e10 years/universe * 3600 * 24 * 365) = 2.3e12, or about 2 trillion times the age of the universe. 512 bit primes would take considerably longer.
Once you calculate the list of primes, you need to figure out where to store it. Storing 4.5e74 numbers is problematic, since that is about a quintillion times the number of atoms in the sun.
We can be fairly certain that the NSA is not just relying on a lookup table.
Re:Um, this is news? (Score:5, Informative)
Here I was about to give you grief on your math ( ln ( 2^512 ) ~= 354 ), and then realized the problem was simply that you mis-typed the initial theorem.
For anyone else thrown off, the correct rule is that there's approximately N / log( N ) primes less than N.
Re:Um, this is news? (Score:5, Informative)
For anyone else thrown off, the correct rule is that there's approximately N / log( N ) primes less than N.
Sorry about that. But the math is still wrong. It is supposed to be ln (log base e) and I did the calculations with log2. So the number of primes less than 2^256 should be (2^256/177) = 6.5e74, not 4.5e74.
Re: (Score:2)
We'll let you off, as you got the important element entirely accurate and sufficiently precise:
512 bit primes would take considerably longer.
Re:Um, this is news? (Score:5, Funny)
Apparently you have no clue how many ages of the universe it would take to enumerate the 256-bit primes.
We are nerds here, so lets calculate it. The number of primes less than N is approx ln(N) [wikipedia.org], so the number of primes less than 2^256 = (2^256/256) = 2^248 = 4.5e74. If you computed one prime per plank time, it would take this long: 4.5e77 * 5.4e-44 secs/planckTime / (1.38e10 years/universe * 3600 * 24 * 365) = 2.3e12, or about 2 trillion times the age of the universe. 512 bit primes would take considerably longer.
Once you calculate the list of primes, you need to figure out where to store it. Storing 4.5e74 numbers is problematic, since that is about a quintillion times the number of atoms in the sun.
We can be fairly certain that the NSA is not just relying on a lookup table.
Yes but with Moor's law we'll beat that eventually, just as athletes running faster and faster will eventually exceed the speed of light. ;-)
Re: (Score:2)
Yes but with [b]Moor's law[/b] we'll beat that eventually, just as athletes running faster and faster will eventually exceed the speed of light. ;-)
Assume your best friend is telling the truth about your wife's infidelity without actually confronting her and hearing her side of the story?
Re: (Score:3)
Yes but with Moor's law we'll beat that eventually, just as athletes running faster and faster will eventually exceed the speed of light. ;-)
No, they will eventually slow down time itself, causing the people watching them to live forever even with their diet of chips and bud light, and lifestyle of a couch potato.
But by that time the American spectators will be so heavy that they form a black hole, meaning not even the athletes can get away.
Re:Logjam (Score:5, Informative)
How is this news? Sounds like they are just describing the logjam attack which was published earlier this year
They are estimating the computation effort to build a number field seive to efficiently compute logs over the 1024 bit prime groups in common use for plain old Diffie Hellman.
They recommend elliptic curves and not the NIST curves. From TFP:
"Transition to elliptic curves. Transitioning to elliptic
curve Diffie-Hellman (ECDH) key exchange with appropriate
parameters avoids all known feasible cryptanalytic
attacks. Current elliptic curve discrete log algorithms for
strong curves do not gain as much of an advantage from
precomputation. In addition, ECDH keys are shorter than
in “mod p” Diffie-Hellman, and shared-secret computations
are faster. Unfortunately, the most widely supported ECDH
parameters, those specified by NIST, are now viewed with
suspicion due to NSA influence on their design, despite no
known or suspected weaknesses. These curves are undergoing
scrutiny, and new curves, such as Curve25519, are
being standardized by the IRTF for use in Internet protocols.
We recommend transitioning to elliptic curves where
possible; this is the most effective long-term solution to the
vulnerabilities described in this paper."
Re: (Score:2)
ECDH in TLS only uses curves proposed by NIST. Some cryptographers believe that constants used to pre-compute the curves are in fact backdoored, which would explain how they decrypt most of the traffic. Curve 25519 and a few others are very likely safe, but not available in TLS1.2. ALL available ECDH curves in TLS were proposed by NIST.
I believ
Re: (Score:2)
You must've seen a pre-published description of Logjam, since this is the paper that first presented it. The second sentence even starts with, "First, we present Logjam [...]". So yeah...
Re:Breaking. lol. (Score:5, Funny)
Backdoors. thank you very much.
Nope. They mention that in the paper and then proceed to show how it can be done without them. But nice try.
The biggest surprise for me in the paper is the revelation that all major browsers would not accept a prime less than 512 bits with one exception- Safari. Safari was found to accept primes as small as 16 bits, essentially rendering it completely vulnerable to real-time attack by almost anybody.
IE, Firefox, and Chrome are already transitioning to support stronger mechanisms which would not be vulnerable. Time to take a hard look at your choice of browser, Apple fanboys.
Re: (Score:3)
Backdoors. thank you very much.
Nope. They mention that in the paper and then proceed to show how it can be done without them.
Just because it can be done without backdoors, doesn't mean the NSA isn't going the easy route. That the NSA is tapping large datacenters before encryption and has access to the private keys of major companies is known now. Schneier says: [schneier.com]
The new Snowden revelations are explosive. Basically, the NSA is able to decrypt most of the Internet. They're doing it primarily by cheating, not by mathematics.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Bullshit yes, 'tis what you spout. If any of those had found a way to break encryption as the NSA had, I would expect a paper on it much like this and a push to deprecate whatever was broken. Particularly given their businesses are built upon secure communications. Instead, the NSA breaks it and uses it to spy on everyone.
Re: (Score:2)
Worst office Christmas party ever.
Re: (Score:2)
Actually most of the mathematicians I have known have been pretty fun people to hang out with. Maybe you're thinking of accountants?
Re: (Score:2)
Strong indications are that Snowden is a government plant, ...
Judging from photos, perhaps some type of Fern [wikipedia.org]...
Re: (Score:2)
Ummm, no, I think he was just speculating. That's why he said "who's to say".
But he said it in the same conspiracy theorist manner as do nut jobs who "speculate" that Obama is a shape-shifting humanoid reptilian from Planet Nibiru.
Re: (Score:2)
I always use 17 as my large prime for DH. I doubt they've cracked it yet.
Everybody else uses odd primes, so I always use an even prime.
Re: (Score:2)
And N/2 is >= sqrt(N) for N>=4 (and since we take the integer floor of the result works for the 4 natural numbers that missed anyway), and thus provides a perfectly valid upper bound - not optimal but there was no claim that it was.
Re: (Score:2)
Assuming you're not just spouting bullshit, most likely you witnessed a dictionary attack against a weak password.
Re: (Score:2)
We could, if we had a couple trillion trillion trillion trillion universes at our disposal.