{"id":29293,"date":"2015-02-18T07:43:46","date_gmt":"2015-02-18T12:43:46","guid":{"rendered":"http:\/\/www.opensource.im\/uncategorized\/private-i-encrypting-email-with-public-keys.php"},"modified":"2015-02-18T07:43:46","modified_gmt":"2015-02-18T12:43:46","slug":"private-i-encrypting-email-with-public-keys","status":"publish","type":"post","link":"https:\/\/euvolution.com\/open-source-convergence\/cryptography\/private-i-encrypting-email-with-public-keys.php","title":{"rendered":"Private I: Encrypting email with public keys"},"content":{"rendered":"<p><p>    In recent weeks, Ive written    about protecting data stored locally on a hard drive, against    both people with physical access and potential remote attacks.    But your data is much more vulnerable in transit, as it passes    between end points or via servers.  <\/p>\n<p>    This problem is effectively    solved for instant messages with iMessage, which uses strong    end-to-end encryption designed in such a way thatApple    saysnot even they can decrypt your messages. This is    accomplished by creating local encryption keys through a    process that cant be reverse-engineered on their side. Even    though iMessages pass through intermediate points on the    Internet, theres no opportunity for others to grab the plain    text, images, and audio within. (The same is true with FaceTime    audio and video.)  <\/p>\n<p>    But its still a mess for    email, whether Mail in iOS or OS X, or third-party email    software. The problem arises from email protocols working    too well. Yes, I know how that sounds, as Apples Mail    app frustrates on both its platforms. But the diversity of what    you can choose among native and Web apps has to do with no    company or organization controlling how email works. iMessage    is entirely Apples ecosystem, which is the case for most    messaging systems, including Facebooks WhatsApp and the    messaging component of Microsofts Skype. In contrast, there    are thousands of native email programs across all platforms and    all time, and hundreds remain in wide use.  <\/p>\n<p>    The email protocols comprise    POP3 (ancient and still in use) and IMAP for email retrieval    and synchronization, while SMTP handles sending. Because they    emerged from the dawn of Internet, they have evolved in fits    and starts with weird vestigial pieces. Email continues to    function because of compromises and a tacit agreement that    nobody can break or refuse to support major componentspartly    because no one controls a big enough piece to force    change.  <\/p>\n<p>    One of the biggest problems    past and present in Apples Mail.app is, in fact, because    Google has an odd setup for its IMAP service, and Apple dances    around fully embracing it. Google cant break IMAP entirely,    because then millions of users who pull in Gmail messages    through Outlook or other software would be out in the cold, and    potentially switch away. (Android has three separate email    apps, in fact: two that work with Gmail in different ways, and    third for regular email accounts.) Likewise, Apple cant    invent a new, superior way to send email because every mail    server in the world would need to be updated to receive    it.  <\/p>\n<p>    In the last few years, enough    standardization and upgrading have taken place that one aspect    is well secured: the connection between an email client and an    email server. Email flows from a client to a server run by your    ISP or company or email host, and from there typically directly    to the recipients corresponding email server. By default,    Apples mail clients and those of other companies try to set up    a new account to use SSL\/TLS, the same session-based encryption    technology used for secure Web interactions.  <\/p>\n<p>    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 thats becoming more secure.    Most email serversall of those run by major companiesare 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.  <\/p>\n<p>    The weak points still remain    when email is decrypted, whether its 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 insecurelywhich is typicalwith another email    server. At those weak points, a criminal or government agent    could gain access.  <\/p>\n<p>    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 thats 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 Im a pretty optimistic fellow.  <\/p>\n<p>    Still, hope springs eternal,    and I think were 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, Ill    explain how to use it practicallyon a Mac at least.  <\/p>\n<p><!-- Auto Generated --><\/p>\n<p>See the original post:<br \/>\n<a target=\"_blank\" href=\"http:\/\/www.macworld.com\/article\/2885191\/private-i-encrypting-email-with-public-keys.html\/RK=0\/RS=oH6hJWYC09JdsmtYNg_mB5P9sMQ-\" title=\"Private I: Encrypting email with public keys\">Private I: Encrypting email with public keys<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p> In recent weeks, Ive written about protecting data stored locally on a hard drive, against both people with physical access and potential remote attacks. <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1600],"tags":[],"class_list":["post-29293","post","type-post","status-publish","format-standard","hentry","category-cryptography"],"_links":{"self":[{"href":"https:\/\/euvolution.com\/open-source-convergence\/wp-json\/wp\/v2\/posts\/29293"}],"collection":[{"href":"https:\/\/euvolution.com\/open-source-convergence\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/euvolution.com\/open-source-convergence\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/euvolution.com\/open-source-convergence\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/euvolution.com\/open-source-convergence\/wp-json\/wp\/v2\/comments?post=29293"}],"version-history":[{"count":0,"href":"https:\/\/euvolution.com\/open-source-convergence\/wp-json\/wp\/v2\/posts\/29293\/revisions"}],"wp:attachment":[{"href":"https:\/\/euvolution.com\/open-source-convergence\/wp-json\/wp\/v2\/media?parent=29293"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/euvolution.com\/open-source-convergence\/wp-json\/wp\/v2\/categories?post=29293"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/euvolution.com\/open-source-convergence\/wp-json\/wp\/v2\/tags?post=29293"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}