Re: SSL search attack

> 
> At 7:25 AM 9/1/95, Daniel R. Oelke wrote:
> >>
> >> I see nothing wrong with the concept of being allocated an initial chunk
> >> and having the scan software attempt to ACK it when 50% of it has been
> >> searched. A successful ACK would allow the releasing of a new chunk (in
> >> response) equal in size to the returned chunk. A failure of the Server to
> >> accept the ACK would trigger a retry at set intervals (such as 75% and 100%
> >> or 60/70/80/90/100%) until the Server responds. Thus the scanner is always
> >> in possession of a Full Sized Chuck to scan (so long as the Server accepts
> >> an ACK before the 100% done mark) and temporary failures will not stop the
> >> process of a scanner as currently happens.
> >>
> >
> >The only way this can work is if the server is told it is a 50%/75%/etc
> >size ACK, and then latter the server is ACKed for the full 100%.
> >
> >Why?  Because what happens if the client dies immediately after doing
> >the ACK - maybe only 51% of that space has been searched, yet
> >the server has already seen an ACK for it.
> 
> You NEVER claim to have searched space until you have actually done so.

That is exactly what I was arguing against - but the first sentance of what
I quoted was saying was ok.


> Assuming that you are multi-threaded--- Simply run two "workers" on the
> same machine. If there are delays in getting keys assigned, the two will
> soon get out of phase and keep the cpu busy.
> 

I kind of like that idea...

Dan
------------------------------------------------------------------
Dan Oelke                                  Alcatel Network Systems
droelke@aud.alcatel.com                             Richardson, TX

>>>> I see nothing wrong with the concept of being allocated an initial chunk
>>>> and having the scan software attempt to ACK it when 50% of it has been
>>>> searched. A successful ACK would allow the releasing of a new chunk (in
>> You NEVER claim to have searched space until you have actually done so. 
> That is exactly what I was arguing against - but the first sentance of what
> I quoted was saying was ok.

No -- If you ask for 2 segments, then when you are 50% done, it is OK to ACK 
the *FIRST* segment.

>> Assuming that you are multi-threaded--- Simply run two "workers" on the
>> same machine. If there are delays in getting keys assigned, the two will
>> soon get out of phase and keep the cpu busy.
> I kind of like that idea...

I thought of that, but:
1) for the same server load, it doubles the number of unACKed segments
2) if process A is lagging process B, then when process B finishes and is idle
   waiting for the server, process A will run faster and thus reduce the lag.
   This will make the processes drift into phase.
   I'm not convinced one way or the other.

> > > ACK ACK
 > > ACK
 > > > ACK
 > ACK


I've just kinda been watching this debate for a while, so I may well
have missed some of the more interesting details; if so, I apologize
for my noise in advance.

I work on a lot of commercial software under constraints of
scalability much like the SSL "attack server" being discussed here.
My instincts tell me that in this situation the whole process would be
*much* simpler if the basic idea of keeping the central server (or
the family of distributed servers in those models) completely
"informed" by all the attacking clients were abandoned.

Tim May's "random attack" idea was extremely attractive, I thought.
However, I think that it'd be possible to take advantage of the fact
that the keyspace itself is basically constant (until the keysize is
increased in the protocol under attack, of course).  I mean, 40 bits
is 40 bits.  Similarly, the capacity of most clients will be fairly
consistent.  (I have access (in theory, of course; don't mention this
to my management) (hi todd) to a hundred or so CPU's here, and that
doesn't really change too often.)

Rather than apportion the search space out dynamically on each attack,
why not simply allow attack clients to "subscribe" on a semi-permanent
basis?  All the server would have to do is make batches of ciphertext
available for cracking.  When a request comes in from a subscriber for
a copy of some ciphertext, the server knows (or at least can
legitimately suspect) that that subscriber's already-known keyspace
will be searched.

As far as getting acknowledgements of search completion, again the
server can by inference assume that (based on the prior establishment
of client capabilities) after a pre-determined period of time the key
sub-space will have been searched.  It might be appropriate for
clients to send back NACK messages, in case for example somebody shuts
down the client's network unexpectedly.  Assuming this goes pretty
smoothly one would hope that the number of failures would be
considerably smaller than the number of successs.

Again, ignore me if I'm blind to something obvious.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Nobody's going to listen to you if you just | Mike McNally (m5@tivoli.com) |
| stand there and flap your arms like a fish. | Tivoli Systems, Austin TX    |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Scott Brickner writes:
 > I think your assumption that available CPU is approximately constant
 > is incorrect.  Different participants have different constraints...

Hmm.  I suppose that's probably true for some more than others.
Again, hmm.

 > Also, the "subscription" process is somewhat discouraging to those
 > who participate for the prize.

Ah.  That looks like one of those little details that got by me.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Nobody's going to listen to you if you just | Mike McNally (m5@tivoli.com) |
| stand there and flap your arms like a fish. | Tivoli Systems, Austin TX    |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~