4 ms·

>assume a somewhat determined and active attacker Cryptology is founded on an academic, mathematical, and logical basis. Your don't assume your attack is activ

>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?
    - valarauca1 12y ago
      >[...]can be from someone you can't trust. So authentication? We are talking about Authentication right? Because I said that. The weakness of DHE is that you can't authenticate who are you are talking too. >You shouldn't use JS crypto if your attack model includes active attackers on the network. A crypto model has to include every possible attack vector. Crypto isn't something that happens in a vacuum. You assume the worst always. If you ever say, "No, nobody would go that far" you aren't doing crypto, your doing obfuscation. Once a message leaves your hand, everything that can go wrong, will go wrong. In crypto research people suggested moving away from SHA-1 because an attack was found, not because it was remotely possible but because it logically and mathematically existed. Crypto is about numbers and logics, not models and cost expense analysis, and what an attacker could do. Obfuscation is a game of frustration where you create a bar, and keep raising it. Your system is fundamentally broken, but you count on people getting frustrated, or bored. Before they break it. Its game of wits. :.:.: The system you're talking about isn't crypto. Its obfuscation. Your counting on somebody not moving beyond A,B, and C. Getting frustrated and giving up. Crypto doesn't do that.
      - DCKing 12y ago
        The weakness of JS Crypto is that you cannot authenticate the source of your crypto library so you cannot make sure it works properly. The problems are equivalent. All your ranting against what I'm saying is also directly applicable to plain Diffie-Hellman. Both simply are not secure under the active attacker model. That does not disqualify plain Diffie-Hellman from having some use (although not under most attack models), and that does not disqualify JS crypto from having some use (although not under most attack models). I'm going to respectfully decline discussing what attack models are and their use in security protocols on HN, as you unfortunately appear to not understand what I mean (which is probably my fault) or what attack models are used for in security research. You also appear to be confusing security research and cryptography research. You can mail me if you want to discuss this further.

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?
  - valarauca1 12y ago
    >[...]can be from someone you can't trust. So authentication? We are talking about Authentication right? Because I said that. The weakness of DHE is that you can't authenticate who are you are talking too. >You shouldn't use JS crypto if your attack model includes active attackers on the network. A crypto model has to include every possible attack vector. Crypto isn't something that happens in a vacuum. You assume the worst always. If you ever say, "No, nobody would go that far" you aren't doing crypto, your doing obfuscation. Once a message leaves your hand, everything that can go wrong, will go wrong. In crypto research people suggested moving away from SHA-1 because an attack was found, not because it was remotely possible but because it logically and mathematically existed. Crypto is about numbers and logics, not models and cost expense analysis, and what an attacker could do. Obfuscation is a game of frustration where you create a bar, and keep raising it. Your system is fundamentally broken, but you count on people getting frustrated, or bored. Before they break it. Its game of wits. :.:.: The system you're talking about isn't crypto. Its obfuscation. Your counting on somebody not moving beyond A,B, and C. Getting frustrated and giving up. Crypto doesn't do that.
    - DCKing 12y ago
      The weakness of JS Crypto is that you cannot authenticate the source of your crypto library so you cannot make sure it works properly. The problems are equivalent. All your ranting against what I'm saying is also directly applicable to plain Diffie-Hellman. Both simply are not secure under the active attacker model. That does not disqualify plain Diffie-Hellman from having some use (although not under most attack models), and that does not disqualify JS crypto from having some use (although not under most attack models). I'm going to respectfully decline discussing what attack models are and their use in security protocols on HN, as you unfortunately appear to not understand what I mean (which is probably my fault) or what attack models are used for in security research. You also appear to be confusing security research and cryptography research. You can mail me if you want to discuss this further.