[tor-dev] (Draft) Proposal 224: Next-Generation Hidden Services in Tor

[Nicholas Hopper]

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 at 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/ )

-- 
------------------------------------------------------------------------
Nicholas Hopper
Associate Professor, Computer Science & Engineering, University of Minnesota
Visiting Research Director, The Tor Project
------------------------------------------------------------------------