# Post-Quantum Migration of the Tor Application
## 2 Literature Review
### Tor Design and Architecture
#### 2.1.2 Relay and Link Layer
In a \"classical\" key exchange context, the assumption relies on Diffie-Hellman, while with PQC integration, it typically includes KEM, implicating a revision of the 1-RTT mode. In 2020, [PERSON] et al. [19] introduced \"KEMTLS\", a fully post-quantum modification of TLS 1.3, replacing signature-based authentication with KEM. Their design drastically cuts the computational costs associated with PQC signatures while achieving IND-CCA but not strict full-forward secrecy, for which they declared achieving levels 1, 3, and 5 according to the Noise protocol framework [20]. The same authors released a variant of their previous KEMTLS named KEMTLS-PDK [21], yet in the context of Tor, this revised version relying on pre-distributed keys and partially cached information might not be a straightforward fit if connections could be linked back to cached or pre-shared keys. As for hybrid instantiation, the main method involves concatenating the classical and PQC key materials (public keys/ciphertexts) and treating them as a single element. [PERSON] et al. [22] draw a transitional capable design with backwards compatibility, allowing one device (client or server) to still use traditional schemes if it is not \"hybrid-aware\", therefore resulting in three possible scenarios: hybrid handshake, client downgrade, or server downgrade to classical only. Their design aims to keep TLS 1.3 features such as high performance or 1-RTT. The IETF draft declares the main security property of KEMs as IND-CCA2, correlating with the first motivation of CECPQ2 [23]--the second version of the TLS 1.3 key exchange protocol developed by Google and Cloudflare. In fact, [PERSON] [23] highlights that, in TLS, managing confidentiality is more straightforward than authenticity, as encryption keys are independently negotiated for each session, while post-quantum authenticity presents a greater challenge, as it needs to integrate with the existing certificate authority and certificate ecosystem, making it considerably more complex to establish and maintain. Tor's TLS connection layer for relays and bridges, like the standard TLS, uses X.509 certificates to authenticate themselves during handshake exchanges [10]. Concerning the OS, the \".onion\" address, being a hash of the service's public key, confirms the server's identity itself without the need for a CA. Firefox, on which Tor's browser is based, has already released the option to use X25519 Kyber768 for TLS. Tor's TLS implementations have been slightly modified from the standard to meet its needs for compatibility and against traffic analysis. The ongoing research and deployments give a strong base to migrate the network's link layer; if the circuit-layer protocol ensures the main security and anonymity guarantees, in Tor, TLS is a necessary complement and has mitigated critical bugs in the past [5] #294. The relay and circuit-extend protocols, as Tor-specific protocols, seem to need a deeper analysis to build a migration design. However, the relay layer does not appear highly endangered [24]. The stream protocol has not been reviewed due to its significant reliance on the other layers and its minimal impact on onion routing compared to them.