5 ms·

All attacks against JS crypto addressed assume a somewhat determined and active attacker. Although this is definitely the big problem to be concerned about, tha

by DCKing 12y ago

All attacks against JS crypto addressed assume a somewhat determined and active attacker. Although this is definitely the big problem to be concerned about, that does not mean that there is no place for JavaScript cryptography as protection against casual passive eavesdroppers. The problem is that users are quick to get a false sense of security because of this, not that JavaScript crypto is utterly without use. Having said that, the state of web cryptography is abysmal. There is work on a Web Cryptography API [1], but so far browsers only implement the part that concerns the generation of cryptographically secure random values. Even then, an attacker can use injected JavaScript to override the window.crypto functions, so they would need to be protected somehow. The lack of secure crypto prevents a whole class of applications from coming to JavaScript. Luckily my bank offers native apps, so I can just recommend my parents to use that instead of their website. [1]: http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/#scope-algorithms http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/#scope-al...

kofalt 12y ago
> assume a somewhat determined attacker Most CVEs that come to mind assume a somewhat determined attacker. It takes a reasonably determined attacker to commit to rails without permission [1] or run a ten-line perl script to crash a server [2] too. Waving away a problem via "the bad guys would need to think for more than one second" is not exactly reassuring. [1]: https://github.com/rails/rails/commit/b83965785db1eec019edf1fc272b1aa393e6dc57 https://github.com/rails/rails/commit/b83965785db1eec019edf1... [2]: http://www.ocert.org/advisories/ocert-2011-003.html http://www.ocert.org/advisories/ocert-2011-003.html
- Joeboy 12y ago
  > Waving away a problem via "the bad guys would need to think for more than one second" is not exactly reassuring. The NSA are well resourced, but I doubt they have much more than a second spare for every internet user on the planet. So speaking as a relatively uninteresting person, I actually would find that somewhat reassuring. If you're a Person Of Interest, that's obviously a very different situation, and you shouldn't use browser-based crypto.
  - kofalt 12y ago
    You're right to point out the difference between targeted and general attacks, but you're also misrepresenting the problem. An attack on SSL can take quite awhile to research and implement, but then can be used widely. One would expect the exact same scenario to play out with any javascript crypto library, as it does with all software. So, yeah - if you rolled your very own library that's unique to this planet for exactly one website, congratulations! You're secure as long as there are no attackers! Doesn't really say anything useful about your security though. Or about the viability of using a fundamentally broken crypto platform to do crypto.
- DCKing 12y ago
  JavaScript crypto is simply not a protection against that attack model. It is protection against the attack model of the passive eavesdropper. That's all I'm saying. I completely agree with what you say. Whether you view that attack model as something worth considering depends entirely on context. But it's a valid view for many applications. As long as people don't use it with any expectations of security under active attack models, I'd say that's okay.
  - kofalt 12y ago
    > protection against the attack model of the passive eavesdropper My argument would be that trying to protect against passive attackers with JS adds nothing beyond what SSL already offers. Which is already required as a matter of course, and already compromises the payload if SSL is broken (again).
    - DCKing 12y ago
      Sure, TLS probably covers many use cases. But if protection against overzealous public Wifi spots is your goal, or uploading encrypted files to something like Mega over HTTP, there are still uses that TLS cannot cover. Again, I am not advocating JavaScript crypto. I'm just putting it in its place.
    - flavor8 12y ago
      That's not true. Client side encryption allows the server to never have to touch user-generated content, which makes defense against subpoenas (and certainly blanket wiretapping) more feasible. It doesn't defend against the NSA who want to target a particular individual, but it's better than storing all content encrypted with the same known key, or storing it unencrypted.
      - kofalt 12y ago
        Which circles back to the "Javascript is hostile to cryptography" point the article makes; I welcome any expert-audited JS libraries that can accomplish secure file encryption, for example. But even assuming this blocker is overcome, any illusions are shattered by the F5 key. As pointed out elsewhere in the thread, there are few attacks that allow you to listen in on an SSL connection's content without also allowing you to modify that content - say, with a version that pastebins your keys. Hence my argument that JS cannot provide anything SSL lacks, plus or minus some wishful thinking. Combine this with the fact that it's impossible to protect against a MITM-modified JS payload (see the "chicken-egg problem" portion), and you have a rather uphill battle here.
