Prizes, and coordinated vs uncoordinated search, redux.

["Peter Trei" <trei@process.com>]

[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