Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Private I: Encrypting email with public keys

Glenn Fleishman | Feb. 23, 2015
In part 1 of a series on PGP, Glenn Fleishman explains the problem with email and why end-to-end encryption is within your reach.

But SSL/TLS protects just the link between an email client and an email server. The data is encrypted in transit for that session, and then decrypted at the server, before being packaged and sent on to the next server. Now, in practice, even that's becoming more secure. Most email servers--all of those run by major companies--are in data centers. And after the Edward Snowden disclosure, Google and other companies have stepped up the security of links among their own data centers.

The weak points still remain when email is decrypted, whether it's for microseconds on a server before being wrapped up to send to another server over an encrypted link, or for much longer, when a server communicates insecurely--which is typical--with another email server. At those weak points, a criminal or government agent could gain access.

The key to security is...keys

iMessage suffers from none of these weaknesses because of its strong end-to-end encryption. So how can we achieve the same in email? Through the use of public-key (PK) cryptography, something that's been available for encrypting documents and email messages since 1991 in one form or another. A decade ago, I reviewed an updated and well-designed commercial version of PGP (originally standing for Pretty Good Privacy) in Macworld, and hoped it would usher in a new age of encrypted email. I guess I'm a pretty optimistic fellow.

Still, hope springs eternal, and I think we're ripe for another pass at PK becoming something that could be used readily and safely, rather than by those with command-line facility. Let me first explain public-key cryptography briefly. In the next column, I'll explain how to use it practically--on a Mac at least.

Public-key cryptography relies on an algorithm that can create a set of numbers used to derive two complementary keys: one public, one private. The public key may be freely distributed, and, in fact, should be widely sent about and associated with one's identity. (More on that in Part 2, as well.) The private key must be kept utterly secure, because its possession allows the party to "prove" that they are you! There's no known or practical way to derive the private key if you have the public one at present, nor likely in the foreseeable future.

With someone else's public key, you can encrypt a message that only he or she can decrypt with the corresponding private key. You can also take a message and "sign" it, producing a cryptographic summary that allows anyone with your public key to confirm that the message wasn't tampered with and that only you could have signed it.

PK isn't practical to encrypt long messages, and the genius of PGP's inventor, Phil Zimmermann, was using the public-key portion only to encrypt a strong symmetrical session key--an encryption key unique to the document that both encrypts and decrypts the data--and that could only be extracted with the right private key. (When a message is sent to several people, the session key is encrypted with each party's public key separately.)

 

Previous Page  1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.