[Sorry about the long list of lists, but this issue is being discussed in all of them.] 1. Different set of people seem to be working towards different sets of goals, and this seems to be the source of a lot of contention. My personal goal is to promote the easing of US export restrictions on cryptographic software. I regard these restrictions as promoting crime and espionage. They are also driving US jobs overseas, and crippling the US software industry's ability to compete in the world marketplace (yes, I'm an American, and have every intention of promoting my countries best interests). Recently, the US government tightened the rules on cryptographic software export, but left one tiny Devil's bargain of a loophole: if firms would agree in future to compromise the integrity of their products by adding back doors for 'key recovery', then they could export single DES sofware without 'key recovery' until the end of 1998. Clearly, the government's intent is to bribe software developers into 'voluntarily' adopting GAK (Government Access to Keys), when they would never do so without incentive. The rules also require that if either end of a transmission uses a GAK'd product, then both sides of the transmission must be tappable. This makes it difficult for GAK'd and non-GAK'd products to interoperate, and is a wedge to force GAK'd products into even purely domestic communications. I think that this is a horrible idea. One way to fight it is to discredit DES, by showing that any one with sufficient computing resources (or a modest amount of cash) can get single-DES keys broken. If I destroy the market for new DES products, developers will have less incentive to go along with the government's Faustian scheme. The model I am trying to emulate is that of a criminal or spy agency which wishes to decrypt a captured transmission. It's not unusual for such a capture to have a partially known plaintext. In some cases, they may be able to use special hardware to search the keyspace quickly, but if they don't, they could simply put out a message on the sci.crypt: "Tell me what DES key decrypts 0f 1e 2d 3c 4b 5a 69 78 to 'HTTP/1.0' and I'll send you $10,000." This level of attack is available to almost anyone, and I intend to show that it is effective. ------------------ As for the prize money, if the person winning it wants to send it to a non-profit organization, or is contractually bound to dispose of it in some particular way, that's their business. Myself, I'd probably buy a couple really top-of-the-line PCs (for me and my wife), and throw a big party. Thomas S. writes:
2. What about the developers? They invest an awful lot of time and effort into this project because they believe in a future of the internet. The majority would be very unhappy if the money would be used for personal profit.
Speaking as a developer: I've been working on this project in my spare time for about 5 months now. When I talked to RSA about how to best set up the challenge, I *wanted* the money to go to the person finding the key, and I am pleased that that is what they have done. Which particular developers do you claim to speak for, anyway? Can't they speak for themselves? ------------------------- If the coordinated groups don't want to share their keyspace maps with others, that's their business. Effectively, they become just another uncoordinated searcher (though a very fast one). If a coordinated searcher does publish it's map, then people who trust it can use the data to avoid going over old ground. This would speed the search as we near the end, but has very little effect at the beginning. --------------------------- The coordinated groups are still trying to get their infrastructure in place. In the meantime, at my small employer, we are already searching about 10 million keys/sec, with probably twice that being searched by people with my software on the outsde. And I have still to do a general call for participation... Peter Trei trei@process.com ptrei@acm.org Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei@process.com