The Idea Fountain

Also of great importance is the ability to digitally sign an encrypted message to assure not only the authenticity of the sender but that the message itself was not tampered with in transit. This Public Key encryption technique allows for non-repudiation- not being able to deny that the message did in fact come from its claimed source. Now of course, all signing and types of authentication techniques just mean that the person who sent the message had the keys to “look” like the real sender. This may be Biometric, physical, one time passcode generator, etc. The point being is that digital signatures give a MUCH better assurance that the message actually came from the claimed source but it is still not 100% guaranteed.

I will not go further into the cryptography explanation since there are SO many places that explain it better and much more thoroughly than I can. Use google or check out wikipedia for sources of encryption explanation.

Now down to the topic at hand… Encrypted email. Why hasn’t encrypted email really been used by the general public? There are numerous reasons that come to mind.

1) The general public my not be concerned with privacy issues beyond a certain point. The attitude, “well if you are not doing anything wrong in the first place” or “I would never send anything private over the internet anyway”, etc has gripped the general populace’s attitude for a very long time.

2) The complexity of encryption demands knowledge that is quite difficult to implement without a toolkit. Most email vendors have been busy with implantation of the used protocols to meet message transport standards, security vulnerabilities and general user features. Encryption has been low on the list of demands and that usually means that other requests are serviced first.

3) The lack of integration of encryption tools within email clients has left users not wanting to really spend the extra time and effort to exchange keys and encrypt/decrypt messages using an external application in conjunction with their e-mailers. This lack of integration and ease of use has put encryption out of grasp for most people.

4) Solutions such as PGP, require people to do key management (as simple as that may be) and that is somewhat undesirable to people. Other solutions such as S/MINE are equally as good except that the PKI infrastructure demands that a third party validate the integrity of the Certificate for the feeling of validity. This 3rd party has traditionally charged money for the Certificate or at the very least made it intrusive for people to obtain them. Can you imagine, they want MY NAME: FIRST AND LAST? Are you kidding me? One aspect of privacy is Anonymity… and they want my NAME??? That leaves only self signing Certificates or providers that don’t ask that information… which is none (not even CACert.org).

5) Expensive Encryption calculations make a heavy demand on a personal computers and email servers. Both are not very desirable.

6) When a user forgets their passphrase, all of his data stored on the server will become inaccessible forever to anyone.

What is changing that makes people wish to use encryption?

1) Ever since Identity Theft and Phishing attacks have left their mark very close to home, if not at home, for all of us. People are starting to be concerned that the government is beginning to use techniques that are too broad based and heavy handed in the name of protecting the public. The Government Dragnet may indeed snag, catch, entrap many innocent citizens or even worse that information can be used against citizens who challenge people in power. Also, people are have growing concerns about Heath Care/Insurance issues that certain personal information may preclude them from coverage.

2) Toolkits are now available to incorporate encryption engines into email clients and servers.

3) Integration of encryption tools within email is becoming more prevalent.

4) Some email providers such as CryptoMail, Hush Mail, and CryptoHeaven are offering Automatic storage of Keys for their members.

5) Advances in inexpensive processor technology and custom solutions such as SafeNet’s SafeXcel PCI cards are now available to make encryption a more obtainable reality.

6) By not using ONE encryption key to encrypt all your messages, you avoid this problem. A loss of one key only causes the partial loss of messages (those encrypted by the lost key).

With all these advancements, what’s still the hold up? Inertia. It takes some time for this technology to become understandable to the general public. Remember there was a time when only the techno savvy knew what gif, jpg, mp3, etc meant. Now people talk about codecs and the like as if it was second nature. With the injection of commodity hardware and appliances into the market place, people become more techno-savvy. As more of providers give easy to use encryption tools the more people will use them. Skype has proven this model and has taken the world by storm with an easy to use secure way of communication.

Now with ALL that said, there is STILL one major practical difficulty with the use of encrypted e-mail that prevents its acceptance universally. The fact that you can’t scan for viruses or spam until the email has been decrypted is a major deployment hurdle. To get though spam filters and virus checkers someone just needs to use your Public Key and send you a malicious package. This drawback puts the burden of checking for spam and for malicious payload completely on the email recipient, which is not a good thing.

Both of anti-spam and anti-virus scanning functions have qualities that scream for centralized management instead of the distributed individual workstation scanning approach. Most people don’t want to bother with, know about, or can afford all the tools needed for a safe network and computing environment. Anti-virus, Anti-Spam, Anti-spyware tools constantly need to be updated to be effective. There are free Virus Checkers such as AVG and free personal spam filters such as WndowWasher. But there is a deficiency of choices for Macintosh and Linux users. But again, the main point being is that end users need to install, maintain and learn how to use these tools for them to be effective. Part of the reason people are attracted to service providers such as AOL, EarthLink, etc. is that they give you some decent level of anti-spam, anti-virus, etc. facilities for free. If messages are encrypted that would decrease the chance of using those tools effectively or at all.

So how do you get around this difficult problem of not being able to scan encrypted payload? Well, scanning messages BEFORE they are encrypted and sent and then decrypted and scanned BEFORE they are delivered to the recipient is one solution. But that solution either requires tools installed on the emailing computers which need to be continuously upgraded and maintained OR the message encryption/decryption to be handled at the server. I am just going to discount the first solution since it is expensive and problematic for everyone concerned as mentioned above. The second proposition is interesting. If your email server keeps the keys for the Crypto and does all of the work for you, people will consider that not so secure. Your service provider could potentially snoop your email as well as anyone else that has access to the keys. This is where anonymity comes into play. If you can’t tie a “real name” to the email it does not really matter much. See “How do you make provider-based auto crypt and decrypt better?” for more ideas.

