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

George Kadianakis desnacked at riseup.net
Thu Nov 19 13:13:48 UTC 2015

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!


> (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

More information about the tor-dev mailing list