Opened 3 years ago

Closed 3 years ago

#22995 closed defect (wontfix)

prop224 should say we use SHA3-256 for rend circuit digests

Reported by: teor Owned by: asn
Priority: Medium Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: prop224, tor-spec, doc
Cc: Actual Points:
Parent ID: Points: 0.5
Reviewer: Sponsor:

Description (last modified by teor)

In prop224, the rend section says:

   A successfully completed handshake, as embedded in the
   INTRODUCE/RENDEZVOUS cells, gives the client and hidden service host
   a shared set of keys Kf, Kb, Df, Db, which they use for sending
   end-to-end traffic encryption and authentication as in the regular
   Tor relay encryption protocol, applying encryption with these keys
   before other encryption, and decrypting with these keys before other
   decryption. The client encrypts with Kf and decrypts with Kb; the
   service host does the opposite.

But that's not what the code does: circuit_init_cpath_crypto() uses SHA3-256 rather than SHA1 when is_hs_v3 is true.

Child Tickets

Change History (4)

comment:1 Changed 3 years ago by teor

Description: modified (diff)
Summary: prop224 should say we use SHA256 for rend circuit digestsprop224 should say we use SHA3-256 for rend circuit digests

comment:2 Changed 3 years ago by dgoulet

Owner: set to asn
Status: newassigned

Assigning to asn because he knows best about the ed25519 validation and put the second tor spec ticket to him because why not :P. That might change, this is just so we don't have any "new" tickets in 032.

comment:3 Changed 3 years ago by asn

What's the problem here? The spec does say that SHA3-256 should be used:

4.2.1. Key expansion

   The hidden service and its client need to derive crypto keys from the
   NTOR_KEY_SEED part of the handshake output. To do so, they use the KDF
   construction as follows:

       K = KDF(NTOR_KEY_SEED | m_hsexpand,    HASH_LEN * 2 + S_KEY_LEN * 2)

   The first HASH_LEN bytes of K form the forward digest Df; the next HASH_LEN
   bytes form the backward digest Db; the next S_KEY_LEN bytes form Kf, and the
   final S_KEY_LEN bytes form Kb.  Excess bytes from K are discarded.

Do you think we should make it clearer in section 5 that those keys are from KDF() which:

      * Instantiate KDF with SHAKE-256.

comment:4 Changed 3 years ago by teor

Resolution: wontfix
Status: assignedclosed

That's fine, I was confusing it with the similar section in tor-spec.txt.

I think we can leave it as-is.

Note: See TracTickets for help on using tickets.