Mailvelope – OpenPGP Encryption for Webmail
mailvelope.com
mailvelope.com
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.
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.
Protocol docs here: https://www.gnupg.org/documentation/manuals/gnupg/Agent-Prot...
The ssh-agent, on the other hand, does keep the key material out of the ssh client executable.
But yes, obviously.
(https://blog.mozilla.org/security/2013/02/13/using-cryptosti... close ... so close)
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)
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.
0: http://www.acs.com.hk/en/products/17/acos5-64-cryptographic-...
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).
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).
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.
At the very least, these extensions could provide an option to communicate via the GnuPG Agent protocol.
This sounds very much like what I would want, yes!
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.
[1] http://manpages.debian.org/cgi-bin/man.cgi?query=gpg-agent
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 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.
Also, the problem is that you can't re-use the keyring from GPG, since they are using openPGP.js and the duplication is inevitable..
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.
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.
https://code.google.com/p/end-to-end/
and Yahoo plans to use that code to fork his own
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.
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.
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.
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.
Try gpgtools with a openpgp smartcard. Its easily the most user friendly experience going for token based PGP, and supports 4096 bit RSA keys.
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.
https://github.com/toberndo/mailvelope/releases/tag/v0.10.0b...
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.
It is possible to do better with NameCoin, which promises and somewhat delivered a solution to key management and practically working robust PKI.
There is another E-mail encryption Chrome extension, called SecureDolphin (http://www.securedolphin.com) that uses NameCoin for public key delivery. Check it out in the Crome Store (https://chrome.google.com/webstore/detail/securedolphin/nefm...) if anyone is interested.
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.
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.
Why not, "Mailvelope - OpenPGP encryption for webmail"?