compatibility-breaking crypto improvements

[warner]

In #58 we noted that our symmetric encryption primitive (XSalsa20/Poly1305) is pretty much only used in libsodium, and the rest of the world (i.e. RFC7539 and ring's AEAD construction thereof) has moved to ChaCha20. Libsodium is a nuisance to use from Rust (since it's an FFI binding to a C library that takes some manual effort to build), so a short-term effort is to run a pure-rust XSalsa20 crate that's compatible with SecretBox.

But the long-term hope would be to move to ChaCha20 and RFC7539 (maybe Noise uses this?). That's a compatibility break, so I want to batch together all the other breaking crypto changes we might want to make and do them all at the same time, since as we all know version negotiation should happen just once at the highest level of a protocol, and it should be on a number instead of a matrix of individual features.

So this ticket is to collect the crypto changes we might want to make. Some others to consider:

• get a PAKE pattern into Noise and use that instead of our initial setup protocol
• replace Transit with Noise (although the new Dilation protocol already does this)
• if we ever manage to establish a better encoding format or well-known-element selection process for SPAKE2, switch to that flavor for the PAKE phase

[warner]

see also magic-wormhole/magic-wormhole#348

[warner]

Also:

• switch to the original M != N flavor of SPAKE2, by computing both the "A" side and the "B" side at the same time (different random scalars, of course), and putting both PAKE messages into the initial payload, along with the random "side" value. Upon receipt, compare sides to see which role you're playing, and proceed with only one of the two PAKE messages. This doubles the CPU of the initial step, but doesn't need a roundtrip, and lets us stick with the original security proof.