The RC5 Team Warped Page

From OS2World.Com Wiki
Jump to navigation Jump to search

By Colin Hildinger

Note: The Key was found on 12-Aug-2002

This page is devoted to using OS/2 to help with the brute force attacks on the RC5-64-bit RSA Secret-Key Challenge. And, while we want to rally all the OS/2 systems we can, you can also throw any other supported systems our way.

Why am I doing this page? I want an OS/2 RC5 client to break the code. I think it would be cool to get some publicity from doing it. We also are trying to make the OS/2 team one of the top teams in the "standings" at both sites because it will get some attention for the fact that, yes, quite a few people do use our really cool operating sytem. This has been successful so far, and I've discussed OS/2 with quite a few people in #RC5 who are very interested to know that OS/2 is alive and well.

Who should join the effort? Anyone who has a computer that is connected or can be connected to the Internet at any time during the week. The newest Bovine client allows you to download 1000 blocks of 2^31 keys at one time (at least a full month's worth for any PC), thus diminishing the amount of time online required for us dialup users.

What are we doing again? We are attempting a brute force crack of a 64-bit RC5 ecrypted message. Skip Huffman posted a great explaination to the RC5/2 mailing list:

  • Imagine that you are Indiana Jones and are trying to open the padlock protecting the relic. Now, you could just shoot the lock off, but being a Good Guy you decide to do it the hard way.
  • You know that the Nazis have just had every possible key for this brand of lock loaded into several large freighters that just happen to be passing by. Well, you manage to highjack the freighters, hundreds of them, and dump the keys in a huge stack by the lock. Now you are going to try each and every one in the lock until it opens.
Why should you join the effort?
  • 64-bit encryption isn't good enough. 80 bit or higher should be the standard. If we can prove that a group of folks on the net can use their spare CPU cycles to break 64-bit RC5 -- a better standard should ensue.
  • If you join the Bovine effort you can make $1000 if you're the one to crack the code.
  • If a Team Warped member finds the code, Team Warped gets $1000 to spend promoting OS/2.
  • Your computer is bored, give it something to do.

Getting Started With Bovine

OK, sounds cool, what now? Go to the RC5 home page and get the client. As of the time of writing, the latest version of the OS/2 client is 2.7107.437 Command Line Interface (CLI).

How do I set it up? This is a general overview to assist new participants in getting started in the RC5DES contests using the V 2.7107.437 OS/2 Command Line Interface (CLI) client. It is acknowledged, that there is probably no "typical" implementation and virtually every situation will differ in some way. Notwithstanding this, I have attempted to provide what I consider to be "General Recommendation" for most of the settings and a brief description of each option. Don't get overwhelmed with all the possible options. In most instances, you can just put in your email address and fire it up.

It is also notable, that the visibility of some options is reliant on others being selected first. So if you do not see all the possibilities listed below, do not get concerned.

I do not assert that everything here is 100% correct, but they do reflect to the best of my knowledge their influence on the client configuration. Please don't hesitate to send any recommendations or corrections to Phillip.

If you want to ask questions then I recommend that you join the Team Warped RC5 mailing list via the web..

The first time you start up the client, you'll get a screen similar to this:


The notification that you have not provided an ID is important. You must provide an ID for the blocks you process to be able to be attributed to Team Warped. Select Choice 1, and you'll see the following screen.

RC5DES Client Configuration
Block and Buffer Options

1. Your email address (distributed.net ID) General Recommendation: Essential Information (use your own email address) This is the easiest but most important of all the options. Each block that is tested is attributed to someone, who gets credit for doing the work. But take some care in initially choosing and correctly spelling your email address. Many people have several addresses, and if this is the case, you should preferably use one that is likely to be the most "permanent".

2. Frequently check for empty buffers? General Recommendation: No (default) This is normally not needed, however it can be used if you are using one input buffer to serve several clients on different machines over a network. In this instance, it may be preferable to use a Personal Proxy (and allow each machine to have its own input buffer) instead of using one shared input buffer. However, this option makes the client check that there are blocks available in the input buffer (ie. the "buff-in.rc5" file) every few minutes; this reduces the downtime that may be caused by an empty buffer.

3. Buffer blocks in RAM only? (no disk I/O) General Recommendation: No (default) You should only select this option if the computer running the client has a reliable permanent connection to a Personal Proxy (PProxy) or Keyserver (KS), and no HDD. If the client is shutdown, any unflushed completed blocks are lost. This option is not recommended unless absolutely necessary.

4. Preferred Block Size (2^X keys/block) General Recommendation: The higher the better. The recent client builds allow you to set your preferred block size, ranging from 2^28 to 2^31. In simple math terms, one (2^31) block = two (2^30) blocks = four (2^29) blocks = eight (2^28) blocks. Generally, a larger preferred block size means it will take longer to complete each block. Depending on the speed of your PC, it is better to request larger block sizes as this places less less demand on the keyservers and usually means your client doesn't need to connect as often to fill and flush its buffers. But there are 2 important points to note here: (i) Irrespective of your preferred block size, all statistics are converted to multiples of a 2^28 base. (eg. if you submit one 2^30 block, you will be credited for 4 blocks on all the stats pages.) So, by choosing a larger block size you will not be disadvantaged in any way; and (ii) A larger block size is really only a request to the PProxy/KS to try to fill your order as best it can. There is no guarantee you will get your "order" filled to your specifications. The supplier, may only have partly-filled "boxes", so if you requested five 2^31 blocks, you may actually receive two 2^31 blocks, one 5*2^28 "block", and two 2^29 blocks. It is important to be aware of this, if you connect to the internet once per day and only aim to hold enough blocks for that day.

5. Block fetch/flush threshold This setting determines how many blocks are stored in the input and output buffers. If you only periodically connect to the internet, you should attempt to keep sufficient blocks to cover the time until your next connection. This is often only one or two days for many people. Do not horde too many blocks (it would be very unusual to need more than a weeks worth of blocks). For those with a permanent connection, it is likely you may only need a setting of 10 or 20 blocks. Note: this should be determined in combination with your Preferred Block Size (discussed above).

6. RC5 In-Buffer Path/Name General Recommendation: buff-in.rc5 (default) This allows you to specify the name of the file that holds the blocks that are yet to be processed. For the vast majority of people, it is easiest to leave it as the default name of "buff-in.rc5" in the same directory as the rc5des.exe program. It is possible to place the files in different directories, but this should only be done for unusual configurations.

7. RC5 Out-Buffer Path/Name General Recommendation: buff-out.rc5 (default) As for the In-Buffer file, it is highly recommended this is left as the default name of "buff-out.rc5".

8. DES In-Buffer Path/Name General Recommendation: buff-in.des (default) Distributed.net also participates in other periodic contests that use different encryption methods. If you use a setting (discussed later), you have the option of participating in these competitions. This option works independently of the DES In-Buffer Path/Name setting, so it is strongly recommended you leave the the name as the default of "buff-in.des".

9. DES Out-Buffer Path/Name General Recommendation: buff-out.des (default) Same as for the In-Buffer file, it is strongly recommended to leave this setting as the default name of "buff-out.des".

10. Checkpoint Filename General Recommendation: ckpoint.rc5 In the normal course of events, when the client is shut down, any partially processed blocks are written back to the In-Buffer file with details of how much of that block was already processed. When the client is restarted, this information is retrieved, and processing continues from where it left off (this avoids duplicating effort). However, in cases where the computer suddenly shuts down (eg. loss of power or a system crash, the client doesn't have the opportunity to write back this information. A checkpoint file alleviates this problem by regularly writing this information to your nominated checkpoint file. Given the larger block sizes available, it's probably not a bad idea to use this option.


Save the options you've selected, and go back to the main menu. The next page (Selection 2) will be similar to:

RC5DES Client Configuration
Logging Options

1. File to log to General Recommendation: Personal Preference A log file can be generated that provides similar information that is shown on screen, and it's use is very much personal preference. The advantage is that it can provide you a history of client speeds for various setups and options. A possible downside is that the file size can become substantial. On one machine that I rarely attend, the log file is now almost 10 MB. If you wish to use a log file, type a filename in this option and it will be automatically generated.

2. Log by mail spool size (bytes) General Recommendation: No There are very few circumstances that this option is probably of any use. In essence, it allows you to email a log of client activity to someone. It might be of some use if you are administering a client on a remote machine that you very rarely get to. If you do select this option, you will be asked for more information regarding which mail server to use, and the sender's and recipient's email address. But in general terms, don't select this option.

Back to the main menu again (by selecting 0), and the 3rd page is:

RC5DES Client Configuration
Network and Communication Options

1. Offline operation mode General Recommendation: Permanent/Dialup connection - no Sneakernet - yes If this option is set to yes, the client never automatically attempts to connect to a PProxy/KS. It will use the blocks in the the In-Buffer file, but when these run out, it will generate random blocks. (If sneakernetting, it is a good idea to manually edit the "randomprefix=" setting in the rc5des.ini file every few weeks so randomly-generated files are being cracked in acceptable keyspace. The randomprefix setting in a "connected" client will usually be up to date.)

2. Network Timeout (seconds) General Recommendation: 60 (default) With the newer clients, this value can be between 5 and 300 seconds, but I've never had any difficulty with the default setting of 60. It's purpose is to provide a waiting time limit for a response from a PProxy/KS before it assumes the flush or fetch has failed.

3. Firewall Protocol/Communications mode General Recommendation: No special encoding (default) In general, many clients will not need to alter this setting. However, those machines behind various types of firewalls, may need to vary this setting to enable connection to a PProxy/KS. The number of possible scenarios is huge, so if you need assistance in setting this up, ask your network administrator. If you're not game to ask him/her, then you probably shouldn't be running the client on those computers anyway!

4. Automatically select a distributed.net keyserver? General Recommendation: No Team Warped runs several PProxies to fetch and flush blocks. These all feed into the Team Warped Statistics Pages, which in turn feed into the main Distributed.Net Statistics Pages. If you want to have your blocks tracked through all the Team Warped pages, set this option to no and set the next option (Keyserver to communicate with) to proxy.os2ss.com for those in the US and nearby, or rc5des.phile.com.au for those in Australia or nearby. For those that don't wish to use the Team Warped proxies for whatever reason, you can select Yes for this option. Just make sure that you assign your blocks on Distributed.Net to Team Warped (Team 112).

5. Keyserver to communicate with General Recommendation: proxy.os2ss.com or rc5des.phile.com.au See discussion in preceding paragraph.

6. Keyserver port to connect to General Recommendation: 0 (auto select) (default) Just about all PProxies/KS use Port 2064. Other ports are used for issuing test blocks, or specific ports for use through firewalls etc, but if this option is set to AutoSelect, there shouldn't be any problems.

7. Keyserver is a personal proxy on a protected LAN General Recommendation: No This is another option that is really only needed in specialised or unusual circumstances. It allows the relaying of blocks via a PProxy inside a firewall to another outside a firewall. If you need to use this, you should seek assistance from your network administrator.

12. Modem detection options General Recommendation: Permanent connection - 0 Normal mode Dial-up connection (Dial on Demand) - 1 Dial-up detection mode Basic Dial-up connection - 2 Dial-up detection ONLY mode There are many possible scenarios here. Basically, with a permament connection or access to a PProxy, the best is often to use Normal Mode. If you have a dialler that is capable of Dial-on-demand (DOD) and you wish to have minimum intervention, then you may like to select Dial-up detection mode. This means that when the In-Buffer is empty or you have reached any of the thresholds defined in the Blocks Fetch/Flush option, the modem will automatically dial your ISP, and fetch/flush the next blocks. If you choose this option, be careful that you have your dialler timeouts setup correctly. The final option, Dial-up detection ONLY mode, will not initiate DOD. If the In-Buffer file is empty, it will generate random blocks until you manually initiate a connection to your ISP. Once it detects a connection to the internet, completed blocks will be flushed and fresh blocks will be fetched. A common alternative is to setup your dialler to automatically run a script or batch file when it connects to your ISP. (Note that this does not require you to stop the RC5DES client since you can run more than one instance of the same executable). By putting a script containing the line "rc5des.exe -update" (include the path if necessary) in the autostart section of your dialler, the buffers will be fetched and flushed every time you connect to your ISP.

13. Interfaces to watch General Recommendation: [Leave blank] (default) This is not usually necessary for novice users, and there are many people with a lot more expertise than I, that suggest this is not needed in most situations. I suggest leaving it blank. If you require further assistance, consult your network administrator.

14. Use scripts to initiate/hangup dialup connections General Recommendation: no (default) This can be used as an alternative if your dialler does not support Dial on Demand and you wish to use Dial-up connection in the Modem detection options section. By making your own scripts or batch files to initiate and drop the connection to your ISP, you can minimise the amount of intervention needed on your behalf. However, it is suggested you feel reasonably confident about your scripting skills before attempting to use your own scripts.

Return to the main menu again (by selecting 0), and then the 4th page is:

RC5DES Client Configuration
Performance and Processor Options

1. Processor type General Recommendation: Autodetect (default) The newer clients do a good job in most instances in detecting the CPU correctly. However, if you are sure of the specification of your CPU, you can manually select the processor type. Parts of the code are very highly optimised to make the most of abilities of your particular processor, and setting this incorrectly may significantly slow down the client. If you are not certain which one to use, allow the autodetection to best guess this for your computer.

2. Number of processors available General Recommendation: -1 (autodetect) (default) Most people would know how many CPU's are in their particular computer, so feel free to set this to the correct setting. But the autodetection works well. There is no penalty or overhead in leaving autodetection on.

3. Priority level to run at General Recommendation: 1 or 0 This option allows you to set the "niceness" or "priority" of the client and will accept values from 0 to 9. At 0 (the lowest priority), the client will yield processor time to any other task the computer is running. This way, only unused CPU cycles are being used for RC5DES.exe. On a cautionary note, this also means that if you are using a CPU Monitor of any variety, it will most likely equally share the CPU usage, and dramatically reduce the client speed. I normally use a priority level of 1, and have found no interference with any of my programs. On a computer that is dedicated to RC5DES, you may wish to increase the priority. For those that want to experiment with this setting, it can be rewarding to find the "right mix" of priorities for the client and the normal programs you run.

Just about done now. The final page will look like:

RC5DES Client Configuration
Miscellaneous Options

1. Complete this many blocks, then exit General Recommendation: 0 (no limit) (default) This option allows you to specify that the client can only crack a certain number of blocks. As soon as this limit is reached, the client will automatically shutdown and exit. This option, like many in the Miscellaneous section, is normally only needed for specific and/or unusual situations.

2. Run for this long, then exit General Recommendation: 0:00 (default) This works in a similar way to Point 1, but tells the client to shutdown after a certain time period. Some people use this for machines that are always running, but might only be heavily used during business hours, for example. In this case, they may automatically start the client at the end of the work day, and let it run until the start of the next working day.

3. Pausefile Path/Name General Recommendation: [Leave blank] (default) If this option nominates a filename, as soon as a file by that name exists, the client stops running. However, it does not close itself down - it goes into a state of "suspended animation". It remains stopped, as long as that pausefile exists. When the pausefile is deleted, the client resumes normal operation.

4. Disable all screen output? (quiet mode) General Recommendation: no (default) As the option name suggests, this stops all output from being sent to the window/screen. If the logging option is chosen, output will continue to be written to the log file. This option is probably of most benefit, if the client is being run in a detached (or hidden) session.

5. Disable exit file checking? General Recommendation: no (default) Exit file checking works by regularly checking for the presence of a particular file (by default this file is "exitrc5.now"). If it is detected, the client stops all processing, shuts down and exits. Conceptually, it is similar to the pausefile option except the client shuts down instead of being suspended.

6. Disable the block completion indicator? General recommendation: no (default) When running in normal mode, the progression through the current block can be seen in the window/screen via the percentage completed indicators. By disabling this, only the completion of each block is written to the window instead of the real-time progression.

To join Team Warped: You will need to run the client and submit blocks for at LEAST 24 hours and then:

  • Go to the Bovine stats page
  • Search for your email address (there's a search box on the left)
  • Get your password
  • Join team 112 (that's Team Warped)

Please don't inundate me with questions, I don't know most of the answers, so if you have a question, post it to the RC5 mailing list (rc5@llamas.net) or the Team Warped mailing list and someone will help you. Also, please make sure you read through this page before asking a question. Chances are your answer is here somewhere.

Performance Tips

  • Always use the latest client. I'll try and keep this page updated when new clients come out.
  • Pick the fastest CPU type - the descriptions are accurate for what optimization to use. Make sure and pick your CPU since the autodetect feature doesn't seem to be too dependable and the correct optimization can make a 30% or more difference in speed. If you want to make CERTAIN that you have the best optimization, close all programs on your system and benchmark the client with each of the different selections. To benchmark just run the client with the -benchmark option.
  • Shut down unnecessary applications. This includes things like Warpcenter, OD's Control Center, NPSWPS, and any screen savers. Just turn your monitor off when you're not at your computer. I shut down all of these apps when I'm not at my computer. I put a shadow of Tab Launch Pad on my desktop, and all my other apps (Control Center, NPSWPS, etc.) in Tab Launch Pad so that with a few clicks I'm back up to full "User Friendly mode," but at night I only run RC5. Note that CPU meters will suck 50% of the CPU time away from the client because both work by using all available idle CPU cycles. There are a few exceptions, but do you really need to run a CPU meter???
  • Tweak out your PC's performance. See Tom's Hardware Guide (a really cool site) on information about BIOS settings, RAM speeds, and overclocking (do it if you can/dare).
  • Buy a new computer or processor, more cache, or more RAM. This is a great excuse. If you're running a slow 486, there is a clock quadrupled chip from AMD that's pretty cheap, fast and can be overclocked a good share of the time. If you're running a Pentium class system, check Tom's page for info about Pentiums, Pentium MMX's, Cyrix 6x86's, AMD K6's, and Cyrix 6x86MX's (the latter 2 are really cool, inexpensive, and work in many current Socket 7 boards). Going from 256k to 512k cache should help some, and will give a good performance increase in OS/2. Adding more RAM isn't likely to help the RC5 client much, but it is nice to have, and might help the client work better when you have lots of apps open. The best chips for RC5 (per dollar spent) are the fast 486's, K5's, Cyrix 6x86 (M1) and 6x86MX (M2), Pentium Pro's, and Pentium II's (OK, not on a per dollar spent basis, but they are fast at RC5). CPU's which perform worse on RC5 than they do on other tasks are the Intel Pentium and Pentium MMX and the AMD K6.
  • Tweak any DOS and WinOS/2 sessions you run. DOS and WinOS/2 sessions tend to hog CPU time. Messing with the "idle sensitivity" can help.
  • Tweak your dialer. InJoy will let you adjust its priority, try messing with that. I don't know how much you can affect thigs with it, but hey, computers are for playing, right?
  • Increase the priority. The clients allow you to select one of three "nice" levels: (0) Idle 0, (1) Idle 31, and (2)Normal 0. I recommend (1) Idle 31. Unless you don't use your machine at all, I don't recommend the (2) Normal 0 priority, as it can cause severe performance problems with other programs running on your system. There are also utilities available that will let you change the priority of a given app.

Stats for Team Warped

Info for IBMers Participating

New info for IBMers and the new effort from other IBMers. Let's see if we can get more IBMers on board! Come on OS/2 Developers! The client won't affect your compile times or system stability and you can help OS/2 look a little better. If all the OS/2 developers and support personnel would join in, we could probably be the number one team! Let's do a little recruiting within Big Blue! Hey, we could probably be the number one team if it was just running hidden on all of IBM's secretary's machines. Here are a few proxies running at IBM:

  • rc5proxy.charlotte.ibm.com is running on an OS/2 box 24x7x365 and all blocks are reported through the Team Warped stats server. The proxy is run by Jeffrey Doolittle
  • spec17.greenock.uk.ibm.com is a desktop OS/2 machine in Scotland run by Wouter Cloetens (AKA Zombie).
  • plato.ibmus2.ibm.com using the port of 8090 is reported by IBMer David Jackson in Columbus, OH.
  • m023274.somers.hqregion.ibm.com is located in Building One at IBM Sterling Forest in Sterling Forest, NY and it's up and available 24x7x365. This proxy is run by Steve Dale. Any blocks reported to this proxy server get reported to the Team Warped stats server. Steve also publishes the stats for his proxy server (internal IBM) and updates them on an hourly basis.

I suspect that each of these proxies will work quite well for those in IBM, but if you know another proxy that's up 24x7x365, please feel free to let me know and I'll add it to the list. Also, feel free to recruit as many other IBMers as you can. IBM is the largest computer company in the world, they produce the best PC OS in the world, they should be a major part of Team Warped.

Links