Security → It's Time to Encrypt the Entire Internet

»www.wired.com/2014/04/https/ from »www.hardocp.com/news/201 ··· nternet/

"The Heartbleed bug crushed our faith in the secure web, but a world without the encryption software that Heartbleed exploited would be even worse. In fact, it’s time for the web to take a good hard look at a new idea: encryption everywhere..."

HTTPS isn't cheap. :/

It's been time since 1993.

A shared medium requires individual security.

I've thought that email should be encrypted end user to end user. And it's obvious that the certificate/key approach is too cumbersome. I'd like to see a cypher/password approach implemented.

Get an email client such as Thunderbird with an appropriate addon, where in the address book, one picks the cypher, such as AES256 and enters the secret password only he and the remote correspondent knows. Everything sent between the two is encrypted, automatically. The address book would have to be encrypted itself, at least the component that houses the secret password.

The password would be something like this:
ceHqpcPgyeo_*0{^<-yrpFujEVbUQBKdPdM]v-]y]\kyzK(>KJ.5jgydyfvl#dc#
Rots of ruck brute cracking that one. There would be a different password for each correspondent.

In email, it is obvious that continuing the same approach (key certificate) isn't going to yield a different result (low usage). It's time for plan B, and the above is my idea for plan B.

And how do you propose securely sharing that secret key?

Public key/private key is good as you can publicly share the public key and no one but the private key holder can decrypt it.

Please do and do it it every time. The more people start doing that, the less incentive will be for tracking businesses and other agencies to intercept and peruse mail correspondence of people...

Instead of using symmetrical encryption with individual passwords for every recipient (which could work of course, but inconvenient) there is well developed and reliable way - use PGP/GPG keys. I'm sure that email clients like Thunderbird have appropriate add-ons supporting that. And it's easy and well documented everywhere.

Personally I prefer to use automatic approach with mail encryption proxy. It's mail client independent (I can use any email client with it). If outgoing mail is directed to client that has public PGP key - content of the mail will be automatically encrypted before it's leaving my computer and then goes to mail server for further processing. If mail comes encrypted with my public PGP key, it will be automatically decrypted (on the fly), no any action is required from me... It's like enclosing my mail into an envelope (so no one can see it) and removing that envelope, when it comes to my mail box. It's easy, convenient, requires one time configuration and then it works automatically.

With this approach - all mails kept locally un-encrypted. But when they go via proxy to the Internet, they are protected with envelope, no one can see except its recipient.

Here is example of such proxy - .GPGrelay. You may find my old post related to it here - Re: [encrypt email SW] No Members' Choice since 2011! ~ Really?

I'm assuming that was directed at me. Maybe the sharing occurs over a phone call. Maybe I press a button in my addon, and a SSL server initiates, and the respondent accesses my IP address and gets the password. That wasn't really my point.

The thing about certificate/key versus shared password reminds me of betamax versus vhs. One was better, and one wound up getting used.

The certificate/key (so long as the key doesn't reside with key escrow corporations) approach is better. But it is a absolute failure, as evidenced by the lack of adoption by the public. It has a very low rate of usage.

The way I look at it, shared password is a half a loaf. And it is quite clear that half a loaf is better than none. Using the same approach (certificate/key) will not get us to the point where more email is encrypted then not.

So, I think a different approach, whether it is my approach or some third or fourth kind of approach is needed, in order to trigger mass adoption by the public towards encrypting email.

Yes it was.

You don't seriously think making people read a 10+ digit password over the phone is easier then clicking "generate" then "attach" in an email do you? Your idea will see even less adoption as it's WAY harder.

The biggest obstacle is ease of use. Making someone generate a key/password and then share it out of band is not going to work. Making someone dig through menus to generate a key and then force them to dig through other menus to make it used by default will also not work. You need to make it really easy to use and distribute if it's to have any chance at all of succeeding. If software makers were serious about encryption then they would:
1) When the software is installed it would either import your existing key or generate a new one
2) Turn on encryption by default
3) Attach your public key to all outgoing messages
4) When sending to a new recipient who you do not have a key for, throw up a box giving you the option to either a) send "signed only" (unencrypted) with the hopes of getting their key when they reply or b) send a welcome / "message waiting" email instead asking them for their public key so you can send them the encrypted message.

If you wanted to trade some security for backwards compatibility you could replace the box in #4 with just sending signed only instead of asking. Both key distribution and key selection could be done with headers (say X-My-Public-Key: and X-Encrypted-With-Key:) instead of inline as well to make the whole thing transparent to end users.

/M

Crypto is easy. Key management is hard.

Who instructs my mom?

With all due respect to your mom, what about me?
To this day I still struggle with key management.

If you use Verisign, now Symantec (I have issues with sites that don't let you easily see their pricing options) sure you're going to pay an arm and a leg, but there are more reasonably priced offers, like DigiCert.