NEXT CHALLENGE: plan of action?

[aba@dcs.exeter.ac.uk]

[First please moderate my previous couple of postings with the
knowledge that they may (if they even got out) have been hanging in
suspended animation for ~40 hours due to stuffed mail server, and some
things have changed since then.]

I've been out of things for a couple of days due to aforementioned
dead mailer.  All's well now (well it's croaking along passably
anyway).

Just posted a config file for Hals 2nd challenge, which Alex Tang
<altitude@cic.net> has kindly checked.

I read on Saturday Ian Goldbergs post about starting out on the
challenge using Damiens code.

It doesn't matter a great deal which code is used as such, but the
main thing is to ensure that this is a coordinated effort.  The aim of
the challenge (which I requested and Hal kindly provided just before
popping off for a week or so's holiday) was to see how fast a SSL
challenge could be broken.  Not how *soon*, note the distinction.

That means that if for instance we count the time that Ian has been
clocking up since Saturday, the real time will be slowed by approx 2
days.  We really need to do this with a starting-line like affair, so
that someone is running a server, and everyone gets the code compiled
etc, and then the server starts offering the challenge and all the
clients fire off.

That way we have a less straggly start up which makes for better
bruteing figures.

Agreed so far?


If so here's my ideas...


Use Andrew Roos client & Piete's socket server / WWW client for the
reason that this combination has been designed to operate both an
automated sockets master / slave system and offer manual key
allocation over WWW for those without direct connectivity, or behind
firewalls.

All of the software for this system is indexed from the URL:

	http://www.brute.cl.cam.ac.uk/brute/
or	ftp://ftp.brute.cl.cam.ac.uk/pub/brute/

The socket server running SKSP protocol (more ont he protocol later)
is at this address:

	sksp.brute.cl.cam.ac.uk 19957

(ie port no 19957)


The clients are setup to use this address by default in any case.  The
WWW based key doler is indexed from the WWW page above:

	http://www.brute.cl.cam.ac.uk/brute/

and this (transparently) interacts with the socket server also, so WWW
users can via a WWW forms interface take out keyspace to sweep, and
return the keyspace after sweeping.


The SKSP (Simple Key Searching Protocol) is described in an RFC like
document available here:

	http://www.brute.cl.cam.ac.uk/ftp/pub/brute/protocol.txt

for anyone wishing to write clients for other platforms, or with more
advanced features, or for those simply wishing to know what language
the client is talking.


Where to find things...

The brutessl software, the unix socket client, and the Windows NT
client are on:

	http://www.brute.cl.cam.ac.uk/brute/

Also I have put an untarred version of the brutessl code here:

	http://dcs.ex.ac.uk/~aba/brutessl/

(individual files untarred).

If and when people compile binaries for architectures which don't
typically come with compilers by default - such as DOS, OS/2, Macs,
I'll put any binaries sent to me in this directory, and / or send to
Piete for a pointer to this repository, or copying to brute.cl.


UNIX client.

How to use the unix client...  download brclient from the www page:

	http://www.brute.cl.cam.ac.uk/brute/

it is a perl program so you may have to edit the path to perl (the 1st
line of the program should be #!/full/path/to/perl/binary), and you
will have to mark it as executable.

You will also need a shell script called brloop which uses brclient.
It is on Piete's "sources" page, this page is indexed from the main
brute page above, here it is explicitly.

	http://www.brute.cl.cam.ac.uk/ftp/pub/brute/README.html

So get brloop.

Get and compile the brutessl.tar.gz file.

Run brloop.

The brclient perl socket client talks to a machine with a DNS:

	sksp.brute.cl.cam.ac.uk on port number 19957

At the moment the server is running and will ask your client to sleep,
as the challenge has not been started yet.  When Piete starts it up,
your client will periodically ask for work, before the start time
(Tue 12:00 GMT, or later time if this time is changed) your client
will just be told to sleep for a while, when it wakes up it will ask
for work again.  In this way the client can be left ticking over, when
work does arrive it will notice, as it will actually recieve some work
when it makes the request, and start doing it, and reporting back when
it finishes each chunk.

There is a windows NT socket client written by Andrew Brown, pointers
to that also.

Adam