<div dir="ltr">Hi list,<div><br></div><div>This is a proposal to use quantum-safe hybrid handshake for Tor communications.</div><div>Given NSA's recent announcement on moving towards quantum-safe cryptography,</div><div>it would be nice to have a quantum-safe feature for Tor. </div><div><br></div><div>The idea of the quantum-safe hybrid handshake is to combine both classical key</div><div>exchange and a key encapsulation mechanism (KEM) instantiated by a quantum</div><div>safe encryption algorithm, so that the combination gives both (classical) </div><div>authentication and quantum safety. In a bit more details, the client and the server </div><div>agrees on a classic pre-master secret, $c$, using the ntor protocol. In parallel, client </div><div>generates a public/private key pair of the quantum-safe encryption algorithm, and</div><div>send the public key to the server. The server picks a random string, $q$, encrypts</div><div>it with the public key and send the ciphertext back to the client. The final secret</div><div>is the output of KDF(c|q). </div><div><br></div><div>This proposal defeats the harvest-then-decrypt attack with a minimum impact to</div><div>the existing ntor protocol. An adversary needs to be able to break the quantum-safe</div><div>encryption algorithm to learn q. On the other hand, if the quantum-safe encryption</div><div>algorithm turns out to be not secure, the protocol is still as secure as ntor protocol.</div><div>In other words, it will at least do no harm to the current security.</div><div><br></div><div>In addition, this is a modular design that allows us to use any quantum-safe <br></div><div>cryptographic primitives. As a proof of concept, we instantiated the protocol with</div><div>NTRUEncrypt lattice-based crypto. We implemented the the protocol with NTRU</div><div>parameters that gives 128 bits security. The code is available at</div><div><a href="https://github.com/NTRUOpenSourceProject/ntru-tor">https://github.com/NTRUOpenSourceProject/ntru-tor</a></div><div><br></div><div>Please find the attachment for the request to change the feature. The proof of the</div><div>protocol can be found at: <a href="https://eprint.iacr.org/2015/287.pdf">https://eprint.iacr.org/2015/287.pdf</a></div><div><br></div><div>Some known issue:</div><div>1. cell size. As far as we know, all quantum-safe encryption algorithms have </div><div>large key and/or ciphertext size that exceeds the cell size ~500. So this protocol </div><div>needs to transmit multiple cells, no matter which quantum-safe encryption </div><div>algorithm we chose. This is addressed by "Proposal 249: Allow CREATE cells </div><div>with >505 bytes of handshake data".</div><div><br></div><div>2. quantum-safe authentication: there is no quantum-safe authentication in this </div><div>protocol. We believe that authentication can wait, as future (quantum) adversary </div><div>cannot come back to present time and break authentication. Hence, we use ntor</div><div>authentication to keep the proposal compact and simple. It will be a future work</div><div>after this proposal.</div><div><br></div><div>Thanks for your time, and happy holidays!</div><div><br></div><div><br></div><div>Zhenfei Zhang</div><div>Security Innovation.</div></div>