On Mon, 16 Nov 2015 21:58:41 +0000 isis <isis@xxxxxxxxxxxxxx> wrote: > Hey Yawning, > > I'm generally in favour of merging this, but I'll wait a couple days > to see if anyone has any feedback. Particularly, I'd like to hear if > Nick has any comments. I talked to Nick about this, and now think that adding a line or two to each microdescriptor probably is less painful. So no need to merge this. > What new behaviour do we need from RELAY_EARLY? If I understood > prop#249 correctly, RELAY_EARLY should work as before (in particular > with 8-9 total RELAY_EARLYs allowed per circuit construction), but > that (potentially multipartite) EXTEND2(s) within RELAY_EARLY(s) > should contain variable length authentication data. Are you just > concerned that we'll go over the 8-9 cell limit and open ourselves > back up to infinite circuit attacks? Or am I missing something? Since this is an orthogonal issue... Until the changes that Nick added to #249 last night, RELAY_EARLY behavior was unspecified for fragmented EXTEND cells. The pedantic interpretation could have been "all fragments must be contained in RELAY_EARLY", which wouldn't let you build circuits consisting of more than 1 hop. Since only the first fragment needs to be in RELAY_EARLY now, there's no further issues. I'm gonna poke at some other things (in particular I'm multithreading the rest of our circuit build crypto) for a bit before I come back to this, but I have a rough idea of what I want our PQ options to look like. Regards, -- Yawning Angel
Attachment:
pgp6Mi488Y_Lq.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev