wiki:org/meetings/2016WinterDevMeeting/Notes/CryptoChanges

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 GF2256…? 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…

relaycrypt_()

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@….

New Proposals

We should compose a proposal for NewHope.

Getting Involved

Depends on your skills. There are some tickets. Send nickm@… an email to get the tickets.

Attend the proposal discussion meetings. See above section.

Last modified 2 years ago Last modified on Aug 12, 2016, 5:41:07 PM