Hacker News Reader

Comment by pnathan | Hacker News Reader

How do you manage your private keys not getting into Javascript land & being POSTed out to an arbitrary site?

We don't store the password in the DOM. When you choose to sign/encrypt, the password is passed to gpg (via the plugin) and promptly goes out of scope. (It means you have to enter your password every time you want to sign/encrypt, but this seems safer)

Goes...out of scope.

I am suspicious that that's not really sufficient password protection. What protection do you have from an attack that provides access to your machine's address space? (or chrome's address space)?

I'd like to see the source code before I use this. If that sounds paranoid, it's because if I'm using crypto, it's because I'm concerned about snoopers.

--- edit - source got posted. Thanks!

-nod- an attack with full access to chromes address space would grab the password in memory.

I'm guessing someone with that sort of threat model isn't using gmail for comms. (I guess even then, it could be useful to verify signatures (when gmail doesn't break the mail) without risking your private key)

Could you mitigate that by having a separate process to do the crypto, which the plugin talks to by IPC? The separate process is then the one that prompts for the password.

This would also mean you don't have to reenter your password every time.

You're at zero right now because my finger slipped. Sorry about that.

I don't see a reason why private keys should be accessible via Javascript at all. It's a plugin and not a JS-based extension. With the right API the JS code would never see the private keys.

Sure. But people make mistakes. And it behooves one to be careful with their crypto.

c.f. Zimmarman's Snake Oil essay & its comments today: http://news.ycombinator.com/item?id=2917384

If your keys are on a smartcard, you don't need to worry about that. The OS couldn't give up your keys even if it wanted to.

Reply on news.ycombinator.com