Comment by maxtaco | Hacker News Reader

Comment by maxtaco | Hacker News Reader

Parent Full thread

Thank you for your reply and expanded comments.

The adversary we are most worried about is a government agency in 2023 demanding a large Website turnover of all live data, backup data, and backup tapes. If a weakness in AES is found sometime before then, the agency can decipher secret data offline and in parallel, regardless of when it was uploaded to the server. In other words, the attack window for encrypted data stored on a server is infinite. If we're encouraging the upload of encrypted data to the server, the encryption has to be future proof, since server-side data is in practice never thrown away.

In the attack you mentioned, the secrecy of TLS via AES isn't at issue since there is nothing secret about our open-source libraries. If the integrity of TLS is broken (due to a real-time exploitable weakness of SHA1-HMAC or of the public key system used in session negotiation), then only those who upload data in the attack window are vulnerable. Those who downloaded and used TripleSec code before the discovery of the attack are not at risk, and of course those who use it after TLS is fixed are also OK.

Finally, I see no problems with older (i.e., 90s era) crypto constructions that haven't been broken. RSA from the 70s is still useful. The cipher cascade here is essentially a one-time pad, so predates Schneier and is better attributed to Shannon 1949: http://netlab.cs.ucla.edu/wiki/files/shannon1949.pdf

Nobody has told you that cipher cascades are insecure. They're just silly.

The problem with your threat model is that it handwaves away the actual NSA threat --- that they will actively intercept your data and decrypt it on the fly by breaking TLS --- and then doubles down on an imaginary threat (that they will break AES and Salsa20 but find themselves foiled by the cascade that added Twofish). Then you take that weird construction and advertise it as a way for developers to NSA-proof their applications. Cryptocat does a better job!

Also, again: Twofish? Huh?

Here's what Nate Lawson had to say about this system:

Item! NSA is attacking implementations, of which there are too many and too diffuse an interest from cryptographers to secure.

Solution! another implementation of JS crypto, with triple redundancy for the only thing the NSA can't break.

Or, how about Matthew Green?

People: while I appreciate that you are earnest, we do not need to encrypt with AES+Salsa20+Twofish. Especially not in Javascript.

Composing three ciphers in Javascript crypto is like building a survival bunker, then locking your keys inside.

But who knows, maybe they don't "know the crypto" either.

And, for what it's worth, when you wrote your dismissive (and incorrect) blurb about my "rant" about Javascript cryptography, you might have considered reading Nate Lawson's as well. For that matter, you might try to find any professional cryptographer with something good to say about doing crypto in browser Javascript.

Well, I am done here. I imagine if we ever met each other in person we'd find each other reasonable people, but over these channels it's not coming across. Until then, good luck.

And I can't resist: you'd be hard pressed to find a better cryptographer than Dan Boneh, one of the authors of SJCL.

Have you read the front page of SJCL? It includes a warning about the relative insecurity of browser Javascript cryptography.

You do this a lot: weird little namedrops (Langley, Boneh) that aren't quite saying what you want them to say, and smug dismissals, such as your characterization of "my rant" about Javascript cryptography as (a) the sum total of all arguments against Javascript crypto and (b) disproven by modern browsers†, or things like "look at what Adam Langley, who knows the crypto, says". What's more annoying is that you use both tactics as a smokescreen, as if to suggest that you were responding to the criticisms I've offered, when you are in fact dodging them.

You want more consideration from me than you're willing to extend to me. No, I don't think the conversation would be much different in person.

That's fine, by the way. I'm not a gatekeeper and you don't need my approval to do anything. I simply stand by my recommendation: I don't right now think people should use the tool you've built, or anything like it.

† You've since edited this page, but we both know what it said.

Reply on news.ycombinator.com