How Secure Is Your Secure EmailIntroductionWhere Are We Today in Securing Our EmailsIssues to Consider in Securing Our EmailsSecure Email Product SurveyFeature ComparisonsClaims to ClarifyWhat’s the Matter with PGP?The Latest Efail Attacks on S/MIME and OpenPGPMitigation of Efail AttacksSecure Email Threat ModelModelingEffectiveness against ThreatsProtonMailDIME (Dark Internet Mail Environment) and Lavabit ServiceVirtru Secure EmailCriptext Ai-Fi SecureEmailSet It UpAi-Fi.net Design PrincipleAi-Fi Secure Email is Based on Conventional Email InfrastructureReferences
The primary goal of Ai-Fi.net is to protect your privacy based on a secure virtual space of your own, your private Ai-Fi Domain, constructed out of Ai-Fi.net's tool sets. The advanced and modern technology of Ai-Fi.net affords our users the maximum level of privacy and security achieved at the least amount of threat from any third parties. It mobilizes your personal resources, such as your PCs, mobile phones, and Internet services incorporated into your Ai-Fi Domain, to build your own defenses against unwanted tracking, censorship, and surveillance. To earn this independence without relying on any third parties of unknown motives, our users are asked to involve themselves more in applying the underlying technology (but not much more, as it nicely turns out). We'd consider this involvement as a rewarding tradeoff.
The root cause of not being able to secure our emails, or any of our online identities and assets, is because we rely too much on other parties for crucial resources and services. To secure our emails, as will be explained in details later, we need the key pairs for encryption, the key directory for finding our friends, the "prekey store" to negotiate session keys dynamically for "perfect secrecy", the storage to store our emails without other people peeping in, and the ability to read our emails from our many personal devices from anywhere in the world. Ai-Fi.net allows you to carve out a piece of the Internet real estate which you can call home, the private "Ai-Fi Domain" of yours, through which you conduct your business in a self-reliant manner. Without this private home base of yours, it's difficult to establish a stable foothold in this age of surveillance capitalism. You need the protection of your own castle. You need to forearm yourself with the castle defense built into our Ai-Fi Domains.
Among all our solutions, the Ai-Fi SecureEmail is designed and released as a demonstration of the power of Ai-Fi.net in delivering secure/private/anonymous emails for our users. The below diagram is a snapshot of some other notable applications supported by Ai-Fi.net castle infrastructure. Ai-Fi SecureEmail is just one of the Ai-Fi features that is immediately useful for many of us. You may be interested in learning more about us from our web site at https://ai-fi.net for other privacy-preserving applications based on the same foundation of your "Ai-Fi Domain".
In this blog, we will examine various secure email products, analyze many issues those products have been struggling with, and conclude it with the introduction of our Ai-Fi SecureEmail that answers many difficult security and privacy issues based on the underlying support of Ai-Fi.net.
Our aim is to create happy users of Ai-Fi SecureEmail and move them on to other advanced privacy and security focused Ai-Fi products: Ai-Fi Private Social Networking, Ai-Fi Cloudless Private Dropbox, Ai-Fi IoT Security Perimeter, and many more coming down the pipe.
Security and privacy are relative concepts. Absolute security or absolute privacy doesn't exist. Usability is another relative concept. Worse yet, usability is highly subjective in addition. All three concepts, the security, privacy, and usability, must be examined in their targeted applications under specific context based on comparative measurements in relative terms.
In this report, the application context is "secure email". This is not intended as an exhaustive survey covering all vendors on the market. Rather, it reviews a few noteworthy vendors representative of their respective technologies in order to compare features and to learn the lay of the land. We offer an introduction of our Ai-Fi SecureEmail in the second half. In the end we hope you will be convinced that a fully private and secure email service is achievable only through the strength of a healthy and comprehensive foundation.
Emails have been around for a long time since the beginning of the Internet era. It is a convenient way of contacting your friends, family, colleagues, and business associates. It is informal, universal, reliable without guaranteeing delivery (quasi-deniability), and asynchronous without requiring the recipients to be online.
In this context of secure email, we will base our comparison on the following feature considerations:
Needless to say the content of a secure email must be kept confidential, which is usually effected by a digital lock that may only be opened by the intended recipient. Immediate follow-on questions are:
The lock/key pair protects a single round of correspondence. However, even without the capability of peeping into your messages, knowing your circle of email friends collected over a prolonged timeline tells a lot about you. This piece of information is part of the meta-data, which records all your social footprint and associations through emails. Obviously you don't want any "third party" to learn your writing to a psychiatric clinics, visiting women's shelters, booking a hotel room next to a Las Vega casino, or contacting your counterpart of the other company in a merger negotiation. If Edward Snowden were among your correspondents, you would be on NSA's radar instantly. You want all your meta-data protected in addition to the sensitive contents of your emails. You want your provider shields you from leaking any meta-data to protect your innocence.
Adversary Identification and Defense:
Your emails hop around from one MTA (Message Transfer Agent, operated by Google, Hotmail, Yahoo, etc.) to the other MTA through some dynamic and widespread delivery paths before reaching the destination mailbox. Each of those MTAs may belong to some different email service providers. This flexible delivery routing scheme is what affords emails the "federation" architecture and their universal addressability (more later). Unfortunately it also exposes them to any prying eyes present along the way. They are vulnerable to attackers of the following types:
Carefully and defensively implemented email encryption is usually sufficient to ward off the first two threats above. Organizational attackers are more formidable, with the full institutional resources behind them, including the serving of search warrants. In the case where search warrants are served and complied with, the email service providers effectively become part of the attacks[Going Dark].
With the issues we care about our emails more clearly defined, next we consider the myriad of features offered by various service providers and check if they've accomplished what they set out to do. The below diagram is borrowed from the spec "DIME Architecture & Specification 2018"[DIME], which summarizes the traditional email architecture quite nicely with popular acronyms explained. Note that MUA is a fancy way of naming the email client, which is the software that the email Author and Recipient run on. Emails are passed around based on the SMTP protocol, which may involve any number of MTAs along the way. The email author relies on the MSA, the service provider the author signed up to originally, to initiate the transport of their emails. The recipient typically uses IMAP protocol to retrieve their emails from the MS (Message Store) of their own MDA (Message Delivery Agent) at the last MTA stop. Note that all the MTAs involved in delivering the emails may be run by different self-governing email service providers like Gmail, Yahoo mail, Outlook.com, AOL Mail, etc.. Jointly they form a "federation" in order to enable senders from one domain to send emails to any recipient of another domain.
There are many so-called "Secure Email" services around, which make various function claims. For you as an informed consumer evaluating secure emails, we would recommend working from the following checklist of features:
Federation: Is the secure email service capable of participating in the global email federation? Does your secure email service still conform to the existing email standards? Among all the important functions of traditional email architecture, federation is the most powerful one, which allows someone to send from, e.g. firstname.lastname@example.org, to, e.g. email@example.com. Unlike other messaging services in social networks or instant messengers that tend to favor a limited number of behemoth service providers like Facebook, WeChat, and WhatsApp, email federation offers a level playing field so that all email services, large and small, may coexist harmoniously through the federation infrastructure. We must make sure that the secure email service we adopt is compatible with existing email community so that we continue to benefit from this well-accepted federation ecosystem, without which you will not be able to reach all the friends in your email circle. Strictly speaking an email service that does not support federation is non-email[Secure Email Review].
End-to-end Encryption: Is the encryption end-to-end? While your email is encrypted, it is also critical to know if it's encrypted by parties along the SMTP trips from MTA to MTA, which could be just an encrypted relay path, or if they are indeed end to end, which allows only the Author and Recipient to decrypt it and no one else. For instance, if your MSA is Gmail, only the first hop of submitting your email is encrypted and not qualified as end-to-end. We obviously prefer the encryption to be end-to-end and not indirectly mediated by the service providers or any third parties.
PFS: Is PFS (Perfect Forward Secrecy) offered? Usually the encryption is based on Public Key Cryptography and typically the recipient is not present to negotiate with the author of the email in real time for a dynamic session key, without which your encryption stops protecting you once your key pair is compromised, including all your past and future emails. In other words, the protection does not move forward indefinitely (hence the lack of PFS). End-to-end encryption does not automatically offer PFS.
Key Store: Is the CA (Certificate Authority) required or offered? Almost no email client relies on publicly issued CA certificate for authentication due to its expenses, hassle in maintenance, and the tricky issue of certificate revocation. OpenPGP or similar self-signed certificates are instead adopted for consumer-grade secure email authentication. Many secure email services store the private keys at their servers, which are retrieved through entering a password. The popularity of “Trust On First Use” (TOFU) authentication in secure email, borrowed from SSH with self-signed certificates, demonstrates significant demand for host authentication that is low-cost and simple to deploy without struggling with the "strength" of a password. While TOFU-based applications are a clear improvement over completely insecure authentication protocols, they do leave users vulnerable to even simple key directory attacks, especially in relation to the trust bestowed upon the service providers. Allowing the email owners to safekeep their own private key is highly desirable, albeit demanding additional technical sophistication in detecting possible compromises on their public keys.
Private MS: Where in the world is your MS (Message Store)? Traditionally when we analyze cryptographic algorithms we concern ourselves with the expected inputs and outputs of the system. But real systems leak all kinds of extra information, namely the meta-data, critical to your privacy. Furthermore, there are many so-called ‘side channels’ — which include operation time, resource consumption, cache timing, and RF emissions — which can often be used to extract secret key material if your MS is out of sight somewhere else. The longer your emails are out of your direct reach and under the "care" of someone else such as those cloud providers, the more attackable they become[NSA Breaking SSL].
SP Meta-data Protection: This is often the outcome of lacking Private MS explained above. To send secure emails based on proprietary email routing, those emails are often required to be aggregated at the storage facility of the service provider prior to delivery. This aggregation of all emails sent from a specific "From" address leaks the private meta-information about the "To" recipients in the author's social circle. Even the Tor network will not be able to help shielding your privacy, since this aggregation forces all your emails to go through a MITM (Man In the Middle). This leaked meta-data. Similarly, if you are required to own a user account from a specific secure email service provider (e.g. Tutanota, Mailfence, Protonmail, or Hushmail) before sending secure email, the meta-information about your circle of email friends is also exposed to the service provider and vulnerable to search warrants. Security and privacy are all about "attack surface". This aggregation enlarges it.
There are an increasing number of projects working on next generation secure email or email-like communication. In the table below we examine a few popular and representative products for comparison purposes with the Ai-Fi SecureEmail offering, which we believe is demonstrably superior. For a more extensive survey of those secure email services, you may be interested in visiting the survey paper here.
|ProtonMail||PGP Based (CounterMail, Hushmail, Mailfence, Tutanota, etc.)||LavaBit/DIME||Virtru||Ai-Fi|
|Email Federation||No (requiring bridging)||Yes||No||Yes||Yes|
|End to End Encryption**||Yes||Yes||Yes||Yes~~||Yes|
|Key Store||At provider's||At provider's||Residing with Clients Privately||At Server||Residing only with Clients Privately|
|Private Mail Store||No||No||No||No||Yes|
|SP Meta-data Protection||No||No||No||No||Yes|
**Without exceptions, all secure email providers claim "end-to-end encryption". However, the follow-up question ought to be whether it is mediated by the email providers or any other third parties, which are technically a MITM (Man In the Middle) with all its risk implications, including the fact that this end-to-end encryption is no longer "warrant-proof". For instance, Mailfence keeps the private keys of its users, which is as MITM as you can get. All other email providers provide email storage and key management, which could also be turned into MITM contraptions.
~~ Not all end-to-end encryptions and PFS properties are created equal. More on Virtru later[Virtru Review].
This blog intends to ask questions regarding the claims made by those popular secure email services, to explain why most of them are outdated with known vulnerabilities, to compare features in more precise terms beyond confusing semantics, and to highlight those distinct features in the Ai-Fi SecureEmail offerings made possible only through the latest technologies.
The secure email functions offered in Ai-Fi.net are only part of an integrated whole that delivers a consistent set of privacy and security infrastructure. The PFS and Private Message Store in the above table are natural extensions of the core functions of Ai-Fi.net, which are managed through the crypto wallet associated with the protected email address. Without the backing of a sound privacy/security architecture, many of the critical secure email functions are difficult to achieve. This Ai-Fi SecureEmail may be viewed as a demonstration of the power underlying the Ai-Fi.net architecture.
The first half of this blog is rather lengthy in explaining why PGP and S/MIME, the more popular technology, are outdated and broken, and the services like Virtru are not really suited for personal protection. If you are of the same opinion or only curious about Ai-Fi SecureEmail, then jump directly to the second half[Ai-Fi].
There are many so-called secure email services on the market (like those identified in the above table), including both paid and free ones. They make a variety of security claims that may be summarized as follows:
At least for now, the focus has been on confidentiality through encryption. Most encryption schemes offer no Perfect Forward Secrecy. Potential attacks on email meta-data and public key directories are largely ignored, mostly due to limitation on various adopted technologies.
Most so-called secure email services offer Public Key Encryption with or without CA (Certificate Authority) and their encryption keys are statically generated without the ability of carrying out the dynamic key negotiation for a session key with the recipient. Among its many deficiencies, one glaring defect of PGP-based schemes is this lack of "Perfect Forward Secrecy", a highly desirable property that the compromise of any long-lived cryptographic keys such as the private/public key pair does not put any previous correspondence in jeopardy. This deficiency is due to the fact that often OpenPGP messages are sent and read from different machines, at different times, and in different order, the typical traits of email delivery. This asynchronous nature of sending and receiving precludes the creation of ephemeral keys that require both parties to be online, much like what is carried out by TLS, one of the strongest, tried and true security standards.
The legend has it that the CIA, NSA, and many other three-letter agencies are a patient bunch. They may have all your correspondence in a stash waiting for the keys to be deciphered, perhaps through quantum computing one of those days. The lack of Perfect Forward Secrecy can be a real bummer for any of us 10 years down the road when quantum physicists have enough reliable qubits. Quoting the same expert cryptographer: "If the NSA is your adversary just forget about PGP".
In addition to their lack of Perfect Forward Secrecy, both S/MIME and OpenPGP are ancient standards and very slow-moving in addressing their security defects and ever increasing challenges. It is also highly "balkanized" in the sense that the OpenPGP ecosystem is made up of so many different parts that are only loosely coordinated, which begets complexity and retards coordinated effort in resolving any vulnerabilities[ Efail Postmortem]. For instance, recent reported "Efail" attacks are quite horrendous, affecting 65% of popular email clients. It is so serious that a web site has been set up to track the progress of the repair works required to ameliorate the defects[Email Attack1].
Under Efail attack, the encrypted email text may be surreptitiously altered without detection or consequences, and the altered text would subsequently trigger the sending of your decrypted content to bad places. The following offers more technical details:
One may notice that the MIC (Massage Integrity Check) is expected as a matter of course in popular SSL or TLS transport protocols. Unfortunately, those transports are not applicable here due to the inherent limitation of email services where the sender is unable to demand that the recipient is online to receive the message synchronously. This technical difficulty, plus other flaws caused by the complexity of the S/MIME format, introduces those unfortunate attacks.
If you need to know the latest on how security communities view the OpenPGP, read the following observation:
This is just a round-about way of stating that PGP is outdated, which stands little chance of winning the arms race between hackers and the defenders of our security/privacy.
The Efail attacks on S/MIME and OpenPGP-based "secure" emails have exposed major defects in these two email standards. The published analysis shows that Efail plaintext exfiltration channels exist for 25 of the 35 tested S/MIME email clients and 10 of the 28 tested OpenPGP email clients. While it is necessary to change the PGP and S/MIME standards to reliably fix these vulnerabilities, Apple Mail, iOS Mail and Mozilla Thunderbird had even more severe implementation flaws allowing direct exfiltration of the plaintext that is technically very easy to exploit.
ProtonMail and the inventor of Pretty Good Privacy (PGP) Phil Zimmerman have released a strong statement dispelling recent reports that the encryption program should be disabled because of alleged vulnerabilities[Email Attack3], claiming "the Efail vulnerabilities are not flaws with the OpenPGP protocol, but are actually errors created during implementation of the program". Actually, almost all vulnerabilities in history are "implementation" related; the malleability of plaintexts in CFB and CBC encryption is at the root of the problems, which require fundamental fixes. Zimmerman and his cohorts went on to say "Both our recommendations and EFF's require user action on the part of the sender and recipient of messages". Well, it is interesting to find out how many of those users are so well informed and technically adept that the recommended "user action" can be carried out, which is summarized as follows: "Ensure that everyone you communicate with is also using unaffected implementations or has updated their PGP software. Be sure to get a verified confirmation from your contacts before sending sensitive information to them"[Email Attack4]. Despite all of these "actions" to be taken, they insist that "PGP" is not broken.
To fix the defects requires the revision of RFC 2045, 2440, 4880, 5652, and 5751. Almost all email clients such as Outlook, Google Mail, Apple Mail, Thunderbird, Foxmail, et cetera, must be modified to the new specifications if they ever come out at all. We can be certain that it will take a long time for those standards committees to agree on any resolution.
For the short term those academics who successfully launched and publicized Efail attacks recommend the following mitigationshttps://github.com/noiseprotocol/noiseprotocol.github.io/blob/master/noise.pdf:
Clearly restricting secure emails to only plain text or proprietary Microsoft RTF format or decrypting them outside of the email clients is not going to be acceptable to email users. We need to go back to the drawing board.
For security and privacy protection, we need a threat model to guide our implementation focus. Based on our observation and reported incidents in the recent past, it is probably not too far off in assuming "Bad guys own any server infrastructure". The implication of this model is that we should rely primarily on the clients for protection, over which we have immediate and direct control, and demand all third-party providers for auditable services at least on the level of PCS (Post Compromise Security).
Specifically for email service, the threat model in terms of the malicious goals of the attackers is defined as follows:
In this day and age, the line between friend and foe is often blurred. The case history of secure email vendor Lavabit involving Edward Snowden's emails stored on its servers can attest the fact that email service providers may be turned into an adversary overnight per government or political pressure. This is where the secure email technology adopted by various vendors becomes crucial. Cleverly designed secure email service may render those threats nonoperational. You may be interested in learning one of those cases where the superiority of technology trumps grand jury subpoena.
To evaluate various secure email offerings, we will apply the threat model described above. Obviously the offered feature set is also an important evaluation criteria in addition to the defense against threats. The smaller the feature set includes, the less the built-in protection covers.
ProtonMail is one of the most popular secure email providers with open-sourced email clients decrypting emails end-to-end based on OpenPGP. It requires both the sender and recipients adopting email accounts with ProtonMail in order to realize the full function sets (This turns it into a "non-email", working only among ProtonMail subscribers).
We have voiced our opinion about its questionable claims on the advantage of being "Based in Switzerland" and will not repeat it here. We will only pay attention to technical aspects of the ProtonMail's offerings. The ideal technical solution to secure emails should not rely on the notoriously fickle government policies (unless "warrant-proof" is not legally allowed).
We'd like to dive into exactly how the so-called end-to-end PGP based encryption is implemented. Since the OpenPGP's stand regarding the public key directory (e.g. "web of trust") is not universally accepted, it has become the issue central to the schemes provide by various secure email providers with a host of approaches. We'll give a full description of ProtonMail's approach as a representative of this class of products.
Ignoring the issue of PFS (Perfect Forward Secrecy), the above diagram is fine and dandy except the thorny issue of how the public key is published to all interested parties. Base on the open source of ProtonMail client, its encryption scheme and key distribution are outlined as follows:
Like the majority of the secure email products, there is no Perfect Forward Secrecy.
As indicated in Step 2 and 3, the private key is stored at ProtonMail's server, which creates the weakest link. Even though it is encrypted with the SRP password that ProtonMail has no knowledge of, the strength of the whole protection scheme is greatly reduced to that of the SRP password. In other words, ProtonMail is perfectly capable of decrypting your emails in most cases. Given the fact ProtonMail is not able to provide forward secrecy and having all your emails in its server storage, all your email contents can be handed over to any parties by ProtonMail in a pinch. I just tried to check the strength of my password using the popular password cracker zxcvbn, it took less than a second to crack mine by a ordinary PC of certain number of cores. ProtonMail has all the facilities to make the less demanding "offline guessing" on your password. Worse yet, once your password is compromised, your SRP protection is out of the window as well.
In summary, ProtonMail is not able to withstand any of those threats in our threat model defined previously. (After finishing writing this section, we found an academic paper based on a much more rigorous analysis that agrees with out conclusion.)
Lavabit is an open-source encrypted webmail service, founded in 2004. The service suspended its operations on August 8, 2013 after the U.S. Federal Government ordered it to turn over its Secure Sockets Layer (SSL) private keys in order to spy on Edward Snowden's emails. It started operating again with the newly proposed and not yet complete DIME architecture in 2017. Lavabit is certainly the longest running secure email service. Here we are only going to discuss the newly proposed DIME architecture, since its previous so-called secure email left a lot to be desired.
Lavabit and its push for DIME standards are a heroic effort in getting to what they consider "the next generation email" in a specification of 181 pages. However, it is not compatible with any of the traditional email service providers. Given the fact that their emails are encrypted, in direct conflict with the business model of those service providers, none of the email providers is likely to support the new DIME standard. The so-called "DIME emails" are hardly qualified to be emails under this standard and Lavabit is left to shoulder the cost of the complete "email" infrastructure. If it is not email anymore and forgoes all the federation possibilities offered by conventional email services, there are plenty of competing secure messaging transports out there that offer pretty much the same, including the crucial feature of not requiring the recipients to be online which is considered the most critical email feature. The well implemented secure IM of signal.org with private file transfers works reasonably well without losing much of what is currently being delivered by Lavabit. (Actually Signal guarantees both Perfect Forward Secrecy and Future Secrecy.) However, we would not call Signal's IM "Secure Email" since there are no matching agents corresponding to those MSA/MTA/MDA in conventional email.
DIME is brand new, with a very low level of deployment and experience. For reasons argued above this situation is unlikely to change. In contrast, considering the wide acceptance of traditional email services and the huge experience gained along the way, it is difficult to see how defects on DIME can be discovered and repaired in time to stay competitive.
Among all the secure email services, Virtru makes the most confusing claims. They declare similar functions as other providers, using the same terminology such as end-to-end encryption, privacy, and forward secrecy, but deliver some other things altogether different:
In other words, not all secure email providers are created equal and not all catchphrases mean the same.
Virtru also claims that its products are based on "open standards". Since they are not based on PGP and S/MIME, the best we can gather about the "open standards" is the TDF (Trusted Data Format), an open-source security wrapper created by Virtru co-founder Will Ackerly. It's used by the intelligence community to secure sensitive data, we're told. It is useful only in an intra-community setting, e.g. in the IC (Intelligence Community). However, in our opinion, TDF contradicts the very concept of privacy for individuals. The so-called TDF wrapper is exactly the set of meta-data which would aid one's adversaries in deciphering it.
Quoting an article in Forbes, Virtru's future goals "revolve around securing different types of files in different types of formats across different types of technology platforms – so that any type of data you want to protect can be protected, without risk of hack, theft, or misuse". To us as practitioners of security and cryptography, these are unnecessary and dangerous goals. Like TDF, they are unnecessary, since the encryption ought to be the outmost wrapper around the confidential data, after the delivery of which the recipients would better know well enough how to decrypt it, most likely based on the "types of files". These goals are also dangerous, since complexity inflates the attack surfaces and breeds vulnerabilities. Technically, these future goals of Virtru's and its adoption of TDF appear to be errors in software and service layering, which could be harmful for private inter-personal communications.
Quoting another article from The Register, "The ongoing revelations of PRISM and other US-led internet dragnets, fueled by leaks from whistleblower Edward Snowden, may render the premise of upstart Virtru laughable." Among those laughable premises is the claim of email DRM (Digital Rights Management) protection. Virtru declares the DRM as part of its capability: "To share information safely, you need to be able to control how it is used even after you send it." This desire for DRM control after the message is sent has been proven little more than a wishful thinking[DRM], unless one introduces some third-parties who "must be able to supervise users and data, enforce DRM protection rules, and maintain control of data, even after it’s left the organization." This futile attempt to achieve DRM reflects Virtru's strong slant for enterprise control and the general lack of concern or understanding for personal privacy in its service offering.
Virtru's various products do indeed offer supreme usability. This partially explains why it is popular in public sectors, which are mandated by federal law to comply with the federal Standards for Privacy and Security under HIPAA, CJIS (Criminal Justice Information Systems), or ITAR (International Traffic in Arms Regulations) requirements that restrict third party access to sensitive data. Obviously Virtru doesn't consider itself as "third party". We don't want to speculate unjustifiably on the fact that Ackerly served for eight years at the NSA as a cloud security architect prior to founding Virtru in 2012. It does make one wonder how loosely the governmental requirements could be interpreted and the potential for many back doors, intended or unintended, in this brand of secure email.
For email consumers searching for personal security and privacy solutions, without the burden of HIPAA/CJIS/ITAR, Virtru and its likes may not meet their requirements and, more importantly, their privacy concerns.
The Criptext email service utilizes the same open source Signal Protocol as Ai-Fi.net. Both services offer the same nice properties of end-to-end encryption with PFS. However, for full protections Criptext requires both the sender and recipients to be users of Criptext with proprietary Criptext email addresses. For sending emails to non-Criptext email addresses, the protection downgrades to a passphrase and loses the PFS. Furthermore, to not lose incoming emails, the user must stay online and logged into at least one of the "Criptext devices" installed with Criptext software. This online requirement is a severe enough defect to place this secure email product into the "non-email" category.
Does Criptext store your emails in its servers? Well, Criptext claims that it never stores them in its servers. Rather, emails just "pass through" its servers momentarily until they get delivered to the users' devices. This implies three things:
All in all, Criptext achieves high degree of email confidentiality through Signal protocol but loses compatibility with the traditional emails. Furthermore, there is very little consideration invested in protecting your meta-data. It is a commendable effort in the "non-email" category striving for PFS, but leaves a lot to be desired on the privacy protection front.
TDB: why Johnny can't encrypt
The breakthrough Technology of Ai-Fi SecureEmail is chiefly attributable to the foundational support by the Ai-Fi.net infrastructure. To configure and to send/receive secure emails are quite straightforward:
Download the Ai-Fi Central app, bind your app to an email address, and define/configure your Ai-Fi Domain as follows:
Bind/Configure/register you email accounts from any email service providers to Ai-Fi.net as follows:
Send/Receive your Ai-Fi SecureEmail securely and anonymously to any other Ai-Fi email accounts
These user visible functions are explained by examples in the following sections.
Under the cover, the actual key pairs for your configured email and cover accounts are created automatically and transparently through the Ai-Fi Crypto Wallet created for your Ai-Fi Central app, which has its own key pairs for managing its Ai-Fi Domain. The encryption with both the Forward and Future Secrecy is performed in the lower routing/delivery layers without involving the users. Internally all emails managed through Ai-Fi infrastructure are protected as Ai-Fi digital assets, the key pairs associated which are recorded in an Ai-Fi Blockchain to effect the pseudonymity by segregating all PII (Personally Identifiable Information) from the Ai-Fi Domain management. In other words, given an email address, there is no way for Ai-Fi.net to tell which Ai-Fi Domain the email owner controls or where the MS (Message Store) physically resides amongst all the nameless Ai-Fi domains. Only the public key of the owner is publicly recorded.
If you are interested in the innards of the Ai-Fi SecureEmail architecture and other design details, finish reading the following two sections and then look into our specification on Ai-Fi.net Service Architecture.
As a first step, in order to take advantage of Ai-Fi SecureEmail, an installation of the Ai-Fi Central app is required with an associated Ai-Fi crypto wallet automatically created. This wallet is not tied to any of your real world accounts (your "Real Names"; or PII, your "Personally Identifiable Information", in the jargon of security practitioners, such as your email addresses, phone#, bank accounts, credit card numbers, social security numbers, etc.). The key pairs in your Ai-Fi account are the real actors pulling the strings behind all the Ai-Fi functions, including your secure emails. You don't need an Ai-Fi account to take advantage of the various Ai-Fi services, only the Ai-Fi Crypto Wallet stored on your mobile phones, which currently are among the most secure consumer-grade devices with hardware-protected key rings.
Ai-Fi.net open-sources all the client logic, including that used by the Ai-Fi Central app in order to attest the exclusive nature of the private keys and their handling, the only copies of which are kept in the secure store on the owner's personal phone.
For Ai-Fi SecureEmail, the owner of the email addresses to be protected must additionally set up the following:
Note that there are potentially two "From" addresses involved. The outer "From", if opted for, is in clear text in the email header in order to conform to the email standards. The real "From" is revealed only after the decryption. The Cover Address is the "From" on the outer layer. This mechanism protects the meta-data very effectively. The Tor Network is automatically adopted when the Cover Email Address is opted. The "To" addresses may be utilized to anonymize the recipients as well.
So, right off the bat, you need an Ai-Fi Crypto Wallet and provide up to two email addresses to Ai-Fi.net. The possibility of Ai-F.net becoming a bad actor or forced to comply with search warrants is addressed as follows:
There you have it. To adopt Ai-Fi.net secure email, you create a set of friendly accounts and collect their Safety Fingerprints. From then on you are in charge of your security and privacy destiny, with built-in precautionary mechanisms to eliminate even the risk of the service provider itself, namely Ai-Fi.net, still very much a third party. The encryption and email routing are fully automated and largely transparent to you.
To get more tangible feel for Ai-Fi Secure Email, let's look into an actual Ai-Fi Secure Email configuration. It adopts conventional email infrastructure with additional facilities:
Both sender and recipient own their private Ai-Fi Crypto Wallets and bind to their respective email addresses. The sending and receiving of Ai-Fi Secure Email are conducted in the Ai-Fi client software natively.
To encrypt Ai-Fi Secure Email end-to-end with forward and future secrecy, the sender retrieves the recipient's email public key from the Ai-Fi Email Key Store, which is equivalent to a self-signed certificate. As a recipient, in order to enter credential data such as the key pair into the Key Store, the Ai-Fi Crypto Wallet must first prove that she or he has an access right to the specified email account. This is the only guarantee offered and enforced by Ai-Fi. However, a compromised email account or even the email service provider may circumvent this check and enter the bad keys into the key store. To mitigate this potential risk, Ai-Fi provides various verification assistances to make sure a compromised email account can be discovered. Ai-Fi Secure Email adopts the mechanism of Safety Fingerprint, which is the easy-to-read hash of the recipient's public key, and warns the sender about its change and modification history whenever such compromise might have taken place.
Since the Ai-Fi SecureEmail observes the public email standards, most meta-data carried in conventional email transports having the same exposure in Ai-Fi Secure Email except the body of the email, which is encrypted end-to-end. However, the sender's and recipient's email addresses are not required to be the same as their real identities, which may be indicated and protected only in the body of the secure email. This offers the opportunity for obscuring the meta-data:
Note that in order to compromise the Ai-Fi Secure Email system, the attacker must have illegal access to both the real email address and its "cover address". The availability of the "cover address" lessens the risks of your email service provider being utilized or ordered (by warrant) to alter your prekeys. This is especially effective if the intended email address and its cover address belong to two different email services.
Once the email is securely delivered and decrypted, the recipient has the option to either leave it at MDA (Mail Delivery Agent, the last hop of the email transport) or delete it from the MDA and stash it away privately. Obviously leaving it at the MDA is always a concern without the physical possession of it even if the Perfect Forward Secrecy is maintained. The next best thing is to keep it on a "Homeserver", e.g. in the context of NextCloud, maintained and managed privately in the cloud but without the REAL physical possession. In the Ai-Fi framework, the "Homeserver" is hosted in your designated server, PC, or mobile phone, owned by you and completely in your possession. Your open-sourced personal Ai-Fi Secure Email client decrypts the email with previous dynamically-negotiated end-to-end session keys, stores it away at its designated private host and is forever yours. It may be placed in a distributed fashion and remotely accessible. Once stashed away through the Ai-Fi framework with your Ai-Fi Crypto Wallet, the pseudonymity of the Ai-Fi public keys guarantees its privacy and secrecy. There is no traceability to its whereabouts once deleted from the MDA.
^[Email Spoofing] [8/2013 Forward Secrecy for Asynchronous Messages ](https://www.infosecurity-magazine.com/news/mailsploit-allows-spoofed-mails/）