There's long been stories about meddling in other standards orgs (both to strengthen and to weaken them), but I don't recall hearing rumors about sabotage of IETF standards.
Almost immediately after that happened, a well-known cypherpunk person accused the IETF IPSEC standardization process of subversion, pointing out Phil Rogaway (an extraordinarily well-respected and influential academic cryptographer) trying in vain to get the IETF not to standardize a chained-IV CBC transport (this is a bug class now best known, in TLS, as BEAST), while a chorus of IETF gadflies dunked on him and questioned his credentials. The gadflies ultimately prevailed.
The moral of this story, and what makes these "NSA at IETF" allegations so insidious, is that the IETF is perfectly capable of subverting its own cryptography without any help from a meddling intelligence agency. This is a common failure of all standards organizations (W3C didn't need any help coming up with XML DSIG, which is probably the worst cryptosystem ever devised), but it's somewhat amplified in open settings like IETF.
The 3 letter agencies usually recrut people from academia and sensitive organizations in order to pursue their agenda.
We ended up with a huge mess that solves no actual problems, introduced problems that never existed before, and so confusing in what it does that people still blindly defend it.
Surely this can't be a phenomenon unique to technology, can it?
I think --- I am not kidding here, I believe this sincerely --- the correct conclusion is community-driven cryptographic standards organizations are a force for evil. Curve25519 is a good standard. So is Noise, so is WireGuard. None of those were developed in a standards organization. It's hard to think of a good cryptosystem that was. TLS? It took decades --- bad decades --- to get to 1.3. Of that outcome, I believe it was Watson Ladd who said that if you turned it in as the "secure transport" homework in your undergraduate cryptography class, you'd get a B.
Joining a gadfly swarm just gives them an opportunity to prove their worth to the group.
Skip to 1 minute in and you’ll see the problem in experimental form.
I suspect most of it was done under different corporate identities, and probaby just managed to slow adoption of systematic security architectures. Of course, once the Snowden papers came out, all that effort was rendered moot as the IETF reacted pretty hard.
If you told me the NSA/CIA had purposefully sabotaged the development of the OAuth2 protocol to make it so complex that no one can implement it securely it'd be the best explanation I've heard yet about why it is the monstrosity it is.
Have you ever seen SAML? Now there is a protocol that seems borderline sabotaged. CSRF tokens? Optional part of spec. Which part of the response is signed? Up to you with different implementations making different choices; but better verify the sig covers the relavent part of the doc. Can you change the signed part of spec in a way that alters the xml parse tree without it invalidating the signature? Of course you can!
Oauth2 is downright sane in comparison.
[To be clear, saml is not a ietf spec, it just solves a similar problem as oauth2]
This is definitely an unpopular opinion however.
The most famous JWT issue, to my mind, was people implementing JWT and -- as per spec -- accepting an encryption mode of "none" as valid.
That could be described as an "implementation bug", but it can also be described as "not an implementation bug" - all your JWT functionality is working the way it's supposed to work, it's just not doing the thing that you hoped it would do.
RFC 7519 (the JWT spec) delegates all signature / authentication validation to the JWS and JWE specs. (And says that an unholy mechanism shall be used to determine whether to follow the JWS validation algorithm or the JWE algorithm.)
JWS even discusses algorithm verification (https://www.rfc-editor.org/rfc/rfc7515.html#section-10.6), but does not suggest, let alone require, the absolutely mindbendingly obvious way to do it: when you have a key used for verificaiton, the algorithm specification is part of the key. If I tell a library to verify that a given untrusted input is signed/authenticated by a key, the JWS design is:
bool is_it_valid(string message, string key); // where key is an HMAC secret or whatever
bool is_it_valid(string message, VerificationKey key);
The JWE spec is not obviously better. I wouldn't be utterly shocked if it could be attacked by sending a message to someone who intends to use, say, a specific Ed25519 public key, but setting the algorithm to RSA and treating the Ed25519 public key as a comically short RSA key.
Sure that is pretty silly. However in saml you have xmlsec accepting the non standard extension where you can have it "signed" with hmac where the hmac key is specified inside the attacker controlled document. I would call that basically the same as alg=none, although at least its non-standard.
I don't know which species is worse. You don't see them ignoring CVEs for a percentage.
So ripe for man in the middle attacks. Even if you just did a straight modal and said “put your google credentials into these fields”, we’re training people that that’s totally fine
There's a lot of random additional complexity floating around it, but that complexity tracks changes in how applications are deployed, to mobile applications and standalone front-end browser applications that can't hold "app secrets".
The whole system is very convoluted, I'm not saying you're wrong to observe that, but I'd argue that's because apps have a convoluted history. The initial idea of the OAuth2 code flow is pretty simple.
I can imagine special cases where they would exert resources and effort, such as the IETF or some other economically efficient chokepoint (Rust?), but not in general.
So they have hardened DES towards attacks from those with much less money than NSA, while making it weaker against rich organizations like NSA.
I don't think all that many serious people believe there's anything malign about them. It's easy to dunk on them, because they're based on "random seeds" generated inside NIST or NSA. As a "nothing up our sleeves" measure, NSA generated these seeds and then passed them through SHA1, thus ostensibly destroying any structure in the seed before using it to generate coefficients for the curve.
The ostensible "backdoor attack" here is that NSA could have used its massive computation resources (bear in mind this happened in the 1990s) to conduct a search for seeds that hashed to some kind of insecure curve. The problem with this logic is that unless the secret curve weakness is very common, the attack is implausible. It's not that academic researchers automatically would have found it, but rather that NSA wouldn't be able to count on them not finding it.
Search for [koblitz menezes enigma curve] for a paper that goes into the history of this, and makes that argument (I just shoplifted it from the paper). If you don't know who Neal Koblitz and Alfred Menezes are, we're not speaking the same language anyways.
The real subtext to this "P-curves are corrupted" claim is that there are curves everyone drastically prefers, most especially Curve25519 (the second-most popular curve on the Internet). Modern curves have nice properties, like (mostly) not requiring point validation for security (any 32-byte string is a secure key, which is decidedly not the case for ordinary short Weierstrass curves, and being easy to implement without timing attacks.
The author of Curve25519 doesn't trust the NIST curves. That can mean something to you, but it's worth pointing out that author doesn't trust any other curves, either. Cryptographers have proposed "nothing up my sleeves" curves, whose coefficients are drawn from mathematical constants (like pi and e). Bernstein famously co-authored a paper that attempted to demonstrate that you could generate an "untrustworthy" curve by searching through permutations of NUMS parameters. It was fun stunt cryptography, but if you're looking for parsimony and peer consensus on these issues, you're probably better off with Menezes.
Incidentally, you said "ECDSA curve". ECDSA is an algorithm, not a curve. But nobody likes ECDSA, which was also designed by the NSA. A very similar situation plays out there --- Curve25519's author also invented Ed25519, a Schnorr-like signing scheme that resolves a variety of problems with ECDSA. Few people claim ECDSA is enemy action, though; we all just sort of understand that everyone had a lot to learn back in 1997.
Now, IMO I thought the whole point was that the curve itself didn’t really matter. As you are just picking X Y points on it and doing some work from there. But if there is a flaw, and it required specific curves to work, well there you go.
Unfortunately, at some point we (non-crypto-experts) have to trust something.
> Under SORM‑2, Russian Internet service providers (ISPs) must install a special device on their servers to allow the FSB to track all credit card transactions, email messages and web use. The device must be installed at the ISP's expense.
originally there was a warrant system but it seemed quite liberal and they don’t bother with the secret court system “oversight” like the US:
> Since 2010, intelligence officers can wiretap someone's phones or monitor their Internet activity based on received reports that an individual is preparing to commit a crime. They do not have to back up those allegations with formal criminal charges against the suspect. According to a 2011 ruling, intelligence officers have the right to conduct surveillance of anyone who they claim is preparing to call for "extremist activity."
Then in 2016 a counter terrorism law was passed and it sounds like they ISPs/telecoms are required to store everything for 6 months and it merely has to be requested by “authorities” (guessing beyond just the FSB) without a court order
> Internet and telecom companies are required to disclose these communications and metadata, as well as "all other information necessary" to authorities on request and without a court order
> Equally troubling, the new counterterrorism law also requires Internet companies to provide to security authorities “information necessary for decoding” electronic messages if they encode messages or allow their users to employ “additional coding.” Since a substantial proportion of Internet traffic is “coded” in some form, this provision will affect a broad range of online activity.
Russia is not alone. The EU required the same thing from 2006, until the EU Court struck it down in 2014: https://en.wikipedia.org/wiki/Data_Retention_Directive
https://en.wikipedia.org/wiki/Data_retention#European_Union is a fun read in how the EU fined countries for adhering to their respective national constitutions and refusing to implement that directive.
Looking beyond the EU, there are plenty of allegedly democratic countries on that wiki page with legally-required data retention:
In 2015, the Australian government introduced mandatory data retention laws that allows data to be retained up to two years. [..] It requires telecommunication providers and ISPs to retain telephony, Internet and email metadata for two years, accessible without a warrant
dd if=/dev/urandom of=encrypted1.zip bs=4M count=1
and upload it to dropbox and google drive
NSA will archive it for you expecting to decrypt the content later in the future when a software bug is found or hardware is more capable.
Who is really winning if anybody does this?
The NSA uses a completely different set of algorithms called Suite A. They don't use AES for exactly this reason.
My theory is they've got a backdoor in the iPhone hardware random number generator. It's the most obvious high-value target, it's inherently almost undetectable (the output of a CSPRNG is indistinguishable from real random numbers), and you can keep crypto researchers busy with fights about whose cryptosystem is best, safe in the knowledge that it doesn't matter what they come up with, they were owned from the start.
^ that is what that is. Or, in more detail: https://github.com/Enegnei/JacobAppelbaumLeavesTor/blob/mast...
You can't connect real things like these documents with slander by people who do nothing to step on the toes of the NSA. That is all that the BS about Assange or Appelbaum being a sex menace or Snowden being a Russian asset is. "Oh noes, they're a threat to the work we're not doing". Nobody is asking you to get drinks with Assange or Appelbaum. They don't want to be your friend. It's okay if you don't like them, for whatever personal reasons (and choosing to fall for this crap falls under personal reasons). It's not okay to be part of a mob that murders people by throwing a pebble each with this plausible deniability, in this "genuinely curious" just wondering kind of way. Enough is enough.
It certainly isn't fascinating. 3 letter agencies are torturing and murdering people, and having nothing better to do than gossip about gossip about messengers is just vulgar, boring, infantile cowardice, puffed up with not even clever words.
I didn’t know who this was, others probably too.