Description

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 #20657 is being done before client, setting parent ID to that ticket.

Child Tickets

Oldest firstNewest firstThreaded

Show commentsShow property changes

Change History (11)

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 #20657 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.

This is a big piece of groundwork for prop224 service implementation #20657.

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.