On Thu, 12 May 2016 14:18:41 +0200 Jeff Burdges <burdges@xxxxxxxxxx> wrote: > On Thu, 2016-05-12 at 11:17 +0000, Yawning Angel wrote: > > Well, if we move the handshake identifier inside the AE(AD) > > envelope, we can also add padding to normalize the handshake length > > at minimal extra CPU cost by adding a length field and some padding > > inside as well. > > > > It would remove some of the advantages of using algorithms with > > shorter > > keys (since it would result in more traffic on the wire than > > otherwise would have been), but handshakes will be > > indistinguishable to anyone but space aliens and the final > > destinations... > > Is that even beneficial though? Padding the handshake out for the number of cells? Maybe? I'm not entirely convinced here either way, just highlighting it as an option. > If we choose our post-quantum algorithm randomly from New Hope and > SIDH, and add random delays, then maybe an adversary has less > information about when a circuit build is progressing to the next > hop, or when it's actually being used? Dunno. I need to re-benchmark product form NTRU but I think it's in the same ballpark as newhope (May be faster, but the differential isn't totally ridiculous as anything compared to SIDH is). I don't think SIDH is really something to worry about now anyway... having both NTRUEncrypt and newhope as options for the first pass should be sufficient, and the bulk of the code required to do this is the infrastructure work for modular/large handshakes anyway (Once we support at least one PQ algorithm, adding others is relatively easy). > Is there some long delay between circuit build and first use that > makes anything done to obscure build useless? We pre-build circuits, but the telescoping extension process and opportunistic data both mean that circuits see "traffic" near-immediately in most cases (everyone but the exit will see the traffic of handshaking to further hops, the exit sees opportunistic data in some cases). Regards, -- Yawning Angel
Attachment:
pgpWqE3mPnuNn.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev