[tor-dev] [proposal] Post-Quantum Secure Hybrid Handshake Based on NewHope

[Yawning Angel]

On Thu, 12 May 2016 14:18:41 +0200
Jeff Burdges <burdges at gnunet.org> 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
-------------- 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/20160512/a27099fd/attachment.sig>