NSA infiltrated RSA security more deeply than thought: Study | Hacker News Reader

NSA infiltrated RSA security more deeply than thought: Study

reuters.com

425 pointsLibertatea97 comments

The extended_random_value extension is by itself innocuous; in fact, in its historical context (2008), it's just on the edge of plausibly beneficial.

All extended_random_value does is add, to the random_bytes value in the TLS handshake, another variable-length blob of random data. The ostensible idea behind the extension is that there are protocols that want randomness proportional to key sizes, and the 28 random bytes already in the handshake are insufficient.

That is all the extension does. It doesn't influence your random number generator, it doesn't change the crypto algorithms in TLS.

Now, extended_random_value is not innocuous in 2014. There's a very good chance that the PKRNGs (Dual_EC and the like) are intended as cryptographic backdoors, and modern sensibilities about crypto protocols dictate that both sides of a protocol should be careful about "showing all their cards" (as it were) when it comes to random number generators. It's now thought to be risky to disclose too much state.

But that was definitely not the attitude in place in the early 2000s --- more randomness was better.

Finally, it's worth knowing that nobody uses extended_random_value. Even fewer people were exposed to it than were exposed to Dual_EC (which very few apps were --- so few that, from what I can tell, nobody has ever named such an app on HN [companies using BSafe do not equate to apps using Dual_EC, much less exploitably]). Even the Internet Draft seems quizzical about why the extension would exist, and it more or less says "you'd use this if your TLS needed to be compatible with the DoD".

PS: It's been a few months since I looked, but interesting to note: the mailing list discussions about extended_random_value were also skeptical about the intention behind the extension. Rescorla more or less said (IIRC) "the USG asked me to specify this so they could use TLS". Nobody on the TLS WG ever told an implementor that they should adopt this.†

PPS: Whatever 'pbsd says that conflicts with this comment, believe the 'pbsd comment, not mine. :)

† I'm a little wrong here; the mailing list discussion I'm thinking of is about OpaquePRF. But OpaquePRF is basically the same concept, and by the same authors; extended_random_value is a refinement. Neither was standardized.

Maybe OT, but what's PKRNG?

Public-key RNG; an RNG that has asymmetric structure.

The concept of PKRNG and how it ever could be innocuous got debated on Twitter last year, and (I think) Matt Blaze pointed out that you might want one in order to constrain the number of different math/crypto operations you relied on in your protocol. If your security already depends on number-theoretic crypto because (for instance) you use DSA, you might think "in for a penny, in for a pound" regarding discrete log, and use an RNG that has the exact same dependency; the thought might be that there's only one thing that could then go wrong to destroy your security, not several.

That said: PKRNGs are weird, uncommon, and (in 2013-2014) very shady. They're also very slow. Nobody uses them.