But the question is this… As a email user, do you care about the “privacy” of the majority of your messages more than the inconvenience of spam, viruses, and malware? Most messages are not really “worthy” of encryption and those that are, you should DEFINITELY use strong privately done encryption. BUT every message is worthy of obfuscation to deter the general hacker from snooping or seeing information if they break in to the email server (remember if you separate the keys from the messages it is MUCH harder to connect the two). This mentality is reminiscent of the driving force behind most security concepts… make it harder to get to you and the malicious people usually move on. Remember, when you and your buddy are attacked by a Bear… you don’t have to out run the bear, you just need to out run your buddy. Is this obfuscation technique worth the computational resources that it required to implement? Well, my personal feeling is that ANYTHING is better that unencrypted storage. The problem with EASE of use, is that people FORGET that this technique is not highly secure for highly sensitive content. Then when there is a compromise, the people are outraged- no surprise there.

Combine this technique with easy integrated encryption tools into the email tools and the email user has many options to draw on. Remember, the message content disclosure may only be of concern to the person on the “other end”. If Suzie and Jack are emailing each other, Suzie may not care if anyone at her ISP sees the messages, she just does not want her coworkers seeing it OR Jack may not care if anyone but his coworkers sees the mail. So Jack may just ask Suzie to (auto) encrypt messages to him so his circle of associates can’t see their correspondence. He doesn’t care if Heywood at Suzie’s ISP reads the message since it can never be connected to him BUT it can be connected to him if it is delivered to his job. How people feel about this truly just depends on the situation. All messages and traffic should be encrypted. It is more of a choice of what the content is and how much you don’t want anyone to see it.

All this talk about encryption and decryption problems with email payload validation and the related techniques… but I really think that the more focused solution that answers the question of sender validity is of greater importance. In otherwords, “Did the message REALLY come from the claimed source?” By focusing on Sender Validation techniques, other problems are reduced automatically. Sender Validation techniques such as Digital Signatures are REALLY important. The problems of phishing and spam are greatly reduced when you can trust that the people you know won’t intentionally send you spam (hmmmmm, well that’s another problem saved for later). Well at least you can be assured that the spoofers and the people you don’t know won’t be able to send you spam and harass you. This still does not address the virus problem created by “intelligent” email clients that blast messages away using the address book. Anti-virus tools and Web Client e-mailers take care of that issue. Message signing by Domain Holders (DomainKeys or Sender ID) and use of Sender Policy Framework (SPF) is a good start but that doesn’t stop people within a Domain from spamming but it does stop them from spoofing the message headers of people outside the spammer’s domain, which is VERY important. All Sender Validation techniques should be implemented so people have the best protection.

Another proposed solution to stop spam is White Listing. Unfortunately White Listing can be circumvented via spoofing. But coupling White Listing and Sender Validation together makes an almost UNBREAKABLE duo. Joining this duo with educating email recipients to NEVER give out their personal information is the real solution to spam and phishing problems. There is a problem with White Listing and that is the problem that people you know who are not on your White List have a difficult time contacting you in the first place. For “first contact” scenarios, some challenge/response techniques have been proposed such as Ham passwords. Unfortunately, only those who despise spam really ever implement techniques like this.

In summary, the difficulties with encrypted email are related to the inability to validate the potential malicious payload of messages. There are potential centralized solutions that depend on a person’s willingness to consider that their content is “protected well enough” for privacy concerns weighed against the concern of virus and spam threats. Through the use of Sender Validation techniques such as Domain Signing, Personal Digital Signatures and White Listing, reduction of the problems (spam, etc.) that face the majority of people is accomplished. For organizations with anti-malware tools installed on all systems, the malware check after the decryption phase, is an acceptable solution but for normal home users this approach is not viable. Until free tools are available on all platforms and integrated into all clients, the problem of after-the-fact malicious payload checking will plague the general populace.

As a side bar…

The problem with closed services such as CryptoMail, Hush Mail, CryptoHeaven may be a focus of another Blog entry soon. My biggest complaint is their inability of ensuring SOME level of encryption automatically even if one of the people sending OR receiving mail is NOT on the same encrypted mail network. It is true that Hushmail Express allows an Email Portal solution for people not in your email network… but it is far from optimal. Cryptomail has no solution to this problem- even if there are 2 unrelated Cryptomail networks, they don’t exchange keys with each other. I have to research CryptoHeaven further… there is little published about it on their website.

As a another side bar…

How do you make provider-based auto crypt and decrypt better?

Separate the Keys from the messages. Separate systems would require multiple system compromise. Separate the Keys from the Identity of the Key Holder and that increase the privacy of the recipient by creating anonymity. If the message IS compromised, the email recipient is better protected since the thief must have the Keys and even if they have those, they may not be able to associate the message to a specific person (that of course strongly depends on the message content.)

[Idea Fountain]

Devise a way to separate the storage of encrypted messages and the encryptions keys that are used to encrypt and decrypt them to prevent people who don't know your passphase to associate the two and thereby compromising the security of the messages and the anonymity of the recipient.

[Idea Fountain]

Devise a way to over come the White List “First Contact” Problem.

[Idea Fountain]

Devise a way to store the Public and Private Keys on a server so that they are available anywhere that connectivity is available and all the emailer needs to do is to remember their passphrase. CryptoMail and Hushmail have techniques using a java client as their emailer client.

More on this topic later…

posted by TheGuardian  # 11:17 PM