[tor-dev] prop224: Deprecating SHA1 circuit digests

teor teor2345 at gmail.com
Fri Jul 21 14:02:33 UTC 2017

Hi all,

At the moment, Tor uses SHA1 for the running digests of circuit cell

Some of the prop224 code seems to use SHA256 for the digests for
client to service rendezvous circuits. But that's not in the spec yet
(see #22995 at [0]).

How and when do we plan to move away from using SHA1 in Tor circuits?

For non-onion service circuits, this would mean:
* implementing support for SHA256 [1] circuit digests
* adding a Relay protocol version 3
* teaching clients to use SHA256 digests with relays with Relay
  protocol >= 3

For onion service circuits, it's more complicated, because the
following circuit types can't use relay versions from the consensus:
* client to intro
* service to rend
* client to service
(Using relay versions from the consensus leaks which consensus clients
and services have, which reduces the anonymity set.)

Here are the upgrade mechanisms in prop224 at the moment, for both
circuit protocol versions and any necessary handshake material:

client to intro:
* the protocol version could be in a proto line to each intro point,
  but this isn't implemented yet
* the handshake data can be in the link-specifiers (I think?)

service to rend
* the protocol version could be in the EXT_FIELD in the INTRODUCE
  cell, but this isn't implemented yet
* the handshake data can be in the link-specifiers (I think?)

client to service:
* the protocol version is in the create2-formats in the descriptor
* the handshake data is in HANDSHAKE_INFO in the RENDEZVOUS cells
* SHA256 digests are implemented, but not documented in prop224 [0]

I suggest we make the following changes to prop224 to make this happen:

Protocol version information:
* add the relevant relay protocol versions to the intro point section
  of the descriptor
* put the relevant relay protocol versions in an EXT_FIELD in the
* check create2-formats contains all the version info we will need to
  change the client to service circuit protocol version

Downgrade resistance:
* teach clients and services to use the highest common protocol between
  client/service and relay, excluding protocols that are below the
  minimum required protocol versions
* work out how we will tell clients to no longer accept an old
  create2-formats line from a service

[0]: https://trac.torproject.org/projects/tor/ticket/22995
[1]: By SHA256, I mean "a good secure hash at the time"


Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
xmpp: teor at torproject dot org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170722/5de2e0ab/attachment.sig>

More information about the tor-dev mailing list