A Guaranteed Spam-Free, Pre-Encrypted Email Service

Hacked emails have become so common that the Russians actually started using typewriters to insure privacy. There's a better way.

Some of the best ideas are at their heart, simple. This one is both easy and complicated. The core concepts are very easy to implement, but the complicated part is finding somebody willing to launch such a service. After all, if they do it right, it will make them billions.

Here's how it would work.

Unlike traditional email services, which send plain, unencrypted text through the Internet, this service would be a closed system. In order to communicate with somebody using this secured system, both sides would need to be subscribers of the service, and both would be required to accept an invitation to communicate with each other.

Example (fictional) Company... PrivateMail.Email

For example, assume Bob is a diplomat or Hollywood studio President, who frequently writes sensitive information that needs to be private. He signs up for "PrivateMail.Email", and sends an invitation to Angelina, the person he needs to communicate with. Embedded in the Invitation is Bob's "Public Encryption Key", let's call this "Salt".

Angelina accepts Bob's invitation, and in her reply is her Public Encryption Key, let's call this "Pepper".

So, Bob has Angelina's Public Encryption Key on his computer, and Angelina has Bob's. At this point, using a custom email App, every time Bob sends Angelina an email, it's pre-encrypted with a unique combination of both keys, "Salt and Pepper". Once the email is encrypted, the protocol would be just like any other email system, but the information is encrypted before it even goes online. Using this system, if the transmission or even the server itself is breached, the message would be completely unreadable unless the hacker has both encryption keys... the Salt and Pepper.

What this means is Bob would have a database of the encryption keys of all the people he will be communicating with, so that every email is encrypted with the unique combination of encryption keys for each invited person he communicates with. To be clear, while every email he sends through the service is encrypted, they do not all share the same encryption key, because each email is encrypted with the specific combination of his key with the recipient's key.

So if he securely communicates with 20 different people, all 20 will have their own combination of his key, plus theirs.

Two Approaches to Implementing the Service.

1. Assign both parties an email address within a closed system.

This would limit participants to communicating within the same platform, so they would be assigned Bob@PrivateEmail.Emal and Angelina@PrviateEmail.Email. Using this approach, you would know for sure that any email address within the private email domain is private and the protocol is always turned on.

2. Creating an open standard.

Using this approach, any email account in the world would be able to participate, so whenever a secured email is received, it will be scrambled and unreadable unless the receiver is using the correct email software that contains their database of encryption keys. This would actually be somewhat easier to implement and it would allow people to send emails without modifying email servers. The only change is that the participants would need an external email reading app that can process the invitations, and track the encryption key database.

The only down side of the open approach is you would need some kind of indicator to remind people when encryption is turned on or off, so they don't accidentally send a sensitive email without knowing if encryption is turned on. An easy fix is to build a simple graphic into the email software that essentially "Certifies" the email as being private.

Technically, I've simplified the system just a bit, by leaving out private keys and other goodies, but deep down what we have is a VERY simple system for every single email to be completely private. There would be absolutely zero chance anyone could read mail from a hacked server.

Because the system is by invitation, where both parties have to accept the invitation, you would also guarantee ZERO Spams.

Related Posts

So, where you store Salt and Pepper? On a local machine? It's not safe, and what if Bob lost his keys? Do you want to store it on the internet? That's like gluing the key to the lock.What about transferring the Salt and Pepper? A man in the middle can take the Salt and Pepper and use it later. This is just screwing things more than ever.

Local, but passwords are still required.

A closed, invitation only system would guarantee #1, Spam free emails, because you could only send and receive emails between members who accept your invitation.

Encryption is not essential to a Spam free system, but for those who absolutely need truly secure emails, the encryption keys would never be stored on the server.

On the positive side, if the server is hacked, as it was with Sony, every email would remain totally unreadable, and therefore secure. Since each email was scrambled before sending, the server's only role was to send and receive the already encrypted email.

You can think of this as a P2P email system. Servers only facilitate transfers between parties, but they never have access to the keys.

On the local side, the user will be required to enter a secure password, which unlocks the security keys for the session. Although this still leaves room for access if that user shares the password, it's far more secure than when somebody hacks a server, exposing countless accounts.

On the downside, if you forget your own password, there would be no way to unencrypted the local security keys, so you would lose access to all the original emails. That may sound like a real big negative, but for some people, that's a small price to pay for truly secure email... with "Plausible Deniability" if you are asked to release emails that you don't want made public.

* Note: The ideas on "Idea of the Day" were posted without any formal research into existing inventions.

In some cases, patents may already exist for these ideas, in other cases, there may not be any existing patents and you are free to develop and explore the viability of developing and patenting the ideas.

The authors make no claim that any of the ideas are safe, practical, or suitable for any particular purpose. You are responsible for the results of trying, developing, patenting or using any of the ideas on this site.

For some people, our ideas are just an interesting read, but our goal is to encourage you to take action. If you see an idea that you like, do something with it... Take action.