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,