Preparation for post-quantum

[diptimahamuni]

Problem

1. Eventually, we should add the option of post-quantum signatures and encryption.
2. Unfortunately, this may add a kilobyte or multiple kilobytes to the signature for each message (depending on the algorithm used). That could be VERY inconvenient.
3. There is a simple change that will improve that. For each triplet (sharer, helper, secret ID), define a single AES-256 key to be used to encrypt all messages between them, using GCM to give strong authentication at the same time (equivalent to a digital signature, but much smaller, for post-quantum). Then, only the initial two messages of initiating the pairing and the reply will need to include possibly-gigantic keys and signatures. All future messages will have very little overhead. In fact, even before we switch to post-quantum algorithms, this change will save few bytes on every message.

Solution

1. This can be implemented as a change to the protobufs and library implementation, without much effect on the API and the app using it. So it can be mostly invisible to the app developers. But it is a breaking change to the protocol. So it suggests that it should be implemented soon, before there are multiple libraries in multiple languages that will all need to be updated.
2. The only drawback is that traffic analysis can now identify when two messages were sent by the same party. But that does not seem like a bad tradeoff.

[johnalanwoods]

I'd like to consult on the implementation. Let's discuss prior to design.

If we do use a symmetric primitive XChaCha20-Poly1305 is preferable.