Overview
Tor is revising all of its crypto and in many cases switching to new primitives. Here is summary of the work thus far, what still needs to be done, ideas for the future, and how to get involved.
Status of Ed15519 Support for Identity Keys
We're done with adding support for Ed25519 keys. New routers use the new Ed25519 relay ID keys.
See prop#220: https://gitweb.torproject.org/torspec.git/tree/proposals/220-ecc-id-keys.txt
and prop#228: https://gitweb.torproject.org/torspec.git/tree/proposals/228-cross-certification-onionkeys.txt
Parent Ticket: https://bugs.torproject.org/15054
TODO DirectoryAuthority Support
Ed25519 keys are not yet in use by the DirectoryAuthorities.
See prop#321: https://gitweb.torproject.org/torspec.git/tree/proposals/231-migrate-authority-rsa1024-ids.txt
Tickets
https://bugs.torproject.org/17702 https://bugs.torproject.org/17668
TODO Link Authentication
Ed25519 keys are not yet used during link authentication.
XXX: Is there a proposal for this?
Tickets
https://bugs.torproject.org/15055
TODO Ed25519 ←→ RSA1024 Keypinning
We want to turn on keypinning. See prop#220, §3.1: https://gitweb.torproject.org/torspec.git/tree/proposals/220-ecc-id-keys.txt#n277
Also see prop#256 for handling key revocation: https://gitweb.torproject.org/torspec.git/tree/proposals/256-key-revocation.txt
We have not done this yet, largely due to concerns that relay operators are going to have problems with proper key management.
TODO Circuit Extension
We need to finish the code to have EXTEND* cells use Ed25519 keys.
XXX: Is there a proposal for this?
Tickets
https://bugs.torproject.org/15056
Relay Crypto
509-byte Wide-block Cipher
Nickm wants a 509-byte wide-block cipher. Nick says, "Each block should have a key, and it should be also derived from all previous blocks, that way we will be able to learn at which point a circuit became corrupted."
It needs to support 509-byte blocks
Rather than using a wide-block ciphers, we could use something where a MAC is removed at each hop, then the cell is deterministically re-padded. However, lots of fast MACs are unsafe to truncate, and most cryptographers cringe if you start talking about ~6-byte secure, fast MACs.
We could take a 512-byte non-wide-block cipher, but ugly because padding and re-MACing at each hop. it's better if we keep the 509-block cell size, because then the cell-size is interoperable with older relays.
It needs to be fast, constant-time, and cross-platform, without special hardware
Needs to be fast AND cross-platform, i.e. "don't assume that binary operations on a finite field are constant-time on all platforms."
We NEED fast, constant-time versions of whatever we do, without specialised hardware.
(More or Less) Concrete Suggestions
AEZ
AEZ is a bit ugly.
There is a prop#261 describing using AEZ for Tor's circuit crypto: https://gitweb.torproject.org/torspec.git/tree/proposals/261-aez-crypto.txt
HHFHFH, a.k.a. "Hufflepuff"
Berstien et al. are working on something new, but it's not finalised.
Nick says: "It's basically a 2- (or 1-) round feistel. First, you hash to key a stream ciphre, then hash to key another stream cipher, then add that back in."
Dan suggests XChaCha20 for the stream cipher. It also needs a fast universal hash. Something about a polynomial in GF2^^256…? No solid recommendation from Dan yet.
Something about real-world cryptography…
The conversation devolves to discussing rogaway's "on the moral nature of cryptographic work" paper…
"Bernstein monoculture" is apparently a phrase now.
The existence of prime fields to base your primitives on is lacking, in that there's really only "use the fields which curve25519 is based upon."
Cryptol claims they'll release the codegen backends opensource sometime in 2016, but we've no idea. Someone mentions that that would be an excellent place for GCHQ to hide a backdoor.
Separate experimental Tor network for real users to test out experimental new crypto
Suggestion from someone: A new, separate Tor network where crypto is tried? I.e. a real network where "untested" code goes, but which has real users who know that they are using the testnet.
Nick says: Nobody wants to set up a real network with real authorities because it's painful.
Suggestion: set a flag so that clients can choose the new relays which support newer crypto, e.g. via prop#264: https://gitweb.torproject.org/torspec.git/tree/proposals/264-subprotocol-versions.txt
Nick is still worried about backwards-compatibility, esp. with packages from various Linux distributions.
"Sadly there's a lot of engineering involved with doing crypto. It would be nicer if we could just have crypto be equivalent to its mathematical representation."
The conversation devolves to the symantic differences between pure math and programming…
relay__crypt_()
Why is the current crypto making us nervous?
AES in CTR mode is not so nice because it allows relays to collude, because the authentication is end-to-end, not at each hop.
We would prefer instead to use an Authenticated Encryption cipher, i.e. one of the CAESAR candidates. See: http://competitions.cr.yp.to/caesar-submissions.html
Post-Quantum Handshakes
We would like to use basically NTOR cross-signed/hybrid with something post-quantum secure.
Nick wants a way to minimize attacks which utilise any sort of precomputation to break handshakes.
NTRU
There is an NTRU-based proposal from some of the NTRU developers, see prop#263: https://gitweb.torproject.org/torspec.git/tree/proposals/263-ntru-for-pq-handshake.txt
Perhaps more importantly, please see the meeting notes from the proposal discussion session on prop#263: http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-02-04-13.28.html
A cryptographer present mentions that, reading the things which the NTRU people are writing, it was unclear if they put much thought into how the signature composition should work. This cryptographer asks if newhope is designed from the start to do this sort of hybrid approach?
NewHope
A new, faster, more-secure version of NewHope is finalised in a paper and has been submitted. Isis has a copy and code, but can't/shouldn't give it out unless the authors say it's okay to do so. We've been jokingly referring to it as "NewestHope".
TODO Write a Tor proposal for composing "NewestHope" with NTOR-style ECC-based handshakes.
Getting Involved
Proposal Meetings
See our wiki page where we organise proposal discussion meetings: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/MeetingSchedule
Email Threads
See tor-dev@lists.torproject.org.
New Proposals
We should compose a proposal for NewHope.
Getting Involved
Depends on your skills. There are some tickets. Send nickm@torproject.org an email to get the tickets.
Attend the proposal discussion meetings. See above section.