The draft (the last version I've found is March 2009):

http://tools.ietf.org/html/draft-rescorla-tls-extended-rando...

(The first seems to be "Opaque PRF Inputs for TLS" from December 2006. http://tools.ietf.org/html/draft-rescorla-tls-opaque-prf-inp... so the process lasted more than two years)

The relevant parts from the last:

   TLS [I-D.ietf-tls-rfc4346-bis] and DTLS [RFC4347] use a 32-byte
   "Random" value consisting of a 32-bit time value time and 28 randomly
   generated bytes:

         struct {
            uint32 gmt_unix_time;
            opaque random_bytes[28];
         } Random;

   The United States Department of Defense has requested a TLS mode
   which allows the use of longer public randomness values for use with
   high security level cipher suites like those specified in Suite B
   [I-D.rescorla-tls-suiteb].

   This document defines a new TLS extension called "extended_random".

   The "extended_random" extension carried in a new TLS extension called
   "ExtendedRandom".

        struct {
            opaque extended_random_value<0..2^16-1>;
        } ExtendedRandom;

Note how they used the notation that casually looks smaller as in "there's 2 and 16 and 1" when they actually mean up to 65535 bytes (I've first thought it's fixed but it looks the length is a subject of negotiation).

Roughly 2300 times more than the default 28 bytes.

TPtacek says: "It's now thought to be risky to disclose too much state. But that was definitely not the attitude in place in the early 2000s --- more randomness was better."

I can't imagine that there was ever an attitude that it's not risky "to disclose too much state."

I'm not sure what you're trying to say here that my comment doesn't already say.

It might be helpful to note that there are crypto people --- some of the authors on the recent Dual_EC exploit paper included --- that believe TLS already discloses too much random state, even without the TLS extension.

I think it's uncontroversial in 2014 to say that any more state disclosure --- 2 bytes, 200 bytes, 16k bytes --- is probably not a good thing.

It might be a little controversial to say this next thing, but I'll stand by it for the sake of an interesting argument: in 2005, when this discussion started, it was not known to be a bad thing to increase the amount of random state in the handshake.

As Thomas is not sure what I'm "trying to say here that" his "comment doesn't already say," he actually wrote: "All extended_random_value does is add, to the random_bytes value in the TLS handshake, another variable-length blob of random data."

It sounds smallish "just another random-data blob." It's actually huge "up to additional 65365 bytes from the generator added to the default 28" before the encryption even starts.

Thomas also wrote "The ostensible idea behind the extension is that there are protocols that want randomness proportional to key sizes."

The biggest ECC key is 571 bits which fit in just 72 bytes and this thing provides up to 65535 bytes. Again, fully different impression. I quoted the draft to show the actual number. The numbers matter here. Hadn't I looked at the draft directly, I'd get the fully different impression only reading Thomas' comment.

I think you're missing the part where people can make credible arguments that twenty eight bytes of random state (the protocol as standardized) is already a problem. The difference between 10 and 60,000 extra bytes seems to make a big difference to you, and, fair enough I guess, but the underlying problem isn't the size of the random state.

Read the Dual_EC exploit paper that just came out; the authors used minimal compute resources and standard TLS to exploit a model Dual_EC problem.

About that (even a little more over 28 bytes makes the big change) we can agree: The paper http://dualec.org/DualECTLS.pdf shows that exploiting Dual EC takes hours (without additional bytes), but that RSA (intentionally or unintentionally) managed to adjust the BSAFE C implementation to enable especially easy exploits: in seconds vs more than an hour on the 16-CPU AMD cluster for other implementations (Table 1 in the PDF). The reason:

"due to the use of the requested number of bytes rather than the number of remaining bytes after pulling from the cache, the concatenation of the 32-byte session ID and the 28 pseudorandom bytes in the server random always contains a full 30-byte output block and between one and 30 bytes of a subsequent block."

So the 28 default bytes take hours, just adjusting that a little to push always continuous 58 bytes from the PRNG resulted in reducing the exploit time to seconds. The small number of bytes more, the big difference.

Paper's conclusion: "Our analysis strongly suggests that, from an attacker's perspective, backdooring a PRNG should be combined not merely with influencing implementations to use the PRNG but also with influencing other details that secretly improve the exploitability of the PRNG."

This is exactly why having the "extended_random_value" too was so convenient to the NSA.

That's offline time, isn't it? In other words: the numbers we're talking about are based on the computing resources available to these researchers. It's not as if not having extended_random_value or OpaquePRF means the NSA needs to monitor many many TLS connections, right?

To me it looks that the "just seconds" on the off-the-shelf hardware means that creating the custom chip can allow for a large-scale real-time online decryption of "many many" connections. And even if such a chip is not feasible, additional bytes do make attack much more scalable and reduce the possible response times significantly.

Maybe we're talking past each other. I'm saying, there are different kinds of complexities in implementing attacks on TLS.

The first, most obvious kind is what this paper is talking about: the amount of raw compute it takes to break whatever part of the protocol you're targeting. When this paper says it takes minutes (or seconds) to reverse model Dual_EC, they're referring to the amount of time it takes to work out the current state of the RNG from the partial state disclosed in the TLS handshake.

Another complexity is the kind we saw in the RC4 attacks, where you're exploiting a statistical bias recurring over many connections. It doesn't matter how fast your computer is, because the attack requires your victim to make large numbers of related requests to the target system. That's the "many many" I'm referring to. A TLS handshake change that took NSA from needing 2 million connections down to 1 connection would be extremely bad.

For full context, another complexity is the nature of the TLS connections we're talking about. The RC4 attacks we've seen depended on the BEAST attack model, where attackers could predetermine which connections the victim made (owing to the control HTML/JS gave them); that attack is much more difficult to carry out over other application protocols. So, similarly to the point I just made above, it would also be very bad if a protocol extension took an attack that only worked in the BEAST model and made it work in (say) the SMTP STARTTLS model.

Just to be clear: with Dual_EC, we're already in the worst-case scenario with or without TLS extensions. If a group of researchers with a straightforward hardware setup can reverse the RNG state in an hour, it's reasonable to assume that NSA (if it cares about this attack, and I think it does) can do it in real time.

Incidentally, here are the original requirements that these drafts were intended to satisfy:

   In a number of United States Government applications, 
   it is desirable to have some material with the following 
   properties:

   1.  It is contributed both by client and server.
   2.  It is arbitrary-length.
   3.  It is mixed into the eventual keying material.
   4.  It is structured and decodable by the receiving party.

(Amusingly, this comment got downvoted.)

That is what they appeared to satisfy then (2006-2009). We know now that if implemented it would allow them almost real-time or even real-time decryption of communication of whoever uses it, as we discussed here:

https://news.ycombinator.com/item?id=7503287

We also know extended_random_value is actually implemented in RSA's BSAFE library, as the paper http://dualec.org/DualECTLS.pdf shows.

And we know http://security.stackexchange.com/questions/43164/which-prod...

"the RSA BSAFE library uses Dual_EC_DRBG (...) by default (...)

I can easily find (hint: use your favourite search engine to search for the terms "This product includes" "RSA BSAFE") implementations, oddly skewed towards imaging and gaming devices: surprisingly many printer/copier/fax devices use BSAFE, though for unknown purposes.

Including Ricoh, Minolta, Océ/Canon, Brother, Fuji/Xerox, Epson ...

Your Playstation (PDF), PSP, or your Nintendo DS wifi (PDF)

Software from Adobe, Hitachi, Oracle and HP Some Nokia phones(PDF)"

Which of those products do you know to actually be using Dual_EC at all?

At least, every product which uses defaults of the library? You know, "leave the hard choices to the experts who know more."

Can we name one of them that uses Dual_EC, and has been shown to do so? I know a little about BSafe, and my impression is that most programs that use it don't use it to get TLS, which their OS already provides. Feel free to correct me if you've got more BSafe experience than I do.

This is obviously a rehash of an argument that recurs on HN a lot, but just to be fair to what I'm trying to say here: that argument has (as far as I can tell) never been resolved.

So who needs, apart from the spies from other countries and TPtacek more precise list of the possibly vulnerable products than the one already here? I don't think many people see the benefits in making the list more precise. The companies mentioned have all the incentives to remain silent.

All things being equal I'd rather know more than less.

Remember, I'm not asking how many vendors keep the BSAFE default. I'm asking how many use BSAFE in a way where the RNG matters.

Isn't your company's business to discover the security flaws? I believe the fact that you don't know the details means that there isn't much interest, at least in your part of the world, to fund such a research. There are no incentives for academia to make it too. All that doesn't mean the list doesn't exist, only that there is no economic reason to publish it.

No. My company provides an engineering service for vendors to find security flaws in specific pieces of software before (and sometimes after) that software ships. You should think of us as part of the development process.

If you gave us a piece of software that used BSAFE, you could reasonably expect detailed mitigation advice on not having a PKRNG exposed in your system.

No process in the market compensates us for acquiring a Ricoh printer and digging into its firmware to find how any why it's using BSAFE. It's not an especially interesting research project either.

I'm not surprised we don't know which products actually use Dual_EC, and I don't find the fact that we don't particularly telling. I'm saying something different: that I have worked with software that used BSAFE, and it used BSAFE for idiosyncratic reasons that didn't much implicate Dual_EC. I would not, for instance, be at all surprised to find an embedded device that used BSAFE for some goofy thing, but used OpenSSL as its TLS library.

The only "process in the market" for this kind of work is individuals or companies breaking random things in public to build their reputation as auditors (e.g. homokov), or selling vulns. But as you point out it's only really awesome when you follow the Cryptography Research model: find a new class of attack, develop the countermeasure, package (potentially patent) the countermeasure, then make scary demos of the attack to get responsible parties to buy your countermeasure.

In this case the mitigation is so simple ("don't use PKRNG; avoid RSA, Inc. going forward.") that it's not monetizable, so it's really only for reputation points.

This is almost certainly not true given the fact that ECDRBG is chronically slow (think orders of magnitude). Any developers working on implementations which generate a reasonable amount of random data switch to HMAC very quickly.

So "it's not true that companies who use default use default because if they use default they will measure the speed and then not use default?" Too much reading Catch 22?

In fact, the companies who use default simply use it. Period. And they use default in spite of it being slower than something else.

I think that's a very long bow to draw... Especially seeing as the trouble shooting guide for bsafe libraries has a section dedicated to speeding up the toolkit which advises switching to HMAC.

I'm not sure about you, but when I see a chronic change in performance I look into it, and if there is a vendor recommended suggestion, I usually try it.

This is particularly true for the Java tools as it is trivial in the extreme to compare the bsafe performance with the standard oracle crypto performance.

Basically, as tptacek points out, there is a lot of information we aren't privy to and there is no point assuming every bsafe customer is using ec .

When the company uses the default in the product, it uses it. There's nothing "to draw." It's a true statement, not a hypothesis.

And it has nothing to do with what you do when you "see a chronic change in performance." If somebody uses something and not something else, there's no "change" at all. Nobody ever claimed "every customer uses Dual_EC."

The claim is: there are a lot of famous customers and products using BSAFE and the Dual_EC is the default in BSAFE.

Interestingly, Dual_EC can still be negotiated in other implementations too. Poisoning the standards sets leaves some possibilities as long as the dangerous implementations are present.

The big problem with the claim that "lots of famous customers and products use BSAFE" is that the statement by itself doesn't mean much. Does BSAFE provide the TLS library for Cisco IOS? Neither of us probably has a ready answer, but if you'd like to put some money on which way this will go, I'm game.

For awhile during the late 1990s, some products used BSAFE because there were patent concerns with using any public key encryption in a commercial product, and BSAFE was an innoculation. Also, some products have codebases that date back before credible open-source crypto libraries. But those same products tend to have crypto features that were implemented later.

Like I said, we do a lot of casual reversing, and we look at a lot of random products that big F500 companies deploy, because F500s pay us to do that. I see a lot of OpenSSL. After that, I see a lot of Windows Cryptography API. Next in line is probably cryptopp, and then Bouncycastle. I see BSAFE once in a blue moon.

The more I think about it, the more interesting the research project of working out exactly why different products depend or don't depend on BSAFE actually starts to sound.

This is interesting in that regard: http://dualec.org/. If this research is true, it seems that a number of servers use it.

There's an extra dimension to what might or might not have been known in 2005: Known to whom?

Given that the standards in question are already widely believed (to put it mildly) to have been deliberately weakened by the NSA, which still has quite a bit of nonpublic crypto knowledge, you really have to keep that in mind as well.

In addition, "requested by the Department of Defense" strikes me as a big warning.

It was known to the NSA that it was bad before it was known to the public, obviously.

Right, that's true. I think I pointed that out because I'm knee-jerk waiting for the horrible "Eric Rescorla is an NSA plant" arguments --- which, as it turned out, never really came.

Is there a safe generator (CS-PRNG) where more state disclosure does NOT compromise the generator?

What if you needed to disclose 1MB of state. What about 1TB?

The problem with Dual_EC is that you're disclosing state at all; most RNG designs don't do that.

draft-rescorla-tls-extended-random says: "A cryptographically secure PRNG [RFC4086] SHOULD be used."

RFC 4086 Section 6.2: "The correct technique is to start with a strong random seed, to take cryptographically strong steps from that seed [FERGUSON, SCHNEIER], and not to reveal the complete state of the generator in the sequence elements."

In other words, you should not reveal the complete state of your PRNG regardless of how many values you disclose, and the authors explicitly warned against using a PRNG that does so (in practice every PRNG with finite state will cycle at some point, at which point all future values become predictable, but good designs have cycle lengths in the range of 2^(several thousand), so 1 TB of random data is no problem).

Are there any details on how negotiation is handled? I think this may be innocuous by itself, however coupled with the software that requests large amount of randomness it is dangerous.

It's not innocuous. There's no debate here about whether it's a good idea to have protocol participants expose extra random state on the wire. They shouldn't.

As for details: we're talking about public Internet drafts.

Considering how rarely this was used, and the small amount of money ($10m) involved, I think this activity was designed for a specific system (or family). Perhaps something sold to an ally.

A far bigger issue is "The NSA played a significant role in the origins of Extended Random. The authors of the 2008 paper on the protocol were Margaret Salter, technical director of the NSA's defensive Information Assurance Directorate, and an outside expert named Eric Rescorla."

Given Rescorla involvement with the TLS standard and Mozilla it's concerning that he declined to comment on this.

I'm maybe too naive/optimistic but I think the most likely is that he has been manipulated in co-authoring a document which by itself is innocuous but once coupled with a rigged prng might have disastrous effects.

Sure, he might be innocent, but he really needs to put out a statement clarifying what his involvement was and what he knew.

Mozilla should probably hire an independent auditor to review all of his code changes. It might be unnecessary but this seems to be a scenario where it's better to play it safe (plus always good to audit security related code).

>Sure, he might be innocent, but he really needs to put out a statement clarifying what his involvement was and what he knew.

Why does he need to do that? What benefit will it be to him? If he said he was unaware of any underhandedness would you believe him? Do you think that if he was aware that he wouldn't have signed NDAs about these things?

Well there's at least one other document coauthored by M Salter and E Rescorla [1], so the notion that Rescorla was manipulated into co-authoring the Extended Random paper has is a bit more problematic since it wasn't a one-off collaboration.

[1]http://tools.ietf.org/html/draft-ietf-tls-suiteb-00

That's the TLS standard for all of Suite B, which until recently was the de facto standard way virtually all software used elliptic curve crypto. It's not exactly a sketchy RFC.

The word "collaboration" is funny here too, given how the IETF works. These people shared a mailing list. Rescorla is perhaps the most experienced person on the Internet at turning TLS WG mailing list discussions into Internet drafts. That his name would be on any number of TLS RFCs is about as surprising as seeing Mockapetris' name on a DNS RFC.

Fair enough. I'll admit my speculation is about as useless as hypothesizing Rescola was somehow manipulated by the NSA into putting his name on the extended random paper.

It's also very concerning that are least 2 NSA employees working within IETF groups as far as I know, and they don't want to get rid of them. One is the one Trevor Perrin called out from the CFRG, but I remember someone else calling out another on a security blog, either months before the Snowden leaks came out or soon after.

NSA is not to be trusted in terms of security anymore, when by far their main priority these days is to undermine the security of protocols. If certain organizations don't want to get rid of them, then I can't trust that organization either. And I don't care how much of a "good guy" he is within the organization. It's probably his job to play the good guy.

Having NSA employees standardizing TLS extensions is about as surprising as having Google employees standardizing HTTP extensions. The NSA isn't just a bunch of spies; they're also the managers of the US government's crypto infrastructure.

If the USG wants to make some devices--secure phones, say--that use TLS in a weird way, but wants other devices--commercial off-the-shelf routers, say--to be able to interoperate with those devices, then the USG gets the NSA to draft a TLS extension allowing the routers to consider the behavior of the secure phone normative.

Careful with how you word this. Rescorla isn't an "outside expert"; he's been at the center of TLS standards for almost a decade now (he's also the author of SSLDump, which is/was a very useful tool). It's not hard to see why Rescorla would get roped into this: he's a standards sherpa. If you want to get some oddball extension you need for your internal systems specified, so that other systems might interoperate with yours, Rescorla is naturally the person you'd turn to.

Rescorla's name on an Internet draft is hardly an endorsement from Rescorla. I'm not sure that's how you're supposed to read any Internet standard; it happens to often be true, but it isn't always true. Sometimes those things get written with their authors holding their noses.

It's a direct quote from the Reuters article; but my point is that saying "no comment" isn't a good approach in the circumstances.

Reuters should be especially careful about how they word things, given the size of their readership and the authority people invest in their reporting.

In the press "declined to comment" doesn't mean that the person responded "no comment", as far as I can tell. It means the person did not respond.

I've seen a few cases of press folks sending an email with a question and then going to press an hour later claiming that the addressee of the email (who happened to be 12 timezones away and asleep, as it happened) "declined to comment".

Mozilla?! wow this is going to hurt their image...

I remember when this first broke getting heavily downvoted for suggesting that RSA wasn't paid $10 million to create a backdoor for their customer's as everyone was implying at the time. Rather, they (naively) were paid to joint develop a technology that would be a marketing dream "Hey this included help from the brightest minds at the NSA so why wouldn't you use it for your own organization?!"

So I found this quote to be very interesting: "We could have been more sceptical of NSA's intentions," RSA Chief Technologist Sam Curry told Reuters. "We trusted them because they are charged with security for the U.S. government and U.S. critical infrastructure."

They took the money and then accepted NSA's "help".

"We trusted them because they are charged with security for the U.S. government and U.S. critical infrastructure."

Which is true, and as examples we have SE Linux and apparently strengthening the S-boxes of DES against differential cryptanalysis, which had not yet been independantly discovered by public researchers (https://en.wikipedia.org/wiki/Data_Encryption_Standard#NSA.2...).

However, that was then; now, we legitimately trust the NSA a lot less, but I'm not sure we should blame RSA too much for not noticing the transition.

I'd also note that I arrived at MIT a couple of years after RSA was first published, and I heard various rumors that there were rather intense sub rosa interactions between the team and the NSA et. al. in that period. With a good outcome, but threats were made etc.

I've brought up the S-Box strengthening several times before, but it's important to note that the NSA pushed IBM to reduce the key length in DES. IBM wanted 64 bits, NSA wanted 48, and we all got 56 as a compromise; not entirely egalitarian work.

What I've been told is that 56 bits is pretty close to its actual effective security in the presence of differential cryptanalysis. So the key length was 'right sized' and it ended up having truth-in-labeling after all.

"We could have been more sceptical of NSA's intentions," RSA Chief Technologist Sam Curry told Reuters. "We trusted them because they are charged with security for the U.S. government and U.S. critical infrastructure."

PS: "We also would like to express that we believe the entire World to be a bunch of idiots."

The actual analysis is available here: http://dualec.org/

I don't see much cryptographically new here; authors stretched what is a simple attack into 17 pages, and noticed that some non-standard TLS extensions that increase the amount of random data on wire make the attack easier.

One of the authors of that duealec paper had this to say [1]:

>Our results <dualec.org> say nothing about whether NIST, the NSA, or anyone else inserted a backdoor into dual ec. Instead, they say that if you know the relationship between P and Q, then some TLS implementations can be broken at a given cost. The precise results are more nuanced than that. You can read the website for a summary or the paper for the details.

[1]http://www.ietf.org/mail-archive/web/tls/current/msg11730.ht...

Maybe not cryptographically, but it is definitely news and looks relevant for practical security engineering: they demonstate that the RSA BSAFE implementation in C was especially easy to be attacked compared to the other implementations: in seconds vs in hours, even without the newsworthy "extended_random_value."

The NSA is now actually making US infrastructure less secure. Consider that many companies will forego association with the most advanced security agency in the country. The country has placed it's best security resources in one pot and then spoiled it.

They're a resource that could have continued to provide valuable assistance. Instead, due solely to their organizational egoism, the NSA will be shunned and their advice dismissed as suspect.

Well it's a little more complicated than that: Other than the uniformity problems dual-drbg is a secure PRNG … against anyone who doesn't know the matching discrete log for the parameters.

If you don't consider a cryptographically locked single party back-door to be "less secure" then I don't think we can point out where they've done something to make things less secure.

Most likely also Vasco security tokens since NSA owned Digitalnotar which Vasco owns.

CA is a flawed security model with governments wanting to read all your data. Far to easy to forge a CA either by running one covertly or hacking into one.

One subset of users will get man in the middle certificates and interception.

The other set will get normal certificates.

How many really check the certificate fingerprints and who issued the certificate?

I thought the evidence was pretty clear that Diginotar was pwned by the Iranians.

Those certs did end up on the .ir national ISP's firewall doing man-in-the-middle attacks on Gmail users within Iran.

It seems to me we are seeing a variant of the same problem that Ken Thompson articulated in his paper "Reflections on Trusting Trust."[1]

While not a compiler intercept of the sort Thompson is talking about, this is effectively a library intercept of critical crypto functions and it poses the same basic problem. I don't think the industry will ever be the same. I think more and more folks are going to demand source-level access to everything crypto-related, and cryptoanalysts are going to put a lot more effort into scrutinizing these things.

The NSA failed to heed the basic warning of the Greek drama: ὕβρις-ἄτη-Νέμεσις

Or in more familiar terms, "Pride goeth before a fall."

[1] http://cm.bell-labs.com/who/ken/trust.html

I just had too look up the Greek words:

hubris [ὕβρις] ‘outrage’; the opposite of dikē [δίκη]

dikē [δίκη], plural dikai [δίκαι] ‘judgment (short-range); justice (long-range)’; dikaios [δίκαιος] ‘just’

atē [ἄτη], plural atai [ἆται] ‘aberration, derangement, veering off-course; disaster; punishment for disaster’

nemesis [νέμεσις] indicates the process whereby everyone gets what he or she deserves

In other words, the basic formula of Greek tragedy is the hubris or outrageous pride overwhelming judgement, leading to deserved disaster. There's an additional subtext btw of exceeding prudent limits in "hubris."[1]

The thing here is that the NSA has acted out of hubris and exceeded prudent limits, and the result will be predictable. The deserved disaster will come from far more routine use of encryption, and this will deny legitimate law enforcement investigations many critical tools. While this is a cost that to some extent will be borne by everyone, it will particularly hit the NSA and law enforcement really hard.

[1] See "From Religion to Philosophy" by F. M. Cornford, 1914. Some parts are dated, but the general discussion of partition and nomos/nemesis is very well done.

Thanks for the book recommendation!

> The deserved disaster will come

It's still hard for me to see that. I don't know any person who started to more encrypt. And the companies will always have to fullfill the requests of the state:

http://www.theatlantic.com/technology/archive/2014/03/don-t-...

There's still a lot to be done to induce the significant change.

> It's still hard for me to see that.

If nothing else, criminals will take encryption far more seriously, which is where the real cost comes in from a LEO perspective.

> I don't know any person who started to more encrypt.

I have started to encrypt more, and new businesses are springing up with more encryption built-in. It's also something which has impacted Efficito's approach to security to some extent.

> And the companies will always have to fullfill the requests of the state

Sure. However as of now, there is no requirement that they be able to fulfil the requests, so the current struggle is really with coming up with systems where the administrator/cloud provider has no access. This will lead to predictable results, and the next battle will be over whether to require such providers to retain access. To my mind, that's the legal battle we must prepare for.

> "director of the NSA's defensive Information Assurance Directorate"

Now how many of you think dividing the NSA into defensive and offensive parts will do anything to restore trust?

The best defense is a strong offense!

One main argument for doing so has been that right now IAD has a conflict of interest.

Except that it doesn't; NSA has a conflict of interest, but they're already split internally.

Even if you split them into separate agencies they're still going to both be part of the USG so while that might reduce the risk of a conflict of interest somewhat, it wouldn't eliminate it.

After all, think of the existing reaction we get when actually independent agencies of the USG throw out comments in support of NSA's signals intelligence. If the NSC, Congress's intelligence subcommittees, Executive Office of the President, Department of Justice, various Inspectors-General, Dept. of Defense, FBI, and, oh yeah, the courts can all be looped into what hacktivists claim is a vast conspiracy to violate the Constitution, then what defense would splitting IAD out really be?

So then, we should just accept what NSA is doing?

I think that accepting what they are doing is the first step to fighting it.

> The system, called Dual Elliptic Curve, was a random number generator, but it had a deliberate flaw - or "back door" - that allowed the NSA to crack the encryption

I would very clearly draw the line at the point where the NSA is deliberately weakening national security by undermining widely used cryptography. Companies or even other government agencies are now easier targets because of the doings of the NSA.

> I would very clearly draw the line at the point where the NSA is deliberately weakening national security by undermining widely used cryptography

There was no "threat to national security" here. Unlike what we think of as a normal backdoor, this one is and remains completely in NSA's control, as long as they're the only ones with the private key underlying the Dual EC constants. So even knowing there's a backdoor in there somewhere, there's no way for other security agencies or hackers to break Dual EC (assuming, of course, that it's properly implemented, which is not a given, and NSA's changes may have made it harder to implement).

What's the best viable alternative to RSA SecurID?

Probably something like OATH (as used by google authenticator and similar software) or a yubikey. With yubikey you can even get your own HSM for the authentication server.

Thanks. I had heard about yubikey. will def check it out.

Might be worth to note that the YubiKey authors did mess up quite badly at one point in time:

http://www.lsv.ens-cachan.fr/Publis/PAPERS/PDF/KS-stm12.pdf

Mcaffee Pledge, Yubikey

Yubikeys are more secure than RSA

Duo Security[0] is awesome.

[0] https://www.duosecurity.com/

Is there an elliptic curve that is trustworthy?

Yes. There are many trustworthy curves. Elliptic curve cryptography in general has not been discredited.

To answer that you will have to define "trustworthy". I'm personally leaning toward trusting the curves proposed by Dan Bernstein [1], since he clearly explains the reasons for choosing the specific parameters and they're demonstrably valid.

[1]: http://cr.yp.to/ecdh.html

None of the issues being talked about in this story have anything to do with the trustworthiness of elliptic curves.

Does the word "NSA" still have a 60 percent upvote penalty here? It seems to be moving pretty slowly up. I understand using that sort of penalties if during a period of time the site gets flooded with those stories, but I don't think keeping the penalty forever is such a good idea, or at least not such a big one. Maybe make it "decay" over a period of time.

What is your documentation for saying that a particular word in a headline has any penalty at all?

AFTER EDIT: I guess I'm glad I asked, downvotes and all, because I see the link is to a source off HN, not to a statement from any of the HN moderators (which is what I was checking).

http://www.righto.com/2013/11/how-hacker-news-ranking-really...

Scratch HN moderators, here it is straight from the horse's mouth:

> "So already for the past week TSA stories have had an automatic penalty applied. Or more precisly, they've been autotagged as being political, which entails a penalty."

> "When anything gets over a certain number of flags, it shows up on a list that admins see. They decide either to kill it, mark it as political or whatever, or do nothing."

https://news.ycombinator.com/item?id=1934950

So, at least as of 3 years ago, HN both "autotags" and has admin driving tagging. Penalties are given to posts that have received particular tags.

Strictly speaking, "words in titles" may or may not be involved in that "autotagging", but given PG's history with content classification... I suspect it is.

I'm glad you asked. I was not aware of any published documentation of HN's algorithmic workings, and had the same question.

I also appreciate an established name in HN pointing out that the linked article was not from a moderator. It points itself out quickly, but it's nice to know something is derived information before clicking.

Derail!

This story is on the front page which suggests to me that the current system, whatever it is, can't be that broken. Meanwhile these meta discussions (of which I'm now a part) get tired pretty quickly.

You can tell that the article has been penalized by comparing it with the articles above it. Currently this article is at #7 with 168 points and 2 hours. The #6 article is at 179 points and 6 hours. The #5 article is at 172 points and 4 hours. Because time is weighted heavily (an exponent of 1.8), the NSA article would easily rank above these ones if there are no penalties. Thus, due to penalties, the NSA article is ranking a few spots below where it should, but is still on the front page.

Source: I did the righto.com analysis of how HN ranking really works.

It's been penalized, but you don't know how. It could simply be a bunch of flags.

Although these stories have a political dimension, they also have at least two other highly relevant dimensions:

1. Who can be trusted? Is it OK to have NSA employee participation in open source projects? Is it OK to mask contributor identity in open source projects that are widely used to provide security?

2. What are the technical measures US and other nations' Internet service companies can take to restore trust? Will any major provider provide auditable, buildable client software that implements end-to-end encryption?

Currently, the value of this set of issues is over $100B in lost business for US technology companies. What other $100B+ issues are on the table here where there are available technology solutions?

Reply on news.ycombinator.com