Re: [tor-dev] Draft sketch document with ideas for future crypto ops

[Robert Ransom <rransom.8774@xxxxxxxxx>]

On 2011-11-01, Roger Dingledine <arma@xxxxxxx> wrote:
> On Mon, Oct 31, 2011 at 09:25:58PM -0400, Nick Mathewson wrote:
>>   The point of this document is to discuss what crypto we ought to be
>> using.
>
> Thanks Nick!
>
>>     - To make sure that the extending node is talking to the right next
>> node
>>       when sending an extend cell.
>>
>>   The new extend cell format needs to allow the client to tell the
>>   extending node about some identity for the destination node that the
>>   extending node will be able to understand.  This is a capability of
>>   the extending node that the client needs to be able to check. (Also,
>>   the extend cell needs to hash that identity in a form the extending
>>   node can understand, but that's a fingerprint issue.)
>
> Right now microdescriptors don't have any identity key in them. It would
> seem that Alice never needs to remember the identity key for the relays
> she uses at all. (She learns the fingerprint of the identity key from
> the microdescriptor-flavored consensus, and if she does a handshake with
> the relay she can learn its identity key while making sure it hashes to
> the right thing, but otherwise she doesn't use or remember it.)
>
> This is fine until we get to your sentence about Alice needing to know
> how to hash the identity in some other form.

I suggest gluing the fingerprint-extraction function to the
identity-key signature cryptosystem in our protocols.  So, instead of
hashing 2048-bit RSA keys in multiple ways, we would have
rsa2048-sha256 for 2048-bit RSA keys used to sign SHA-256 hashes *and*
hashed into fingerprints using SHA-256, and we might also have
rsa2048-tiger for 2048-bit RSA keys used to sign Tiger hashes and
hashed into fingerprints using Tiger.

Curve25519 public keys do not need to be hashed to form fingerprints
-- the keys themselves are shorter than the output of any hash
function we would consider using.  (Yes, I know Tiger has a 192-bit
output.  We wouldn't consider using it.)

>>   a  When representing them in the UI, we should
>>   use the notation %b64, where b64 is a base-64 encoding, omitting the
>>   trailing =s.
>
> Another use for identity keys that we left out of the list is the dot-exit
> notation. I don't think base64 domain names will work.

They won't work.  I suggest base32-encoded 255-bit (sÄc) hashes or
public keys (51 characters long).

> It may well be fine to say that the feature dies in the migration,
> but we should actively decide it rather than overlooking it.

We need to support some way to extend circuits to a specified exit
node without requiring a controller that reimplements Tor's full path
selection algorithm.

>> 3.4. Implications for EXTEND cells
>>
>>   As mentioned in 3.3, when a client Alice tells node Bob to extend
>>   to node Carol, she needs to give Bob a fingerprint for Carol that Bob
>>   will understand: one where Bob understands the digest algorithm, and
>>   understands the identity key type.

No.  We will only use fingerprints of identity keys for TLS-based link
protocols.

Link specifiers for our UDP-based link protocol will contain a
link-authentication public encryption key, and the CREATE cell that
causes a relay to open a UDP-based link will be sent encrypted to that
public key in the packet which opens the link.  (Yes, I know we can't
get forward secrecy for anything we send in that first packet
encrypted to a non-short-term public key.  We don't need forward
secrecy for a CREATE cell.)

>>   There are two ways we can do this:
>>
>>     1) Alice's EXTEND cell contains every fingerprint for Carol that
>>        Alice knows about.  Bob treats the cell as valid if every one he
>>        can verify is correct.
>>
>>     2) Alice knows which fingerprint types Bob understands (either via
>>        his version, or something else in his directory info).  She
>>        selects a fingerprint for Carol using the best one of these
>>        types.
>>
>>   The first seems more robust to me, if we have space for enough bytes.
>>   If we proliferate too many types, though, we'll need to do the second.
>
> The first seems more prone to partitioning worries to me. If different
> clients know how to handle different fingerprints, and the anonymous
> client tells us which fingerprints it knows how to handle, that could
> be bad news. Unless we're planning to just have Alice stick in all the
> blobs that she thinks are fingerprints, whether her Tor version knows
> how to read them or not? That could work.

We discussed how to handle multiple crypto protocols earlier this
year.  Each relay publishes an ordered list of the protocols it likes
for each protocol slot; the consensus contains a set of currently
approved protocols for each protocol slot; each client uses the first
protocol in the relay's list which (a) the client supports and (b) is
listed in the consensus as âapprovedâ, unless the user specifically
configures the client to use a custom set of protocols.  The
approved-protocol set in the consensus can both protect the anonymity
of clients which support new protocols and disable old protocols if
they break.


Robert Ransom
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev