
A Criticism of JavaScript Cryptography - Agrosis
http://bren2010.github.io/jekyll/update/2014/06/17/javascript-crypto.html 
======
bascule
I thought this was a good post, but I wasn't impressed with the criticisms of
other blog posts. Okay, perhaps I'm biased, because I wrote one of them, but
how about I try to defend the other?

The Matasano post is here:

[http://matasano.com/articles/javascript-
cryptography/](http://matasano.com/articles/javascript-cryptography/)

Perhaps the most objectionable thing about the Matasano article is title.
Otherwise it does a very good job of criticizing a particular way of
engineering web cryptography that is, for lack of a better term, total
bullshit. But is the approach criticized in the Matasano post used in the real
world?

Let's try an experiment! Go to google.com and type in "encrypted chat"

If your results are similar to mine, one of the top 3 results will be
"chatcrypt.com". Let's read the "How It Works?" page:

> Most people thinks that if a website uses a HTTPS connection (especially
> with the green address bar) then their "typed-in" informations are
> transmitted and stored securely. This is only partially true. The
> transmission is encrypted well, so no third party can sniff those
> informations, but there is no proof that the website owners will handle them
> with maximum care, not mentioning that the suitable laws can enforce anyone
> to serve stored data for the local authorities.

Okay, so this site attempts to implement end-to-end encryption in a web
browser. Except... what's the problem? Oh, it looks like chatcrypt.com isn't
served over HTTPS. In fact, if we try to visit the site over HTTPS, it doesn't
work at all.

chatcrypt.com claims to keep your traffic secure using end-to-end cryptography
implemented in JavaScript, except the JavaScript is being served in plaintext
and is therefore easily MitMable.

Top 3 Google result for "encrypted chat"

Is the Matasano post that unreasonable? (besides the title) It pretty much
describes that sort of site to a tee.

~~~
bren2013
I mean, it is secure against passive adversaries... but that's nit-picking.

ChatCrypt has made a large number of mistakes, though, I concur. They don't
use HTTPS, it isn't open sourced, and the developer is practically anonymous.

I would still maintain that Matasano's article is problematic, though, because
it has one of two effects on the reader:

1\. The reader is more-than-well convinced on faulty basis that JS crypto
should never be used.

2\. The reader is still adamant on continuing their project, but is now
alienated from a source that could have offered a plethora of helpful advice.
(Example: "Please, for all that is good, use HTTPS.")

Of course, nothing will prevent the occasional surfacing of bad crypto, but
their article certainly doesn't help any of its causes.

~~~
tptacek
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 limit of installing browser extensions
(at which point you're no longer talking about content-controlled code).
What's a system like this _that has worked well_ , and would be resilient to a
determined adversary?

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

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

------
skrebbel
Wow.

 _A construction or implementation is secure if an adversary, given a certain
level of power, is unable to achieve a given objective. The level of power an
adversary is assumed to have and their ultimate objective is called the threat
model.

If a new construction is secure under a new threat model that either increases
the amount of power an adversary can have or makes the adversary's objective
broader, the new construction is said to have a higher level of security._

This is what we need more in security discussions. So many discussions, here
on HN but also, well, everywhere, are really misunderstandings about which
threat model to assume. People get into hot-headed fights about whether some
solution somewhere is or is not "secure", when really all they disagree about
is which definition of "secure" to use.

Well done! I propose that security related blog posts take some time out to
casually define these terms over and over again, for a while, until we can all
just assume them known and be done with all the vague imprecise nonsense.

~~~
tptacek
This sounds important, but the distinction between "passive" and "active"
attackers has come up in every discussion of JS crypto I can remember on HN,
and indeed in every discussion of TLS (see, for instance, every discussion of
why certificate authorities are necessary and why self-signed certificates are
insecure "despite using exactly the same cryptography as CA-signed
certificates").

I do not believe this is a dimension that has been missing from previous
discussions, but perhaps you can use the search bar below to find a debate
about JS crypto where it was missing and where the result was misleading to
readers.

~~~
skrebbel
> _but perhaps you can use the search bar below to find a debate about JS
> crypto where it was missing and where the result was misleading to readers._

Oh come on, was that sneer called for? If you really feel that none of the
security discussions here on HN are getting way out of hand over what's really
a misunderstanding on some basic assumptions, then you haven't been looking.
Note, I didn't say "JS crypto discussions", I said "security discussions".

In fact, I'm mostly referring to the kinds of discussions that did _not_ start
as a security topic, but evolved into them. There, there's often people like
me, who care about security but who are far from experts, and these people
(myself included) often mix stuff up. Clearing out definitions and which
threat model to assume would _really_ help in such discussions. I thought that
this blog post did that in a very clear and non-opinionated way in that little
paragraph there, so I complimented it.

Is that really so bad?

~~~
tptacek
I'm not sure what controversy you think you're wading into here, or why you
think I was sneering. I was being completely serious.

------
tptacek
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 this bickering changes a simple truth: when a web mail provider claims
to provide "NSA-proof" end-to-end encryption, hosted in Switzerland just to be
safe, using software that _you don 't have to install on your computers at
all_, then you need to assume that web mail provider can read your email, and
so can anyone who can coerce that provider into doing something. If you
believe that --- and you should --- then I don't care what you think about the
rest of the Matasano article.

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

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

------
jerf
One problem with the "passive adversary" attack is that even if the nonce+HMAC
protocol defeats the passive adversary, you as a user have no way of verifying
whether or not your adversary is passive. Or whether they exist, or, indeed,
anything about them, as in the real world, you don't get to pick your
adversaries. The user needs a way to determine whether the connection is
secure before they can trust it, because they can't (correctly) assume that
only passive adversaries exist.

So, if that is the best in-browser crypto can do, then it is still basically
useless, unless you get to choose your adversary. And "active adversary"
software is off-the-shelf tech, not some sort of bizarre thing only the NSA
has access to. Active adversary is the lowest baseline of attack worth talking
about.

~~~
bren2013
No, you don't get to pick your adversaries, but you do get to pick the
strongest one you wish to be secure against. Or for that matter, can be secure
against. I briefly mentioned Diffie-Hellman key exchanges to provide an
example of another common primitive that's only secure against passive
adversaries. (DHKEs are typically used in peer-to-peer applications.)

Also, if you keep reading, I mention several uses for in-browser crypto.

~~~
jerf
Let me say it again: As a user, you can't _verify_ that you're secure against
the attackers.This is my important point, not whether a particular chosen
attack was blocked. Therefore, if you care at all about security, you can't
trust the channel. You're only looking from the POV of the attacker, but
you've got to consider all the POVs, including the users, and not impute to
them knowledge that they can't have about the universe ("I am only being
attacked by passive attackers") in order to declare your system "more secure".

Saying "I'm secure against passive attackers" doesn't mean that you're safe
doing anything on your "secure" channel, because the bar for active attack is
so low that that's hardly saying anything. You can be secure against "passive
attackers", but you still can't verify that you _haven 't been attacked_, in
general. A definition of security in which a user blithely sticks sensitive
data on a channel, unconcerned about whether the channel was attacked, is a
useless definition of security... by definition, we're not talking about a
user concerned with security, of _any kind_.

If we are talking about a security scenario where the equivalent of "active
attack" is actually quite difficult and it takes a nation-state's resources,
I'd be happy to discuss this argument. We've historically used some encryption
at points in time where technically brute forcing it was feasible for very
large entities, for instance. But the bar for active attack on the web is low
here, very, _very_ low.

~~~
bren2013
This is an example of the Perfectionist Fallacy I was talking about in the
article.

You can't verify that someone isn't MiTM'ing with a stolen certificate. You
can't verify that the CA hasn't been coerced into forging a valid certificate.
You can't verify that your government hasn't ordered that computer
manufacturers install surveillance devices. That doesn't mean that the
internet is unusable.

Some things are vulnerable to active attacks, and if they were attacked,
nobody would know. Every cryptographer knows this. It's not a big deal.

~~~
mpyne
I didn't get the impression jerf was arguing for perfect security, as much
that they were saying that securing _only_ against a passive attacker is as
useful for the user as not using TLS at all.

Selecting a threat model is all well and good, but if you select an
artificially easy threat model to defend against then you're not really
helping users (in this case, helping them against random evil ISPs?)

------
jarrett
It's not clear to me if the author is _endorsing_ the use of browser crypto in
any particular scenario. Regardless, probably the most common reason for
wanting browser crypto is to protect the data _before_ it hits the server,
thus protecting against a malicious or compromised server.

For example, consider a web-based mail client. You want to send an encrypted
message, say via PGP, and you don't want the server to be able to read it,
even if the server is evil. You'd _like_ to be able to do the PGP encryption
100% in-browser, with no browser plugins or extensions necessary.

I think that's the most common category of use-case for browser crypto.
Unfortunately, it's one where browser crypto plainly doesn't work. The whole
point here is to defend against an evil server, but if the server is evil, _it
will send you evil crypto JS._ TLS doesn't help you. Nobody's impersonating
the server or altering the JS file in transit. You're getting an authentic
copy of the JS file from the real server. It just happens to be an authentic
copy of an _evil_ JS file.

Given that, what _can_ you do with browser crypto, practically speaking?

~~~
scotty79
It still might protect you if you won't access server while it's compromised.
It protects you from someone just hacking your server, downloading all the
data and getting away.

Also you might serve files that do the encryption from different server that's
smaller, better protected, more stable, that less people have access to.

~~~
jarrett
> It still might protect you if you won't access server while it's
> compromised.

The end user can't know when that's the case.

> Also you might serve files that do the encryption from different server
> that's smaller, better protected, more stable, that less people have access
> to.

That doesn't provide any assurance to the end user that the JS isn't
malicious.

Remember, "compromise" doesn't just refer to a drive-by hack. The site
operators themselves may become compromised (or start that way), and
deliberately serve malicious JS. Users can't know when that's the case. When
it is the case, the strategy you suggested offers no protection, because the
"more secure" JS server is still under the control of the bad actor.

~~~
tinco
> > It still might protect you if you won't access server while it's
> compromised. > The end user can't know when that's the case.

This is the entire point of the article. You can't know if it's the case, you
can't either with any software distribution. When you type 'apt-get install
opensshd', how do you know if you're getting the package from an uncompromised
server?

You just have to trust that the public keys you got are the right ones, and
their private keys have not been stolen.

So what the author is saying is that regarding that aspect web crypto is at
roughly the same level.

The big problem of course is that there is evidence that the whole CA system
is much less reliable than the old GPG signing party system.

~~~
jarrett
> When you type 'apt-get install opensshd', how do you know if you're getting
> the package from an uncompromised server?

If you don't take any steps to verify the integrity, then you don't know.

The big difference, as I see it, is that the JS code gets served over and over
again to the same clients. Every time you visit the website, it can load a new
version of the JS.

~~~
eric_bullington
Even if you do verify the integrity of the package, then you still can't know
for absolute certain that the package maintainer hasn't somehow exposed their
private key or been otherwise compromised. You have to trust them.

~~~
jarrett
If the package maintainer has exposed their private key, and yet the package
itself in intact, what harm is there (at the moment)? With the key
compromised, you _could_ have been MITMed, but you weren't. You _could_ be
MITMed in the future, but that's a problem for another day.

~~~
eric_bullington
I just saw this reply, and I have to clarify: the moment the maintainer's key
is compromised, it becomes possible for someone to MITM. It's not clear if
that's what you were saying, but that's how it is, and that's absolutely a
problem as soon as the key is compromised (particularly if he/she was
targeted).

------
diafygi
One aspect of in-browser functionality OP mentions is "offline". However,
browsers are pretty cool in that they can mix offline and online. You can open
a local html file and it can then make online requests. Alternatively, you can
request an html file online that then can access local files.

This ability to mix offline and online content is something that I think has a
lot of potential to improve client-side encryption. Specifically, client-side
encryption coupled with an unhosted webapp[1].

I've been exploring this potential for my byoFS[2] project, and made an
example end-to-end encrypted chat demo[3]. You can request the app anonymously
(or even save it and open it locally). The app then lets the user connect an
online datastore (e.g. Dropbox) to save the encrypted chats.

This separates who serves the anonymous static webapp and the authenticated
datastore, and makes it much harder to target a javascript attack (the most
common attack from the Snowden leaks).

[1] - [https://unhosted.org/](https://unhosted.org/)

[2] - [https://github.com/diafygi/byoFS](https://github.com/diafygi/byoFS)

[3] -
[https://diafygi.github.io/byoFS/examples/chat/](https://diafygi.github.io/byoFS/examples/chat/)

------
nadaviv
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 integrity of
the files served by the server. The verification is done using two factors:

\- Cold storage signature verification: In addition to SSL, static files
(html/css/javascript) are signed using standard Bitcoin message signatures,
with a private key that is stored offline and encrypted. This ensures that the
content served from the webserver was not tampered with by a third party.

\- Comparing against the code on GitHub repository: The source code from the
GitHub repository is built on Travis-CI and the resulting hashes are published
publicly on Travis's job page. The extension ensures that the content served
by the webserver matches the open-source repository on GitHub.

If an attacker gains control over the web server, he still only has access to
information the web server already knows (which is very little). To get
sensitive information, he would have to modify the client-side code to send
back more data to the server.

For an attacker to successfully mount such an attack against someone with the
browser extension, he would have to:

\- Gain access to the web server.

\- Gain access to the personal computer of a developer with commit access to
the GitHub repository. [3]

\- Commit his changes to the public GitHub repository, where they can be seen
by anyone. [3]

\- Gain physical access to the offline machine with the private key and know
the passphrase used to encrypt it.

[1] [https://www.bitrated.com/](https://www.bitrated.com/)

[2] [https://www.bitrated.com/security.html#browser-
extension](https://www.bitrated.com/security.html#browser-extension)

[3] That's assuming that GitHub and Travis-CI are themselves secured. Gaining
access to any of them would make those steps unnecessary.

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

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

------
bugmen0t
Attesting software (i.e. JavaScript, even from third parties) might be
possible if
[https://w3c.github.io/webappsec/specs/subresourceintegrity/](https://w3c.github.io/webappsec/specs/subresourceintegrity/)
gains traction.

------
d1str0
Why do people use styles like these that push all the content uncomfortably to
the sides? 40% of the screen is dedicated to what? The blog title and a link
home.

Edit: [http://i.imgur.com/62l4zCG.png](http://i.imgur.com/62l4zCG.png) 500%
better

~~~
rmrfrmrf
The line length in your edit is WAY too long.

~~~
drdaeman
That depends on its physical size (and viewing distance). Pixels don't really
mean anything.

------
cybernytrix
Can any of you comment on my scheme described here:
[http://ashkash.github.io/ajaxcrypt/index.html](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

------
jdbernard
Ten years from now, when web security is even more laughable and anemic than
it already is, some of us are going to remember discussions like these where
application developers at large ignored the warnings from the established
crypto community. Some of us are old enough already to remember this pattern
happening before.

I understand the strong reaction to the actions of the NSA, but all this is
doing is providing the appearance of security while not making it any more
difficult for adversaries like the NSA.

~~~
notblahbl4hblah
Yep. This whole NSA thing has forced a new generation to start reading Applied
Cryptography...or at least make it plain that they need to.

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

~~~
zAy0LfpBZLC8mAC
"they just make the task of programming a crypto library a bit more fun and
challenging, not riskier"

Seriously? It makes it more difficult to get things right, but the risk of
getting it wrong is not increased? And that after you just described how the
challenges of JS have already directly led to vulnerabilities?

Also, you mostly don't really support your own argument. How exactly does a
malicious server not affect "crypto browser apps"? How does staying out of
scope for PCI DSS have anything to do with security (except maybe
demonstrating that PCI DSS is crap because it can so easily be circumvented)?
Also, in what kind of scenario would leaking info in a referer be a problem,
but leaking the same info in encrypted form would not? And how do you
guarantee that your verification code is loaded fresh from the server once
your application has been compromised in a browser?

~~~
cryptbe
> Seriously? It makes it more difficult to get things right, but the risk of
> getting it wrong is not increased? And that after you just described how the
> challenges of JS have already directly led to vulnerabilities?

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.

> How exactly does a malicious server not affect "crypto browser apps"?

I didn't claim that malicious servers won't be able to affect crypto browser
apps. What I said is that in these apps you have to trust the server already,
so it doesn't make sense to consider them untrusted.

> How does staying out of scope for PCI DSS have anything to do with security
> (except maybe demonstrating that PCI DSS is crap because it can so easily be
> circumvented)?

It's exactly the point. When people say "javavascript crypto is harmful" they
don't consider use cases where it's really useful, even just to circumvent PCI
DSS.

> Also, in what kind of scenario would leaking info in a referer be a problem,
> but leaking the same info in encrypted form would not?

I don't understand this question.

> And how do you guarantee that your verification code is loaded fresh from
> the server once your application has been compromised in a browser?

Because every time I refresh my browser I get a chance to get some trusted
code from the server.

~~~
zAy0LfpBZLC8mAC
> 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 because it seems
to me that the cipher text usually would be a plain-text equivalent, so it
doesn't really matter to the attacker whether they have the plain text or the
cipher text.

> Because every time I refresh my browser I get a chance to get some trusted
> code from the server.

So, in other words, you don't have a guarantee?

Other than that, and in general, it seems to me that your argument is somewhat
of an equivocation fallacy: You are essentially redefining crypto to include
kinda-non-crypto, to then claim that this redefined crypto actually can
sensibly be used in browser-side JS, and therefore the arguments against the
use of the original crypto are somehow not good advice.

I would think that it is rather obviously implied in most criticism of JS
crypto that you are not just executing code that performs a cryptographic
primitive, but that you are actually using it to achieve some security goal,
and in particular that you are using client-side JS rather than some server-
side crypto for some security advantage. That is essentially the implied vague
threat model.

So, yeah, it's true that there are uses for crypto primitives that aren't
affected by that threat model, because they aren't about security at all. And
others that are less affected for various reasons. But it's highly misleading
to therefore claim that "most applications aren't affected by that threat
model". I'd think that most applications actually are. Except for those built
by people who do understand enough of cryptography to not need posts such as
the one by matasano. That is to say: Yes, once you yourself can write such an
FAQ, you might be able to make use of JS crypto. But at that point, that post
won't keep you from doing it anyhow. If you can't, though, chances are you
first need to understand every single point made in it.

~~~
cryptbe
> 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 ain't. When you don't control the instructions being executed by the
CPU you may have the risks of security-sensitive information leaks. This
applies not only to Javascript, but also to all scripting languages. I could
say that it also applies to Java, if the methods in its BigInteger class
aren't fixed-timing.

In other words using Javascript doesn't make the problem any worse. 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.

> I just can't see any actual scenario where that helps, mostly because it
> seems to me that the cipher text usually would be a plain-text equivalent,
> so it doesn't really matter to the attacker whether they have the plain text
> or the cipher text.

I described where it helps in my article.

Re your last point: if doing SSH in a browser isn't crypto I don't know what
could be. Is the only thing you consider Javascript crypto encrypted webmail?
That's your problem then. You know one wrong use case, and you refuse to admit
that there are other legitimate ones.

Edit: remove a few unnecessary sentences.

Edit: some people don't like Javascript crypto so much that they downvote me
without saying anything.

~~~
pbsd
> 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/browse/javascrip...](https://code.google.com/p/end-to-
end/source/browse/javascript/crypto/e2e/cipher/idea.js#312)

When x == 0 but y != 0, the result of the modular multiplication is always 0,
when it should not be. The correct code would be (in glorious C syntax,
everything unsigned and 32-bit):

    
    
        if(x != 0) {
            if(y != 0) {
                return x*y % 65537; // result fits in 32 bits
            }
            else return 65537 - x; // or 1 - x mod 2^16
        } else return 65537 - y; // or 1 - y mod 2^16
    

Of course, even if correct this code is still vulnerable to timing attacks
(under contrived conditions) [1]. This can be worked around using a little
bitwise magic:

    
    
        t0  = 65537 - x;
        t1  = 65537 - y;
        t2  = x*y % 65537;
        b0  = -(1 ^ ((x | -x) >> 31)); // 0xfff..ff if x == 0
        b1  = -(1 ^ ((y | -y) >> 31)); // 0xfff..ff if y == 0
        return ((t0&~b0&b1) | (t1&b0&~b1) | (t2&~b0&~b1) | (1&b0&b1))&0xFFFF;
    

Additionally, the modular inversion seems to be needlessly complicated by
using Euclid's algorithm (and I'm not sure it's correct either: it seems not
to respect the "0 means 2^16" rule). Use the usual a^(p-2) mod p inversion
trick, using an optimal addition chain [2], to make it simpler, constant-time,
and possibly faster.

None of this is Javascript's fault, for what it's worth. But I certainly don't
expect Javascript to make it any easier to write correct code, much by the
contrary.

EDIT: Fixed constant-time code.

[1] [https://www.schneier.com/paper-side-
channel2.pdf](https://www.schneier.com/paper-side-channel2.pdf)

[2] [http://wwwhomes.uni-bielefeld.de/cgi-
bin/cgiwrap/achim/scrip...](http://wwwhomes.uni-bielefeld.de/cgi-
bin/cgiwrap/achim/script_lookup_ac?para=FIXED)

[3] [http://www.isiweb.ee.ethz.ch/papers/arch/xlai-mass-
inspec-19...](http://www.isiweb.ee.ethz.ch/papers/arch/xlai-mass-
inspec-1991-2.pdf)

~~~
cryptbe
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](https://code.google.com/p/end-to-
end/issues/detail?id=82). We can discuss the problems of IDEA there. Thanks!

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

~~~
cryptbe
Oh yeah, it was restricted to my team. I'll make it public, and notify you via
email. BTW IDEA is not enabled/registered.

------
btreecat
I really enjoyed reading this. Certainly put the browser security model in a
new perspective for me.

------
notblahbl4hblah
I think that the main reason that people keep wanting to do this is that web
developers would like to work on this problem but don't have skills that are
applicable immediately. It's going to require a great deal of learning on most
of their parts that is at least as daunting as becoming a good front-end
developer to use existing crypto libraries well...much less engineer new
cryptosystems. That would be the difference between being able to code and
being able to write a high quality optimizing compiler, for instance. With
study and hard work you can use the fruits of the crypto community well...but
you have to start by realizing where you are starting from. In browser
javascript isn't just another programming language and runtime that's
completely akin to c and the c runtime. The Matasano article does a great job
of describing why.

------
notblahbl4hblah
No such thing as a secure keystore? He needs to look harder. Aside from
hardware which is tamper proof... which exists in smart cards and TPM chips...
most operating systems use file system ACL's. Yes running as "root" means you
can get the keys... you have to protect them...

~~~
notblahbl4hblah
Why did this get downvoted? No one even replied!

~~~
jdbernard
You are right, and the fact that people are just dismissing you out of hand is
frightening. It shows a lack of even the interest to understand how off-base
they are.

