Quote: "Addendum: the White House Press Secretary was asked about this story, and their answer is “please stop asking about this story.” h/t " - https://youtu.be/Hfa6bih_gVc?t=1740
With the new Twitter changes, this should become a HN rule - that the OP should post a threadreader (or equivalent) link in the comments if TFA is a Twitter post.
The NSA actually had their own term for this, NOBUS, which meant "nobody but us". They were fond of attacks that they thought nobody but the NSA could exploit. They were arrogant enough to think they were better than all adversaries.
They're probably not dumb enough to think that they're so much better than their adversaries that they can do this stuff and it's fine anymore given how badly they've just been exposed in public.
Not saying that will change behaviour but it's hard even for the massively delusional to continue to really believe they can walk on water when they find themselves under it.
Calling out the cryptographic community on this has always resulted in becoming tarred & feathered in my experience. "How dare you question these experts? You are not a cryptographer."
No, I am not. But, I understand information theory and people. I don't need an ivory tower credential to call out potential bullshit or leverage my own intuition.
This kind of nonsense also makes me wonder how many of those "dont roll your own crypto" people are intentionally pushing developers towards these state-sponsored libraries & methods.
Just so we are clear, rolling my own crypto doesnt necessarily involve reinventing SHA256 and AES from scratch.
It just means using these primitives directly rather than farming out and allowing others to select the underlying methods for you.
I use Microsoft's cryptographic implementations, but I don't let them pick the method for me. I don't think this is unreasonable if you have some experience in the space.
It's that old saw of "anyone can create a security system that they can't break". How do you know that your combination of methods is secure?
There may well be hidden (or at least non-obvious) complications with using certain methods and/or implementations together that make them easier to break. If you're not aware of that, but someone else is, then the first you'll know about it is years later when a security leak is traced back to your "secure" system. And the only other way of knowing about this sort of stuff is to spend a lot of time staying current with the research.
Or you can let someone else do all that hard work, and run the extremely small risk that their work has been silently compromised by the NSA (or other state actor of your choice).
> How do you know that your combination of methods is secure?
Because if you give me some hashes, some messages, and a black box that signs arbitrary things for a arbitrary public key (with my combination of methods), I can turn around and give you back either a preimage of one of the hashes or a second preimage of one of messages. Provable security is nice.
Still working on how to extend such a scheme to key agreement rather than just signing, admittedly.
Putting together primitives in a way that doesn't have subtle flaws is not trivial. Many a standard have been vulnerable due to this. You think you can do better?
We do have simple, well engineered, and sometimes even probably secure constructions. Look at libsodium if you want a decent example of what a modern library looks like.
And stay away from anything that mentions the words NIST, FIPS, or any other government acronym. You aren't going to find modern, well-engineered, simple crypto in anything catering to that market. It's always hideously overcomplicated and rife with chances for bugs.
Not that I sanction all of the parent's post, but for instance Telegram did exactly that, and they still receive grief for rolling their own crypto. So per the parent you can either use back-doored state-sponsored encryption or roll your own which nobody trusts. Which is better? Is there another alternative?
State sponsorship doesn't matter, what matters is that it's secure. Everyone knew Dual-EC DRBG was likely backdoored, it stank to hell and back. There are dozens of other CSPRNGs, including other "state sponsored" ones, that pretty clearly aren't. There is also a whole world of crypto developed by people not associated with any state, including the modern ec25519/ChaCha based combinations (which are partly a response to the idea that the widely used NSA proposed ECC parameters may also be backdoored).
There are trustable people doing things right with easy to use libraries you can just drop in today, with documented rationale for the designs and without any "magic numbers" (which are a telltale of the backdoored and suspected-backdoored NSA algorithms).
But the cryptographic community was RIGHT on this, with at least six papers from respected researchers raising concerns back around 2007. It was businesses (like RSA and Juniper) that overrode these concerns under pressure.
> Members of a hacking group linked to the Chinese government called APT 5 hijacked the NSA algorithm in 2012, according to two people involved with Juniper’s investigation and an internal document detailing its findings that Bloomberg reviewed. The hackers altered the algorithm so they could decipher encrypted data flowing through the virtual private network connections created by NetScreen devices. They returned in 2014 and added a separate backdoor that allowed them to directly access NetScreen products, according to the people and the document.
Can we have more technical details regarding this? I guess some heavy math (number theory) is involved here but really intrigued how it was developed.
The entire concept of a backdoor that only the good guys have the keys too is so moroinic as to make my blood boil. The TSA locks were picked because a photo of the keys were posted online. The NSA forced an encryption method that they knew how to defeat got pwned. Yet the backdoor method still gets bandied about like it's the one thing to save us when it is exactly what will sink us.
The attackers didn't get the keys to the back door. They actually replaced the entire door with a new door that they made, which went unnoticed (by Juniper) for 3 years, locking out the owners of the original back door too. It's a rather impressive attack.
No, the attackers just re-pinned the backdoor lock cylinder that the NSA put on their "secure" door. That's why nobody noticed. The NSA conveniently left them a door with a backdoor they could hijack in a way that is effectively invisible.
Replacing the whole door would've been like replacing the entire DRBG, which would've much more likely raised alarms.
Having a convenient backdoor already integrated definitely aided the attack, but a sophisticated attacker with the ability to silently modify your codebase is a pretty bad place to start from regardless.
how would you possibly prevent such a thing? even if Juniper subjected all potential employees to clearance-like screening - that's not foolproof either.
Absolute prevention is probably impossible, but you can severely reduce the chances of successful attack by a) limiting access to security critical parts of code b) having shadow reviews of the same code (e.g. a separate team, that gets a notification every time these pieces of code are modified, and re-reviews them without notifying the original patch submitter)
> In practice this would simply mean hacking into a major firewall manufacturer’s poorly-secured source code repository, changing 32 bytes of data, and then waiting for the windfall when a huge number of VPN connections suddenly became easy to decrypt. And that’s what happened. 10/
I would definitely not describe replacing 32 bytes as "replacing an entire door."
Back in college, my (CS) department shared a student area with the students from the EE department, so naturally a friendly rivalry evolved.
There was a shared common area, and a private office for CS and EE each, both separated by lockable doors from the common area.
One day, we arrived to find that the EE department had left a taunting note on a desk in our (still) locked office.
At first we thought they airdropped it (since the office walls didn't reach all the way to the slightly domed ceiling), but we didn't think of the obvious: The office doors simply had their hinges on the outside. They straight up took the door off the hinges, and then put it back.
That reminds me of some dodgy locks I encountered at university. There was a gap between the door and the frame, and if you slid a knife down here, it would unlock the door (one of our tutors informed us of this, oddly enough). This was fixed by screwing a metal plate over the gap - of course, if you were determined enough, you could just unscrew the plate.
There are people who act with malice and sadism, people driven to harm others, people overwhelmed by greed and people consumed by a lust for power. And there are people who devote their lives to aiding others, people who are mindful of their community's needs, people who take opportunities to help others over opportunities to help themselves.
All these sorts can be found across the whole spectrum of wealth.
While I generally agree with your take, it's important to remember that the road to hell is paved with good intentions. Sometimes the most evil actors are those knights who believe they are fighting for some great holy cause.
> The entire concept of a backdoor that only the good guys have the keys too is so moroinic as to make my blood boil.
Uhm...isn't the whole basis of modern cryptography the idea that you can have keys that only the good guys know? Every time you use an HTTPS site for example you are relying on the existence of keys that only the good guys know. Every time you use an end to end encrypted messaging system you are relying on the existence of keys that only the good guys know.
The issue with backdoors is not keeping keys secret. It is keeping others from also installing backdoors.
I'm thinking you're not understanding the problem correctly. Backdoors mean that people with that access can read things without having the shared keys. You and I exchange keys so we can communicate privately. Because only you and I have those keys, nobody else can read those messages. However, because the TLAs have backdoor access, you and I and the TLAs can read the messages. However, you and I don't know that or at least we're unaware when it is occurring (because we read things like HN and are at least aware of backdoors). Now, bad actor #1 discovers the backdoor and jimmies the lock, and now they can read our "private" messages. Then bad actor #2 comes along and releases to the public how to use the backdoor on anyone's private messages, and now nothing is private and the crypto is a waste of energy. Then the TLAs come along and make it illegal to distrubte code that allows access to the backdoors and someone releases a new t-shirt.
The rest of the world sits back and says "I told you so".
I don't understand the significance of the Dual EC vulnerabilities here. The attackers had write access to the target's crypto code, and altered it to their convenience. What cryptosystem is secure against that threat model?
That the "re-keying" edit fits in 32 bytes is a neat math trick, but doesn't seem to me like a central issue. What am I misunderstanding?
>"In practice this would simply mean hacking into a major firewall manufacturer’s poorly-secured source code repository, changing 32 bytes of data, and then waiting for the windfall when a huge number of VPN connections suddenly became easy to decrypt. And that’s what happened. 10/"
The implication here is that the "change a 32 byte constant that nobody knows the provenance of to begin with" thing is what allowed this to fly under the radar for 3 years compared to an "if (attacker) { give_root(); }"-style insertion.
It's the kind of hack that survives a security audit. There is no leaked data or anything, it is just that afterwards the crypto works precisely as the standard intended.
The way Dual_EC works, to exploit it you need a TLS extension that has the server send "large nonces", which you use along with knowledge of the backdoor key to recover RNG state and so recover the server's Diffie-Hellman keys.
Now, if the backdoor is in place but no one was using it, no one would know if the public backdoor key got changed. But the attacker gets to decrypt all these sessions. OTOH, if NSA was trying to use the backdoor and noticed it wasn't working, they might start looking into it and find the hack.
So being able to make a very small source code change (32 bytes of public key material in this case) that has this impact is fantastic because that change is small enough that no one might have notice for a long time (which is apparently what actually happened).
But you're right, if you can change the source code then you can add a backdoor anyways, so Dual_EC being backdoored is not what was fatal to the Juniper systems. What was fatal to them is that they had poor internal security.
Still, an intentional backdoor key is plausibly -likely even- easier to replace than a backdoor is to add. So this is a decent argument against intentional backdoors. But it's not really a devastating argument against intentional backdoors.
Intentional backdoors are bad for political reasons too -- or good, maybe, depending on your point of view. Intentional backdoors are bad because the key to the backdoor can leak, and when that happens it can be very hard to fix -- this is devastating to security of the backdoored system, so I think it is a devastating argument against intentional backdoors, especially for a backdoor where exploitation is passive, like Dual_EC.
Dual_EC was a fine covert key escrow system for U.S. government systems, but there was no need to make it covert if it was only for that.
EDIT: But the real problem with Dual_EC is that it's terribly slow. /s
The amount of brain power that the NSA is using is staggering, it is not surprising they have such upper hand on cryptography.
I've heard the NSA is one of the biggest employer of math people.
At that point, I'm guessing some form of obscurity might somehow be a better idea to protect data from the NSA, or at least it would force NSA employees to analyze some obfuscated data, buying more time than just using mainstream methods.
In the end, I don't think nobody has good enough reason to hide stuff from the US government, at least that's my opinion, as long as the US gov is not too evil or not too corrupt. As long as other dangerous governments or criminals can't do too much cyber damage, things are fine.
I'm still curious if ML can create new kinds of cryptography.
Maybe a time will come where China/Russia will have enough expertise to break good enough crypto, and then the cyber battlefield will really change.
This has nothing to do with brain power. This was a deliberately backdoored algorithm that any cryptographer familiar with elliptic curve cryptography could've come up with. It wasn't even good or clever, seeing as people saw through it almost immediately. The only thing it had going for it is it was plausibly deniable and that allowed the US government to force people to implement it, since nobody could prove the NSA really had the secret keys.
Stuff like this is, on the contrary, evidence that the NSA can't break modern cryptography. If they could, they wouldn't need to try to push through blatant backdoors like this.
If you want to be safe from the NSA, use well-vetted, simple, auditable cryptography tools. The NSA doesn't break real crypto any more, they just find or make software bugs.
The only "thing the NSA has probably broken" that comes to mind in the modern crypto world is when people realized that you could do a one time mass computation for fixed parameters for n-bit Diffie-Hellman and then use the result to decrypt any communications that that used them, efficiently... which was a bit of a problem when tons of software around the world was using default parameters, often 1024-bit, which is in "the NSA can almost certainly break it" range. I remember when that happened, I went through all my servers and re-generated my own dh parameters for OpenSSL, at 4096 bits. But this wasn't a particularly mind blowing idea, it was more like an "oh shit" moment since everyone knew the NSA had the storage/compute budget to actually carry out this attack. But anyone serious about crypto shouldn't have been using 1024-bit DH anyway; it was just a failure of the ecosystem that nobody had proactively deprecated such small sizes.
> Stuff like this is, on the contrary, evidence that the NSA can't break modern cryptography.
Unless they're one step ahead here and they want us to think that which is why they add backdoors knowing that years later that knowledge will become public, giving us all a reason to think they cannot break modern crypto.
or taking the false flag further to be able to say that all crypto is weak and has flaws, so mights as well forgoe it. sure would make everyone's job easier.
> The NSA doesn't break real crypto any more, they just find or make software bugs.
They still can, and do break crypto. The Snowden papers (IIRC) mentioned that NSA factored a bunch of primes by throwing ridiculous amounts of compute at it: billions of dollars.
With that,they could break schemes with no forward secrecy at their leisure (from all the historical internet traffic they had gathered), and they could decrypt ~30% of all "secure" internet connections in real time at the time,IIRC
You're describing the Diffie-Hellman story I mentioned (in a somewhat confusing way; forward secrecy isn't involved here, this isn't about breaking RSA TLS keys, and in fact DH is used in connections with forward secrecy). Again, that only works for 1024 bit DH schemes. The NSA can't factor 2048 bit keys, and they definitely can't factor 4096 bit keys. These aren't unknown capabilities; it's pretty easy to get an order of magnitude estimate on how much compute power the NSA has (spoiler alert: Google has more).
>I've heard the NSA is one of the biggest employer of math people.
What are the other options for pure maths people? Academia? Does that really pay any better, plus, depending on your teaching level, there's a good chance you're just a babysitter. A cush gov't job probably sounds pretty good where you will actively be using your skills on a daily basis.
Are there FAANG opportunties for math people at the same level as gov't?
Finance is a good one. Academia is really hard to make any money in, if you can even get a job. Otherwise you can slide into stats or some applied field and do some consulting or something.
> In the end, I don't think nobody has good enough reason to hide stuff from the US government, at least that's my opinion, as long as the US gov is not too evil or not too corrupt. As long as other dangerous governments or criminals can't do too much cyber damage, things are fine.
Such a bizarre take. The US government is one of the most belligerent and feared governments in the world, with a known track record of starting wars, toppling democratic governements that are opposed to them, ignoring international law, prioritizing US corporations over any local peoples. China and Russia aren't even half as scary to the vast majority of the planet.
> The second lesson is that “serious” people are always inclined away from worst-case predictions. In bridge building and politics you can listen to those people. But computer security is adversarial: the conscious goal of attackers is to bring about worst-case outcomes.
Are they suggesting that bridge-building and politics are not adversarial? It seems to me that bridges and politics are weak points that are frequently attacked.
Yes, they're suggesting that bridge building isn't adversarial.
In bridge building you might often ignore questions like "what if that nearby skyscraper fell on the bridge" or "what if there was a 100-year flood every day for a week". They're scenarios that can conceivably happen but they're very unlikely.
In computer security, you wouldn't be so safe because you need to protect your digital bridge from an adversary who has no problems demolishing the nearby figurative skyscraper.
Of course there are real-world situations where bridge building is adversarial, if you're in a war-zone for instance. I think the author is discussing more civil situations like "should we spend an extra $1B to make the bridge asteroid proof".
Bridge building is only minimally adversarial. You have to make the bridge strong against chance, natural threats, and casual vandals.
You don't have to make the bridge more than minimally strong against attack by a foreign military-- or even some wacko with a van full of ammonium nitrate, and you probably can't (or at least it would be utterly budget breaking to make a serious attempt and doing so).
While if you don't make your computer strong against fairly powerful attackers it will get attacked, because the economics of powerful computer attacks make them much less costly to create, almost free to deploy, and relatively low risk of consequences for using them. Fortunately, defending computers from attack also has good economics compared to defending bridges.
A bit of a tangent, but why do people insist on posting these things to twitter? They are so annoying to read like that. What does twitter offer that other platforms, designed for this type of content, don't?
There are a lot of information security discussions that only take place on Twitter, so it's kind of a self-perpetuating situation.
The entire reason I signed up for a Twitter account, after something like 5 years of refusing to do so, was that I asked for some clarification on a post to Full Disclosure, and was told something to the effect of "this has already been discussed at length on Twitter". I had done a bunch of web searches already, and none of them had turned up the thread they linked to, but they were right.
I wouldn't say I'm a fan of Twitter, but because of that situation, I discovered a lot of other discussions in other fields that I wouldn't have seen otherwise, so it seems like a net positive.
Was this modified Dual EC ever used for actual sessions? It's my recollection that programs offered Dual EC as an option, but never the default one. And nobody enabled it because it was slow, and had little advantage. But perhaps that was different with NSA mandating government use standards?
Searching for the text "strcmp" finds a static string that is referenced in the sub_ED7D94 function. Looking at the strings output, we can see some interesting string references, including auth_admin_ssh_special and auth_admin_internal. Searching for auth_admin_internal finds the sub_13DBEC function. This function has a strcmp call that is not present in the 6.3.0r19b firmware:
The argument to the strcmp call is <<< %s(un='%s') = %u, which is the backdoor password, and was presumably chosen so that it would be mistaken for one of the many other debug format strings in the code. This password allows an attacker to bypass authentication through SSH and Telnet.
[1] is the backdoor. [2] is more details regarding discovery.
That's one of them, and the least interesting of both. I remember that the other one was way more concealed and involved a global variable or something like that and it didn't seemed that the code was doing what was actually doing.
There was an amazing blog entry which explained it, but can't find it right now.
Basically, Dual EC was chained to another PRNG, so the output should have been robust to crypto vulnerabilities discovered in any of both. The thing is: the second one was never called, because the for's index(a global variable) was set to 32 inside a function call, so the loop never run.
It has been quite a while since security researchers publish about a potential backdoor in Dual_EC_DRBG, and even without the backdoor, they found it rather weak. It was even before it was a standard.
Then, there is mentions of the NSA intent on backdooring encryption standards, and the surprising push for making that dubious algorithm a standard.
It makes the scenario of a NSA backdoor very likely, but strong suspicion is not a proof, and yet, all these articles make it into a fact, did I miss something or do they jump to conclusions. Not saying they didn't do it, they most likely did, but if I get accused of a crime one day, I hope that the court will be held to higher standards.
And there is many things I don't get about that story. Dual_EC_DRBG was suspicious from day one, I can't imagine an enemy of the US using it except to transmit misinformation, no need for leaks, the very existence of the algorithm is enough. If the story is true (it is a NSA backdoor), then it is really a show of incompetence (like the whole mess with Snowden, really), or maybe part of the plan of a mastermind, I bet on the former.
That the generator is undetectably backdoorable through choice of constants has never been in question, from what I understand, and has been known outside the NSA (who designed it and chose the constants) via an explicit construction since before the relevant standard was finalized; it’s also so pointlessly slow nobody would normally include it in their own software except maybe out of completionism, which was ANSI’s official motivation for including it as well. (Green’s 2015 blog post[1] has the history and references.)
It’s also long been certain that Juniper included that generator in their software with the standard constant, then were hacked and afterwards for several years their software included in that place a different constant, with no other code changes, and finally an official emergency security update rolled that value back. The presence of the generator was not mentioned in the official documentation neither before nor after the hack, and the code gave the appearance of combining its output with that of another generator (which would have eliminated the backdoorability) while in fact not doing so because of something that looks like a logic bug. (I haven’t gathered the links on this but the surrounding comments here have most of them I think.)
Now, to me this seems like overhelming evidence that Juniper products have had a crippling security vulnerability due to the known backdoorability of Dual_EC_DRBG, without Juniper wanting it so. There is just no other plausible reason to break into Juniper and out of everything you could changing this one apparently pseudorandom string.
To make an argument against standardizing or using backdoorable cryptographic algorithms (Green’s point in the thread under discussion), this is as far as we need to get. The only thing the rest is relevant for is NSA’s reputation, government backdoors, and willing participation in them; but the Juniper story already suggests that the distinction between backdoorable and backdoored (and broken) is at best academic.
* * *
There is also a second place where Dual_EC_DRBG is known to be implemented, and that is the RSA BSAFE library. This library also includes but in most builds does not enable a weird TLS extension from what came to be known as the Extended Random family, though old and uninteresting Internet-connected devices have been spotted with it enabled. Now, the only thing this extension does—the thing it was described to be for by people bearing a US government badge who presented the Internet-Drafts on the IETF mailing lists—is expose more raw randomness from the system’s cryptographic random generator. No cryptographer anywhere has ever (publicly) described or even suggested any way to use this to improve the security of TLS in any configuration, including the authors of the Internet-Drafts. (See Green’s 2017 post[2] and links therein for the details.) However, if you are trying to break the system’s vulnerable random generator, exposing more of its output is immediately useful.
We are now two for two in commercial vendors of security products who implemented Dual_EC_DRBG also exposing its raw output (thus enabling the exploitation of the backdoor if one is configured through the choice of its constant) through ways that are both unusual and unnecessary for the operation of the product (logic bug for Juniper, completely useless and unused experimental TLS extension for RSA).
That when implementing Dual_EC_DRBG in the first place necessitates an explanation. Random generators are essential in a cryptographic systems, but unlike ciphers and such they are a completely opaque implementation detail—somebody you’re communicating with not only mustn’t depend on but actually can’t distinguish which generator you’re using (indeed a generator that can be distinguished is defined to be broken). Thus the choice of generator is a combination of speed (and it’s a speed-critical component) ease of im...
> What part of the “mess with Snowden” do you count as incompetence? The exfiltration approach he describes in his book does sound like run-of-the-mill incompetence if taken at face value, but that’s hardly the part that people were (and, I hope, still are) miffed about.
That's what I am talking about. And to be honest I find it a bigger problem than the content of the leaks (the part most people are angry about). In fact, the worst is when you combine the two.
That the NSA spies is to be expected, that's part of their job, they overstepped their borders and it is a problem, but at least, that alone doesn't fail their mission. But that they let Snowden leave with a stash of secret documents, to Russia no less means that an agency for which half of the mission is to keep secrets couldn't keep secrets. And Snowden is just a whistleblower who exposed everything, how many actual spies covertly leaked data before him?
So now there is an agency that stores tremendous amount of data about everything including its own people, and can't keep it secure, great!
And I completely agree with your second point about the enemies of the US. In fact, I suspect that the main reason for that ridiculously wide surveillance is to justify big budgets and to make sure everyone keep their job, and maybe even hire a few friends and relatives.
> or by imposing that condition in government contracts
Not just government contracts. The intelligence community extensively partners with corporations. If I had to take a bet I wouldn't be surprised if the customer that demanded this wasn't the government, but was one of these partners.
A minor nit:
> is not “suspicious” as a choice of random generator, it’s stupid.
I don't think this is completely fair. The security of dual ec is related (though not quite reducible) to the hardness of elliptic curve discrete log in the relevant group.
If it weren't unreasonably slow I think a lot of people would be inclined to adopt a well reviewed and standardized RNG for their ECC-crypto system that itself had security traceable to ECC: if the DL assumption in that group is broken, then the connections are already insecure.
Overstating the arguments against dual_ec weakens our security, rather than strengthening it because it obscures how reasonable people would go along with such proposals and undermines how critical it is that our standards receive adequate public review.
Huh. I had not though of the rekeying issues before. Glaringly obvious in hindsight. The question of "how can you ensure that this system will not be rekeyed to respond to someone else" is a great one. The best answer is "there is nothing that can be rekeyed."
My favourite part is that the NSA acknowledged to Wyden that they had written a lessons learned memo, and when asked to produce it they could never find it...
"In a July 2020 response to Wyden and other members of Congress, Juniper provided few new details of the case but blamed the intrusions on a “sophisticated nation-state hacking unit.” NSA told Wyden’s staff in 2018 that there was a “lessons learned” report, but the agency “now asserts that it cannot locate this document,” according to a Wyden aide. "
One thing I think I recall from the prior coverage(*) but don't see mentioned in the thread: I believe Netscreen/Juniper had followed the appendix procedure and rekeyed the DualEC. If that's true, it would explain why NSA wouldn't have noticed a loss in observation capabilities, as some in the twitter thread remarked. But perhaps I'm misremembering the reporting.
(*) Before someone asks, yes I worked at Juniper in the past, but never on netscreen: netscreen was an acquisition. Also this incident was after I worked there... so I don't know anything about this stuff that wasn't public.
94 comments
[ 3.0 ms ] story [ 164 ms ] threadQuote: "Addendum: the White House Press Secretary was asked about this story, and their answer is “please stop asking about this story.” h/t " - https://youtu.be/Hfa6bih_gVc?t=1740
That's f*ing hilarious
I'd like to go even further and propose the following terms:
Not saying that will change behaviour but it's hard even for the massively delusional to continue to really believe they can walk on water when they find themselves under it.
No, I am not. But, I understand information theory and people. I don't need an ivory tower credential to call out potential bullshit or leverage my own intuition.
This kind of nonsense also makes me wonder how many of those "dont roll your own crypto" people are intentionally pushing developers towards these state-sponsored libraries & methods.
It just means using these primitives directly rather than farming out and allowing others to select the underlying methods for you.
I use Microsoft's cryptographic implementations, but I don't let them pick the method for me. I don't think this is unreasonable if you have some experience in the space.
There may well be hidden (or at least non-obvious) complications with using certain methods and/or implementations together that make them easier to break. If you're not aware of that, but someone else is, then the first you'll know about it is years later when a security leak is traced back to your "secure" system. And the only other way of knowing about this sort of stuff is to spend a lot of time staying current with the research.
Or you can let someone else do all that hard work, and run the extremely small risk that their work has been silently compromised by the NSA (or other state actor of your choice).
Because if you give me some hashes, some messages, and a black box that signs arbitrary things for a arbitrary public key (with my combination of methods), I can turn around and give you back either a preimage of one of the hashes or a second preimage of one of messages. Provable security is nice.
Still working on how to extend such a scheme to key agreement rather than just signing, admittedly.
We do have simple, well engineered, and sometimes even probably secure constructions. Look at libsodium if you want a decent example of what a modern library looks like.
And stay away from anything that mentions the words NIST, FIPS, or any other government acronym. You aren't going to find modern, well-engineered, simple crypto in anything catering to that market. It's always hideously overcomplicated and rife with chances for bugs.
Probably doesn't make me feel secure. Did you mean properly?
There are trustable people doing things right with easy to use libraries you can just drop in today, with documented rationale for the designs and without any "magic numbers" (which are a telltale of the backdoored and suspected-backdoored NSA algorithms).
Can we have more technical details regarding this? I guess some heavy math (number theory) is involved here but really intrigued how it was developed.
As i understand it, the hackers replaced a magic number Q with a different value than the standards compliant one, where they had pre-computed P.
[1]:https://www.youtube.com/watch?v=nybVFJVXbww
https://dl.acm.org/doi/pdf/10.1145/3266291 goes into it in some detail
Replacing the whole door would've been like replacing the entire DRBG, which would've much more likely raised alarms.
> In practice this would simply mean hacking into a major firewall manufacturer’s poorly-secured source code repository, changing 32 bytes of data, and then waiting for the windfall when a huge number of VPN connections suddenly became easy to decrypt. And that’s what happened. 10/
I would definitely not describe replacing 32 bytes as "replacing an entire door."
Back in college, my (CS) department shared a student area with the students from the EE department, so naturally a friendly rivalry evolved.
There was a shared common area, and a private office for CS and EE each, both separated by lockable doors from the common area.
One day, we arrived to find that the EE department had left a taunting note on a desk in our (still) locked office.
At first we thought they airdropped it (since the office walls didn't reach all the way to the slightly domed ceiling), but we didn't think of the obvious: The office doors simply had their hinges on the outside. They straight up took the door off the hinges, and then put it back.
There are people who act with malice and sadism, people driven to harm others, people overwhelmed by greed and people consumed by a lust for power. And there are people who devote their lives to aiding others, people who are mindful of their community's needs, people who take opportunities to help others over opportunities to help themselves.
All these sorts can be found across the whole spectrum of wealth.
Uhm...isn't the whole basis of modern cryptography the idea that you can have keys that only the good guys know? Every time you use an HTTPS site for example you are relying on the existence of keys that only the good guys know. Every time you use an end to end encrypted messaging system you are relying on the existence of keys that only the good guys know.
The issue with backdoors is not keeping keys secret. It is keeping others from also installing backdoors.
The rest of the world sits back and says "I told you so".
No it in any way, but based on your other examples, maybe you're thinking about certificate authorities?
That the "re-keying" edit fits in 32 bytes is a neat math trick, but doesn't seem to me like a central issue. What am I misunderstanding?
>"In practice this would simply mean hacking into a major firewall manufacturer’s poorly-secured source code repository, changing 32 bytes of data, and then waiting for the windfall when a huge number of VPN connections suddenly became easy to decrypt. And that’s what happened. 10/"
Now, if the backdoor is in place but no one was using it, no one would know if the public backdoor key got changed. But the attacker gets to decrypt all these sessions. OTOH, if NSA was trying to use the backdoor and noticed it wasn't working, they might start looking into it and find the hack.
So being able to make a very small source code change (32 bytes of public key material in this case) that has this impact is fantastic because that change is small enough that no one might have notice for a long time (which is apparently what actually happened).
But you're right, if you can change the source code then you can add a backdoor anyways, so Dual_EC being backdoored is not what was fatal to the Juniper systems. What was fatal to them is that they had poor internal security.
Still, an intentional backdoor key is plausibly -likely even- easier to replace than a backdoor is to add. So this is a decent argument against intentional backdoors. But it's not really a devastating argument against intentional backdoors.
Intentional backdoors are bad for political reasons too -- or good, maybe, depending on your point of view. Intentional backdoors are bad because the key to the backdoor can leak, and when that happens it can be very hard to fix -- this is devastating to security of the backdoored system, so I think it is a devastating argument against intentional backdoors, especially for a backdoor where exploitation is passive, like Dual_EC.
Dual_EC was a fine covert key escrow system for U.S. government systems, but there was no need to make it covert if it was only for that.
EDIT: But the real problem with Dual_EC is that it's terribly slow. /s
I've heard the NSA is one of the biggest employer of math people.
At that point, I'm guessing some form of obscurity might somehow be a better idea to protect data from the NSA, or at least it would force NSA employees to analyze some obfuscated data, buying more time than just using mainstream methods.
In the end, I don't think nobody has good enough reason to hide stuff from the US government, at least that's my opinion, as long as the US gov is not too evil or not too corrupt. As long as other dangerous governments or criminals can't do too much cyber damage, things are fine.
I'm still curious if ML can create new kinds of cryptography.
Maybe a time will come where China/Russia will have enough expertise to break good enough crypto, and then the cyber battlefield will really change.
Stuff like this is, on the contrary, evidence that the NSA can't break modern cryptography. If they could, they wouldn't need to try to push through blatant backdoors like this.
If you want to be safe from the NSA, use well-vetted, simple, auditable cryptography tools. The NSA doesn't break real crypto any more, they just find or make software bugs.
The only "thing the NSA has probably broken" that comes to mind in the modern crypto world is when people realized that you could do a one time mass computation for fixed parameters for n-bit Diffie-Hellman and then use the result to decrypt any communications that that used them, efficiently... which was a bit of a problem when tons of software around the world was using default parameters, often 1024-bit, which is in "the NSA can almost certainly break it" range. I remember when that happened, I went through all my servers and re-generated my own dh parameters for OpenSSL, at 4096 bits. But this wasn't a particularly mind blowing idea, it was more like an "oh shit" moment since everyone knew the NSA had the storage/compute budget to actually carry out this attack. But anyone serious about crypto shouldn't have been using 1024-bit DH anyway; it was just a failure of the ecosystem that nobody had proactively deprecated such small sizes.
Unless they're one step ahead here and they want us to think that which is why they add backdoors knowing that years later that knowledge will become public, giving us all a reason to think they cannot break modern crypto.
<takes off his tinfoil hat>
They still can, and do break crypto. The Snowden papers (IIRC) mentioned that NSA factored a bunch of primes by throwing ridiculous amounts of compute at it: billions of dollars.
With that,they could break schemes with no forward secrecy at their leisure (from all the historical internet traffic they had gathered), and they could decrypt ~30% of all "secure" internet connections in real time at the time,IIRC
What are the other options for pure maths people? Academia? Does that really pay any better, plus, depending on your teaching level, there's a good chance you're just a babysitter. A cush gov't job probably sounds pretty good where you will actively be using your skills on a daily basis.
Are there FAANG opportunties for math people at the same level as gov't?
Such a bizarre take. The US government is one of the most belligerent and feared governments in the world, with a known track record of starting wars, toppling democratic governements that are opposed to them, ignoring international law, prioritizing US corporations over any local peoples. China and Russia aren't even half as scary to the vast majority of the planet.
> The second lesson is that “serious” people are always inclined away from worst-case predictions. In bridge building and politics you can listen to those people. But computer security is adversarial: the conscious goal of attackers is to bring about worst-case outcomes.
Are they suggesting that bridge-building and politics are not adversarial? It seems to me that bridges and politics are weak points that are frequently attacked.
Or am I missing sarcasm?
In bridge building you might often ignore questions like "what if that nearby skyscraper fell on the bridge" or "what if there was a 100-year flood every day for a week". They're scenarios that can conceivably happen but they're very unlikely.
In computer security, you wouldn't be so safe because you need to protect your digital bridge from an adversary who has no problems demolishing the nearby figurative skyscraper.
Of course there are real-world situations where bridge building is adversarial, if you're in a war-zone for instance. I think the author is discussing more civil situations like "should we spend an extra $1B to make the bridge asteroid proof".
You don't have to make the bridge more than minimally strong against attack by a foreign military-- or even some wacko with a van full of ammonium nitrate, and you probably can't (or at least it would be utterly budget breaking to make a serious attempt and doing so).
While if you don't make your computer strong against fairly powerful attackers it will get attacked, because the economics of powerful computer attacks make them much less costly to create, almost free to deploy, and relatively low risk of consequences for using them. Fortunately, defending computers from attack also has good economics compared to defending bridges.
Its audience.
Wide reach, and ongoing engagement/discussion.
I read threads like this because the follow-on discussion is often just as or more interesting than the thread itself.
I think a blog post is also a good option here, but most blogs aren’t well suited for having a discussion.
The entire reason I signed up for a Twitter account, after something like 5 years of refusing to do so, was that I asked for some clarification on a post to Full Disclosure, and was told something to the effect of "this has already been discussed at length on Twitter". I had done a bunch of web searches already, and none of them had turned up the thread they linked to, but they were right.
I wouldn't say I'm a fan of Twitter, but because of that situation, I discovered a lot of other discussions in other fields that I wouldn't have seen otherwise, so it seems like a net positive.
[1] https://github.com/rapid7/metasploit-framework/blob/master/m...
[2] https://blog.rapid7.com/2015/12/20/cve-2015-7755-juniper-scr...
There was an amazing blog entry which explained it, but can't find it right now.
Edit: I don't think this was the one I read, but it's similar. https://cryptologie.net/article/316/junipers-backdoor/
Basically, Dual EC was chained to another PRNG, so the output should have been robust to crypto vulnerabilities discovered in any of both. The thing is: the second one was never called, because the for's index(a global variable) was set to 32 inside a function call, so the loop never run.
It has been quite a while since security researchers publish about a potential backdoor in Dual_EC_DRBG, and even without the backdoor, they found it rather weak. It was even before it was a standard.
Then, there is mentions of the NSA intent on backdooring encryption standards, and the surprising push for making that dubious algorithm a standard.
It makes the scenario of a NSA backdoor very likely, but strong suspicion is not a proof, and yet, all these articles make it into a fact, did I miss something or do they jump to conclusions. Not saying they didn't do it, they most likely did, but if I get accused of a crime one day, I hope that the court will be held to higher standards.
And there is many things I don't get about that story. Dual_EC_DRBG was suspicious from day one, I can't imagine an enemy of the US using it except to transmit misinformation, no need for leaks, the very existence of the algorithm is enough. If the story is true (it is a NSA backdoor), then it is really a show of incompetence (like the whole mess with Snowden, really), or maybe part of the plan of a mastermind, I bet on the former.
That the generator is undetectably backdoorable through choice of constants has never been in question, from what I understand, and has been known outside the NSA (who designed it and chose the constants) via an explicit construction since before the relevant standard was finalized; it’s also so pointlessly slow nobody would normally include it in their own software except maybe out of completionism, which was ANSI’s official motivation for including it as well. (Green’s 2015 blog post[1] has the history and references.)
It’s also long been certain that Juniper included that generator in their software with the standard constant, then were hacked and afterwards for several years their software included in that place a different constant, with no other code changes, and finally an official emergency security update rolled that value back. The presence of the generator was not mentioned in the official documentation neither before nor after the hack, and the code gave the appearance of combining its output with that of another generator (which would have eliminated the backdoorability) while in fact not doing so because of something that looks like a logic bug. (I haven’t gathered the links on this but the surrounding comments here have most of them I think.)
Now, to me this seems like overhelming evidence that Juniper products have had a crippling security vulnerability due to the known backdoorability of Dual_EC_DRBG, without Juniper wanting it so. There is just no other plausible reason to break into Juniper and out of everything you could changing this one apparently pseudorandom string.
To make an argument against standardizing or using backdoorable cryptographic algorithms (Green’s point in the thread under discussion), this is as far as we need to get. The only thing the rest is relevant for is NSA’s reputation, government backdoors, and willing participation in them; but the Juniper story already suggests that the distinction between backdoorable and backdoored (and broken) is at best academic.
* * *
There is also a second place where Dual_EC_DRBG is known to be implemented, and that is the RSA BSAFE library. This library also includes but in most builds does not enable a weird TLS extension from what came to be known as the Extended Random family, though old and uninteresting Internet-connected devices have been spotted with it enabled. Now, the only thing this extension does—the thing it was described to be for by people bearing a US government badge who presented the Internet-Drafts on the IETF mailing lists—is expose more raw randomness from the system’s cryptographic random generator. No cryptographer anywhere has ever (publicly) described or even suggested any way to use this to improve the security of TLS in any configuration, including the authors of the Internet-Drafts. (See Green’s 2017 post[2] and links therein for the details.) However, if you are trying to break the system’s vulnerable random generator, exposing more of its output is immediately useful.
We are now two for two in commercial vendors of security products who implemented Dual_EC_DRBG also exposing its raw output (thus enabling the exploitation of the backdoor if one is configured through the choice of its constant) through ways that are both unusual and unnecessary for the operation of the product (logic bug for Juniper, completely useless and unused experimental TLS extension for RSA).
That when implementing Dual_EC_DRBG in the first place necessitates an explanation. Random generators are essential in a cryptographic systems, but unlike ciphers and such they are a completely opaque implementation detail—somebody you’re communicating with not only mustn’t depend on but actually can’t distinguish which generator you’re using (indeed a generator that can be distinguished is defined to be broken). Thus the choice of generator is a combination of speed (and it’s a speed-critical component) ease of im...
That's what I am talking about. And to be honest I find it a bigger problem than the content of the leaks (the part most people are angry about). In fact, the worst is when you combine the two.
That the NSA spies is to be expected, that's part of their job, they overstepped their borders and it is a problem, but at least, that alone doesn't fail their mission. But that they let Snowden leave with a stash of secret documents, to Russia no less means that an agency for which half of the mission is to keep secrets couldn't keep secrets. And Snowden is just a whistleblower who exposed everything, how many actual spies covertly leaked data before him?
So now there is an agency that stores tremendous amount of data about everything including its own people, and can't keep it secure, great!
And I completely agree with your second point about the enemies of the US. In fact, I suspect that the main reason for that ridiculously wide surveillance is to justify big budgets and to make sure everyone keep their job, and maybe even hire a few friends and relatives.
Not just government contracts. The intelligence community extensively partners with corporations. If I had to take a bet I wouldn't be surprised if the customer that demanded this wasn't the government, but was one of these partners.
A minor nit:
> is not “suspicious” as a choice of random generator, it’s stupid.
I don't think this is completely fair. The security of dual ec is related (though not quite reducible) to the hardness of elliptic curve discrete log in the relevant group.
If it weren't unreasonably slow I think a lot of people would be inclined to adopt a well reviewed and standardized RNG for their ECC-crypto system that itself had security traceable to ECC: if the DL assumption in that group is broken, then the connections are already insecure.
Overstating the arguments against dual_ec weakens our security, rather than strengthening it because it obscures how reasonable people would go along with such proposals and undermines how critical it is that our standards receive adequate public review.
"In a July 2020 response to Wyden and other members of Congress, Juniper provided few new details of the case but blamed the intrusions on a “sophisticated nation-state hacking unit.” NSA told Wyden’s staff in 2018 that there was a “lessons learned” report, but the agency “now asserts that it cannot locate this document,” according to a Wyden aide. "
(*) Before someone asks, yes I worked at Juniper in the past, but never on netscreen: netscreen was an acquisition. Also this incident was after I worked there... so I don't know anything about this stuff that wasn't public.