yabc

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


Hi.

I'm writing a replacement for brloop/brclient in perl, one with full
SKSP compatibiliy, and one which is easily extensible and more
straightforward than the original br* code...

What would be some useful features to include in the code?  I'm
attempting to make it more friendly, more "intelligent", etc -- the
whole shebang.  It would be reasonably easy to, as someone here
suggested, have the program start the keyfetch process before the last
key segment finished, or whatever -- the question is, is that worth
it?  I'm also including code to make it possible for the user to
specify how much time she wants to give the search, etc...  It should
be possible to include code for a very simple sort of farming setup
(at least something to allow easy remote launches of the brute code)..

Would all this be useful to other people?  What features would make it
more so?

Also, it seems that there have been some "extensions" to the SKSP
protocol...  For instance, suddenly there are different machines
dedicated just to ACKs, etc.  Is there a central repository of these
changes?  (Have these changes even been publicly reviewed?)

(the program, in case you couldn't deduce it from the title of this
message is to be "yabc" - yet another brute* client.  oh how so clever
and original, no?)

- -sq

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAwUBMEVHLlIP+Y8TPTdtAQHUowQAxVPVlw9WCw8wzSib8HgEitikLs459/rv
zfuSV60L/7eyePb3ah/xVDWvsub/3Alru7PfgmdSssaZe3RX1Ory0xbLXoB8lXTw
2KeGb18ogRkL/2ALfA85rgAycQ6NxY4o+u/oQxY0WVlukWU+WG71bXjVRyh+YEDd
AEKBnx6/uO8=
=TK/a
-----END PGP SIGNATURE-----

On Wed, 30 Aug 1995, Sam Quigley wrote:
 
> Also, it seems that there have been some "extensions" to the SKSP
> protocol...  For instance, suddenly there are different machines
> dedicated just to ACKs, etc.  Is there a central repository of these
> changes?  (Have these changes even been publicly reviewed?)

These aren't changes to the protocol, which just defines what a client and
a server should understand.  The "local" servers that only do ACKs are
designed to collect up reponses from a local client farm and then feed
them en-masse to the central server, using SKSP.

To answer your second point, there are ideas being floated around between 
Adam, Piete and myself as to the "next step".

I had the idea that the load on the central server might be reduced by
having a system where clients register their availability times, PGP key
and computing horsepower to the server, and the server calls the client at
the start of an available period and hands it a keyspace that fills the
time available.  PGP signatures on all exchanges would authenticate the
parties and it would be impossible for large keyspaces to be requested in
error or malicously.  Un-ack'd keyspaces would wrap around.  This idea
needs quite a bit more coding and people have expressed reservations about
just how much load would be saved.

On the other hand, Piete has a proposal that also uses PGP signatures and
retains the existing protocol.  The central server would remain as is, but
would only accept ACKs from servers that it trusted via a signed PGP key. 
There would be a small number of such second level servers, perhaps one in
each country.  This hierarchy of trust extends downwards as far as is
necessary in each country with clients being at the leaf nodes of the
tree.  This method spreads the load worldwide in a very effective manner,
with the final central server only receiving calls from a handful of other
servers.  This idea needs less coding than mine and solves the immediate
problem. 

We're still talking, and listening...


- Andy

+-------------------------------------------------------------------------+
| Andrew Brown  Internet <asb@nexor.co.uk>  Telephone +44 115 952 0585    |
| PGP (2048/9611055D): 69 AA EF 72 80 7A 63 3A  C0 1F 9F 66 64 02 4C 88   |
+-------------------------------------------------------------------------+