Live data from Hacker News

N.S.A. Foils Much Internet Encryption

nytimes.com

351–360 of 395 posts

Re: N.S.A. Foils Much Internet Encryption

#351
post #176

Earlier quoted context omitted.

Ah, yes, I wasn't trying to say they were exploiting that particular vulnerability. Just that we now have better evidence that that really was a (rather poor) attempt to subvert standards to make them easier to decrypt. The NSA seems to be really divided between SIGINT and COMSEC. COMSEC wants to provide good, strong encryption, that can help secure US government and corporate communication. SIGINT wants to be able t…

As you may well know, the NSA has its own ciphers (Suite A) it uses for top secret classified traffic, which to me is positive proof you can't trust anything they recommend (AES) - when they don't even use it themselves.

Not positive proof -- merely suggestive. Which is true of a lot of things in the secret world of the intelligence services.

The more you use a secret cipher, the easier it is to break. It is simply good operational practice to use a different cipher for a small fraction of communications -- namely, the most secret ones. Just like certain antibiotics are reserved for drug-resistant organisms. You don't want it to lose its effectiveness through overuse.

First, security-by-obscurity does indeed buy you some additional time. Because the cipher is secret, your opponent has to figure out the algorithm as well as the attack.

Second, this reduces the amount of traffic that the opponent can analyze. For example, suppose that only 1% of messages use Suite A, and 99% of messages use Suite B. With fewer messages to analyze, the job of breaking the cipher becomes much harder.

Third, the reduced volume also makes known-plaintext attacks more difficult. Especially if you avoid committing the cardinal sin of repeating the same message using two different ciphers.

Re: N.S.A. Foils Much Internet Encryption

#352

Earlier quoted context omitted.

As you may well know, the NSA has its own ciphers (Suite A) it uses for top secret classified traffic, which to me is positive proof you can't trust anything they recommend (AES) - when they don't even use it themselves.

They use AES when dealing with "outsiders", but I have trouble believing that they use it internally (and instead use the Suite A ciphers -- it's impossible for others to break them if they don't know anything about them, right?)

> (and instead use the Suite A ciphers -- it's impossible for others to break them if they don't know anything about them, right?)

It is possible to break an unpublished cipher. Just more difficult, because you've got to figure out the algorithm as well as the key. As long as it is similar to existing algorithms, you can try and look for differences.

For example, American cryptanalysts broke the Japanese Purple cipher during World War II entirely from encrypted messages. It was only at the end of the war that they managed to recover parts of one machine from the Japanese embassy in Berlin. No complete machine was ever found.

(In contrast, Enigma machines were captured, so cryptanalysts could directly examine the mechanism and use this knowledge to look for weaknesses.)

Of course, if the algorithm is completely novel, and bears no resemblance even to any principle used in published cipher, then it's a lot more secure. It would be hard to even begin to analyze it.

Re: N.S.A. Foils Much Internet Encryption

#353
post #169

Earlier quoted context omitted.

Look at what's happening in the UK, in Australia, in France, in Italy, in Spain... the Chinese model is winning hearts and minds of politicians everywhere, and how could it not? If you're into politics, you likely want to reach a Platonic ideal of harmonic society, where nobody is offended, nobody is threatened, and all laws are perfectly respected and enacted. You can't have that on a fully-open network. How can you…

Completely off-base. The US has, by longstanding tradition, had a more expansive attitude towards free speech than Europe. Consider blasphemy laws in the UK, which were only abolished in 2008 but would never have been constitutional in the US. Consider laws against Holocaust denial or displaying Nazi symbols in continental Europe that would be unconstitutional in the US. In Germany you can be arrested for displaying…

Maybe. In practice, however, even in the US there are and there have been censorship instruments, from the FCC all the way to Sen. McCarthy and Hoover. Today, US military personnel and civil servants are "protected" from wikileaks material by blocks at the network level. Federal pornography filters have been proposed several times, and on occasions it looked like they would become a reality. The US Constitution might be more benevolent than average on freedom of expression, but it doesn't mention TCP/IP anywhere.

Re: N.S.A. Foils Much Internet Encryption

#354
post #44

> The documents are among more than 50,000 shared with The New York Times and ProPublica, the nonprofit news organization, by The Guardian, which has published its own article. They focus primarily on GCHQ but include thousands either from or about the N.S.A. Is this the first time we've seen a 5-digit number to describe the number of documents Snowden has? Of course, these are just the ones used for this story...

I noticed that number as well and don't recall seeing it before, but I do seem to recall reading something about "multiple laptops" of Snowden's. Obviously, one can store a helluva lot of documents on three or four laptops.

