X448
After the initial local key setup, or when the user enters the /add command, TFC will launch the Add new contact wizard.
The wizard will display the user their TFC account, prompt them for the contact's TFC account, a nickname for the contact, and finally a key exchange method (X448 or PSK).
Warning! The user should never add TFC-accounts that the Destination Computer shows them. Messages from, e.g., friends could have been spoofed by malware. If the user adds such account as a contact, they could unknowingly leak sensitive keys to the attacker in the network. The user should always obtain the same account through some other way (e.g., TFC Relay Program's group management message, Ricochet, Signal, even SMS or call) before adding the contact. That way they know the account was not created based on sensitive key data on their Destination Computer.
X448 stands for Curve448 Diffie-Hellman key exchange. X448 is the most secure key exchange algorithm that's currently available.
After entering account and nick, select the key exchange by pressing <enter> or by typing X448 and pressing <enter>.
Once the user and their contact have done this, their Relay Programs will connect to one another. The speed varies depending on what random Tor nodes are picked, and it is normal for one user to receive notification about contact being online before the other: This is because Relay Programs form separate circuits via different Tor rendezvous nodes for incoming and outgoing traffic.
Once Relay Programs have connected to each other, they will deliver the public keys. The contact's public key will be displayed by user's Relay Program.
Public key arrives to Relay Program
The user types the public key to Transmitter Program's prompt. The public key contains a checksum so the software will notify if the user has made a typo. In such situation the user can press the <up arrow> to edit previously entered public key. If the contact does not receive user's public key, the user can enter empty public key (i.e. press <enter>) to send it again.
In a situation where there Relay Program displays more than one public key, pay attention to the abbreviated TFC account above the public key: It must match the public key visible in the Transmitter Program's prompt. In the event Relay Program shows multiple different public keys for the same contact, the user must type the most recent public key.
Public key is typed to Transmitter Program
Verifying fingerprints is extremely important. It is the only way to be sure users are not under man-in-the-middle (MITM) attack. Fingerprint verification must be done as soon as possible: If the users negotiate a new key before verifying the previous one, it will be impossible to later verify the previous messages were not eavesdropped on by an attacker.
The verification is best done by comparing fingerprint of the public key via an authenticated, out-of-band channel, namely Signal by Open Whisper Systems. Signal uses it's own end-to-end encryption and to make sure it works, the users should verify the Signal's fingerprints (called safety numbers).
Once the authenticated channel is set up, the users must read their TFC public key fingerprints. The two must pay attention to the instructions on Transmitter Program: Each user must read their own public key. Otherwise, MITM attacker present in Signal call is harder to detect, as the attacker only has to spoof the "yes" or "no" answer when the user reads the attacker's public key aloud and asks the attacker if it was authentic.
If the users are unable to verify fingerprints at the time, they can press Ctrl+C to skip fingerprint verification. This marks X448 keys as "Unverified" when viewing the list of contacts with /names command. Fingerprint verification can be completed later with the command /verify. More about this later.
Transmitter Program prompts user to verify fingerprints
If the public key was not correct, the users should answer n or no to the prompt to abort key exchange. They should then consider trying again later or exchange PSKs if the attack persists.
If the fingerprint is correct, TFC prompts the user for a confirmation code that ensures keys for the new contact are added to both Transmitter and Receiver Program.
Transmitter Program prompts for the confirmation code
Suppose the TFC user is a journalist who wants to be reachable by whistleblowers. In that situation the user wants to publish their TFC account in multiple places to make it as hard as possible to replace with a malicious address. When a whistleblower contacts the user, they will add them as a contact, and select X448 key exchange, which sends a contact request to the user. The user can either choose to ignore the contact request (or disable requests altogether with the command /set allow_contact_requests False), or add the account as contact.
The contact is added with the command /add, that opens the Add new contact wizard. As obviously there's no way to exchange PSKs with strangers, they have to select X448. The nickname should be set to something that reminds the user this is an unknown contact.
Once both contacts are online at the same time and the X448 public key has been received and input to the Transmitter Program, the program will display the fingerprint verification window. In this case the contact is not known so it would be a bad idea to blindly type yes, because that sets the trust level on the key exchange as "Verified". Instead, the user should press Ctrl + C which does not abort key exchange, but skips it and sets the key exchange trust level as "Unverified."
The user must press enter to confirm they have read the warning. After that, they are asked to enter a confirmation code.
Once the contact has been selected, the conversation can begin. The user can set a nickname for the unknown contact with /nick command after they've made acquaintance. If the two know each other in real life, they should call each other over an authenticated channel and verify the fingerprints with the /verify command, which sets the key exchange status as "Verified". Until that takes place, it's a good idea to keep the status as Unverified to remind the user they can't fully trust the contact or the key exchange.