Implement an extended diffie-helmen exchange to protect against possible man-in-the-middle attacks

[arades79]

An extended diffie helmen exchange provides protection against a theoretical man-in-the-middle attack where a bad actor may be able to establish shared secrets with both a guest and counselor and be able to read all messages between the two. Counselors already upload public ed448 keys for long term authentication use, so the new process should be relatively easy to implement.

The full process should follow:

1. counselor signs up with long term ed448 pubkey

2. counselor signs in with x448 pubkey encrypted then signed with ed448 key

3. guest logs in with ed448 pubkey, obtains list of ed448 public keys for counselors (list may be stored with server in json file

4. guest requests counselor with x448 pubkey encrypted then signed by ed448 key, server provides counselor signed encrypted x448 key

5. guest decrypts counselor x448 key, performs x448 key exchange, generates new x448 key, new key is signed with ed448 key, guest encrypts new x448 key with shared secret, then encrypts with counselor public ed448 key, resulting content is posted to messages endpoint, creating endpoint with counselor id for get

6. counselor obtains counselor ed448 key, signed encrypted guest x448 key, decrypts and verifies x448 key, exchanges x448 keys, generates a new x448 key pair, encrypts new x448 public key with shared secret, then encrypts with guest public ed448 key, resulting content is posted to messages endpoint, creating endpoint with guest id to messages endpoint

7. both users get from their id's messages endpoint to receive the double-encrypted key material, decrypt the material with their ed448 key, then decrypt with their initial derived shared secret key, the results are verified with the signature, and the new shared secret is created via x448 key exchange for use during the rest of the chat session

[arades79]

Ed448 (at least within pyca/cryptography) does not support encryption/decryption of data except via DH key exchange. Thus anywhere above that says "encrypt" or "decrypt" should instead be taken to be "sign" and "verify" (except for the pieces encrypted by the symmetric shared secret)