Tim Wilson-Brown - teor teor2345@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 keysThe 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)
On 7 Nov 2015, at 07:22, teor teor2345@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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev