[messaging] Axolotl for email

[Ian Miers]

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> wrote:

> On 9 June 2016 at 13:24, Daniel Kahn Gillmor <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
> https://moderncrypto.org/mailman/listinfo/messaging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20160609/d00100c0/attachment.html>