**** Anyone participating in the SSL Challenge who has logs of their searches **** please ensure you read "What to do if you have logs" below ** Anyone who is running a brclient earlier than 0.14 or a brloop earlier ** than 0.05 please ensure you read "current requirements"

Live and/or learn

The purpose of this project was the latetr ...

-- looks like the performance is a little better now that they're handing out bigger chunks.

That is just one of the tweaks I made ...

The important thing is to learn something new each time so the next one goes more smoothly.

Indeed -- the current project is a merge of three I had planned ...

Should be nicer with hierarchical servers and so on for the next challenge... DES or lobotomized DES or whatever.

Yeah .... :-) This project arose from the "failed" rc4-40 attempt. Personally I think it worked -- it showed that it was possible to scan a 40 bit address space performing the kind of manipulations needed for brute force attacks. The WWW interface was a pain as it required users to do something, so the norm was to allocate large chunks, etc. Also collating the results was a nightmare ! So we decided that cutting the people out would be a good idea all round. We bolted it all together, and it seemed kind of OK. The plan was then to pass it round a wider audience to check that it ported to other systems and environments, and once it was shown to bsasically work, see how it stood up to heavy usage. Finally we could let it rip & see what it could do. Unfortunately, due to various external pressures, we have ended up rolling all these three into one. It has made it a lot messier than I would have hoped, for which I apologise to you all. rc4-40 had shown that 40bit address spaces could be scanned. hal1 slipped through our fingers, and showed somewhat more than we had planned, i.e. that actual code could be broken by a *single* person (this sounds more impressive, but is technically easier !). We asked for hal2 and hal3 to "check it works" and "watch it zip" repectively. Before he left, Hal gave us hal2, so we combined the two remaining stages. SO: this project is: 1) to shake down the code on different systems 2) to see how it works under real load 3) to see how quickly a 40bit address space can be scanned. Again I apologise to you all that (1) has been non-trivial and that (2) has had unpleasant effects of (1). I think next time we may be ready for (3) ... I was going to summarise some of the lessons so far, but things are getting congested again, so I shall send out this PLEA to ensure recent code is used !! current requirements ==================== PLEASE ensure that you are using a brclient of at least 0.14 ("grep comment.inffo brclient" to discover what you are using) You can updare brclient while brloop is running. Some people are still running old versions, and this is hammering the server. It also helps to run at least brloop 0.05 ("grep BRLOOPCOMMENT brloop"). What to do if you have logs =========================== During the early part of the project, the server was highly congested, and I fear that many ACKs may have been lost :-( If you have logs of the searches your machine(s) did, it would be useful to check that all ACKs got through. Look at the stats page http://www.brute.cl.cam.ac.uk/cgi-bin/brute?op=stats (or something like http://www.brute.cl.cam.ac.uk/cgi-bin/brute?op=stats&project=&proj=2977+Hal%27s +second+challenge&substring=YourID&patt=unacknowledged but with YourID repleaced by the ID ypou use) and look for all the NOACKs. e.g: 008f NOACK 008f 1 Piete Brooks <pb@cl.cam.ac.uk> See if there is a corresponding entry in your logs grep -h '2977 [0-9a-f]* 008f [0-9]* [n0-9a-f][o0-9a-f]' and if so, ACK it brclient -Ltssl -a'2977 2a07 008f 1 no' [ If your a HACKer, you can automate it, as in lynx -dump 'http://www.brute.cl.cam.ac.uk/cgi-bin/brute?op=stats&project=&proj =2977+Hal%27s+second+challenge&substring=Piete.Brooks&patt=unacknowledged' | grep ' NOACK ' | while read a b; do grep -h '2977 [0-9a-f]* '$a' [0-9]* [n0-9a-f][o0-9a-f]' ~/BR-*; done | while read a; do brclient -Ltssl -a"$a"; done of the like .... ]

Server timing problem: Goodbye unknown -- you have been timed out which I assume is a message from the server telling me it's too loaded,

No -- it means that you were taking too long to respond, so it timed you out.

No input when expecting an ACK line which sound even worst... I've been having trouble getting keys all the afternoon now, what a pity.

brclient -k failed to get any keys, so brutessl didn't generate any output, so brclient -A didn't get any input :-( Latest brloop should avoid this by not calling brutessl if brclient -k failed and also not calling brclient -A if brutessl didn't run / failed.

BTW, the versions I'm running now are brloop 0.05 and brclient 0.16 and since I'm in Cambridgeshire-UK too, with a 2Mbps link, I doubt that the timeout is due to congestion on the net.

Well, the problem with brclient 0.16 was that a "go faster" stripe made it go *too* fast if local, perl losses data, so it times out :-((

Any suggestions? Or is it only the overload in the server that's giving me nightmares?

Kind of -- slow clients hogging the single threaded (idle) server :-((

1) Abandon the central command way of doing things. Little if any communication is required for this computation, it should be self-distributing to and between volenteer sites. That makes it ideal for implementation as a safe virus.

I need some hints as to what the above means, but combined with (3) it becomes trivial ...

2) Give these computations a defined and limited lifetime. The problem you have with old versions is because they don't die automatically or even check to see if they are up-to-date and update themselves.

You want self updating code running on *your* system ??? What do you mean by "safe virus" ??

3) Use randomness to break up the search space and redundantly perform the computation. This should eliminate the problems with malicious key-space requests, etc.

If you take this step, you can chuck SKSP altogether. All that is needed is some way to tell the virus to stop when teh answer has been found -- or would you not bother with that ? If random searching were permitted, that would indeed be the way to go.

4) Use feedback in the form of selective survival/replication to optimize the search and allocate search space. If a processor goes quickly, give it more to do - if it goes slowly, give it less.

I'm lost -- if thee search is random, you kusst let it run !

This will produce an overall system that adapts with time to the cahges in network and system usage so as to optimize overall performance as a function of time.

Eh ? With random searching you just run it on all machines you can ! No adaptation, jusst brute CPU cycles .... Have I missed something ??