Comment by DCKing | Hacker News Reader

Comment by DCKing | Hacker News Reader

Parent Full thread

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-al...

>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.

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.

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.

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?

>[...]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.

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.

>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.

>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.

> What use is there for client side JS crypto?

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.

[1]: https://github.com/liftoff/GateOne

[2]: Choosing which risks to accept or not is daily practice for anyone dealing with security issues.

>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.

Please stop pretending I'm advocating JS crypto. I did no such thing, and you are being extremely disingenious and rude for suggesting that.

Sometimes you don't need the data to be decrypted on the host.

Your crypte is still useful if the host doesn't want to decrypt anything. Javascript crypto as an alternative to SSL makes no sence, an implementation in which the server never gets the plaintext is currently only possible with client side javascript crypto.

I agree that any discussion of using JavaScript-crypto instead of SSL is nuts and likely a strawman complaint.

But just because it's "the best we can do," that doesn't mean it's a good idea.

EDIT 1 minute before I made this comment 'tptacek said the fallacy better elsewhere on this page "we really need browser crypto to work, therefore it works"."

Javascript crypto added to SSL is a great way to let your errors insert vunerabilities on an otherwise secure page.

> 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/b83965785db1eec019edf1...

[2]: http://www.ocert.org/advisories/ocert-2011-003.html

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.

> 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).

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.

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.

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.

My colleagues who do this more than I say that while it's possible, it's rare for an attacker to be able to sniff traffic without being able to interfere with traffic.

Not true, depending somewhat on your attacker, but there are plenty of ways to read emissions from networks which give you no opportunity to modify the traffic.

On the other hand, plenty of people who can modify the traffic exist. Starting with every employee at your ISP and the Amazon picker who shipped your router.

> 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.

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.

Reply on news.ycombinator.com