<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> (Long-time lurker here.)<br> <br> 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.<br> <br> https://github.com/nylas/<br> <br> --Michael<br> <br> Sent from <a href="https://nylas.com/n1?ref=n1">Nylas N1</a>, the extensible, open source mail client.<br>  <div class="gmail_quote">On Jun 9 2016, at 2:38 pm, Ian Miers <imiers@cs.jhu.edu> wrote: <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <meta content="text/html; charset=utf-8"> <div dir="ltr"> <div> <div><span style="line-height:1.5">Forward secure public key encryption (FSPKE) is a good alternative to consider here. It avoids </span> complexities of doing key exchanges over SMTP and having shared state between the sender and recipient. </div> <div><br> </div> <div>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. </div> <div><br> </div> <div>Matthew Green and I've done some work on improving such schemes and even produced a fairly decent implementation. <span style="line-height:1.5"><a href="https://github.com/imichaelmiers/libforwardsec/" target="_blank">https://github.com/imichaelmiers/libforwardsec/</a> . Crucially, this doesn't require synchronized clocks.</span></div> <div><br> </div> <div>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.</div> </div> <div dir="ltr"> <div> <div><br> </div> <div>Ian Miers</div> </div> </div> <div dir="ltr"> <div> <div dir="ltr">On Thu, Jun 9, 2016 at 4:32 PM Wei Chuang <<a href="mailto:weihaw@gmail.com" target="_blank">weihaw@gmail.com</a>> wrote:<br> </div> <blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir="ltr"> <div> <div>On 9 June 2016 at 13:24, Daniel Kahn Gillmor <span dir="ltr"><<a href="mailto:dkg@fifthhorseman.net" target="_blank">dkg@fifthhorseman.net</a>></span> wrote:<br> <blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <span>On Thu 2016-06-09 15:15:35 -0400, Vincent Breitmoser wrote:<br> >> b) synchronizing the complex and changing keystore (pairwise state<br> >> between all correspondents) between multiple e-mail clients, since<br> >> many people use multiple MUAs to access a single mailbox<br> ><br> > The obvious place to put the data is the mailbox. Mail servers via imap<br> > are pretty okay at synchronizing immutable blobs of data, so it should<br> > be possible technically to achieve synchronized state among all MUAs.<br> > We can also get confidentiality and integrity for this data with a<br> > secret shared in all MUAs, like the user's pgp key.<br> ><br> > But I think there's a catch: We can never reliably *delete* data from<br> > the server. This essentially breaks the properties we gain from key<br> > erasure ("forward secrecy") in the first place. That's a huge problem,<br> > and I'm not sure there is a way to work around it. At least not if we<br> > want to be able to read mails from a session established by one MUA in<br> > another.<br> <br> </span>I had the same thoughts, which is why i didn't propose syncing it via<br> IMAP -- it seems like a mistake to move the key storage to the same<br> server that we're trying to defend against, which is why i see it as a<br> serious challenge if we want this to be a useful improvement over<br> existing e-mail security features.<br> <br> :/<br> <br> Simplest is to start by assuming that this is a one-MUA-per-account<br> setup for the initial implementation.<br> <br> as a strawman: what about an OMEMO- or axolotl-protected pairwise chat<br> conversation between MUAs on a single account, using IMAP as the<br> transport, where each MUA sends the other MUA updates as messaging<br> progresses?<br> </blockquote> <div><br> </div> </div> </div> </div> <div dir="ltr"> <div> <div> <div>+1 Agreed this is the simplest approach that will help the discussion.</div> </div> </div> </div> <div dir="ltr"> <div> <div> <div><br> </div> <div>-Wei</div> </div> </div> </div> <div dir="ltr"> <div> <div> <div> </div> <blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> happy to hear other suggestions,<br> <br> --dkg<br> </blockquote> </div> </div> </div> _______________________________________________<br> Messaging mailing list<br> <a href="mailto:Messaging@moderncrypto.org" target="_blank">Messaging@moderncrypto.org</a><br> <a href="https://moderncrypto.org/mailman/listinfo/messaging" rel="noreferrer" target="_blank">https://moderncrypto.org/mailman/listinfo/messaging</a><br> </blockquote> </div> </div> </div> </blockquote> </div> </body> </html>