In today's technological world, virtually everyone has encountered something that has been encrypted, more than likely without realizing it. Encryption is the most commonly used form of cryptography, which, according to RSA Security, is essentially known as "keeping communications private." (Jonsson) Everything from e-mail to e-commerce uses encryption to safely transmit documents and other information over the internet. But encryption isn't limited to the Internet; it is also used in satellite television and telephone access. Without encryption, people would easily be able to eavesdrop on phone conversations and break into others' e-mail accounts.

One Internet organization, Distributed.net, is trying to make sure the United States's encryption standards are tough enough by breaking them. Their project, RC5-64, uses distributed computing to solve an encryption key by RSA Security, a company responsible for encrypting not only major commercial websites and servers, but also that of the United States government. Distributed.net set up servers and provides software for participants around the world to help find the secret key and break RSA's 64-bit encryption. Distributed.net has been involved in other RSA challenges in the past, mainly to help prove to the United States government that security standards aren't high enough, and, with enough computer power and time, even a complicated encryption code can be broken.

One of their previous projects proved that 56-bit encryption can be broken: a mere 4,000 individuals and teams found the secret key. The search only took 212 days and almost half of the possible key combinations, or solutions, were exhausted. (McNett)

This time, the challenge to find the key for the 64-bit encryption is 256 times harder than the 56-bit challenge ‹ 34 quadrillion keys compared to 72 quadrillion keys. Although there are over 600,000 users running Distributed.net's Bovine software for the RC5-64 project, the project has been running for more than 1000 days and they have yet to find the secret key. Until this day comes, users can see RC5-64's progress daily; it takes between 3 minutes and 12 hours for most computers to process the data blocks. One need not be online but once every few days so the computer can connect to Distributed.net's proxy keyservers and obtain more data. If the computer doesn't have access to the Internet at the moment but is done processing blocks, the Bovine software can start checking randomly-created blocks. Thus, the computer1s idle time is never wasted.

Distributed.net has created an interesting, efficient architecture for RC5-64 (see figure 2), the most notable aspect being that each block is sent out only once to a unique user. RC5-64 has a pyramid architecture consisting of keyservers and clients. (distributed.net faq-o-matic) The master keyserver is at the top of the pyramid and has the most important job: it keeps track of the keyblocks, or the data that needs to be processed. Thus, the master keyserver distributes the keyblocks as needed and doesn't send out keyblocks that have already been checked. Under the master keyserver are the main Bovine proxy keyservers. These keyservers are mediators between the master keyserver and the clients. The proxy keyservers request large blocks of keys ‹ superblocks ‹ from the master keyserver. The superblocks are broken down by the proxies and sent to the clients. The clients check the blocks and return them to the proxies, which then return them to the master keyserver.

An analogy that might clarify the process is a person going to their local library to get a book. The book isn't in, so he requests the book from the librarian. The librarian then in turn asks a larger library or county library for the book. The larger library will send the book to the smaller library, and the librarian will give the person that specific book. When the person is done with the book, it is returned to the librarian, who returns it to the bigger library.

C5-64 is one of the largest-running distributed computing projects, second only to SETI@home. Distributed.net does hold the record for longest-running project, though: RC5-64 has been running for over 1,000 days ‹ almost 3 years. It is taking quite awhile to solve this encryption problem because, chances are, every data block needs to be processed until the key is found; there is no way of knowing what block it is in so all blocks must be tested. This is known as the "brute force" solution method. The odds of when the key could be found are virtually unknown; it could be found in the next hour or next year. However, Distributed.net does have the time it will take to find the key if the key is in the last block processed. Since it's taken 1,000 days to get through 30% of the keyspace, it may take another 3,000 days to find the key.

Unlike SETI@home and a few other distributed computing projects, RC5-64 is partially open source. This has led to some problems, as people can use the parts of the code that are given and try to make their computer appear to be processing more blocks, or even make their computer appear that it is processing data blocks when it's really not. The latter would be especially detrimental to the project. The key is hidden in just one block. If that block was returned as negative when it really did have the key, the project would have to completely start over. Something similar could happen unintentionally if someone's computer crashed while it was processing a block. That block then may be "lost," and wouldn't be redistributed for at least 90 days. However, there are options on the software that allows the user to have the computer save the block every so often, so the liklihood of this happening is very slim.

RC5-64 is a finite project, as it will end once the correct key is found. It is likely, though, that RSA will issue another encryption challenge, perhaps featuring a 72-bit code, and yet again try to convince the US Government that standards should be raised to 128-bit encryption. All that is certain is that Distributed.net will be involved in many more challenges and projects to come, as the organization wants to increase distributed computing usage and augment idle computer power and CPU cycles for something useful.