valarauca1 12y ago
>assume a somewhat determined and active attacker Cryptology is founded on an academic, mathematical, and logical basis. Your don't assume your attack is active or determined, you assume that any flaw that exists could and will be exploited against you. The founding principle of modern cryptography is to paraphrase: "If an attack knows the entire system, but if they lack the key they cannot recover the data." >that does not mean that there is no place for JavaScript cryptography as protection against casual passive eavesdroppers Yes, it does. It means you are no longer using cryptography and simply doing obfuscation at that point. Mathematical crypto is out the window and gone, you admitted it. Your goal isn't crypto, but stopping casual and passive eavesdroppers. So you might as well use DES, or RC2. The algorithm doesn't matter any more. Its just a question of defining casual. :.:.: My post is regards to client side webpage crypto, not application level node.js crypto.
- DCKing 12y ago
  Diffie-Hellman also isn't secure against determined and active attackers (with power on the network). What you say about cryptology is utter nonsense. > Your goal isn't crypto, but stopping casual and passive eavesdroppers. So you might as well use DES, or RC2. The algorithm doesn't matter any more. Nonsense, it's not obfuscation. If it was obfuscation, people logging the sent data would have a reasonable chance of decrypting it. If you use JavaScript to AES encrypt things (with a good password), passive eavesdroppers cannot decrypt it later without breaking AES.
  - valarauca1 12y ago
    The weakness of Diffie-Hellman is authentication not the algorithm itself. >Nonsense, it's not obfuscation. The issue with in browser JS you seem to be completely missing is if you can't trust the network to deliver your message. How can you trust it to deliver your crypto unchanged, un-tampered, etc? The answer is you can't. If you create a system where you can, you render your crypto unnecessary.
    - DCKing 12y ago
      1. The weakness of plain Diffie-Hellman is that the data you receive (the other part of the key exchange) can be from someone you can't trust. You shouldn't use plain Diffie-Hellman if your attack model includes active attackers on the network. The weakness of JS crypto is that the data you receive (the JS crypto library) can be from someone you can't trust. You shouldn't use JS crypto if your attack model includes active attackers on the network. See what I did there? 2. Under the attack model of the passive eavesdropper, the assumption is that the crypto works because the passive eavesdropper does not tamper with JavaScript. Was this not clear from my previous posts?

by DCKing 12y ago

kofalt 12y ago

> assume a somewhat determined attacker Most CVEs that come to mind assume a somewhat determined attacker. It takes a reasonably determined attacker to commit to rails without permission [1] or run a ten-line perl script to crash a server [2] too. Waving away a problem via "the bad guys would need to think for more than one second" is not exactly reassuring. [1]: https://github.com/rails/rails/commit/b83965785db1eec019edf1fc272b1aa393e6dc57 https://github.com/rails/rails/commit/b83965785db1eec019edf1... [2]: http://www.ocert.org/advisories/ocert-2011-003.html http://www.ocert.org/advisories/ocert-2011-003.html

Joeboy 12y ago
> Waving away a problem via "the bad guys would need to think for more than one second" is not exactly reassuring. The NSA are well resourced, but I doubt they have much more than a second spare for every internet user on the planet. So speaking as a relatively uninteresting person, I actually would find that somewhat reassuring. If you're a Person Of Interest, that's obviously a very different situation, and you shouldn't use browser-based crypto.
- kofalt 12y ago
  You're right to point out the difference between targeted and general attacks, but you're also misrepresenting the problem. An attack on SSL can take quite awhile to research and implement, but then can be used widely. One would expect the exact same scenario to play out with any javascript crypto library, as it does with all software. So, yeah - if you rolled your very own library that's unique to this planet for exactly one website, congratulations! You're secure as long as there are no attackers! Doesn't really say anything useful about your security though. Or about the viability of using a fundamentally broken crypto platform to do crypto.
