[tor-dev] prop224: Deprecating SHA1 circuit digests

Sun Jul 23 14:00:31 UTC 2017

On 23 Jul (12:08:25), teor wrote:
> 
> > On 22 Jul 2017, at 00:07, David Goulet <dgoulet at ev0ke.net> wrote:
> > 
> > On 22 Jul (00:02:33), teor wrote:
> >> Hi all,
> >> 
> >> At the moment, Tor uses SHA1 for the running digests of circuit cell
> >> payloads.
> >> 
> >> 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]).
> > 
> > That is not accurate. It uses SHA3, notice DIGEST_SHA3_256 in
> > circuit_init_cpath_crypto():
> > 
> >  if (is_hs_v3) {
> >    digest_len = DIGEST256_LEN;
> >    cipher_key_len = CIPHER256_KEY_LEN;
> >    cpath->f_digest = crypto_digest256_new(DIGEST_SHA3_256);
> >    cpath->b_digest = crypto_digest256_new(DIGEST_SHA3_256);
> >  }  ...
> 
> Oops, missed the "3".
> 
> We still need to think about how we migrate hashes, because all hashes
> break eventually:
> https://valerieaurora.org/hash.html
> 
> And I am concerned that we might be hard-coding either SHA1 or SHA3-256
> in the v3 hidden service protocol.
> 
> The following handshakes depend on version information in the HSv3 protocol:
> * client to intro,
> * service to rend, and
> * client to service.
> They can't use version information from the consensus.
> 
> I've opened a ticket for this:
> 
> https://trac.torproject.org/projects/tor/ticket/23010

I want to discuss couple of things about this ticket here (discussion on trac
are really unpleasant...).

First of all, afaict, the hashing choice is not relevant to IP/RP/HSDir at
all. The IP only routes cells between two circuits based on the authentication
key it sees in the INTRODUCE1 cell that the client gets from the descriptor.
The RP routes cells based on a cookie and the HSDir stores descriptor based on
the blinded key it sees in the descriptor. If tomorrow we had to change to
SHA9000, they wouldn't care.

That being said, switching the hash algorithm is a problem between the client
and service.

The HS protocol version (prop224 introcuces v3) is bound to some crypto
choices. It is not designed to be extensible in terms of crypto primitives.
All of those are hardcoded and are part of the protocol: ed25519/curve25519
keys, AES-256 is stream encryption, SHAKE-256 our KDF and SHA3 for our hash
function.

Negotiating cipher suites is a trap for all sorts of really bad issues (SSL is
the prime example). So then we have versionning, different version uses
different things (basically HS v2 and v3). And I think it is what you are
proposing.

Let's imagine a world where next year SHA3 is broken and thus replaced by SHA4
which means that we need to make changes to the HS protocol. In a nutshell,
we'll need to release a tor client and service that can use SHA4 in the HS
protocol.

I guess the question you are asking here is: can we do that without bumping
the HS protocol to v4? (Because bumping to v4, we hardcode SHA4 and job done).
And remember, the version of the service is in the onion address so the client
either know how to speak to it or doesn't.

Now back to trying to switch to SHA4 within the v3 protocol. We either put a
field in the INTRO cell (for instance an EXTENSION) saying "oh I can speak
SHA3 and SHA4". But then you end up with the problem of "which one the client
uses in the INTRO cell?". We don't have protocol version negotiation so either
the client sends all possibilities (huge cell) or try SHA3 and if fails,
re-try with SHA4. Or client picks SHA4, tries the service and service can
speak it or not. This is kind of crummy, all sorts of reachability issues,
more load on the network and user will get hella confused on why there are
failures all of the sudden for this service it was happilly connecting to
before.

Second option, the service adds a hint somewhere in the descriptor saying "My
hash algorithm is SHA4". I strongly think the service should NOT provide a
choice because of the downgrade attack. And we must have a consensus param
that provides the minimum required (as you proposed) so malicious service
advertising SHA3 (that is broken in our example here) will get rejected by
legit clients.

What this approach gives us here versus bumping the protocol version to v4?
The only thing I can see is for the service to be able to keep its onion
address intact which is kind of a big useful thing :P.

However, we end up with the problem of partition ... where some clients will
reach the service that has upgraded and some will fail until they upgrade.
Consensus param can help here that is we have a param that tells the service
what hash algorithm it must use.

It's not an easy problem to be honest, seems most solutions will bring
problems.

To be honest, the version in the address allows a very simple and easy
transition because 1) the service can run a v3 and v4 in parallel with two
addresses and can decide when to cut off the broken v3. It is actually a good
way to transition if you ask me, you put a page on the v3 saying "hey, upgrade
Tor and use this v4 address", 2) the client doesn't even touches the network
if it can't speak v4 and 3) we avoid the version negotiation problem between
client and service. But of course, downside is a new address.

Complexifying the protocol for something that can be fixed with a bump of the
hidden service version protocol is something that I'm not comfortable with
*unless* it provides an important plus value for the users in terms of
security or/and usability.

Cheers!
David.

> 
> T
> 
> --
> Tim Wilson-Brown (teor)
> 
> teor2345 at gmail dot com
> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
> ricochet:ekmygaiu4rzgsk6n
> xmpp: teor at torproject dot org
> ------------------------------------------------------------------------

> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-- 
gWHGWRozhr9DOkdWsxQmZqjzjtgDHfRbX0Qa8n7Bo6c=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170723/c93165e9/attachment.sig>