Hi Nick!
On #tor-dev last Friday, you specifically asked for feedback on the following section of Prop 224:
On Fri, Nov 29, 2013 at 7:27 PM, Nick Mathewson nickm@torproject.org wrote:
3.3.2. Example encryption handshake: ntor with extra data [NTOR-WITH-EXTRA-DATA]
The PROTOID for this variant is "hidden-service-ntor-curve25519-sha256-1". Define the tweak value t_hsenc, and the tag value m_hsexpand as:
t_hsenc = PROTOID | ":hs_key_extract" m_hsexpand = PROTOID | ":hs_key_expand"To make an INTRODUCE cell, the client must know a public encryption key B for the hidden service on this introduction circuit. The client generates a single-use keypair: x,X = KEYGEN() and computes: secret_hs_input = EXP(B,x) | AUTH_KEYID | X | B | PROTOID info = m_hsexpand | subcredential hs_keys = HKDF(secret_hs_input, t_hsenc, info, S_KEY_LEN+MAC_LEN) ENC_KEY = hs_keys[0:S_KEY_LEN] MAC_KEY = hs_keys[S_KEY_LEN:S_KEY_LEN+MAC_KEY_LEN]
and sends, as the ENCRYPTED part of the INTRODUCE1 cell:
CLIENT_PK [G_LENGTH bytes] ENCRYPTED_DATA [Padded to length of plaintext] MAC [MAC_LEN bytes]
Broadly, I don't see any obvious problems here. Just from this description, it's unclear whether the MAC covers CLIENT_PK and ENCRYPTED_DATA or just ENCRYPTED_DATA (or, possibly something else). Since X goes into the KDF, it should be OK just to compute the MAC over ENCRYPTED_DATA. From a crypto security standpoint, this will basically become elliptic curve DHIES with associated data, so it will inherit the nonmalleability and confidentiality properties of that scheme. It should also be possible to show that the scheme has key-privacy: if the IP can distinguish between ciphertexts encrypted using different IP keys B1, B2, it can solve the DDH problem in the Curve25519 group. This property could be useful depending on the eventual scaling designs supported.
(There is a typo that confused me several paragraphs later: s/faileds/fields/ )