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

[Tim Wilson-Brown - teor]

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 at riseup.net> wrote:
> 
> Tim Wilson-Brown - teor <teor2345 at gmail.com <mailto: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!

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

[0]: https://lists.torproject.org/pipermail/tor-dev/2015-November/009954.html

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151120/bd0fbbf2/attachment-0001.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/20151120/bd0fbbf2/attachment-0001.sig>