Confirmation Code
In TFC, the Transmitter, Relay, and Receiver Programs of the user talk to each other over unidirectional links. Since there is no acknowledgement channel for verifying data was correctly sent over the line, unrecoverable transmission errors are inevitable. The rate at which they occur depend on multiple things:
- quality of the serial adapters used
- data diode components and build quality of the circuit
- baud rate (speed setting of the serial interface)
- the amount error correction applied
- interference from external noise sources
Note: In practice errors are quite rare unless the baudrate is very high. Thus, if transmission errors that hurt the user experience keep occurring, there is probably something wrong with the data diode circuit and the issue should be addressed on HW level, not by tweaking settings, e.g. by lowering the baudrate from the default value.
Because TFC's security relies on unidirectional communication between the programs, there is no automated way to ask packets to be re-transferred. To prevent a situation where important data such as Onion Service private key, PSK or X448-derived keys do not reach their destination, TFC uses something called a confirmation code. Confirmation code is a two hexadecimal (0..9 and a..f) code that is quick to type but annoying enough to guess.
Example of a confirmation code prompt
In the event data does not reach its destination and the user does not see the correct confirmation code on the program specified by the Transmitter Program (from Relay means confirmation code should be visible on Relay Program on Networked Computer), data can be re-transferred simply by pressing enter as many times as needed until the packet reached its destination and the receiving program displays the confirmation code.
Confirmation codes are not sensitive in any way.