On Sun, 08 May 2016 02:00:51 +0200 Jeff Burdges <burdges@xxxxxxxxxx> 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
Attachment:
pgpTpQ7tAWMQ0.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev