Slashdot Mirror
What Gmail's New TLS Icon Really Means: Email Encryption Is Still Broken
An anonymous reader writes: On Safer Internet Day Google announced that Gmail will display warning signs for missing encryption and authentication, a great initiative indeed! Now that it's live we've taken it for a spin, only to find that the warning when composing email is quite slow (for new domains), and that they fail to mention that the non-authenticated TLS encryption that the currently sad state of SMTP encryption leaves us with is really poor, and vulnerable to almost anything (except passive wiretapping). I rather wish they took a stance on how we could move on to proper email encryption.
The problem here is that crypto infrastructure in general is too fucking hard for anyone but dedicated security professionals to work with. Hell, even they have a shitload of trouble with it, as we've seen from the many OpenSSL bug debacles lately! This technology is way beyond what average, or even above-average, computer users are capable of dealing with. Some people will probably reply saying, "But it's not that hard! I can understand it!", yet those are the kind of people who understand this technology the least. At least average computer users know crypto technology is way beyond their capabilities. These self-proclaimed "experts", on the other hand, don't realize how much they don't know! Until crypto becomes far more simpler for average folks to use then we just won't see it used.
Duh.
Use S/MIME, PGP, etc...
All the transport level stuff isn't going to protect your email or ensure it's not modified in transit (or at the destination or origin).
Gmail's help on their new icon:
If you see the red padlock while composing a message
Don’t send confidential material, like tax forms or contracts, to that email address.
Fuck that... if you're sending confidential email without encrypting the content, you're already screwed.
For semi-important information, one should at least digitally sign the content to prove it wasn't modified in transit (ex. this should be used for any contracts, and if it's very sensitive, it should also be encrypted, and not just on the transport layer).
Bill Gates said they would solve the spam problem a few years back. Yet my inbox under office365 that my employer uses is a chum bucket of spam, while good cron and batch job emails end up in "junk" half the time. wtf, Gates. billions and you couldn't at least have pushed domain a authentication/verification system?
Please, this has been available since 1991. 25 years and now there's concern?
PGP https://en.wikipedia.org/wiki/...
09 F9 11 02 9D 74 E3 5B - D8 41 56 C5 63 56 88 C0 45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
I consider gmail to by my biggest threat to the privacy of my email.
If I want end to end security, well there is a standard for that. I use it. It works.
But gmail is close to having a monopoly on email. It isn't quite yet, but almost everyone I know uses exclusively gmail now. That means if I want to email them, Google IS the man in the middle. I can't easily email my friends without giving Google the contents of my email, which they will use to build a profile of me - and I've never signed up for any of their services or estasblished any kind of business relationship with them.
Furthermore, most small to medium businesses are using gmail.
Think about this: we used to have a decentralized, non-censorable, email standard that no one entity could control or pervert for their own ends. But the whole world said, "Fuck that, we want one advertising company to see everybody's email!.
Google is the main threat to the privacy of email today. Like Bruce Schneier observed, they want you to have email privacy from everyone except them.
PGP is godawful
You really want to try to teach people how to use that? S/MIME is better but you still have to port your private key to a bunch of devices- at least it is supported natively by most clients.
to pull a Google, while they continue to read all your e-mails. Eric Schmidt, the politician at the Department of "Justice" who also runs Google, told us everything was encrypted, and the sheep were happy and thought nobody could read their e-mails or Internet traffic.
Some of you will have a hard time with this, but... why is the problem here with SMTP? Is it really that hard to understand that MAIL TRANSPORT is not compatible with HIDE MY STUFF? Good grief people, you can't truly be that ignorant.
Do you trust that anything you mail through the Post office, FedEX, UPS, or any other mail service is "Secure"? Do you believe it's impossible for people to know what's in your boxes because you use those services? I can provide you a list of drug dealers who thought so too, but they are jailed for that thought.
Want secure, use secure. Lotus Notes was friggin awesome for securing content. Nobody wanted to pay for it though, and all the cool kids were using Outlook because you could drag-n-drop audio files right into your email (also read fart noises). Many Writing applications have encrypt/decrypt features. Zip has it too, but generic standard email? Come on now.. it's a MAIL TRANSPORT and works very well as a mail transport.
If you somehow believe "Generic Transport" can also be "Secure", I got some ocean side property you may be interested in buying.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
Great, so this gets you end-to-spam filter encryption. Anyone who has their email delivered to a 3rd-party for spam filtering could appear secure but would only be secure for the first hop. False sense of security.
I dont really need my toasters email alert to be encrypted, I just want it to work
Using GPG seems pretty painless, at least on OS X.
The real problem with GPG is the same one you'll run into with S/MIME... almost nobody else is using it, which means all you can really do is sign your own messages.
#DeleteChrome
Google cannot support client-side encryption. First, client-side encryption is impossible in a web browser without a client-side plugin; gmail's primary interface, and indeed raison d'être, is to provide web access to email on any computer, without having to download a plugin and keep a cache of certificates locally. Second, Google is unwilling to provide such a plugin because it would interfere with the company's ability to scan e-mail and build advertising profiles. It might one day be possible to convince Google to provide server-side encryption on data-at-rest, taking care of S/MIME transparently on its own servers, but nobody with any sense would ever use such a system.
I had someone contact me about my server -> gmail as I host a number of mailing lists and other technical resources. After much research it seems the only way to fix it is to hard code that gmail and other locations are to be encrypted vs the default opportunistic encryption of "if they offer it, try it".
There are a lot of things that should be addressed here to ensure data is properly encrypted, this is easy and a solvable problem but at least for postfix I had to enter some custom maps which the software should have solved for itself with the 'may' setting. I'm past the UUCP days, I don't want to maintain a map of who can do things and who can't. We need to solve this software not doing the right thing problem first.
Ive run my own mailserver for quite some time as both a mark of hacker pride and a means of circumventing what has historically (until google started giving a shit because snowden made them) been a very lax SMTP ecosystem. I use the DJB curve primes, i use 256 bit tls 1.2, i use multifactor, but as for other mailservers? crypto doesnt seem to be even a slight consideration. ive had to leave it enabled opportunistically on my mailserver, however most of the time I fallback and dont use it.
Good people go to bed earlier.
How are you going to implement that for web mail exactly? Will you let the sever do it? That means Google gets to assert your identity, and if they ever get compromised we have a whole mess of people sending signed mail with signatures that may or may not be valid and we are back to a more or less unauthenticated situation.
You could have the client do with JavaScript but that still leaves the door open, if the server is compromised and sends an altered script how can you know?
You go the traditional install plugin route, but then web mail is no more portable than a fat client.
There just isn't actually a good answer for this. You can have secure E-mail or portable E-mail but not both.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Our email servers at work handle encrypted traffic all day every day. STARTTLS works and it works well. Find something else to worry about.
Google is trying to force servers to use STARTTLS encryption for port 25 MX traffic, this is all commendable, but they are giving their users a false sense of security. When gmail does not display the broken padlock it simply means that the first hop to the recipient's MX server supports STARTTLS, but mail is routinely stored in plain text queues on multiple servers, transmitted on in additional hops that are not necessarily encrypted, and even the first hop encryption often times uses self-signed certs or certs signed by non-authoritative CAs, so the message being sent, while being encrypted is still vulnerable to man in the middle attacks.
But Google is giving the impression that if that first hop offers STARTTLS, then the message will be sent securely and encrypted. This will result in people putting all sorts of credit card details and other information in their emails thinking (because Google said so) that the message is secure, when nothing could be farther from the truth.
Google needs to stop this right away, it's going to do way more damage than good. There is only one way to hide the content of an email from prying eyes and that is with properly implemented PGP encryption. There is no way to hide the meta (envelope) data from prying eyes. It is really important that people not be misled on this account.
Windows is a bonfire, Linux is the sun. Linux only looks smaller if you lack perspective.
How are you going to implement that for web mail exactly? Will you let the sever do it? That means Google gets to assert your identity, and if they ever get compromised we have a whole mess of people sending signed mail with signatures that may or may not be valid and we are back to a more or less unauthenticated situation.
You could have the client do with JavaScript but that still leaves the door open, if the server is compromised and sends an altered script how can you know?
You go the traditional install plugin route, but then web mail is no more portable than a fat client.
There just isn't actually a good answer for this. You can have secure E-mail or portable E-mail but not both.
Agreed, nobody should be using web based email.
Google would be more helpful by cancelling the service.
It's too bad on Linux either - many popular mailers wrap it all up in a nice GUI and you never have to be exposed to the nuts and bolts of it.
But yes, same problem, almost nobody is using it. It's like people don't really want security.
Second, Google is unwilling to provide such a plugin because it would interfere with the company's ability to scan e-mail and build advertising profiles.
Actually they were working on a PGP plugin for Chrome, though it's moving very slowly, possibly dead.
Use S/MIME, PGP, etc...
All the transport level stuff isn't going to protect your email or ensure it's not modified in transit (or at the destination or origin).
Gmail's help on their new icon:
If you see the red padlock while composing a message
Don’t send confidential material, like tax forms or contracts, to that email address.
Fuck that... if you're sending confidential email without encrypting the content, you're already screwed.
S/MIME & PGP do not hide the sender, receiver or the subject of the email (nor where you sent it from). That information is in the header, and only TLS or STARTTLS will hide it.
By the way, the TLS-SMTP problems are related to STARTTLS and stupid client software, but not TLS (but cert verification requires DNSSEC for either).
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
Has anyone any idea what's happening with Google End-to-End ?
nobody should be using web based email.
At first I thought you were being sarcastic, but then realized that sarcasm makes no sense here. So you must be serious.
It's quite simple - use email for the 99.9% of your communications that does not need to be secure. Send your tax forms through a secure web site. Problem solved. Web email is still useful.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
I don't think that's the important part to hide, you want to hide the message.
>Implying that encryption cannot be implemented in JS.
>2016 not using JS for encryption.
>Client side JS.
>JS.
https://en.wikipedia.org/wiki/...
How are you going to implement that for web mail exactly?
End to End with something like Mailvelope?
You go the traditional install plugin route, but then web mail is no more portable than a fat client. There just isn't actually a good answer for this. You can have secure E-mail or portable E-mail but not both.
People SHOULD be using "webmail" via IMAP with proper e-mail clients Then it's portable because there are mobile mail clients that can support PGP. So yes you can have portable secure e-mail, even on a phone or tablet.
You are calling for link-encryption. That is obvious nonsense for email. Proper email encryption is end-to-end and does not trust the transport at all.
Incidentally, this problem has been solved since 1991 with PGP.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Great questions, and they all have answers already.
Webmail s/mime, pgp, gpg encryption: See https://www.mailvelope.com/, or https://www.penango.com/produc..., or similar products.
Alternatively (or in addition to that), Google could provide a javascript based solution. The private key storage would be an issue, but it could be held server side via zero knowledge encryption (ie. enter password on client side, get blob from gmail, decrypt client side). JS validation is also a solved problem, though it's ugly - basically, you just sign the javascript and then validate the signatures, but there is, of course, a bit more to it than that.
For almost all users on smart phones, they use a local client, and not webmail. Google could CERTAINLY implement S/MIME and pgp support there!
As of this moment, you can already do that with products such as R2Mail2 (https://play.google.com/store/apps/details?id=at.rundquadrat.android.r2mail2&hl=en).
You go the traditional install plugin route, but then web mail is no more portable than a fat client.
For this to be even partially true, you would have to assume that all received email is encrypted (rather than just signed).
Personally, I find the need to encrypt email to be rare, but the need to verify the contents (sign) to be useful almost all the time.
If the email is only signed, then you can still read all your email via webmail without a plugin. You can even verify the signatures without a plugin (with just javascript) because signatures do not rely on the recipients private key.
You could also still send unsigned/unencrypted email, so a dumb webmail client is still useful.
All that said, the goal would be to make the feature ubiquitous. Google ships chrome, and could ship the "plugin" as part of chrome. Firefox could add a similar feature. Both could use the existing password/key storage that is already built into the browsers. For users that are taking their security VERY seriously, they'll be using a dedicated client, and probably won't be using gmail anyway.
You can have secure E-mail or portable E-mail but not both.
Sorry, but you are wrong.
All that said, it's obvious that gmail isn't the party we should look to for these features. They need to read the contents of your email in order to pay for the service (targeted ads support the service). Part of the business model is being able to read your email, so you can forget about keeping your email private from them based on any solution they provide.
I am surprised that they haven't attempted to implement s/mime or pgp with server-side private key storage. While that would significantly reduce the security of those technologies, it would also significantly increase the security and privacy for all those that currently use clear text email (and especially their webmail service), and it would provide interoperability with existing real email clients implementing the same standards (outlook, thunderbird, alpine/pine, mutt, mail.app).
There's nothing wrong with them improving the state of server-to-server and client-to-server transport layer encryption but, on its own, it does not provide sufficient protection for the examples they provided.
Here is a script that I use to pass sensitive content from outside email. I should probably redo it to use keypairs on both sides.
#!/bin/sh #openssl genrsa -aes256 -out ~/.prv.key 8192
#openssl rsa -in ~/.prv.key -pubout -out ~/.pub.key
PVK=~/.prv.key
PBK=~/.pub.key
SESSION_KEY=$(mktemp -t crypter-session_key-XXXXXX)
case $(basename $0) in
encrypter)
openssl rand -base64 48 -out ${SESSION_KEY}
openssl rsautl -encrypt -pubin -inkey ${PBK} -in ${SESSION_KEY} |
openssl base64
echo ___:
for f
do
openssl enc -aes-256-cbc -salt -a -e -pass file:${SESSION_KEY} -in "${f}"
echo ___:$(basename "${f}")
done;;
decrypter)
TMP=$(mktemp -t crypter-tmp-XXXXXX)
PW=${HOME}/.pas
while read l
do if [[ ${l%%:*} == '___' ]]
then if [[ -s "${SESSION_KEY}" ]]
then f=$(basename "${l#___:}")
openssl aes-256-cbc -salt -a -d \
-pass file:${SESSION_KEY} \
-in ${TMP} -out "${f}"
else openssl base64 -d -in ${TMP} |
openssl rsautl -decrypt -inkey ${PVK} \
-passin file:${PW} -out ${SESSION_KEY}
fi
> ${TMP}
else echo ${l} >> ${TMP}
fi
done
rm ${TMP};;
esac
rm ${SESSION_KEY}
This company lives off of mining your data and violating your privacy. You expect them to allow you to fully protect your communications to the point where they can't figure out how to advertise to you?
Give me a fucking break.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
The two products you pointed out are essentially plugins, they won't be installed on your friends computer and they wont be on the computer in the Hotel business center. Try again. People like web mail because they don't have to carry their own laptop everywhere they go.
For this to be even partially true, you would have to assume that all received email is encrypted (rather than just signed).
No, if you are not in a position to verify the signatures, and sign your replies we are back to essentially have no identity or integrity assurance at all. Only now the non technical person has to remember different rules are in effect when using the web interface than when using their client at home. That isn't a win, its a recipe for tears.
As to mobile devices you have a point, but who wants to compose a long form message on their cell phone, table maybe but not phone.
I still see it as either portable or secure, not both.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
While usage of gpg is low, signing does show people that you use it and can help them find your pubkey if it's on a keyserver.
The story is from an author of utterly unknown email server software ranting about something he thinks he understands but doesn't, and the proceeds to tell us that the method he supports is the right one and all others suck ... If he weren't biased I might have ... Oh who am I kidding, dude doesn't know what he's talking about and utterly fails to understand how and why email is in the star it's in: hint ... Your shiny new feature breaks compatibility with far too many PAYING CUSTOMERS, so some random no name vendor like yourself doesn't mean jack shit.
No one who matters is going to go hard TLS until everyone of their CUSTOMERS supports it. Your new shiny tech that you think will solve the problem will do the opposite, and just make it take longer.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
MARID was when Microsoft's chicanery destroyed any chance of global co-operation for email source verification, which is the necessary first step for spam elimination.
But, seriously - if YOU, YOU PERSONALLY, aren't aware of whether your email has valid SPF or not (better yet, DKIM) then YOU, YOU PERSONALLY, are a part of the problem. This shit is just not hard; SPF takes literally 5 minutes to implement on your DNS server today.
However, it's Microsoft's fault that the email server and service providers haven't solved the problem for you. They were just such dicks about their submarine patents that they alienated everyone and broke consensus for a decade.
You're telling me that PGP is a serious contender for non-technical people to secure their communications? Seriously?
Google cannot support client-side encryption.
That is true. ... it is protected against automated content mining. Profit!
but you can choose "lesser evil" compose message locally, sign/encrypt message locally (including business "headers") , convert to ascii and then paste into gmail editor.
you are not signing whole email with headers, but
Given they can't even maintain a steady pop.gmail cert I'm not expecting too much.
So if they DO get hacked, we're in the same mess as now.
But if they DON'T get hacked, we're better off.
Sounds like a no-brainer to me ... bring-on client-side encryption.
Of course they won't, as mining email data is linked to their advertising revenue.
The reason people don't use PGP is because of the name Pretty Good Privacy makes it sound amateurish (that and the initialism PGP is too similar to PHP). Maybe they could get more users if they called it Good Privacy or Very Good Privacy, but I know there's a local-maximum trust in there somewhere because I think trust would go down if they called it Excellent Privacy or Perfect Privacy.
IMO, more people would consider using it if it used an animal name or some name from mythology.
You dont need a plugin, just implement encryption via JavaScript where the private key pairs are stored on the server but encrypted with a secret key derived from a password the server never sees. Server sends an encrypted blob to the client, client inputs a special password which then decrypts their keys.
All of the communication happens over HTTPS so man-in-the-middle replacement of the JavaScript cant easily be done.
Is it as secure as having a dedicated setup with keys stored in the client and a plugin on the local system? (or using a dedicated client with proper encryption support) No. But its much more secure than doing nothing.
Of course this leads to 2 problems for Google. First is that Google looses the ability to scan everyone's email and use that to feed people targeted advertising. And the second and more serious is that Google is now unable to provide emails when sent a warrant or a secret letter or whatever and then has to compromise the system for everyone so it can obtain the private keys of the user(s) the government is interested in (or do what Lavabit did and shut it down but I dont think Google can do that)
I still see it as either portable or secure, not both.
There are a million shades of grey between the absolutes.
Phones are portable, and can be secure, as you noted (and in so far as a phone can be secure).
Moving yourself between random 3rd party computers with who knows what running on them and checking your webmail from them... yeah, that's never going to be very secure.
Moving between multiple devices you own... you can certainly use a local mail client, or a plugin, or a javascript implementation with zero knowledge encryption holding the private bits.
Moving between devices you do not own, but aren't entirely untrustworthy (ex. a friends computer), it'll depend on the situation (maybe he has the plugin installed already and you're carrying your usb key with your private bits? maybe he creates a guest account on his computer for you? maybe you use the 100% javascript solution and the zero knowledge encryption to pull your key from an encrypted blob stored online somewhere?). There are option.
And, maybe you consider the server-side s/mime implementation as another possibility. While partially compromising the security of your private key, it's still adding a significant amount of security and verification.
Your duality statement could easily be exaggerated to, "something is either online or secure, not both". You've gotta draw your lines somewhere, but there are multiple end-to-end email encryption solutions that will greatly improve the privacy and verification of email through webmail far more than the TLS work that the article mentions.
And you're going to sign/encrypt locally with what software? Oh, that's right, you need a plugin for that or some sort of separate software. There's no easy way to roll that out to all gmail users: grandma isn't going to understand it.
Are you trolling? Do you understand what an S/MIME or PGP cert is? Where is your magic JS going to get the encryption certificates it needs to do the encryption? The problem with encryption is not that the code is hard to do: it's that the key is hard to secure.
Gmail's strength is that you can log in from anywhere with no software other than a standard web browser. That means that you don't have configuration files with you (or certificates): you don't haul around anything. You just log in through a web browser, and you're in your e-mail. The take-no-files-with-you aspect means that you can't have client-side private certificates. You can't send certificates from the server, (a) because letting the server store your certs is a bad idea, and (b) they'll be intercepted en route for a game over. You can't have them on the client, you can't have them on the sever, so you can't have them. No certs = no S/MIME and no PGP. EOL.
Previous comment is spot on - why mod it down?
E
The keys can be saved on the server and processes in the JS client. The point is to encrypt email during transit so nobody can snoop. If you don't trust gmail don't use gmail. Alternately the keys can be decrypted with a user inputed pass phrase in the JS client, then mean even gmail would be unable to read your mail. Assuming they don't snoop your pass phrase themselves. But if that is a problem, why use gmail in first place.
There is no need to plugin for any of this.
The keys can be saved on the server and processes in the JS client.
Keys cannot be saved on the sever. If you give the private keys to Google, they can decrypt the messages at rest on their servers. This is why no encrypted storage uses server-stored keys: see Spideroak for an example of modern encrypted storage that keeps keys client-side only for a very good reason. Rule one of having keys: never give them to anyone.
The point is to encrypt email during transit so nobody can snoop
The point is not to encrypt email during transit. The point is to encrypt e-mail at all points between the correspondents. The mail should be encrypted clientside and remain encrypted while at rest on the servers as well as during transit. S/MIME and PGP/GPG do that. Encrypting only during transit means that plaintext is sitting around waiting to be hoovered up by Google (for ad profile building) and whatever other parties (NSA, hackers, etc) have access to Google's servers.
If you don't trust gmail don't use gmail.
Despite seeming an off-topic statement in a discussion about securing gmail, this is the root of the problem. Google is scanning gmail accounts and does provide governments (and any hackers it doesn't know about) with access to those accounts. Using client-side S/MIME or PGP/GPG solves that trust issue, for values of "solve" that require an attacker to expend more work than is feasible. Self-hosting e-mail also solves that trust issue in other ways, but it is out of the realm of discussion, since the topic is how best to secure gmail.
Alternately the keys can be decrypted with a user inputed pass phrase in the JS client, then mean even gmail would be unable to read your mail. Assuming they don't snoop your pass phrase themselves. But if that is a problem, why use gmail in first place.
The user passphrase is far weaker than an S/MIME or PGP key. That negates the point of having an S/MIME or PGP key, which is in effect a very, very long passphrase stored clientside. The difference between the two (certificate and passphrase) is important to cryptography: for this, see any discussion of the difference between SSH with keys and passphrases (or preferably both in combination). There is an advantage to having both, but there is no security advantage in having a much weaker link alone guard a much stronger one. Take a second to reread that carefully.
There is no JS solution to the problem of securing gmail; otherwise, one would have been written long ago. People have thought about the issue and realized that there is no good solution. That is why people have created solutions like the Firefox addon for S/MIME and the MyMail Crypt for gmail: they are plugins for a reason. You should try understanding that reason, because it will advance your knowledge of the dangers and limitations of cryptography.
I'm not saying this to be an asshole, but because you demonstrate a certain hubris when it comes to what you believe can be done with Javascript and how security works. That hubris could hurt some project that you work on, and that pain is unnecessary. You will be better able to contribute valuable work to your business or the community if you take the time now to learn the limits of what you should and should not do with encryption keys.
You dont need a plugin, just implement encryption via JavaScript where the private key pairs are stored on the server but encrypted with a secret key derived from a password the server never sees. Server sends an encrypted blob to the client, client inputs a special password which then decrypts their keys.
What is the difference between using the decrypted key to sign the message and using the passphrase? Think that over. If the passphrase gets the key, and the key signs the message, then the passphrase, in essence, signs the message. That means that the key is extraneous. You might as well simply sign with the passphrase: the key is adding no security whatsoever. The key is a distraction, a Maltese Falcon, in that scenario. All an attacker with access to the key (anyone with a warrant) needs to do is crack the passphrase, never the key itself, because cracking the passphrase will crack the key. Furthermore, the passphrase will logically be simpler and shorter than the key. It will be crackable in far less time, probably only a matter of minutes for a well-equipped and funded adversary.
They could at the very least provide signing, and verification of externally signed messages... If people started getting used to all messages being signed then phishing scams would become a lot less effective, and the presence of a signature doesn't have any negative side effects on anything else.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
The point is not to encrypt email during transit. The point is to encrypt e-mail at all points between the correspondents. The mail should be encrypted clientside and remain encrypted while at rest on the servers as well as during transit. S/MIME and PGP/GPG do that. Encrypting only during transit means that plaintext is sitting around waiting to be hoovered up by Google (for ad profile building) and whatever other parties (NSA, hackers, etc) have access to Google's servers.
In an ideal world yes, but for now having mail thats encrypted whenever it traverses the internet and is cryptographically signed so you can verify the recipient is an improvement. Yes this requires trusting google (which users already have to do anyway), or not - you're free to use a different email provider and/or do all the crypto client side if you want.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Not if the passphrase is manipulated using something like argon2 or scrypt that are specifically designed to make brute-forcing the password/key difficult and computationally expensive.
I doubt even the NSA has the computational horsepower to crack the best of these schemes in a reasonable space of time (if you have the parameters set really high that is)
So you're saying that...
1, users would need to trust google (but clearly they already do or they wouldn't be using their mail service)
2, the worst case (google getting hacked) would be no worse than the current status quo.
So basically email signed/encrypted by google would be better than what we currently have, but not ideal. And users are free to pick a different provider and/or do proper client side crypto but most simply don't bother. If gmail started implementing pgp or s/mime even server side and started prominently showing when mails are signed or encrypted then it would massively increase usage and awareness which could only be a good thing.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Well by portable i guess they mean that it can be accessed from any device without needing to install a client (ie from your work desktop)... From a mobile device that you control is entirely different as you can install whatever encryption tools you want on there.
While webmail can be convenient, it's also dangerous not only because of the lack of end to end encryption but also because its primary utility (ie logging in from a random place) is its biggest danger - how do you know who's monitoring any given random box you might use?
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
When it comes to mobile, apple already implement s/mime on ios although configuring it is not as simple as it could be (ie even if you have mail accounts synced from a mac it can't automatically transfer your keys).
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
You can as a minimum implement verification of signatures into a webmail client, as that can all be done server side...
Users already have to (or should) remember that there's different rules when accessing webmail, in fact you shouldn't be accessing the webui from random machines if you value security at all. You should always carry your own portable device, and access your mail from there.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Well, you could call in Perfect Privacy, but then we all know that, particularly if some settings are screwed up, someone might break it, then you'd be Almost Perfect Privacy But Never Mind. And that's not a very good name.
If you're concerned about google reading your mail then such a system wouldn't work, while in theory the javascript performs all its work client side there is nothing stopping them changing the javascript to submit your passphrase to the server. Unless you're going to thoroughly inspect the javascript every time?
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Because the key is a private key with a public key counterpart, while the passphrase is a symmetric key for decrypting (in this case the main private key)... If you have the public key its easier to attack the private key, so the private key generally needs a much larger keyspace to provide an equivalent level of assurance to a symmetric key.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
In an ideal world yes, but for now having mail thats encrypted whenever it traverses the internet and is cryptographically signed so you can verify the recipient is an improvement.
Not really. With SMTP you have no control over which MTAs the email gets queued on before it gets to the recipient. If the content is not encrypted, it will be on those untrusted servers in plain text for some (hopefully very short) period of time before it gets routed to the next server.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
PGP is great. It has one slight issue: you do not see it anywhere. The reason? It is not pre-installed.
It would be trivial to add it to Outlook, Gmail, Hormail and any other mail service or program by default. Now it needs action on the users side.
I would like Email to have PGP by default. Not to hide any content from others (because two people is one to many to keep a secret) but sender verification. Is it my bank that send me the email, or SpammerJohnny who found out you can make your own From in Outlook?
If it would be included by default in email programs, it would be uses. Not by 100% and some would turn it off, but by enough to get others to use it.
It could solve a LOT of the spam email issues, especially phishing mails. No, it will not solve everything; it will be better then what we have now: nothing.
I am not going to hold my breath. It will never happen. At most, each will try to push their own system that willl not work, leaving us worse with what we have now: nothing and no way to improve it.
Don't fight for your country, if your country does not fight for you.
Utilizing decent encryption would have a negative impact on their profits.
S/MIME is pre-installed on most mail clients. It works on iPhones, Thunderbird, Outlook (the one with a client, not the web version)... I used to use it with kmail back in the day, more than ten years ago. It's been a standard feature that long, and the DOD's been using it forever.
The only problem is that S/MIME, like PGP, GPG, and the ilk, doesn't work on webmail for reasons contested on other threads in this discussion. Gmail is primarily webmail.
This is why no encrypted storage uses server-stored keys: see Spideroak [spideroak.com] for an example of modern encrypted storage that keeps keys client-side only for a very good reason.
Spideroak doesn't do what you think it does. To demonstrate that: install their software on a new computer, enter your username and password, gain access to your files. No need to transfer a key from the previous computer.
Spideroak uses your account password (the same one that they can capture when you log into their website or set up a new client) to generate the encryption key. There is no more entropy in your key than there is in your password (choose the password wisely, because they'll let you make an account with a single letter password).
They could gain access to your account at any time. Their client is closed source. Their entire system is all smoke and mirrors and traded security for convenience. They are the perfect example of poor security, but people here seem to love them for some reason. Well, that reason is marketing I guess. They're great at that.
http://openpgpjs.org
https://github.com/openpgpjs/openpgpjs
Even as an SMTP admin for just over 20 years I can't understand what it is they're trying to accomplish here other than perhaps creating a foothold where they can get everyone to pay them for email verification. My port 25 doesn't announce STARTTLS because my port 25 is for INCOMING mail. Did I miss an RFC somewhere that says I'm supposed to encrypt outgoing SMTP streams? What if my method of emailing is a text client on the mail server to which I connect via SSH? It's all just too vague and suspicious.
Yeah, start teaching the users, that something is secure, if a lock appears INSIDE the website (or insecure, if its a broken lock). Because err nobody would ever use this to tell the user the fake banking website is as secure as the email on gmail.
People use computers, which are named like fruit. And operation systems from companies, which are named like some detergent. Their text processor's name implies you may only write one word and so on.
Nope, names aren't important. Ask the novice users, if they even know, what PGP means.