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

[Tim Wilson-Brown - teor]

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.

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151118/39fa03e4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151118/39fa03e4/attachment.sig>