Ladar Levison is probably most well-known to Ars readers as the founder of the secure e-mail service Lavabit, which he shut down in mid-2013 in an effort to avoid being forced to comply with a US government demand to turn over users’ e-mails. But his latest project is a lot grander in scope than a single hosted e-mail service: Levison is attempting, with the aid of some fellow crypto-minded developers, to change e-mail at large and build encryption into its fundamental nature.

As one of the members of the Darkmail Technical Alliance, Levison—along with Jon Callas, Mike Janke, and PGP designer Phil Zimmermann—is working on a project collectively referred to as DIME, the Dark Internet Mail Environment. DIME will eventually take the form of a drop-in replacement for existing e-mail servers that will be able to use DMTP (the Dark Mail Transfer Protocol) and DMAP (Dark Mail Access Protocol) to encrypt e-mails by default.

Conceptually, DIME applies multiple layers of encryption to an e-mail to make sure that the actors at each stage of the e-mail’s journey from sender to receiver can only see the information about the e-mail that they need to see. The e-mail’s author and recipient both know who sent the message and where it was bound, but the author’s e-mail server doesn’t—it can only decrypt the part of the message containing the recipient’s e-mail server. The recipient e-mail server knows the destination server and the recipient, but it doesn’t know the sender. So if you arrange the four steps in a line from left to right—author, origin server, destination server, and recipient—each step in the line is only aware of the identity of the entity directly to its left or right.

Making this work means relying on a federated key management system to handle the layers of encryption, since every entity in the DIME chain has to have its own public and private keypair to encrypt and decrypt the portions of the e-mail that it needs to be able to encrypt or decrypt. Levison envisions this working in somewhat the same manner as DNS, with each organization that uses DIME being the authoritative source for encryption keys for its servers and e-mail addresses. Levison has settled on DNSSEC as being the preferred method for holding a domain’s e-mail trust anchor, but DNSSEC’s poor adoption means the protocol will also allow the use of a root Certificate Authority-signed TLS certificate to validate keys.

Levison is doing the initial implementation of DIME using a fork of Lavabit’s Magma e-mail server, but the plan is to eventually have support for DIME in Postfix and other common Mail Transfer Agents. In e-mail terms, the DIME Magma-based server functions sort of like Exchange, combining the roles of Mail Transfer Agent and Mail Delivery Agent into a monolithic server. If a user’s e-mail client (the MUA, or Mail User Agent) doesn’t support DIME, the spec allows the DIME server to transparently generate keys for the user and encrypt the user’s messages on their behalf.

"You update your MTA, you deploy this record into the DNS system, and at the very least all your users get end-to-end encryption where the endpoint is the server,” Levison explained during a phone interview with Ars. “And presumably more and more over time, more of them upgrade their desktop software and you push that encryption down to the desktop."

This optional mode wherein the e-mail servers transparently do the client’s encryption for them, is called “trustful mode” and can either be a bridge for users to until they have a client program that fully supports DIME, or a way for large organizations with legal discovery or regulatory requirements to use DIME but still have access to their users’ e-mails as needed. It also provides a way for e-mail hosting companies to potentially deploy DIME for hosted accounts without having to worry about what mail clients their customers are using.

From an encryption perspective, DIME will allow some flexibility, while at the same time attempting to ensure some minimal level of security as part of the spec. The DIME toolset will mandate a base set of ciphers, and administrators setting up DIME can specify additional ciphers to use on top of that. According to Levison, DIME will use for ciphers “a mandated baseline that I knew was secure, but make it easy to extend upon that." This will be done by encrypting the message components with whatever alternative encryption method the administrator prefers, and then wrapping each component in the mandatory encryption scheme on top of that.

Adoption of DIME by the IETF as a formal set of RFCs would go a long way toward the likelihood of DIME support appearing in other more common existing MTAs like Postfix, rather than requiring administrators to set up Magma in order to take advantage of DIME. To that end, Levison intends to begin circulating the project’s specifications document among members of the IETF at the group’s meeting this March as a preliminary step toward transforming DIME into a ratified set of standards.

For now, outside of the custom (and preproduction) fork of the Magma server used by Levison, DIME isn’t yet fully available or implementable. There is a GitHub repository containing what Levison describes as “pre-alpha” libraries for DIME, and the team has assembled a 109-page specifications document, but the technology isn’t yet in a state where it can be independently deployed and audited.