[messaging] Axolotl for email

[Michael Grinich]

(Long-time lurker here.)

If folks are interested in easily integrating with email and not dealing with the protocols, we’d love to support you at Nylas. We’ve also built a full cross-platform javascript desktop email app that is easy to extend. Both our sync technology and the desktop app are open source and it would probably be a good starting point instead of dealing with IMAP/MIME/SMTP/Exchange/etc.

https://github.com/nylas/

--Michael

Sent from Nylas N1<https://nylas.com/n1?ref=n1>, the extensible, open source mail client.
On Jun 9 2016, at 2:38 pm, Ian Miers <imiers at cs.jhu.edu> wrote:
Forward secure  public key encryption (FSPKE) is a good alternative to consider here.  It avoids  complexities of doing key exchanges over SMTP  and having shared state between the sender and recipient.

FSPKE  works like standard public key encryption but with a random tag and a time interval as additional input to the encryption algorithm.  On the recipient's end, deleting parts of their key ensures forward security while still allowing decryption of new messages. This eliminates the need for interactive ratchets. Or you could just use it for initial key establishment and then use signal's ratcheting scheme.

Matthew Green and I've done some work on improving  such schemes and even produced a fairly decent implementation. https://github.com/imichaelmiers/libforwardsec/  . Crucially, this doesn't require synchronized clocks.

This work was discussed once before on this list and I believe the general conclusion was just use Signal for everything and eat the cost of interaction and storing pre keys, but perhaps in this context it's different.

Ian Miers
On Thu, Jun 9, 2016 at 4:32 PM Wei Chuang <weihaw at gmail.com<mailto:weihaw at gmail.com>> wrote:
On 9 June 2016 at 13:24, Daniel Kahn Gillmor <dkg at fifthhorseman.net<mailto:dkg at fifthhorseman.net>> wrote:
On Thu 2016-06-09 15:15:35 -0400, Vincent Breitmoser wrote:
>> b) synchronizing the complex and changing keystore (pairwise state
>>    between all correspondents) between multiple e-mail clients, since
>>    many people use multiple MUAs to access a single mailbox
>
> The obvious place to put the data is the mailbox. Mail servers via imap
> are pretty okay at synchronizing immutable blobs of data, so it should
> be possible technically to achieve synchronized state among all MUAs.
> We can also get confidentiality and integrity for this data with a
> secret shared in all MUAs, like the user's pgp key.
>
> But I think there's a catch: We can never reliably *delete* data from
> the server. This essentially breaks the properties we gain from key
> erasure ("forward secrecy") in the first place. That's a huge problem,
> and I'm not sure there is a way to work around it. At least not if we
> want to be able to read mails from a session established by one MUA in
> another.

I had the same thoughts, which is why i didn't propose syncing it via
IMAP -- it seems like a mistake to move the key storage to the same
server that we're trying to defend against, which is why i see it as a
serious challenge if we want this to be a useful improvement over
existing e-mail security features.

:/

Simplest is to start by assuming that this is a one-MUA-per-account
setup for the initial implementation.

as a strawman: what about an OMEMO- or axolotl-protected pairwise chat
conversation between MUAs on a single account, using IMAP as the
transport, where each MUA sends the other MUA updates as messaging
progresses?

+1 Agreed this is the simplest approach that will help the discussion.

-Wei


happy to hear other suggestions,

            --dkg
_______________________________________________
Messaging mailing list
Messaging at moderncrypto.org<mailto:Messaging at moderncrypto.org>
https://moderncrypto.org/mailman/listinfo/messaging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20160609/5f913e8b/attachment.html>