Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Criticism of JavaScript Cryptography

bren2010.github.io

Post reply on HN
Print view View original

61–70 of 84 posts

Re: A Criticism of JavaScript Cryptography

#61

Post by eric_bullington »

Sanddancer wrote: post #41
nadaviv wrote: post #26

In a project I'm working on [1], I'm planning to provide a browser extension that verifies the source code is digitally signed and that it matches the source code published on GitHub. I believe this creates a pretty good security model for a web-based app, even more so than most desktop programs. Some more information from the security page [2]: The browser extension provides improved security by verifying the integr…

So what happens when github goes down? I'd argue a better source for this sort of thing would be to put the hash in dns, either directly in a txt record, or using hacks involving A or AAAA records. Your nameserver almost certainly has more security than your github repo.

That would be really sweet if you could access dns directly in client-side Javascript, particularly given the existance of DNSSEC (great for bootstrapping trust).

Alas, client-side JavaScript doesn't speak DNS. You'd have to go through a server, which would mean you'd lose anything you might gain.

Re: A Criticism of JavaScript Cryptography

#62

Post by niels_olson »

bren2013 wrote: post #53
tptacek wrote: post #37

Earlier quoted context omitted.

How about, instead of arguing that readers of an article are more convinced than they should be about something you yourself appear to be convinced of , you put your money where your mouth is and formulate an argument for a setting in which content-controlled browser Javascript is a sensible place to deploy cryptography. Give yourself the full benefit of every facility the web programming model gives you, up to the l…

Is that a question? I don't understand the question. "Put your money where your mouth is" doesn't sound like a rebuttal. I've no idea what you're talking about.

> I don't understand the question.

Let me break that down for you:

1) formulate an argument for a setting in which content-controlled browser Javascript is a sensible place to deploy cryptography.

1.a) Give yourself the full benefit of every facility the web programming model gives you, up to the limit of installing browser extensions.

2) What's a system like (1) that has worked well, and would be resilient to a determined adversary?

So, he's claiming to have shown that content-controlled browser javascript crypto is worse that useless because it allows good people to inadvertently leak secrets. All you have to do to prove him wrong is just tell him a use case where it would make sense and then cite an example where that worked well* and would be resilient to a determined* adversary.

So, all you have to do is say "chatcrypt.com's use case makes sense and chatcrypt rocks. Here I show that it is unbreakable until long after the stars cool, and no amount of kneecap cryptography will lessen the adversery's burden."

* He's giving you two wiggle words already, you can define them however you'd like.

Re: A Criticism of JavaScript Cryptography

#63

Post by read »

bren2013 wrote: post #56
tptacek wrote: post #39

Earlier quoted context omitted.

I read the whole article and the impression I have is that all the uses you have for in-browser crypto in the current web programming model involve resistance to passive-only attackers .

Then you didn't read the article.

I learned a lot from the article. I liked the research behind it and that it hoped to provide a thorough analysis.

I don't understand crypto very well so I wish the article explained things in simpler terms. Shorter would be better for me.

Re: A Criticism of JavaScript Cryptography

#64

Post by cryptbe »

pbsd wrote: post #57
cryptbe wrote: post #48

Earlier quoted context omitted.

> So, it isn't actually a bit more challenging then? More challenging, yes. Riskier, no. I don't like that Javascript doesn't have native support for big integers (like Python does), or that it stores numbers as floating points in a 52-bit mantissa, but I fail to see why this makes developing crypto code riskier. > Also, it seems to me like you are at least forgetting timing and possibly other side channels. Well, I…

> If you disagree, you're invited to take a look at End-To-End, find a side-channel leak and write an exploit for it. You could earn serious cold cash with that finding. For one thing, the IDEA implementation seems to be incorrect. In IDEA, multiplication is defined as multiplication modulo 2^16 + 1, where 0 means 2^16 [3]. However, looking at the multiplication function: https://code.google.com/p/end-to-end/source/b…

Thanks for the report. I'll take a look and get back to you. Where can I contact you?

Edit: I've just filed https://code.google.com/p/end-to-end/issues/detail?id=82. We can discuss the problems of IDEA there. Thanks!

Re: A Criticism of JavaScript Cryptography

#65

Post by pbsd »

cryptbe wrote: post #64
pbsd wrote: post #57

Earlier quoted context omitted.

> If you disagree, you're invited to take a look at End-To-End, find a side-channel leak and write an exploit for it. You could earn serious cold cash with that finding. For one thing, the IDEA implementation seems to be incorrect. In IDEA, multiplication is defined as multiplication modulo 2^16 + 1, where 0 means 2^16 [3]. However, looking at the multiplication function: https://code.google.com/p/end-to-end/source/b…

