Cryptography in the Browser
blog.opal.io
Cryptography in the Browser
1–10 of 85 posts
Re: Cryptography in the Browser
#2Client side cryptography is almost always about providing a solution that doesn't require server trust. This article mentions end-to-end encrypted messaging, for instance, which provides the nice property that not even the messaging server can read the message contents.
The problem with webapp-based javascript cryptography is that if the crypto code is delivered by the server, then the client is back to trusting the server. The server operator, an attacker who can compromise the server, or an attacker who can compromise the SSL connection from the browser to the server can modify the JS to spray plaintext wherever they'd like.
Basically, the JS crypto is reducible to the strength of the SSL connection. Anyone on the other end of the SSL connection, or anyone who can break the SSL connection, can get your plaintext. This makes the JS crypto nothing but overhead. It's just hand-waving at that point.
This is not a theoretical weakness. This is exactly happened to both Lavabit and Hushmail. The experiment has been tried and the hand waving didn't amount to much. There's no need (and no excuse!) to try it again.
Re: Cryptography in the Browser
#3The Chicken-Egg problem is Problem 0 with Javascript crypto. Until you can solve that, everything else is just farting into the wind.
Re: Cryptography in the Browser
#4Client side cryptography is almost always about providing a solution that doesn't require server trust. This article mentions end-to-end encrypted messaging, for instance, which provides the nice property that not even the messaging server can read the message contents. The problem with webapp-based javascript cryptography is that if the crypto code is delivered by the server, then the client is back to trusting the…
Is there no way to independently verify that a) the scripts are what they are, and b) that the values change before going to the server?
Re: Cryptography in the Browser
#5Client side cryptography is almost always about providing a solution that doesn't require server trust. This article mentions end-to-end encrypted messaging, for instance, which provides the nice property that not even the messaging server can read the message contents. The problem with webapp-based javascript cryptography is that if the crypto code is delivered by the server, then the client is back to trusting the…
Is there no way to independently verify that a) the scripts are what they are, and b) that the values change before going to the server?
I have seen people point to using plugins to verify assets delivered by the server, but at that point, why not just do the crypto with the plugin.
Re: Cryptography in the Browser
#6Client side cryptography is almost always about providing a solution that doesn't require server trust. This article mentions end-to-end encrypted messaging, for instance, which provides the nice property that not even the messaging server can read the message contents. The problem with webapp-based javascript cryptography is that if the crypto code is delivered by the server, then the client is back to trusting the…
This is a deck by Ben Adida (formerly of Mozilla, where he led the Persona project and now at Square) explaining how that argument is reductionistic.
https://docs.google.com/presentation/d/1bLBb0EIJ0cuoAhsmI1XL...
Re: Cryptography in the Browser
#7Client side cryptography is almost always about providing a solution that doesn't require server trust. This article mentions end-to-end encrypted messaging, for instance, which provides the nice property that not even the messaging server can read the message contents. The problem with webapp-based javascript cryptography is that if the crypto code is delivered by the server, then the client is back to trusting the…
> Basically, the JS crypto is reducible to the strength of the SSL connection. Anyone on the other end of the SSL connection, or anyone who can break the SSL connection, can get your plaintext. This makes the JS crypto nothing but overhead. It's just hand-waving at that point.
This is true. However, you can say the same thing about, for example, retrieving an ISO of Ubuntu. A cryptosystem is as weak as its weakest link, and that weakest link may of course be the way you downloaded the cryptosystem in the first place.
But once the cryptosystem is in place, you don't have to trust SSL any more. By default, webapps are always retrieved from the server for every new session, but application manifests and offline storage are an effective means of avoiding this. You can build a webapp that is only ever downloaded once, and from then on loads its own code from the filesystem; and which verifies new "releases" of its own source using whatever crypto it likes before overwriting the client-side stored copies of itself.
Neither Lavabit nor Hushmail implemented this sort of application-release policy, but they easily could have.
Re: Cryptography in the Browser
#8Client side cryptography is almost always about providing a solution that doesn't require server trust. This article mentions end-to-end encrypted messaging, for instance, which provides the nice property that not even the messaging server can read the message contents. The problem with webapp-based javascript cryptography is that if the crypto code is delivered by the server, then the client is back to trusting the…
> Basically, the JS crypto is reducible to the strength of the SSL connection. Anyone on the other end of the SSL connection, or anyone who can break the SSL connection, can get your plaintext. This makes the JS crypto nothing but overhead. It's just hand-waving at that point. This is true. However, you can say the same thing about, for example, retrieving an ISO of Ubuntu. A cryptosystem is as weak as its weakest li…
cryptocat accomplishes this by distributing itself as a browser extension
Re: Cryptography in the Browser
#9Client side cryptography is almost always about providing a solution that doesn't require server trust. This article mentions end-to-end encrypted messaging, for instance, which provides the nice property that not even the messaging server can read the message contents. The problem with webapp-based javascript cryptography is that if the crypto code is delivered by the server, then the client is back to trusting the…
Is there no way to independently verify that a) the scripts are what they are, and b) that the values change before going to the server?
Basically, the way JavaScript security currently works, browsers trust all code sent from the server you are communicating with to manipulate everything coming from or going to that server.
You could talk about ways to independently sign and verify some crypto primitive or crypto library and be confident that it was being used to encrypt your communications appropriately. But this wouldn't help at all. There's nothing stopping the person controlling the server (or MITMing your connection to it) from adding additional code that scrapes the text input boxes, or captures keystrokes, or simply follows the appropriate variables down to the ones which contain your text before its sent off, and then sending that back to the server in an XMLHTTPRequest, via a websocket, via loading an appropriate image, or even hiding it quite well among the timing of when requests are made to the server.
The fundamental problem is that the code comes from the same person providing you the connection, and it is updated every time you use the page, so it offers no additional security above just trusting them directly.
If you want good crypto and good security, you want stable client side software from a trusted source, and a different source routing your traffic, so that both of them would have to be compromised to compromise your data.
Now, there may be one small advantage in client-side crypto. That's if due to problems with TLS (in particular, the version and protocols supported by your browser), there are TLS weaknesses that can be exploited, like a MITM attacker forcibly downgrading your crypto to a weak algorithm that allows them to eavesdrop but not forge content. In this case, stronger crypto implemented in JavaScript could be used to keep your data confidential. But this is a very narrow corner case, that's probably better handled by fixing browsers so they aren't prone to protocol downgrading attacks.
Re: Cryptography in the Browser
#10Client side cryptography is almost always about providing a solution that doesn't require server trust. This article mentions end-to-end encrypted messaging, for instance, which provides the nice property that not even the messaging server can read the message contents. The problem with webapp-based javascript cryptography is that if the crypto code is delivered by the server, then the client is back to trusting the…
> Basically, the JS crypto is reducible to the strength of the SSL connection. Anyone on the other end of the SSL connection, or anyone who can break the SSL connection, can get your plaintext. This makes the JS crypto nothing but overhead. It's just hand-waving at that point. This is true. However, you can say the same thing about, for example, retrieving an ISO of Ubuntu. A cryptosystem is as weak as its weakest li…
> You can build a webapp that is only ever downloaded once, and from then on loads its own code from the filesystem; and which verifies new "releases" of its own source using whatever crypto it likes before overwriting the client-side stored copies of itself.
But if you don't trust Hushmail they could force a back-doored update onto you.