Re: SSL search attacks
-----BEGIN PGP SIGNED MESSAGE----- Scott Brickner <sjb@austin.ibm.com> writes:
don@cs.byu.edu writes
A random (instead of sequential) allocation _by the keyserver_ (out of unallocated piecemeal segments) would also take some work to implement.
The problem is that it's irrelevant to the problem. Random allocation at the server is equivalent to simply "shuffling" the segments before assignment, which doesn't affect the rate at which the space is searched.
The point is that if J. Random Badguy knows that the key lies in segment 0x1bad and wants to get this segment and send a false NAK for it, he can watch as key segments are doled out (perhaps with clients running on a number of machines) and when 0x1bad gets close, say, when 0x1b0b comes out, he can instruct all his clients to start hammering the server for all they're worth in an attempt to get the key segment assigned to one of his clients. If the segments are shuffled before they are handed out then this attack becomes impossible, since the attacker has no way of knowing when segment 0x1bad will be handed out. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMERDPxEcrOJethBVAQG60gP9HsuCd+jID0nyESfXDCNtSwwRuRZ39rkg SIEpltxzwMfHMQ/RD8CD5UmAHIm1EdvsztjbB5M5KnqjPKCMfw42leKhhcBBxUma FCKN3vm4MBs+5vgM8SDeHLbn84rYxn5xijbktRdi+G/MzfAJdjmo5nUPQiWWhLn/ JyWa9rpNHxQ= =9tcN -----END PGP SIGNATURE----- -- David R. Conrad, ab411@detroit.freenet.org, http://www.grfn.org/~conrad Finger conrad@grfn.org for PGP 2.6 public key; it's also on my home page Key fingerprint = 33 12 BC 77 48 81 99 A5 D8 9C 43 16 3C 37 0B 50 Jerry Garcia, August 1, 1942 - August 9, 1995. Requiescat in pace.
David R. Conrad writes
Scott Brickner <sjb@austin.ibm.com> writes:
don@cs.byu.edu writes
A random (instead of sequential) allocation _by the keyserver_ (out of unallocated piecemeal segments) would also take some work to implement.
The problem is that it's irrelevant to the problem. Random allocation at the server is equivalent to simply "shuffling" the segments before assignment, which doesn't affect the rate at which the space is searched.
The point is that if J. Random Badguy knows that the key lies in segment 0x1bad and wants to get this segment and send a false NAK for it, he can watch as key segments are doled out (perhaps with clients running on a number of machines) and when 0x1bad gets close, say, when 0x1b0b comes out, he can instruct all his clients to start hammering the server for all they're worth in an attempt to get the key segment assigned to one of his clients.
If the segments are shuffled before they are handed out then this attack becomes impossible, since the attacker has no way of knowing when segment 0x1bad will be handed out.
An excellent point. One I'd missed. I agree that a random shuffle of segments is appropriate.
participants (2)
-
ab411＠detroit.freenet.org -
Scott Brickner