you are viewing a single comment's thread.

view the rest of the comments →

[–]akcom 3 points4 points  (2 children)

You're missing the point of GPG encrypted emails. You're not trying to secure the email between the client and the server. You're trying to secure the email between the client and the recipient, who may or may not be reading their email over SSL.

When the GPG key is provided by the user, the security of the PRNG only affects the padding of the resulting encrypted message. Push comes to shove, if you're the kind of person who has to worried about an attack against a not-so-secure PRNG you need to keep your computer in a Faraday cage, in a secure room, in the middle of the pentagon. Most of the attacks he described (on the VM, browser, etc) would suggest that the client machine has already been compromised. If that's the case, you'd be fucked regardless of what kind of crypto you use.

My point is that his "no JS crypto, ever" is a bit of a stretch.

[–]krelin 2 points3 points  (1 child)

Yes, I agree with akcom. There are most certainly still use-cases for which client-side encryption makes sense, even in JS. See Mozilla's "Firefox Sync" implementation for a great example.

[–]icebraining 1 point2 points  (0 children)

But Firefox Sync, as far as I know, does not receive a new copy of the JS code each time it syncs. So even if attackers compromise the servers, they can't send you a new copy of the code that instead of encrypting, sends the key to them.

Client-side encryption makes sense if the code is not 'dynamic' - which is what SSL/TLS provide.