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

[Yawning Angel]

On Sun, 08 May 2016 02:00:51 +0200
Jeff Burdges <burdges at gnunet.org> wrote:

> On Sat, 2016-05-07 at 22:01 +0000, Yawning Angel wrote:
> > how an adversary will be limited to just this information, and not
> > things that enable a strong attack on it's own like packet timing
> > escapes me  
> 
> Yes, it's clear that an adversary who can get CPU timing can get
> packet timing.  
> 
> It's not clear if some adversary might prefer information about the
> seed to simplify their larger infrastructure, like say by not needing
> to worry about clock skew on their exit nodes, or even choosing to
> compromise exit nodes soon after the fact. 

The ultimate simplification would be "snoop the loopback interface and
see all the cleartext instead of messing with this timing attack
nonsense". :P

> > Hmm?  The timing information that's available to a local attacker
> > would be the total time taken for `a` generation.  
> 
> Really?  I know nothing about the limits of timing attacks.  I just
> naively imagined they learn from the timing of CPU work vs memory
> writes or something. 

What's there to derive key generation timing information from that
isn't "observe traffic to the SocksPort, along with traffic upstream
and compare times".  There might be better ways, that somehow don't
involve totally pwning the box, but it's not immediately obvious to me.

If we're going to talk about improving `a` generation overall, rejecting
samples only if they are > 5 * q (and using `% q` per sample) is
probably a net win since it lowers the rejection rate by a factor of
~4x...

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/20160508/3df68d98/attachment.sig>