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