4 ms·

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

by 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.
  - valarauca1 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 One of many, this isn't the only issue. Even if you authenticate the host what prevents tampering via MitM attacks? > All your ranting against what I'm saying is also directly applicable to plain Diffie-Hellman yes and no. Standard white paper Diffie-Hellman yes. But implementations can fix that. As you point out. >That does not disqualify plain Diffie-Hellman from having some use except >and that does not disqualify JS crypto from having some use Wrong. Because you keep dodging my main point. Anything that solves the problem of: 1) Is who your talking to the right person (authentication)? 2) Is your code arriving unchanged (authentication + encryption)? The two main issues with JS crypto. Solves what ever problem your trying to solve with JS crypto. And any solution that allows you create secure JS client side crypto, fundamentally makes it obsolete. That's the problem I'm going on about.
    - DCKing 12y ago
      > yes and no. Standard white paper Diffie-Hellman yes. But implementations can fix that. As you point out. Well, there we have it. I happen to have worked on a project where plain Diffie-Hellman was used not long ago. The active attacker model was genuinely not a threat/solved by other methods in this particular context, and simple confidentiality provided by a plain Diffie-Hellman key exchange was enough. As another example, plain Diffie-Hellman is also used in SSH sessions without predistributed keys [1]. Clearly, the presence of active attackers is not always a problem in the real world! If that is the case, then there also exist legitimate uses for JS crypto [2]. As a sidenote nitpick, no implementation of plain Diffie-Hellman can fix the authentication issue. There are instead variations built upon plain Diffie-Hellman (notably authenticated Diffie-Hellman) that solve the authentication issue. But these protocols are not the same as plain Diffie-Hellman. [1] RFC 4253, section 8 [2] I feel that I should stress again that although this is true for these particular use cases, JS crypto should not be trusted in general.
      - valarauca1 12y ago
        >Well, there we have it. This is a slippery slope argument. We solved the issue with X therefore we can solve it with Y. The problem is when you solve the issues JS browser side crypto has, you render it unnecessary. If you can. 1) Authenticate the message is unchanged. I.E.: Assures libraries you are using are secure. 2) Authenticate who your talking too. I.E.: Assures the host is the correct host, not a MITM attack. 3) Ensure the message is unreadable in transmission. I.E.: Insure any eaves droppers are not loging you. What use is there for client side JS crypto? You just solved every issue with 2 way encrypted communication. Just build it into a tool kit and you render JS clientside crypto unneeded. :.:.: Also to outline, compiled JS node.js application level stuff is useful. In Browser JS crypto is bad, completely untrustworthy and broken.

by DCKing 12y ago

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.
- valarauca1 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 One of many, this isn't the only issue. Even if you authenticate the host what prevents tampering via MitM attacks? > All your ranting against what I'm saying is also directly applicable to plain Diffie-Hellman yes and no. Standard white paper Diffie-Hellman yes. But implementations can fix that. As you point out. >That does not disqualify plain Diffie-Hellman from having some use except >and that does not disqualify JS crypto from having some use Wrong. Because you keep dodging my main point. Anything that solves the problem of: 1) Is who your talking to the right person (authentication)? 2) Is your code arriving unchanged (authentication + encryption)? The two main issues with JS crypto. Solves what ever problem your trying to solve with JS crypto. And any solution that allows you create secure JS client side crypto, fundamentally makes it obsolete. That's the problem I'm going on about.
  - DCKing 12y ago
    > yes and no. Standard white paper Diffie-Hellman yes. But implementations can fix that. As you point out. Well, there we have it. I happen to have worked on a project where plain Diffie-Hellman was used not long ago. The active attacker model was genuinely not a threat/solved by other methods in this particular context, and simple confidentiality provided by a plain Diffie-Hellman key exchange was enough. As another example, plain Diffie-Hellman is also used in SSH sessions without predistributed keys [1]. Clearly, the presence of active attackers is not always a problem in the real world! If that is the case, then there also exist legitimate uses for JS crypto [2]. As a sidenote nitpick, no implementation of plain Diffie-Hellman can fix the authentication issue. There are instead variations built upon plain Diffie-Hellman (notably authenticated Diffie-Hellman) that solve the authentication issue. But these protocols are not the same as plain Diffie-Hellman. [1] RFC 4253, section 8 [2] I feel that I should stress again that although this is true for these particular use cases, JS crypto should not be trusted in general.
    - valarauca1 12y ago
      >Well, there we have it. This is a slippery slope argument. We solved the issue with X therefore we can solve it with Y. The problem is when you solve the issues JS browser side crypto has, you render it unnecessary. If you can. 1) Authenticate the message is unchanged. I.E.: Assures libraries you are using are secure. 2) Authenticate who your talking too. I.E.: Assures the host is the correct host, not a MITM attack. 3) Ensure the message is unreadable in transmission. I.E.: Insure any eaves droppers are not loging you. What use is there for client side JS crypto? You just solved every issue with 2 way encrypted communication. Just build it into a tool kit and you render JS clientside crypto unneeded. :.:.: Also to outline, compiled JS node.js application level stuff is useful. In Browser JS crypto is bad, completely untrustworthy and broken.