Re: N.S.A. Foils Much Internet Encryption

#355
post #310
post #297

Earlier quoted context omitted.

I have written lots of Java code accessing HTTPS sites with 2048 or 3072-bit RSA. This is perfectly supported. You do not even need the Unlimited Strength Jurisdiction Policy Files to use such RSA key sizes (other algorithms are restricted). I can't comment on Android Browser on Google TV, but I very highly doubt it fails to support 2048-bit RSA keys. If that was the case, half the HTTPS websites would be unbrowsable…

We had downtime for this, so I am 100% sure. We isolated it to the key, and reverting the cert/key back to 1024 fixed it. It was just an option on GoDaddy one of the engineers picked to generate a 2048 cert. They only offer 1024 and 2048. One key worked, the other didn't.

[deleted]

Re: N.S.A. Foils Much Internet Encryption

#357
post #85

You can't have read Applied Cryptography from the mid-90s and not understand this to have been NSA's M.O. from the jump. Bruce Scheier, who was quoted in the Guardian piece about the same story, is America's foremost popularizer of the notion of NSA as crypto's global passive adversary. People who build real cryptosystems have never, ever been allowed to rely on the goodwill of the NSA not to cryptanalyze their syste…

What do you think the likelihood is of NSA doing (active) SSL MITM attacks using NSL'd CA keys?

Users running extensions that use things like EFF's SSL Observatory (SSL Everywhere has an option to report to that) will cause those NSA-generated certs to show up, and someone will get suspicious eventually. The only reports I've seen recently on that front were things like middle eastern users sending in samples of MITM certs. I'm not saying the NSA can't do it, but what evidence is there that the NSA has done MITM on SSL traffic? For all we know, couldn't the MITM ssl certs in the mideast be an NSA false flag op?

Re: N.S.A. Foils Much Internet Encryption

#358
post #290

Earlier quoted context omitted.

Was that really a seriously considered plan? I don't see how that would ever be a suitable /dev/random replacement. Obviously it works for /dev/urandom, but it should be added to the entropy pool for /dev/random at most.

Not only did it happen before, just TODAY I had to fight back an attempt by a Red Hat engineer who wanted to add a configuration option which would once again allow RDRAND to be used directly, bypassing the entropy pool: https://lkml.org/lkml/2013/9/5/212

"It's unlikely that Intel (for example) was paid off by the US Government to do this, but it's impossible for them to prove otherwise --- especially since Bull Mountain is documented to use AES as a whitener. Hence, the output of an evil, trojan-horse version of RDRAND is statistically indistinguishable from an RDRAND implemented to the specifications claimed by Intel. Short of using a tunnelling electronic microscope to reverse engineer an Ivy Bridge chip and disassembling and analyzing the CPU microcode, there's no way for us to tell for sure."

---

"The NSA's codeword for its decryption program, Bullrun, is taken from a major battle of the American civil war. Its British counterpart, Edgehill"

"N.S.A. spends more than $250 million a year on its Sigint Enabling Project, which “actively engages the U.S. and foreign IT industries to covertly influence and/or overtly leverage their commercial products’ designs” to make them “exploitable.”"

-- http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryp...

--

Bull Mountain, is Intel's code name for both the RdRand instruction and the underlying random number generator (RNG) hardware implementation.

--

bull [mountain|hill] [intel|processor]

http://www.googlewhack.com/ https://xkcd.com/936/ http://subrabbit.wordpress.com/2011/08/26/how-much-entropy-i...

Re: N.S.A. Foils Much Internet Encryption

#359
post #79

Earlier quoted context omitted.

It's a bit harder to sneak in junk in open source projects. You can see the checkins. However, you are right, if the flaw is in the algorithm itself, it's hopeless.

http://underhanded.xcott.com/ You can't rely on a backdoor looking like this: if(!strcmp(username, "secretagentman")) { … }

The Debian OpenSSL snafu showed that even rather blatant changes get missed.

Anything in the leaked docs on that particular incident?

Re: N.S.A. Foils Much Internet Encryption

#360
post #290

Earlier quoted context omitted.

Was that really a seriously considered plan? I don't see how that would ever be a suitable /dev/random replacement. Obviously it works for /dev/urandom, but it should be added to the entropy pool for /dev/random at most.

Not only did it happen before, just TODAY I had to fight back an attempt by a Red Hat engineer who wanted to add a configuration option which would once again allow RDRAND to be used directly, bypassing the entropy pool: https://lkml.org/lkml/2013/9/5/212

kudos.

did Linus ever comment on the roll-back ?

Post reply on HN