[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

Hi George,

Please see below for a spec patch covering this email thread and various issues discussed on Trac and tor-dev@

On 20 Nov 2015, at 00:13, George Kadianakis <desnacked@xxxxxxxxxx> wrote:

Tim Wilson-Brown - teor <teor2345@xxxxxxxxx> 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!

I've created a branch rend-ng-descriptors on https://github.com/teor2345/torspec.git

It addresses the issues I've mentioned in this email trail, tickets #17239 and #17242, and the raw random value leakage issue mentioned by Jacob in [0].

A full list of changes is:
* add a comment that prop252 wants to add extend-info to the descriptor (perhaps it will need more padding)
* add distinguishing values to every hash
* hash raw random bytes before use
* deal with replica hashing collisions
* randomise revision-counter to avoid information leaks
* use a different salt for each replica and upload
* avoid replicas with the same blinded key

They are in approximate order of complexity / impact.

Please feel free to ask me questions about any of these changes.
(And please to cherry-pick as needed.)

Tim


Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev