[messaging] Axolotl for email
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Thu Jun 9 11:45:37 PDT 2016
On Thu 2016-06-09 14:16:02 -0400, Wei Chuang wrote:
> Would it make sense to apply Axolotl for email encryption? While the
> protocol allows the D-E exchanges to be asynchronous, the main remaining
> issue is the initial D-E exchange setup. TextSecure uses pre-keying, but
> that likely has challenges for email as there isn't a standard directory
> service for email. Are other approaches possible? Would it be possible to
> use existing PKI (X.509 or PGP based) to transmit the initial D-E key with
> If that can be overcome, I see the following advantages (and please correct
> me if I'm wrong):
> 1) Perfect forward and backwards secrecy makes key loss much less
> important. So much so that much of the worry about key revocation goes
> 2) Message processing needs only be a single pass authenticated encryption
> encrypt/decrypt that provides both privacy and integrity. S/MIME and PGP
> would have to do two passes and would have weaknesses as described here:
> Assuming that it does make sense is there standardization work for Axolotl
> for email encryption? I've read about the OMEMO for XMPP that is related.
> If so, who is a contact for the Axolotl email standardization work?
I'm interested in this idea, but i haven't had any time to work on it.
I see two challenges for the simplest case (pairwise, single-sender
a) signalling that such an arrangement is possible between the two peers.
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
(i suppose you could punt on (b) for an initial implementation)
I'd say bootstrap off of existing key material would be the way to go,
though, and use standard MIME encryption to handle the misery that is
required when dealing with e-mail structuring. For example, if you use
PGP/MIME, you'd just replace the existing PKESK (public key encrypted
session key) packet with some specially-tagged session key packet that
the peer would detect and use as a prompt to access their keystore.
Anyway, i'm interested, if you want to bounce design ideas off of
someone, i'm game.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 948 bytes
Desc: not available
More information about the Messaging