-----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 | +-------------------------------------------------------------------------+
participants (2)
-
Andy Brown -
Sam Quigley