(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 <[email protected]> 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 <[email protected]<mailto:[email protected]>> wrote: On 9 June 2016 at 13:24, Daniel Kahn Gillmor <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://moderncrypto.org/mailman/listinfo/messaging
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
