Re: [tor-bugs] #17254 [Tor]: Scalable HSes by splitting intro/rendezvous

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#17254: Scalable HSes by splitting intro/rendezvous
-------------------------+------------------------------------
 Reporter:  TvdW         |          Owner:
     Type:  enhancement  |         Status:  needs_revision
 Priority:  Medium       |      Milestone:  Tor: 0.2.8.x-final
Component:  Tor          |        Version:
 Severity:  Normal       |     Resolution:
 Keywords:  tor-hs       |  Actual Points:
Parent ID:               |         Points:  medium
  Sponsor:  SponsorR     |
-------------------------+------------------------------------
Changes (by asn):

 * cc: special (added)


Comment:

 Replying to [comment:11 teor]:
 > Replying to [comment:8 nickm]:
 > > Comments on the spec branch:
 > >    * I really don't like sending private keys around like this.  Is
 there any way to avoid it?
 >
 > I discussed an alternative design with TvdW, where the introduction side
 decrypts the blob using the introduction key, then hands off the decrypted
 fields to the rendezvous side. This avoids sending the key, so if the
 decrypted fields are exposed, only that rendezvous is affected. The
 tradeoff is increased decryption load on the introduction side.
 >
 > I think this change is worth it for the security improvement.

 It seems to me that if this new design goes forward, the feature will be
 almost equivalent to what #16059 needs for the "rendezvous approver" API.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17254#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs