[tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

Nima Fatemi nima at torproject.org
Sat Nov 19 21:20:00 UTC 2016


> - I feel that the max settings imposed by the 50k max size limit, will satisfy
>   most crazy hidden service use cases that someone might have wrt scalability
>   or number of authed clients. It can support up to 350 authed clients, and 20
>   intro points. We should increase the max size limit, if we want to support
>   more advanced use cases.
> 
> - I also feel the configurations that fit in the default descriptor (of 10k
>   bytes blob) will probably satisfy most hidden service use cases out there as
>   it can support up to 80 authed clients, and up to 11 intro points.  The
>   anonymity set of those hidden services descriptors will be good wrt snooping HSDirs
> 
> - Giant hidden service descriptors will stand out and their anonymity set will
>   likely be small. I think such giant hidden services should perhaps split
>   their info to multiple descriptors using some sort of stealth-auth mechanism
>   (where they give different onion address to different clients).
>   Alternatively, we should change our padding rules, or always pad to max
>   descriptor size.

I understand what I'm saying below might be a bit far fetched but while
we're brainstorming on things, I thought I'd just throw this out...

I think it would be interesting to see things like onion-balance get
integrated into this setup at some point in the long run, so if there's
a giant onion service, it would automatically scale after a certain
amount of clients or requests. I haven't thought much about how it can
work in auth mechanism but I find it an interesting subject to think
about. Specially if we want to mainstream the heavy use of onion services.

Kudos for working on such important properties of Tor.

Cheers,
-- 
Nima
0X58C4B928A3E218F6 | @mrphs

"I disapprove of what you say, but I will defend to the death your right
to say it" --Evelyn Beatrice Hall

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161119/3edbfadb/attachment.sig>


More information about the tor-dev mailing list