DCKing 12y ago
JavaScript crypto is simply not a protection against that attack model. It is protection against the attack model of the passive eavesdropper. That's all I'm saying. I completely agree with what you say. Whether you view that attack model as something worth considering depends entirely on context. But it's a valid view for many applications. As long as people don't use it with any expectations of security under active attack models, I'd say that's okay.
- kofalt 12y ago
  > protection against the attack model of the passive eavesdropper My argument would be that trying to protect against passive attackers with JS adds nothing beyond what SSL already offers. Which is already required as a matter of course, and already compromises the payload if SSL is broken (again).
  - DCKing 12y ago
    Sure, TLS probably covers many use cases. But if protection against overzealous public Wifi spots is your goal, or uploading encrypted files to something like Mega over HTTP, there are still uses that TLS cannot cover. Again, I am not advocating JavaScript crypto. I'm just putting it in its place.
  - flavor8 12y ago
    That's not true. Client side encryption allows the server to never have to touch user-generated content, which makes defense against subpoenas (and certainly blanket wiretapping) more feasible. It doesn't defend against the NSA who want to target a particular individual, but it's better than storing all content encrypted with the same known key, or storing it unencrypted.
    - kofalt 12y ago
      Which circles back to the "Javascript is hostile to cryptography" point the article makes; I welcome any expert-audited JS libraries that can accomplish secure file encryption, for example. But even assuming this blocker is overcome, any illusions are shattered by the F5 key. As pointed out elsewhere in the thread, there are few attacks that allow you to listen in on an SSL connection's content without also allowing you to modify that content - say, with a version that pastebins your keys. Hence my argument that JS cannot provide anything SSL lacks, plus or minus some wishful thinking. Combine this with the fact that it's impossible to protect against a MITM-modified JS payload (see the "chicken-egg problem" portion), and you have a rather uphill battle here.

valarauca1 12y ago

>assume a somewhat determined and active attacker Cryptology is founded on an academic, mathematical, and logical basis. Your don't assume your attack is active or determined, you assume that any flaw that exists could and will be exploited against you. The founding principle of modern cryptography is to paraphrase: "If an attack knows the entire system, but if they lack the key they cannot recover the data." >that does not mean that there is no place for JavaScript cryptography as protection against casual passive eavesdroppers Yes, it does. It means you are no longer using cryptography and simply doing obfuscation at that point. Mathematical crypto is out the window and gone, you admitted it. Your goal isn't crypto, but stopping casual and passive eavesdroppers. So you might as well use DES, or RC2. The algorithm doesn't matter any more. Its just a question of defining casual. :.:.: My post is regards to client side webpage crypto, not application level node.js crypto.

DCKing 12y ago
Diffie-Hellman also isn't secure against determined and active attackers (with power on the network). What you say about cryptology is utter nonsense. > Your goal isn't crypto, but stopping casual and passive eavesdroppers. So you might as well use DES, or RC2. The algorithm doesn't matter any more. Nonsense, it's not obfuscation. If it was obfuscation, people logging the sent data would have a reasonable chance of decrypting it. If you use JavaScript to AES encrypt things (with a good password), passive eavesdroppers cannot decrypt it later without breaking AES.
- valarauca1 12y ago
  The weakness of Diffie-Hellman is authentication not the algorithm itself. >Nonsense, it's not obfuscation. The issue with in browser JS you seem to be completely missing is if you can't trust the network to deliver your message. How can you trust it to deliver your crypto unchanged, un-tampered, etc? The answer is you can't. If you create a system where you can, you render your crypto unnecessary.
  - DCKing 12y ago
    1. The weakness of plain Diffie-Hellman is that the data you receive (the other part of the key exchange) can be from someone you can't trust. You shouldn't use plain Diffie-Hellman if your attack model includes active attackers on the network. The weakness of JS crypto is that the data you receive (the JS crypto library) can be from someone you can't trust. You shouldn't use JS crypto if your attack model includes active attackers on the network. See what I did there? 2. Under the attack model of the passive eavesdropper, the assumption is that the crypto works because the passive eavesdropper does not tamper with JavaScript. Was this not clear from my previous posts?