Re: [tor-dev] New revision: Proposal 295: Using ADL for relay cryptography (solving the crypto-tagging attack)

[Nick Mathewson <nickm@xxxxxxxxxxxxxx>]

Hi!

Here are my notes on the latest prop295 that I came up with while
doing a reference implementation in Python.  If you're curious, you
can see the candidate reference implementation at
https://github.com/nmathewson/prop295ref . I'd love to know whether or
not the implementation matches the intention of the proposal.

Minor notes:

* I'm planning to replace HKDF-SHA256 with SHAKE, and AES128 with AES256.

* I agree with dropping the 'recognized' field.  I didn't implement it here.

More important issues:

* To clarify, I believe there need to be two separate T'_I values for each
  hop: T'_I for outbound cells, and T'_I for inbound cells.  I suggest
  calling them Tf'_I and Tb'_I.

* Since Tor allows a relay cell to be addressed to any hop in the circuit, I
  believe that every relay needs to have a separate value for authentication
  state that is currently called T'_{n+1}.  I'm calling this value Ta'_I,
  where the a stands for 'authentication'.

* I believe that the authentication algorithm in section 4.1 does not if
  cells may be addressed to hops other than the last hop.  It needs to change
  as follows:

             T_{n+1} = Digest(Khf_n,T'_{n+1}||C_{n+1})
             Tag = T_{n+1} ^ D(Ktf_n,T_{n+1} ^ N_{n+1})

             If Tag = 0:
                  T'_{n+1} = T_{n+1}
                  The message is authenticated.
             Otherwise:
                  T'_{n+1} remains unchanged.
                  The message is not authenticated.

  The change here is that I think T'_{n+1} (which I'd like to call Ta'_I)
  should only change when the message is authenticated.

Some questions about issues I don't understand:

* Is it really safe to use the same key (Khf_n) for authentication as well
  as for encryption?

* Is there any reason _not_ to initialize the T' values based on the
  KDF?  It seems to me that setting them to zero might give the attacker
  some information they didn't have before.

* What forward secrecy, if any, are we getting here?

many thanks,
-- 
Nick
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev