[tor-dev] DoS resistance for Next-Generation Onion Services
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.)
> 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 |
>> 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 Wilson-Brown (teor)
> : 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
More information about the tor-dev