Subject: Re: [Endymail] Off we go...

From: Werner Koch <[email-masked]>
Date: Mon, 01 Sep 2014 12:11:15 +0200

On Thu, 28 Aug 2014 23:44, [email-masked] said:

> * Easy way to migrate encryption keys into new devices.
>
> * Key recovery mechanisms so people don't loose their mail by accident.

These are closely related.  It is commonly known as backup/restore.
Fortunately we only need to care about the secret key which means we
need to backup 32 bytes plus an identification of 20 or 32 bytes for the
public key.  This can easily be achieved using a QR code.  Print it out
and for restore take a photo of it.  Right, this opens new paths for
local attacks on the secret key but if an attacker already has control
over the local device, we are anyway in game over state.  And it would
be a good start to make that easier.

The current protocols do not allow for an abbreviated backup scheme of
the secret key but it won't not be too complicated to do that.  As long
as we can assume that the public key is really public.  Data protection
rules may be a problem here.

> * Easy key rollover

In case of key compromise or for forward security?  The latter is more
problematic because you need to take the key offline but if you still
want to decrypt old messages (may be just 1 week, 1 month old) there
needs to be an easy way to restore them.

> be solved. But what has happened in the past is that they have been
> shuffled under the mat as 'advanced user problems'.

Yeah.

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Adam Caudill <[email-masked]>
Date: Tue, 2 Sep 2014 14:14:08 -0400

On Aug 26, 2014, at 6:34 PM, Pete Resnick <[email-masked]> 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 [email-masked], 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
[email-masked]
http://adamcaudill.com/