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

[Whoopsies, wrong year. This is Winter 2016. —isis]

# -*- mode: org; -*-

* 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 Ed25519 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

*** 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

*** TODO Link Authentication

Ed25519 keys are not yet used during link authentication.

**** XXX: Is there a proposal for this?

*** 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?

* 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"

Bernstein 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 cipher, 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.

Last modified 21 months ago Last modified on Mar 1, 2016, 12:13:02 AM