>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.
> 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.
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.
Uploading encrypted files over HTTP. A JavaScript SSH client[1] for throwaway servers. Client-side password hashing to prevent passive MITMs to find raw passwords. These are not as secure as their native counterpart, and I don't claim they are. Nor do I claim they are resilient to active MITM attacks in the JS delivery. But they are protected from having their data logged in plain by passive MITM eavesdroppers, and that means that they may be useful to people who are aware of the security they don't have but appreciate the convenience of what they do have. This is all I'm saying.
Just like OpenSSH without server keys is vulnerable to MITM attacks, but still both useful and protected from eavesdropping. Just like people use plain Diffie-Hellman to negotiate a shared key, despite lack of authentication. Sometimes the active attack is simply not considered a problem, or the risk is simply accepted [2].
This is not a recommendation. This is a discussion about people having different requirements and uses. Almost all JS crypto used on the public internet does it wrong. But that doesn't mean that JS crypto is 100% wrong in any conceivable case. Most people using it are just stupid.
Attacking the strawman. No one man will revolution JS crypto. Not you, not Turning. Mathematicians are involved, when they all agree on stuff generally they're right.
The systems your proposing do nothing. And you know they do nothing.
>that means that they may be useful to people who are aware of the security
But you don't care. Its a false sense of security. Your selling rice paper advertised as bullet proof vests. That's my problem.
Yes these programs are entertaining thought experiments, but in the real world they're useless. And if you advertise them as being anything other then useless, you're no different then an 1860's snake oil sales man.
:.:.:
Also you mentioned assumed risk. Assumed Risk is understanding that there exists OpenSSL exploits you don't know about, you have no way of fixing, and no way of preparing for. You have to assume this risk to achieve any level of security. You have to be mindful that the landscape of security can change at any moment, and maybe render you insecure.
Assumed Risk does not mean your using a broken cryptosystem, and you know its weak points that exist BY DESIGN. And are fundamentally impossible to patch out. That's just called broken crypto.
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.