[tor-dev] Proposal: Link Cryptographic Agility

Yawning Angel yawning at schwanenlied.me
Mon Nov 16 22:31:45 UTC 2015


On Mon, 16 Nov 2015 21:58:41 +0000
isis <isis at torproject.org> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151116/100b72b2/attachment.sig>


More information about the tor-dev mailing list