I really wish I wouldn't have to store the private key together with a browser extension I don't trust (no offense to the author(s)).
It would be amazing if Windows, Mac and Linux all would support some sort of "safe" gpg/pgp storage. I don't remember if I'm making this up, but i believe the OS X keyring can do this. There really should be no reason why every application should roll their own storage and interaction of the private key.
This is exactly what gpg-agent is for. Browsers should talk to a locally running gpg-agent, then it would automatically get support for things like OpenPGP smart cards. Then you don't even need to trust your OS with access to your keys, let alone your browser.
IIRC, the gpg-agent is sadly not that capable or intelligent. In theory, it should be usable for this.
In practice, I believe the agent actually just retrieves the passphrase and hands it to the requesting program, which is then responsible for actually working with the private key. So it doesn't keep your keys safely out of the hands of 'normal' programs, even though it seems like it should. Although it is somewhat confusing, and gpg-agent seems to mediate access to smartcards.
Do you not trust the OSX Keyring because of apple? Or outside attackers?
If it is apple you don't trust in this regard, keychain is the least of your problems.
If it is outside attackers. At least they should need physical access to the machine to crack it, right? (If you don't back up that specific keychain to iCloud)
not really. You could imagine a smart card with a software (the smart card itself runs the software)that would take bytes[] as an input and would output the encrypted bytes. The only 'network' communication would be between the card and the computer, and the computer would be unable to access the private key stored on the card.
You don't have to imagine them. They exist [0]. (Sorry, can't easily find a US link.) US government employees all have a CAC, as well, which is a crypto smartcard.
The key stays on the card. The card will do signatures and key generation, and also holds login/etc credentials. It works basically exactly like Malka says: bytes go in, signature comes out. It can likely do encryption as well, but you'd probably use it to generate a temporary key and then to sign the encrypted results, since the processor on cards is relatively weak.
Not quite the same thing, but I have a little (physical) keypad that HSBC provided to generate codes to sign in online. It's small, and flimsy, and my almost-2-year-old is fascinated with it -- when she manages to get her hands on it, she presses buttons and talks on it like it's a tiny phone... it's adorable, but one of these days it's going to decide she has "failed" my passcode too many times and it'll brick itself.
And when I'm spending a month or two in Asia, for example, I have no illusions that I could possibly get another mailed to me, if it broke or was lost.
These are great in terms of security, and should be an option for people who need it, but shouldn't be obligatory (I wouldn't use this for my bank if I had a better option).
At least in this case, there are a lot more eyes and attention on cracking OS X Keychain compared to this browser extension which most will forget about in a week or so.
Sorry, that was my point. There's a lot of effort going into cracking keychain, so there's a lot of attention on preventing these attacks from working.
Private keys are not fungible, if you lose one you're done, game over. By putting them in more places you're making yourself strictly less secure.
Also, with that old and worn proverb about eggs and baskets, if having none of your eggs is equivalent in value to you for having only some but not all (i.e. you must have exactly all of them, or else you fail), then putting them all in one basket is better than putting in two (or more).
> By putting them in more places you're making yourself strictly less secure.
If you're trying to minimize baskets, though, then having two very-secure baskets is much better than having N baskets ever-growing because you can't trust in their sturdiness.
Which is to say, putting a USB with your private key on it in your safe-deposit box at your bank, for example, means being more assured about the fact that you'll have a backup copy, meaning you then feel safe excluding it from local hard-disk backups and synchronized remote backups/cloud storage, and have no reason to have it on any computers you aren't currently using for the sake of having somewhere to import it from. In a sense, you've added one vector of attack, but in practice, you've removed several.
Yes, there is indeed gpg-agent [1]. And you can use it as your ssh-agent too, so you only need to run one instead of both.
I agree with you that it would be awesome to have the option to use gpg-agent from that sort of browser extensions.
Actually if browsers where able to communicate with gpg-agent it would be easy to use that as backend to store randomly generated password for web apps and services.
I don't like seahorse. I think if we're going to do secure element password storage of some sort, we need to standardize on a file format and make it cross-platform.
I'm willing to settle for standardizing on the interop format, but I'd still want it to be cross-platform. I'm not a fan of various somewhat arbitrary "store your secrets" systems coming with an operating system - they're slightly too magical to keep track of and secure, or synchronize.
GPG for example has no real way to synchronize keys across devices, but it's unclear how many or how often you'd want to use different keys other then "clearly more then once, less then all the time".
> I don't like seahorse. I think if we're going to do secure element password storage of some sort, we need to standardize on a file format and make it cross-platform.
I don't understand. gpg-agent is not dependent on Seahorse[0], though the two are often used together.
> I'm willing to settle for standardizing on the interop format, but I'd still want it to be cross-platform.
"Cross-platform" for formats is usually limited by the cooperation of the proprietary providers, not the FOSS ones. In this case, OS X does not provide an open standard format (AFAIK), though it's trivial to create an import/export utility[1] that could be used to synchronize with gnome-keyring and the like.
> I'm not a fan of various somewhat arbitrary "store your secrets" systems coming with an operating system - they're slightly too magical to keep track of
Could you elaborate on your complaint here? I think OS X's keychain works reasonably well in this respect (on by default, single point of storage for all keys). UX is the biggest challenge these days when it comes to cryptography, and having the keychain "just work" while also being a single point of storage for the device is a notable accomplishment.
> GPG for example has no real way to synchronize keys across devices, but it's unclear how many or how often you'd want to use different keys other then "clearly more then once, less then all the time".
Subkeys can be used to address the issue of multiple devices (multiple laptops, or laptop + phone).
You might want to use different master keys for work and personal use. GPG supports this, though the interface for selecting a private key could certainly be improved.
I've been using Mailvelope for a while, it's a good extension and works well. But yes, I share the same frustration regarding the private key storage in the browser.
Why can't you use the GPG keyring? Just implement the protocol in your .js app and talk to a keyring server. This is actually quite necessary if you want to sandbox your browser away from sensitive files like private keys...
I've been using this. It's pretty good but - like all PGP implementations - it's really hard to use casually.
You really need to make an effort to ensure you've got the right keys, that you can remember your password, that you know how to generate a keypair and which part of it you upload to the app.
But, once done, it works pretty well. The main downsides for me were....
- Doesn't encrypt the subject line. You don't want to say "Top Secret Docs" in there, sure, but it does make looking through mail pretty hard. Which leads to...
- No search. I pretty much rely on search to find emails. I just hadn't anticipated how much of a drag it would be to only search via sender.
Same and /second. I'd add that I've trouble encrypting emails with attachments, as Javascript encryption performance in web-based email in a browser that's being abused with lots of other tabs open is not always so reliable. Surprise surprise.
The Stanford Javascript Crypto Library whitepaper provides probably the best performance baseline for all of Javascript crypto [1], and the best they can do is roughly 10x faster than the next fastest JS crypto implementation, but still over 40x slower than native crypto.
Another thing to point out, the Google developers respect the difficulty in securely implementing a Chrome extension that performs encryption. They are going through an extensive period of public review, and they're asking people to not build and deploy as a Chrome extension until after it's been thoroughly vetted.
In contrast, the Mailvelope guys seem to have just flung something over the wall with little regard to the actual security of their implementation. Seems irresponsible at best.
Correct me if I'm wrong, but you're encrypting the message after you type in into the webmail client but before you send it? We all know that GMail constantly saves auto-drafts to server-side as you type. If your GMail is being monitored by a government (and we should assume that it is), this type of encryption client isn't going to do much for you. You'd be better off typing it in a text editor and encrypting that and pasting in.
You type your message in a special window/box, controlled by the plugin so the webmail can't read it. In fact, Mailvelope was audited to check that malicious javascript in the server can't read your plaintext.
Never mind all the other obvious problems that could occur at any stage. The webmail server could change a single setting and record every keystroke. An intelligence agency could push an updated version of the extension which records keystrokes or quietly caches plaintext. A browser update could detect the extension and start recording everything.
Any time you try to make encryption simple and easy for a mass audience you still have to educate the user about risks. Most solutions are not bulletproof enough to keep out intelligence agencies.
Seems like this opens a new window, separate from gmail, to type the message into. This window would not be sending the copy to gmail to save as draft, etc.
PGP uses the pubkey to encrypt a randomly generated symmetric key, because it's much faster to asymmetrically decrypt a small key and then symmetrically decrypt the entire message. For multiple recipients, this symmetric key is simply encrypted once for each recipient pubkey.
Basically - generate a session key, encrypt the session key with for each recipient, at the end add the text of message encrypted with the session key.
AFAIR GPG will generate a small bit of random data and use that to encrypt the message. For each recipient, tt then encrypts that new key (which is only ~100 bytes) with that recipients private key.
Minor but significant nit: that each of the recipients can open.
The reason it's significant: there are encryption protocols which require some subset m < n, but generally m > 1, such that a quorum of members must assemble or cooperate to read a message. If m = n, then you indeed have a situation where all the recipients must cooperate (that is: all are present or contribute their keys) to read a message.
The "postcard -> unencrypted email as letter-in-envelope -> encrypted email" seems to be a very good analogy for explaining the need for encryption to laypeople.
The technicals are trickier (and outside my scope of expertise), but the "why do I need to use this" answer is one of the trickiest and most important questions to answer for any security application.
I'm on the most recent firefox version after previously building it myself. It's not bad; I find it to be better than messing around with enigmail. I wonder what the pros/cons are to this as opposed to Mailpile, which I haven't used yet.
"local client" and "updated/accessed by the developer at any time" are not mutually exclusive: the most common example is Chrome, and AFAIK applications on Android can be updated at the developer's will (I'd guess it's the same for iOs and WP, too).
The model we have for traditional PCs is actually a remnant of the disconnected era in which applications were first conceived: manual update when the user knows they have a connection.
For iOS and Android at least, automatic and relatively transparent updates are a user-preference, so you can't as a developer force users to update, although I'm sure most have automatic updates enabled. You could I suppose version your API calls and disable all but the newest version from working, provided you have a server component, but that's about it I think.
On Android it's off by default, and you can easily enable/disable it. On Chrome it's on by default, and I don't even know how to disable that (I assume it's somewhere in flags, which is of course terrible UX for something like this)
Someone in this thread made a very good point - it is hard (I'd say impossible) to create usable, mainstream E-mail encryption system based on PGP and derivatives. PGP and Web Of Trust models have fundamental limitations that prevented any meaningful adoption during the years since it was invented.
It is possible to do better with NameCoin, which promises and somewhat delivered a solution to key management and practically working robust PKI.
I am still waiting for a proper browser based mail client that will let me read email from a variety of IMAP servers, rather than email 'clients' that are actually not clients, but just interfaces to a particular email service.
What is the advantage of "browser based" in this case? It sounds like you're asking for a mail client that's not tied to a particular mail provider's website, and that's what native clients have provided ever since IMAP was developed.
I think the difference is a browser extension would be portable (and work on locked-down thin clients such as chromebooks where "native" clients are "browser based").
Relatedly, I really, really, wish ChromeOS would support smartcards but reading the frustration of the government/military types that have been begging for this feature for years with no real interest by Google is very disappointing. I really like the form factor of YubiKey Neo that simply hangs on your keychain and just sticks into a USB port to become a smartcard. We're also never going to have gpg-agent on ChromeOS so smartcards is pretty much the only way to keep the private keys off the machine.
It's a nice effort, but effectively no easier than simply composing my message in nodepad/emacs/vi, PGP encrypting it, and pasting that into gmail. And that's far too difficult for 95% of the email using public.
Years ago I would've loved this, but I'm just too productive with a native mobile app. I may only be in this app 20% of the time, but I wouldn't trade that 20% for encryption.
Native apps already have good support for encryption in general. The default Mail app in OS X has a button for it, for example. The only thing new here is bringing it to the big webmail clients via browser add-ons.
Mail on both OSX and iOS have native support for S/MIME, which I've been using daily for many years. You can use it to sign and/or encrypt emails.
Keys are stored in the keychain. S/MIME uses a CA-based system for authentication, so the pro is that you don't even need to do key management (it is sufficient that one user sends you a signed message - and you use the CAs to validate the signature), and the key is automatically imported into the keychain. The con of the CA-based system are the same of SSL/TLS.
The only non-user-friendly pass is acquiring the certificate, which is as hard as getting a server SSL certificate; not complicated for an IT professional, but impossible for a casual user (plus, you have to pay them, unless you use StartSSL). Once the certificates are installed, the whole experience is mostly dumb-user proof.
For enterprises, OSX & iOS supports pulling the certificate from a specific ActiveDomain/LDAP record, so that you can automatically send encrypted mails to anybody in the company, even if you haven't communicated to them before; moreover, they support deployment through configuration profiles, so that it gets auto-installed and auto-configured for the end user.
Even if you put a good title the HN mods tend to strip it to be more bland anyway. I'd much rather they just allow duplicate story submissions with different titles and let the crowd pick the best title with voting. They aren't doing a good job with staff enforced titles.
It would be amazing if Windows, Mac and Linux all would support some sort of "safe" gpg/pgp storage. I don't remember if I'm making this up, but i believe the OS X keyring can do this. There really should be no reason why every application should roll their own storage and interaction of the private key.