8

Axolotl Ratchet is used by the Signal messenger (formerly known as TextSecure) and an enhanced version of OTR in a way to make it suitable for mobile applications, which has the probability to encrypt messages without both parties to have to be online at the same time as described here. The key exchange is happening asynchronously.
Signal also solves a couple of other issues, like out-of-order decryption and preventing metadata to be leaked through cleartexts.

This sounds to me perfect as a replacement for PGP, which is lacking Forward secrecy (PFS) and some other issues.

What problems would have to be thought through, when creating a mail client plugin (like Enigmail for Thunderbird) that uses axolotl encryption instead of PGP?

rubo77
  • 2,350
  • 10
  • 26
  • 48
  • 3
    If there is a protocol, you can implement it. This is not a security question. – M'vy Mar 05 '15 at 08:54
  • related Feature Request: https://bugzilla.mozilla.org/show_bug.cgi?id=1140409 – rubo77 Mar 06 '15 at 14:58
  • As others have mentioned this isn't a good fit for email due to the need for a server component, however, it's currently being implemented in other places like Pond (mentioned by others), and in XMPP (see [here](http://conversationsgsoc2015.blogspot.com/) for details). – Sam Whited Aug 06 '15 at 04:45

3 Answers3

7

Neat idea, good question, but there are a couple issues that make axolotl not a good drop-in solution for existing email clients and/or servers:

1) The asynchronous part of TextSecure requires help from the server that email servers don't provide. Specifically, TextSecure/Signal servers distribute ephemeral public keys for offline users. Email servers don't.

2) Axolotl clients are necessarily stateful, tracking the key ratchet for every conversation. It is (again) just not a function that email clients are built to provide, and it makes having more than one email client hard, because it necessitates synchronizing that state between one's email clients. E.g. your desktop email client must get all the keys generated by your smartphone email client.

It could, however, be a good email replacement. If you want to work on that problem, check out the web client in development for TextSecure, or Pond. Textsecure/Signal needs a desktop client, and Pond needs a mobile client.

While the axolotl ratchet is brilliant and offers some great security properties, there is an argument to be made that the security guarantees that axolotl provides are not worth the state-maintenance hassle for a lot of use-cases.

George Walker
  • 71
  • 1
  • 1
    1. The first one was kinda solved with the PGP model (web of trust and a distributed set of key servers). It's not pretty, but it does work in most cases. The only annoyance is dealing with revocation (which needs non-repudiation, so you'd need to use your identity keys for more than just generating ephemeral keys). 2. While this is an issue, is it *really* not worth it for the security guarantees? Yes, state syncing is a pain (but it's not a *very* hard problem, given the centralised nature of email anyway). – cyphar Nov 30 '15 at 22:01
  • Key servers and web of trust address the distribution of static keys, not the ephemeral "pre-keys" required by the axolotl protocol. – George Walker Dec 03 '15 at 19:21
  • Agree that for an axolotl-based email-like system, such as Pond, the state maintenance problem with multiple devices gets easier if you have a trusted server centralize the state, but that is a heavy dependency and a non-starter for many (if not most) users! There aren't many of us who want to be our own sysadmins. – George Walker Dec 03 '15 at 19:26
1

I'd recommend Pond for asynchronous messaging, ala email, that need to be end-to-end encrypted. Pond uses the axolotl ratchet for forward secrecy, but Pond provides some protection from traffic analysis as well.

It's imho worth disguising the quantity, metadata, etc. of encrypted messages you send. Any email system will expose your metadata to traffic analysis. I'd suggest using GnuPG for one-off messages or infrequent correspondences with people who do not use Pond, but convince regular correspondences to use Pond.

An interesting project might be an email client that attempts to automatically establish a Pond connection though.

Jeff Burdges
  • 837
  • 5
  • 9
0

I am not sure the idea to use axolotl for email is sound or not, but it is worth a try. My team Tradle chose to create an alternative to email like @geargewalker had suggested. Still, here are some pointers for you:

  1. First problem that @georgewalker has mentioned is solvable. PGP have always had public key servers, but they were too clunky to use. One part of our messenger, which we call Trust In Motion (TiM) - preview is on our web site, is to use the blockchain as a key server. I can provide all the help you need to use our solution for public keys on-chain for your email plugin idea. TiM is open source and is soon entering a private beta, so you can start using the code.
  2. I do not see an immediate problem with keeping the state in the email client, per conversation thread, aside from the obvious - the other email client has to support Axolotl. Axolotl protocol itself has alternative third-party JS implementations.

Good luck.

Gene Vayngrib
  • 1
  • 1