Tim Wilson-Brown - teor <teor2...@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 <teor2...@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 _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
