Re: SSL search attack

-----BEGIN PGP SIGNED MESSAGE-----

From: Scott Brickner <sjb@austin.ibm.com>
>>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.

Problem is, though, if *each* segment is shuffled, or shuffled in groups
of 10 or 25 or 50 or what? brutessl is designed for sequential search
through a block of segments. I was pulling down blocks of up to 40 segments 
each, for each machine I was running. Of course, with brloop running I
won't be in such a bind (I have yet to see that it really works though..)
but still it also represents a coding problem as to handing out sequential
segments within shuffled blocks.

Hey, by the way Piete, is there gonna be a ego list (rankings) like there
was with the RC4? 

Don

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBMETbAMLa+QKZS485AQFU7QL/WTljlZyetr0x+L9eBJnrYUNNY1BHfTJn
C83wiJgPO5cpR6b/Vn8hYPnMRXnEhaxRJ062TcRitdngsUND1W+6d04Ph1gg/Qj8
US6FtoP+Yk9BhcYlYfogh3YSOxcgIvbu
=UiWq
-----END PGP SIGNATURE-----
<don@cs.byu.edu>           fRee cRyPTo!   jOin the hUnt or BE tHe PrEY
PGP key - http://bert.cs.byu.edu/~don     or PubKey servers (0x994b8f39)
  June 7&14, 1995: 1st amendment repealed.  Death threats ALWAYS pgp signed
* This user insured by the Smith, Wesson, & Zimmermann insurance company *

don@cs.byu.edu writes
>From: Scott Brickner <sjb@austin.ibm.com>
>>>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.
>
>Problem is, though, if *each* segment is shuffled, or shuffled in groups
>of 10 or 25 or 50 or what? brutessl is designed for sequential search
>through a block of segments. I was pulling down blocks of up to 40 segments 
>each, for each machine I was running. Of course, with brloop running I
>won't be in such a bind (I have yet to see that it really works though..)
>but still it also represents a coding problem as to handing out sequential
>segments within shuffled blocks.

Well, the only real issue is that the requestor *not* be able to
reliably predict which segments will be assigned.  The server may adopt
a strategy of picking a random block of segments for each request.
This introduces a certain amount of fragmentation into the process, but
there are strategies to minimize this.  It may be enough to break up
keyspace into, say, 32 "regions", and fill requests sequentially, but
from a randomly selected region.

> Problem is, though, if *each* segment is shuffled, or shuffled in groups
> of 10 or 25 or 50 or what? brutessl is designed for sequential search
> through a block of segments. I was pulling down blocks of up to 40 segments 
> each, for each machine I was running. Of course, with brloop running I
> won't be in such a bind (I have yet to see that it really works though..)
> but still it also represents a coding problem as to handing out sequential
> segments within shuffled blocks.

My view is that IFF this becomes a problem, I'll do something to fix it.
I can do it in the server (under my control) after a complete scan has been
completed without finding the key.

It may mean you only get smaller blocks, but IFF we get that far, tough !

> Hey, by the way Piete, is there gonna be a ego list (rankings) like there
> was with the RC4? 

Err -- look on http://www.brute.cl.cam.ac.uk/brute/ -- follow CRACKED and then
look at:

	Credits are available as plain text and as a table (needs a browser
	which supports tables !).

"plain text" is <PRE> while "table" needs a fancy browser.


PS: I am working on beloop and brclient still, based on comments.
    brclient now uses early binding on the project, reducing traffic.
    brloop now has -h and -i flags, and a "-a" flag to create a .brloop.rc
    If allowed, it will log allocated and ACKed keys
    I have a "Local CPU Farm" slave server available
    Kevin <kwang@blackbox.punk.net> is working on a central server to "rsh"
	work to local CPUs.
    I am against pre-fetching of the next chunk, as I believe it should not be
	necessary (I'll review that after Hal3) and it tends to increase NOACKs


BTW: you make the 1% (of the TOTAL keyspace) cut :-)

              Credits for the CRACK of Hal's Second Challenge (plain) (p1 of 3)

            CREDITS FOR THE CRACK OF HAL'S SECOND CHALLENGE (PLAIN)

   Note that thet %age is the percentage of the complete address space.

   This data is also available as a table for users with a suitable
   browser.

%age  ACKs NoAs ACK/n ID
===== ==== ==== ===== ======================
8.498 5569 1572 0.780 jshekter@alias.com
2.182 1430  454 0.759 pjw@dcs.ed.ac.uk
1.892 1240    8 0.994 jelson@jhu.edu
1.587 1040  386 0.729 martin@mrrl.lut.ac.uk
1.437  942  412 0.696 bal@mit.edu
1.375  901    0 1.000 rkel02@cs.auckland.ac.nz
1.367  896   51 0.946 nathanw@mit.edu
1.294  848  567 0.599 cwe@it.kth.se
1.083  710  879 0.447 floeff@mathematik.uni-stuttgart.de
1.044  684   42 0.942 aba@dcs.ex.ac.uk
1.025  672    0 1.000 bande@lut.fi
1.003  657  214 0.754 don@cs.byu.edu
0.891  584  254 0.697 droelke@aud.alcatel.com