[tor-dev] Revisiting prop224 client authorization

[teor]

> On 3 Nov. 2016, at 04:45, David Goulet <dgoulet at ev0ke.net> wrote:
> 
> - I think "superencrypted" -> "super-encrypted" would be nicer as everything
>  in the descriptor as that separation of word. Or even "client-encrypted" if
>  we want to add extra semantic. No strong opinion apart from the "-" :).

client-encrypted could be very confusing.
It sounds like the client has encrypted it.

> - [XXX consider randomization of the value 16]
> 
>  If it's fixed, we basically create bucket so a client can know that there
>  are 0-16 clients or 16-32 clients and so on.
> 
>  If we randomize that value and let's say it's 7 then we have bucket of 7. If
>  that value is randomized _every_ new descriptor, we create multiple size of
>  buckets but over time someone could deduce (maybe) the low bound of clients
>  by observing all random values and thus assume there are 0-<low bound>.

Yes, this is true. And it would be quite easy over time, as hidden services
don't change their client auth that often. So you would just need to download
a descriptor every hour.

>  I'm uncertain here what's best but seems that in any case, bucketing is
>  happening as we pad with fake "auth-client". So I would assume here, out of
>  my head to be safe, that we might want _all_ services to kind of look the
>  same thus a fixed value would make sense following that train of thought.

Yes, buckets are the best.

State of the art is add random noise then bucket, but I don't think that's
needed here. And the noise would have to be large to hide an unchanging value.

T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
------------------------------------------------------------------------------