In order to establish an end-to-end crypto channel on a rendezvous circuit, we need a new API that setups the crypt_path_t object on the circuit from the key material computed between the client and service. This API has to be for both service and client side.
Because the service implementation in legacy/trac#20657 (moved) is being done before client, setting parent ID to that ticket.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items 0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items 0
Link issues together to show that they're related.
Learn more.
If we can make it happen before 032, great, else no biggy. Changing parent ticket to the "prop224 groundwork" ticket since this is needed by legacy/trac#20657 (moved) and can be merged safely upstream without affecting tor.
Moving this to 0.3.2 milestone since it requires all the hs_ident stuff that are gonna be merged in 0.3.2 . If we wanted to merge stuff earlier, we could split the branch into a 0.3.1 branch that only does legacy stuff, and then merge the 0.3.2 stuff later.
Trac: Milestone: Tor: 0.3.1.x-final to Tor: 0.3.2.x-final Status: assigned to needs_review
This branch contains basically two things. It adds hidden service identifiers (hs_ident.{c|h}) which is the new and improved rend_data concept. Then, it introduces an API/ABI for the e2e encryption of client<->service.