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 contact request or 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.
*In TFC the options in square brackets are the default option and can be selected by pressing just 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 (i.e. once both users see their contact has come online), 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. The Transmitter Program will also send the incorrectly typed key to Relay Program that shows where the user made the typo(s). In such a 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 the Relay Program displays more than one public key, pay attention to the abbreviated TFC account above the public key: It must match the abbreviated TFC account 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 its 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, if the attack persists, exchange PSKs instead.
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
This completes the X448 key exchange.
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 replacing it as hard as possible for attackers attempting a MITM attack. 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, the user has to select X448. The nickname should be set to something that reminds the user this is an unknown contact.
Once both the user and the contact 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 the fingerprint verification and sets the key exchange trust level as Unverified.
The user must press Enter to confirm they have read the warning about checking fingerprints. After that, the contact information and communication keys are exported to the Receiver Program, and 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.
The Transmitter Program will remember the TOFU state of key authentication, and display the status as Unverified to remind the user keys haven't been verified yet.
If/once the two know each other in real life, they should either meet or call each other over an authenticated out-of-band channel and re-initialize the fingerprint verification with the /verify command. Once the users have compared the fingerprints, assuming their fingerprints matched, they should complete the verification by typing yes to the prompt.
This sets the key exchange status as Verified.
