From: DAVESPARKS@delphi.com
Date: Sat, 23 Jul 94 04:03:53 PDT
To: cypherpunks@toad.com
Subject: Re: Double DES calculations
Message-ID: <01HF1CC26L6Q8ZFRBV@delphi.com>
MIME-Version: 1.0
Content-Type: text/plain


Hal Finney wrote:

> Most of the time-space tradeoffs that I can think of for a basic MITM
> attack like this are pretty costly.  For example, instead of trying all
> the keys on both sides you could try just half the keys each time.  This
> would take only half as much space but up to four times the time.  You
> could also do some hashing to save space at the cost of false positives
> and more time.  Again, the point is not so much that double DES is weak,
> but more that if its strength is solely due to space costs that gives much
> less of a good feeling than if you had an algorithm that was strong both
> in space and in time.

Agreed, Hal.  I was just pointing out the fallacy of saying that 2-DES
would only take *TWICE* as long to break as 1-DES.  While there are some
tradeoffs that trade space for time, the one virtually constant factor is
monetary cost. Whether it's 300 million drives running for 10+ days to crack
the key, or 10 million for a year or so, the total energy consumed will be
virtually the same. By my calculations, the energy costs alone would be over
half a billion dollars per key.  Not only that, but one of these
hypothetical $1.5 TRILLION "monster crackers" can still only break 30 keys a
year.  (Good reason to generate temporary session keys!)
 
Also, I neglected the "overhead" costs associated, such as periodic
maintenance on all those drives.  Drives in nearly constant use will need
frequent maintenance, especially head cleaning, which is not a trivial task
on 300 million drives.

The only way I can see that this would be cost-effective is to locate it
near a prison (for cheap convict labor) with a cheap power source nearby.
That, or invent a cheaper storage medium than DAT.

In the final analysis, though, you're right.  I'd hate to calculate the cost
to break 3-DES.  Unless you're encrypting a high speed data link in real
time, where utmost throughput is essential, I see no reason to not use that,
or something equally strong.

 /--------------+------------------------------------\
 |              |  Internet: davesparks@delphi.com   |
 | Dave Sparks  |  Fidonet:  Dave Sparks @ 1:207/212 |
 |              |  BBS:      (909) 353-9821 - 14.4K  |
 \--------------+------------------------------------/