1995-08-30 - Re: SSL search attacks

Header Data

From: Scott Brickner <sjb@austin.ibm.com>
To: ab411@detroit.freenet.org
Message Hash: 4c28df112dab9ebc356a38e4e8ab3e503ea65fff6ffb1b4ad47d5390ab5226d9
Message ID: <9508301813.AA12150@ozymandias.austin.ibm.com>
Reply To: <199508301056.GAA26657@detroit.freenet.org>
UTC Datetime: 1995-08-30 18:14:55 UTC
Raw Date: Wed, 30 Aug 95 11:14:55 PDT

Raw message

From: Scott Brickner <sjb@austin.ibm.com>
Date: Wed, 30 Aug 95 11:14:55 PDT
To: ab411@detroit.freenet.org
Subject: Re: SSL search attacks
In-Reply-To: <199508301056.GAA26657@detroit.freenet.org>
Message-ID: <9508301813.AA12150@ozymandias.austin.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain


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.





Thread