Re: [Endymail] Off we go...

[Adam Caudill <[e-mail]>]

On Aug 26, 2014, at 6:34 PM, Pete Resnick <[e-mail]> wrote:

> So off we go... What projects are folks working on, and what should the IETF be doing in this space?
> 
> Cheers,
> Pete & Stephen

I’ve been working on a project I call SMIMP[0], it’s a completely new design to meet the use cases of email using modern technologies. I gave a short talk[1] about it at the DEFCON CryptoVillage, slides & notes are online. It’s still a work in progress, there are a number of open issues[2] around items that I’m not entirely sure what the best way to handle is (mailing lists are a particularly complex issue).

In a nutshell, it’s an end to end encrypted messaging system, encrypted via curve25519 / XSalsa20, signing via Ed25519, transported over HTTPS using a REST-like API. At every step, the goal is to make it secure, and easy to implement, to minimize the risks of developer mistakes.

It’s broken up into two major parts, Identity Management, and Messaging (there are a few details left out for brevity; for all of the details see [0]):

Identity Management: To get the public key for a user, a sender calls an API that returns the full profile history for the user; when a user makes a change, it’s signed and includes the hash of the prior change, creating a chain from the time the account was created to the most recent. So if Alice wants to send a message to [e-mail], she would ask the server at example.com for Bob’s profile history, and validate that everything is signed, and that the chain is intact. Alice will save both the oldest and newest public keys for future checks (TOFU). In the future, Alice will ask the server for the most recent public key for Bob, and if it matches what she has, she will proceed to send the message, otherwise she will request the full history to see if it’s been updated with a new key, or if something malicious is going on (profile replaced / truncated).

Messaging: Alice will connect to the example.com server, and request an ephemeral public curve25519 key and validate that it was signed by Bob’s Ed25519 private key. Alice will then request parameters to perform a hashcash-like proof of work as an anti-spam measure; this includes a session specific nonce to prevent the POW from being calculated offline. Once the POW is calculated, Alice will encrypt the message using the ephemeral key, including the POW and other values, and send it to the example.com server. The server will perform validations to make sure that it’s signed correctly, the POW is correct, and the message is in the correct format. Once the message is accepted, the server will store the message for later access by Bob. The messaging API also includes basic mailbox management methods.

The system supports multiple message types that are handled a bit differently by the server, such as email, short text (MMS like), and application specific message types, so new messaging applications (think WhatsApp or SnapChat) could use this infrastructure, instead of using a custom system.

This is a very short overview of the system, I encourage you to look at the full specification if you are interested.

[0] https://github.com/smimp/smimp_spec/blob/master/smimp_specification.md
[1] https://adamcaudill.com/2014/08/16/smimp-at-the-defcon-cryptovillage/
[2] https://github.com/smimp/smimp_spec/issues

-- 
Adam Caudill
[e-mail]
http://adamcaudill.com/