[tor-dev] DoS resistance for Next-Generation Onion Services

[George Kadianakis]

Tim Wilson-Brown - teor <teor2345 at gmail.com> writes:

> Hi All,
>
> prop224 salts the encrypted portion of each descriptor with a random value.
> If we use the same "salt" for every replica/spread, the encrypted portions of the descriptor will be identical.
> (In the spec, it looks like the same encrypted descriptor / salt is used for each replica / spread, but it's not explicit.)
>
> I can't think of an attack based on matching up the encrypted portions of descriptors.
> But I like the idea of making the blinded key and encrypted portion of every descriptor different, so there's no way to tell if they're from the same service or not.
>
> Then there would be no way of telling whether replica/spread descriptors were from the same hidden service, which I think is a useful property.
>

You are suggesting we should use a different salt for each descriptor we push?

Sounds reasonable, with a small cost on implementation complexity since now we
will have to generate N different descriptors and push them properly to the
right HSDirs. Plausible.

If you send a patch for the proposal, I will merge!

Thanks!

> (Unless you can decrypt them, and therefore you'd likely know the key, or could
> match up the introduction points. Even then, the service might be using a load
> balancing technique that puts different intro points in each descriptor, like
> OnionBalance; or posting multiple descriptors with the same key, like the Tor:
> Hidden Service Scaling paper.[0])
>
> The relevant portion of the proposal is:
>>    The encrypted part of the hidden service descriptor is encrypted and
>>    authenticated with symmetric keys generated as follows:
>> 
>>        salt = 16 random bytes
>> 
>>        secret_input = blinded_public_key | subcredential |
>>              INT_4(revision_counter)
>>        keys = KDF(secret_input, salt, "hsdir-encrypted-data",
>>                   S_KEY_LEN + S_IV_LEN + MAC_KEY_LEN)
>> 
>>        SECRET_KEY = first S_KEY_LEN bytes of keys
>>        SECRET_IV  = next S_IV_LEN bytes of keys
>>        MAC_KEY    = last MAC_KEY_LEN bytes of keys
>> 
>>    The encrypted data has the format:
>> 
>>        SALT       (random bytes from above)       [16 bytes]
>>        ENCRYPTED  The plaintext encrypted with S  [variable]
>>        MAC        MAC of both above fields        [32 bytes]
>
> Tim
>
> Tim Wilson-Brown (teor)
>
> [0]: https://www.benthamsgaze.org/wp-content/uploads/2015/11/sucu-torscaling.pdf
>
>
>> On 7 Nov 2015, at 07:22, teor <teor2345 at gmail.com> wrote:
>> 
>> Hi all,
>> 
>> I think we can make next-generation onion (hidden) services (proposal #224) more resilient against certain kinds of DoS / client discovery attacks, by using a different blinded public key for each HSDir.
>> 
>> Attack Summary:
>> 
>> Once a malicious HSDir receives a descriptor, it can locate other HSDirs with
>> that descriptor's blinded public key. It doesn't need to know the onion
>> service address or decrypt the descriptor. Each descriptor contains the
>> blinded public key:
>> 
>>> ...
>
>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev