5 ms·

Is there any justification to your comments? Your criticisms on the crypto have all been debunked by those who know the crypto. See here for an example: http:/

by maxtaco 13y ago

Is there any justification to your comments? Your criticisms on the crypto have all been debunked by those who know the crypto. See here for an example: http://d3j5vwomefv46c.cloudfront.net/photos/large/810438785.png?1379813991 http://d3j5vwomefv46c.cloudfront.net/photos/large/810438785.... Again, I am open to valid criticisms. Those of the form "this is stupid because XSS isn't solved" aren't valid in my book because they are orthogonal problems, and progress along either axis is good.

tptacek 13y ago
What a weird comment. All Adam Langley seems to have to say about your system is that you didn't use a weak cipher composition but did use a weak MAC composition, and all I have to say in that thread is that I didn't think the Joux multicollision attack he was referring to applied. And yet somehow, presumably by ignoring the other cryptographers criticizing this design at the same time, you synthesized a narrative about how "my criticisms" were "debunked". Here's the problem I have with your design: it doesn't make any sense to me. So worried are you about the NSA's ability to break AES or Salsa20 --- a worry not apparently shared by cryptographers, so far as I can tell --- that you resurrect Bruce Schneier's 1990s-era block cipher cascade, chaining Twofish(?!), a modified(?!) Salsa20, and AES. But so confident are you in the safety of Javascript crypto that... you deliver that code over an AES-encrypted TLS channel. I don't get it. What was the point of this again? How is anything you're doing making it harder for the NSA to subvert your comms? They're a single AES key away from rewriting your entire cryptosystem.
- agwa 13y ago
  > a modified(?!) Salsa20 Other concerns aside, XSalsa20 is undeserving of your indignant reaction: it was created by DJB himself and was proven by him to be secure if Salsa20 is.
  - tptacek 13y ago
    I'm not indignant, just confused.
  - maxtaco 13y ago
    Agwa, thanks for coming to DJB's and my defense. Unfortunately, anyone who disagrees with tptacek gets an automatic downvote.
    - tptacek 13y ago
      You have never in your life seen me criticize anything Bernstein said. You've once again deliberately mischaracterized something I said in order to replace rational discussion with emotional appeals. Here you've done it on two dimensions, first by suggesting that you're standing shoulder to shoulder with Daniel Bernstein, which you are not, and then by attempting to personalize the discussion to make it appear that you have a specific conflict with me, when in fact I just pointed out upthread 3 cryptographers, all of them smarter than me, who also had negative things to say about your design. I don't think this style of argumentation is helping you. I think it makes it sound like you don't have good responses to technical criticism. But that's just me.
- maxtaco 13y ago
  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 http://netlab.cs.ucla.edu/wiki/files/shannon1949.pdf
  - tptacek 13y ago
    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.

by maxtaco 13y ago

tptacek 13y ago

What a weird comment. All Adam Langley seems to have to say about your system is that you didn't use a weak cipher composition but did use a weak MAC composition, and all I have to say in that thread is that I didn't think the Joux multicollision attack he was referring to applied. And yet somehow, presumably by ignoring the other cryptographers criticizing this design at the same time, you synthesized a narrative about how "my criticisms" were "debunked". Here's the problem I have with your design: it doesn't make any sense to me. So worried are you about the NSA's ability to break AES or Salsa20 --- a worry not apparently shared by cryptographers, so far as I can tell --- that you resurrect Bruce Schneier's 1990s-era block cipher cascade, chaining Twofish(?!), a modified(?!) Salsa20, and AES. But so confident are you in the safety of Javascript crypto that... you deliver that code over an AES-encrypted TLS channel. I don't get it. What was the point of this again? How is anything you're doing making it harder for the NSA to subvert your comms? They're a single AES key away from rewriting your entire cryptosystem.

agwa 13y ago
> a modified(?!) Salsa20 Other concerns aside, XSalsa20 is undeserving of your indignant reaction: it was created by DJB himself and was proven by him to be secure if Salsa20 is.
- tptacek 13y ago
  I'm not indignant, just confused.
- maxtaco 13y ago
  Agwa, thanks for coming to DJB's and my defense. Unfortunately, anyone who disagrees with tptacek gets an automatic downvote.
  - tptacek 13y ago
    You have never in your life seen me criticize anything Bernstein said. You've once again deliberately mischaracterized something I said in order to replace rational discussion with emotional appeals. Here you've done it on two dimensions, first by suggesting that you're standing shoulder to shoulder with Daniel Bernstein, which you are not, and then by attempting to personalize the discussion to make it appear that you have a specific conflict with me, when in fact I just pointed out upthread 3 cryptographers, all of them smarter than me, who also had negative things to say about your design. I don't think this style of argumentation is helping you. I think it makes it sound like you don't have good responses to technical criticism. But that's just me.
maxtaco 13y ago
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 http://netlab.cs.ucla.edu/wiki/files/shannon1949.pdf
- tptacek 13y ago
  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.