[RC5] FAQ rough draft (was: Client Documentation)
cedric at earthling.net
Wed Jan 21 01:47:50 EST 1998
Jim C. Nasby wrote:
> Ok, well, I'm not gonna wait to hear back from Bovine on this so I'll
> just use my unofficial authority as the unofficial volunteer
> to announce this... :)
> I'd like to get some volunteers for doing some documentation for the
> clients. Documentation that any half-wit could read and understand, so
> it would have to include some info on what d.net is, etc. It should
> step-by-step instructions for setting up the clients.
> I think that it would probably be best if there was one person who was
> in charge of the documentation effort, and several other people to
> out, especially with documenting differences between different
> (ie: the special -install and -uninstall commands for the WinNT
> and the Win95 Hidden clients).
> So, if you'd like to help document these clients, email me. Please let
> me know what machines you have access to (what clients you can
> document), and if you're willing to coordinate the documentation
Hmmm.. I used a few hours during my day off yesterday to go through most
of the email from this list we've gotten since the DES II clients came
out. I've put together the beginnings of a FAQ not just about the
clients, but some other topics that keep popping up from time to time.
Yes, there are holes, and some of the info may even be wrong, but it
should get you started. Do with it what you will.
================= Start of FAQ =========================
First. A couple of items you should be aware of that may not be
addressed by any of the individual questions below:
1) Always make sure you are using the absolute latest version of the
client. Clients can be upgraded frequently and the problem you are
experiencing may be fixed in the current release.
2) Buffer files from clients that predate the DESII project (v2.6x and
earlier) are NOT compatible with the post DESII project clients
(v2.7x). Unfortunately, you won't get a message from the client that
the buffer file is of the wrong vintage. Problems caused by using the
older buffer files are many and varied (not to mention extremely hard to
diagnose). Make ABSOLUTELY SURE you delete or otherwise remove your
older format buffer files before starting the v2.7+ clients.
Q: Why does the Win32 GUI client seem to freeze after calculating <x>
A: The window that holds the log output is limited to 32K. Once the
buffer fills up, the client appears to freeze, though it's just the GUI
window that's frozen. The client is still cracking keys. This has been
fixed in the latest versions of the client (* I think *). If you are
experiencing this problem you need to upgrade your client to the latest
Q: The Win32 GUI and NT Service clients don't seem to recover their
checkpoint files on startup.
A: Older non-command-line clients did suffer from this bug. It was
fixed as of version 2.6403.335
Q: The Win32 client seems to lose blocks when I reboot my machine --
even if I shutdown gracefully.
A: For some reason, the Win32 clients do not seem to recognize a system
shutdown as a signal to exit and therefore do not shut down gracefully.
In other words, they do not write their in-progress blocks back to the
in-buffer(s). The current workaround is to turn on checkpoint files.
Q: Can I have multiple clients accessing a single set of buff-in and
A: Yes, they are designed specifically with this in mind.
Q: Can I have multiple personal proxies accessing a single set of
buff-in and buff-out files?
A: NO! The personal proxy buffer files are images of what the proxy
holds in memory. If multiple proxies shared a single set of buffers,
the buffer files would be completely overwritten by the last proxy to do
a disk flush.
Q: Can I have multiple clients share checkpoint files?
A: NO! Checkpoint files are overwritten by each client without regard to
the contents of the checkpoint file already on disk (except at client
Q: Can I use my pre-DES client's (v2.64x) buffer files with the latest
A: NO! - The buffer files of the v2.7 clients (and DES-aware personal
proxies) are incompatible with previous versions' buffer files. You
should flush your output buffer and delete (or otherwise remove) your
2.6x buffer files before running the v2.7 clients. Failing to do so
will cause difficult-to-diagnose problems.
Q: Why is the Win32 GUI client slower than the command-line version?
A: The author doesn't know. But it IS generally agreed that the GUI
client is slower than the corresponding non-GUI client (at least in the
Q: I thought cracking DES keys was supposed to be much faster than
cracking RC5 keys. So why does it take as long or longer to crack a
block of DES keys?
A: For each key in a DES block, the client cracks the key AND its
compliment (a logical XOR of the primary key). This means that the DES
core is cracking twice as many keys as an RC5 block of the same size.
The reason is that it's apparently more efficient to check a key and its
complement in the same calculation rather than checking the two keys
Q: What's all this business with the block size (2^28, 2^29, 2^30,2^31)
of DES keys?
A: Just what the terminology suggests. The block size is the size of a
block of keys in terms of the number of keys in that block. Therefore,
a 2^28 block represents 2^28 keys (268435456). Keep in mind, however,
that the DES client would actually have to crack 2^29 keys in order to
complete this block (see previous question). All RC5 blocks are 2^28
keys in length. DES blocks are of variable size, presumably, so faster
clients don't have to buffer as many blocks as they might otherwise have
to do given the increased speed efficiency of cracking DES keys (versus
cracking RC5 keys).
Q: The number of keys in a block is wrong in the log file. A block size
of 2^28 is 268435456 keys, not 536870912 as reported in the log file.
A: This is not a bug. See the previous two questions.
Q: What about 2^32 sized DES blocks?
A: The first versions of the dual-core RC5/DES clients allowed you to
request blocks as large as 2^32 keys in size. Unfortunately, we
discovered there is some kind of bug which prevents the clients from
processing these blocks correctly. The latest clients (v2.7001.384 and
up) have been coded to disallow requesting block sizes greater than 2^32
keys, but you should still manually set your preferred block size to
between 28 and 31 just to be safe.
Q: My Win32 client seems to crack keys at a fair clip during the day,
but the rate drops through the floor overnight or at other times when
I'm away from the computer for long periods.
A: Your screensaver is probably kicking in and using up most of the
cycles that would have gone to your client. The screensaver runs at a
higher priority than the distributed.net client at all but the highest
niceness setting. The workaround is to choose a screensaver that uses
very little CPU time (like "blank") or no screen saver at all.
Q: What happens if I accidentally delete my input buffer or otherwise
"lose" some blocks that I am working on?
A: If we get to the end of the keyspace without finding the key that
unlocks the puzzle, the master keyserver will begin handing out keys
that were handed out before, but not returned. In other words, the
"lost" keys will be reincarnated and passed out again.
Q: I fetched too many blocks. Is there any way to return the
"unprocessed" blocks to the keyserver?
A: Not currently. If you must, for whatever reason, abandon your buffer
files, you can rest assured that you will not kill the project if the
*magic* key is in a block you threw away. (see previous question for
Q: When my client tries to connect to a keyserver I get "Network::Error
Read failed 6/0". What does that mean?
A: Specifically? We don't know. We've never been told exactly what the
numbers after a network error mean. In general, we can tell you that
the client had problems communicating with the keyserver (or personal
proxy). About the only recommendation we can make is to check all the
settings for the keyserver and other network communication parameters in
your INI file and make sure they are correct.
Q: How does the switch between DES and RC5 contests work?
A: According to one of the client coders:
If you configure DES as your preference, then... The client will
attempt to download DES blocks. If that fails, it will download RC5
blocks. If that fails, it will generate a random RC5 block.
Q: If I set my input buffer threshold higher than my output buffer
threshold (10:5 or somesuch), will the first blocks I retrieved stay at
the bottom of the buffer indefinitely?
A: Yes; unless the client is unable to replenish is supply of new
(unprocessed) blocks. In classical computer science terms, the input
buffer is LIFO (Last-In-First-Out) , meaning the blocks will be used in
REVERSE order of when they were retrieved.
Q: Why do I get only one DES thread running on my multiprocessor system?
A: The initial release of the DES core is not multithread safe. In
order to run multiple DES threads, you will currently have to run
multiple copies of the client. The programmers are working to get
around this limitation in a future release of the client.
Q: The new (v2.7) client crashes on my 386. What's up with that?
A: The original DES core contained an instruction that was illegal on a
386 chip. We first noticed it on the Linux clients which would crash
with the message "Illegal Instruction (core dumped)". This problem has
been fixed in the current (v2.7005) builds (possibly earlier).
Q: I seem to get pretty much the same DES cracking speed no matter which
CPU core I pick. Why is that?
A: The CPU core on Intel x86-architecture chips pertains to the RC5
cracking project only. Currently, there is only one DES core for all
Q: If the block size for the DES contest is variable, what size blocks
are the stats pages (http://desstats.distributed.net) measuring?
A: Stats use blocks normalized to a 2^28 block size. Thus if you turn
in a completed block of 2^29 keys, you get credit for TWO 2^28 blocks.
Blocks of 2^30 keys are worth FOUR 2^28 blocks, and so on.
Q: I'm having trouble getting my client to communicate through the
firewall. All my settings are correct.
A: Some people have been successful in working around firewall issues by
setting their preferred keyserver to a SPECIFIC keyserver rather than
the round-robin DNS entry. (URL of proxy-stats page that talks about
round-robin DNS entries goes here). If you want to do a manual lookup
on any DNS entry (like us.v27.distributed.net) you can do it via the web
Q: How do I get a Win32 client to start BEFORE the user logs in?
A: Start REGEDIT. Traverse the registry tree to
Add a new string value named "bovwin32". Edit the string and set its
value to the full path to the client (i.e. "c:\rc5des\rc5des.exe" or
whatever accurately reflects your installation). You may include in the
command line any options you wish to pass to the client (-hide, etc).
In most cases, running the client with the "-install" option will
accomplish the same thing, but it also adds the above mentioned string
value to the "Run" key (at the same level of RunServices in the
registry) as well as the RunServices key. The author is not sure what
the benefit of adding this second string value is.
Q: What is the difference between running the Win32 hidden client and
running the command-line client with the "-hide" option?
A: The command-line client (rc5des.exe) with the -hide option briefly
displays a DOS-box when starting in hidden mode. The hidden client
(rc5desh.exe) does not.
Q: I keep seeing references to an 'exitfile'. What is it and how does
A: By default, the client periodically checks its working directory for
the existence of a file called "exitnow.rc5". If the client finds this
file, it shuts itself down gracefully. Therefore, you can stop the
client by creating this file. The contents of this file do not matter;
the client is only checking to see whether or not it exists. Also, the
client will not delete this file when it exits, so you must remember to
delete it yourself before you run the client again.
Q: Will the "old" (v2.6x) clients still work with the current keyservers
and personal proxies?
A: Yes, the v2.6x clients can communicate with the current keyservers
and personal proxies. The reverse, however, is not true: The new
DES-aware clients do not work with the older (non-DES aware) personal
proxies. (I imagine they wouldn't work with any of the older keyservers
either, but as far as the author is aware, the keyservers were all
Q: Why does my personal proxy only fetches RC5 blocks, not DES blocks?
A: With older versions (pre-276 builds) of the personal proxy, you
needed to add "allowdes=1" on the tail end of the [des II] block in your
rc5desproxy.ini. This is no longer necessary with the latest personal
proxies (build 276 or later).
Q: What does the "MT" and "NON-MT" in some of the client names mean?
A: MultiThreaded. Basically this means that the client can split off a
separate thread to take care of network communications while the
"cracking" thread keeps working on keys. Without multithreading the
client has to stop cracking keys in order to communicate with a
keyserver (or personal proxy). You can benefit from a multithreaded
client even if you only have one processor, so you should only use the
non-mt client if you can't get the multithreaded client to work. In
general, Linux distributions with kernel versions above 2.0 will support
the MT client (run "uname -r" to find out which kernel version you are
running). Solaris has MT and NON-MT clients as well, but the author is
unaware of the system requirements needed to run the MT clients under
Q: Why do I keep getting network errors on the Alpha Linux client?
A: Apparently, the Alpha Linux clients have historically had problems
resolving DNS names. The solution is to pick a specific IP address of
one of the keyservers and set that as your preferred keyserver. This
problem existed as late as the early DESII clients (v2.7001.x), and may
continue to exist in the latest versions... anyone?
Q: Can I interchange my personal proxy's buffer files with my client's
A: No. The buffer file formats are incompatible.
Q: What's a "DESCHALL" client, and why do they only exist for non-Intel
A: The original code the programmers got for the DES core was
Intel-Pentium optimized assembly code. As such, it will run
(non-optimally) on any x86 architecture machine. Unfortunately, it
doesn't translate easily to other architectures. Enter DESCHALL -- an
effort put together to complete a previous DES challenge contest. From
what I gather, the original DESCHALL was similar to distributed.net in
that it used the distributed processing power of the participant's
machines to brute-force the correct key. Somehow, the powers-that-be
(within distributed.net) got a hold of the clients used in DESCHALL and
are distributing them in mostly unmodified form as a stopgap measure
until the DES cores for non-Intel chips can be completed. The
limitations of the DESCHALL clients (no buffering capabilities, etc.)
are a consequence of pulling this client out of the context of the
actual DESCHALL project for which it is written.
Q: The DESCHALL clients have a warning that they cannot be used outside
the U.S. and Canada. Is that warning still valid?
A: No. The message was put in there originally because the author (not
me -- the author of the readme within the DESCHALL clients) was unsure
of the legal status of the clients and wanted to err on the side of
caution. It has since been determined that it IS legal to export and
run these clients outside the U.S.
Q: How do I get the client/proxy to talk through a Microsoft proxy
A: According to one of our participants:
We have a MS Proxy server here and I managed to get RC5/DES running
Specify network settings as follows (CLI client):
9) Network Communication mode ==> 4
10) Preferred KeyServer Proxy ==> alde.com
(actually, any individual keyserver should work here, but alde.com
fine for me, us.v27.distributed.net will NOT work)
12) Local HTTP/SOCKS proxy address ==> <IP address of YOUR MSProxy
13) HTTP/SOCKS4 proxy port ==> <probably 80, look in IE settings if
sure (View, Options, Connection)>
Then enter your NT domain login and password under option 15. MS
server uses NT domain security for all its logging and access
Q: I've been cracking blocks for X hours (days), but my email address
doesn't show up in the stats!
A: First, stats are updated once every 24 hours at about midnight GMT.
What this means to you is that you may have to wait up to 24 hours after
a block is submitted before it shows up in the stats. Be patient.
Second, check the email address in your .INI files. The line "ID=" in
your client's .INI file should have your email address in it. Third,
any email addresses with the following characters in them = " , \ <
> will be considered invalid by the keyservers and get rewritten to
rc5 at distributed.net. Make sure your email address does NOT contain any
of the characters in that list or you will not get credit for your blocks.
Q: Would it help randomize things more if I changed the value of the
"randomprefix" parameter in my client's .INI file?
A: NO! Under no circumstances should you change this entry. This entry
will be changed by the client when it determines a need to do so. This
parameter is designed to maximize the efficiency of random block
generation over the lifetime of the project. Changing it yourself might
cause you to waste your own (or other's) cycles on duplicated random
Q: I think I submitted some of the same blocks more than once. Will
that mess up the stats?
A: No. The first person to submit a block as completed gets exactly one
credit for that block. No one (not even that same person) can get credit
for completing that block again. Duplicate blocks just waste bandwidth.
================= END of FAQ =========================
It's amazing what you can do with a whole day off. :->
* Cedric Tefft: Proto-Human, Reluctant Programmer *
* email: cedric at earthling.net *
* PGP FingerPrint: E114-CA05-E498-8A88-0762-79BB-A117-C59B *
To unsubcribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5