Thanks for the report. I'll take a look and get back to you. Where can I contact you? Edit: I've just filed https://code.google.com/p/end-to-end/issues/detail?id=82 . We can discuss the problems of IDEA there. Thanks!

That link gives me a 403 error? In any case, I've put an email in my HN profile.

Re: A Criticism of JavaScript Cryptography

#66

Post by zAy0LfpBZLC8mAC »

cryptbe wrote: post #48
zAy0LfpBZLC8mAC wrote: post #44

Earlier quoted context omitted.

> Well it seems that you misunderstood which challenges I was talking about. Lack of types is a big problem, but besides that everything else doesn't make the risk bigger. So, it isn't actually a bit more challenging then? Also, it seems to me like you are at least forgetting timing and possibly other side channels. > I don't understand this question. I just can't see any actual scenario where that helps, mostly beca…

> So, it isn't actually a bit more challenging then? More challenging, yes. Riskier, no. I don't like that Javascript doesn't have native support for big integers (like Python does), or that it stores numbers as floating points in a 52-bit mantissa, but I fail to see why this makes developing crypto code riskier. > Also, it seems to me like you are at least forgetting timing and possibly other side channels. Well, I…

> More challenging, yes. Riskier, no.

Please explain. Is it that it is more challenging, but in a way that it's not more difficult to get it right (what exactly is the challenge then?) or is it not riskier because the higher probability of getting it wrong does not decrease the probability of getting it right (how exactly do you increase one probability without decreasing the probability of the negated case?)?

> This applies not only to Javascript, but also to all scripting languages.

So, a bridge built from matches isn't any more robust than a bridge built from toothpicks, therefore building bridges from toothpicks is a good idea (nevermind that other people are using reinforced concrete for bridge construction)? I'm sorry, but I can't quite follow your argument.

> If you disagree, you're invited to take a look at End-To-End, find a side-channel leak and write an exploit for it. You could earn serious cold cash with that finding.

You are not seriously bringing forward the "secure-because-hacking-contest" argument, are you?

> Re your last point: if doing SSH in a browser isn't crypto I don't know what could be.

Sure it is, but it still is rather obviously not what those posts are primarily attacking. Or maybe it is, if anyone claims or implies that this "SSH-client in a browser" is any more secure than "browser frontend to SSH-client on the server". Which I think is kinda the whole reason for its existence? Performance- and complexity-wise, I doubt that it makes any sense at all to implement the SSH protocol itself in the browser in that case, vs. using a native SSH client on the server.

Re: A Criticism of JavaScript Cryptography

#67

Post by cybernytrix »

Can any of you comment on my scheme described here: http://ashkash.github.io/ajaxcrypt/index.html This should resist even active adversaries:

- Statically encrypt and publish content on HTTP server - Transmit these via HTTP to an iframe component at client browser - transmit decryption and key routines using HTTPS. - HTTP-iframe locally sends message to HTTPS-iframe via window.postMessage() - HTTPS-iframe decrypts content (with pre-shared key) and renders it on page

Re: A Criticism of JavaScript Cryptography

#68

Post by tptacek »

bren2013 wrote: post #56
tptacek wrote: post #39

Earlier quoted context omitted.

I read the whole article and the impression I have is that all the uses you have for in-browser crypto in the current web programming model involve resistance to passive-only attackers .

Then you didn't read the article.

A response that would have worked would have been "Then you didn't read the article, because XXX".

Re: A Criticism of JavaScript Cryptography

#69

Post by tptacek »

bren2013 wrote: post #54
tptacek wrote: post #35

I suppose I'm expected to give a full-throated defense of the Matasano post, which I wrote, but I'm not going to. While I don't dislike the post as much as this author appear to, I don't much like it either. I wrote it in a single draft, all at once, as a sort of message board comment I'd write once and maybe in the future refer back to. I didn't promote it on HN and I'm not the reason it keeps getting cited. None of…

If you think that's the "simple truth," you either didn't read the article, or you have some piece of information you're not sharing with the rest of us. You also know something about the "formalisms of HBC" (now redacted), and how it doesn't work with browsers that even scholars don't know about. I think we'd all appreciate elaboration.

This comment appears to be totally unresponsive to mine.

Incidentally, the "now redacted" in the parent comment refers to three bullets I had written in the grandparent comment and left for four minutes before realizing that objecting in detail to this person's blog post more or less amounted to making a full-throated defense of the Matasano post. Which, like I said, I'm not in love with either.

Re: A Criticism of JavaScript Cryptography

#70

Post by tptacek »

cryptbe wrote: post #17

Interesting coincidence. I just wrote http://vnhacker.blogspot.com/2014/06/why-javascript-crypto-i... , in which I explain the threat model implied in the Matasano's article doesn't apply to most applications.

This is a fantastic post that deserves to be on the front page of HN.
Post reply on HN