[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Short keys * Options, combinations, and negotiations => simplicity
As you point out, there are multipliers to the raw cost, but there are also divisors.
One example: the key does not typically change for each packet. Even if the key
changes every five seconds, cracking one packet could give you (let's see 1500
byte packets at T1 speed) tens of thousands of cracked packets for free.
Bill
----------
From: Kent Crispin[SMTP:kent@bywater.songbird.com]
Perry E. Metzger allegedly said:
> Robert Moskowitz writes:
> > At 08:05 PM 10/8/96 -0500, Stephen Kent wrote:
[...]
> According to the paper "Minimal Key Lengths for Symmetric Ciphers to
> Provide Adequate Commercial Security"*, by Blaze, Diffie, Rivest,
> Schneier, Shimomura, Thompson, and Wiener, for an initial investment
> of $10Million, a device may be made which will successfully break DES
> keys in six minutes each, at an amortized price of $38. For an
> investment of $300k, one can break the keys in three hours for the
> same amortized price.
> It is clear that for any corporate secret worth more than $38, DES is
> inadequate.
While I find this analysis fairly persuasive, it does leave out an
important extra cost -- the cost of isolating a converstion worth
decrypting. If "valuable" secrets occur in a small fraction of
intercepted messages, then the cost of finding the secret goes up
proportionately. So, if keys are changed frequently, and *all*
traffic is encrypted, the situation is dramatically different. It
would have to be the case, for example, that the *average* value of a
message was greater than $38, for a 56-bit key to be ineffective. If
99% of the messages had a value of 0, then the cost per *useful* key
would be closer to $3800...
Of course, one expects a higher percentage of value for messages
flowing from a bank. But for incidental, opportunistic encryption
(as John Gilmore put it), 56 bits may be adequate for a year or two.
To: Steven Bellovin <smb@research.att.com>
cc: Stephen Kent <kent@bbn.com>, John Gilmore <gnu@toad.com>, ipsec@TIS.COM,
gnu@toad.com
Subject: Re: Short keys (3DES transform)
Date: Fri, 11 Oct 1996 23:51:25 -0700
From: John Gilmore <gnu@toad.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9610140720.aa16058@neptune.TIS.COM>
I'm not 100% caught up on mailing list traffic (I'm not at home),
but thought this deserved a quicker answer than if I waited.
Steve Bellovin said:
> This is a crucial point. I agree that 3DES is too expensive to be the
> default transform. I also agree that the IAB had no intention of mandating
> such a move, and I was one of the authors of the statement. On the
> other hand, I didn't read John's note as suggesting it, either; rather
> (and this may be based on prior conversations with him), he was suggesting
> a mandatory-to-implement 3DES transform, so that people who want it will
> have it.
>
> John -- what did you mean?
I think that as a minimum we should have a mandatory-to-implement 3DES
transform, so that hosts or sites which desire high-security
connections to arbitrary hosts have a prayer of being able to get
them.
I also think that something stronger than 1DES should be the default.
Steve Bellovin, you wrote the paper on breaking it; do you agree? If
so, what would you pick as a default (if we need to pick one)?
I think that DES's susceptibility to brute force is a real problem for
commercial-grade traffic within the early lifetime of IPSEC. Just
like people rely upon the Internet itself because it is there, they
will tend to rely on IPSEC because it is there. Real
high-dollar-value business, life-critical medical information, control
of potentially deadly industrial processes, control of widely used
infrastructures like water and power, and other valuable things will
be secured and authenticated with it. Multi-billion-dollar companies
will rise who depend on IPSEC for their daily commerce with millions
of people. If their reliance is misplaced after two or three or five
years, we will have done them a disservice.
What the market wants is a "magic bullet" that solves the network
confidentiality and network authentication problems.
Non-cryptographers' least favorite thing about crypto is that you
can't solve the problem once and for all; you have to keep redesigning
it as attacks improve. This argues for building for long lifetimes
when we know how to. Steve Kent argues that DES isn't the weakest
link so we shouldn't strengthen it. As an engineer I'll put in the
extra 10% effort to make sure it isn't MY link that fails. And in
doing so I'll teach the designers of the weak links how to improve
by avoiding marginal fixes.
I have been running all of my telnet/rlogin traffic with 1DES (using
Kerberos) for years, even within my local Ethernet, and find the
performance completely acceptable and unnoticeable. I don't think I
would notice 3DES either, though a large server with many connections
might. I hope to have some performance numbers and "feel" for you
(from running real IPSEC with 3DES) next month.
Twenty-five years in this industry have shown me that today's marginal
performance is invisible and irrelevant tomorrow, while today's
marginal interface design decisions cost and cost and cost us
forever. We have big leverage for speeding things up without changing
them, but it takes massive human effort to change interfaces. 32-bit
IP addresses. 640K DOS. 16-bit Windows. Segmented Mac memory.
Unsafe pointers in C. Concentration of privileges in "root" user
ID's. Lack of preemptive multitasking. Let's not add "1DES IPSEC".
1DES IPSEC, even with frequent key changes, will not provide privacy
from inquisitive university students five years from now, just as
40-bit RC2 doesn't today. We're seeing exponential growth in circuit
speed and density, independent exponential growth in the number of
networked machines, and a further factor from our increasing abilities
in software to coordinate parallel processors both in the same box and
worldwide. Not to mention the wild card of increasingly wide access
to circuit design and circuit implementation facilities (soon to
include graphical "plug together blocks" PC tools which redefine
field-programmable circuitry within the PC itself). DES was designed
to be slow in software and fast in hardware, but the line between the
two is blurring, and 56 bits just don't give a 5-year margin of safety
even against poorly funded opponents.
Steve Kent says that commercial customers think DES is strong enough
today. He's right; they mostly do. This is why the Clinton
DES-export-for-GAK gambit could work: the executives who are making
these decisions may be willing to sacrifice the long term security of
their customers to alleviate a short-term frustration. But we who
specialize in this field owe them as customers a design that isn't
obsolete tomorrow. And we owe our children a society that protects
their privacy and their physical infrastructure, rather than leaving
them increasingly vulnerable to thieves, blackmailers, terrorists, and
J. Edgar Nixons.
I considered building a DES-cracker this year to prove to skeptics
that it's really a problem. I can do that because I'm a millionaire,
but there are 140,000 millionaires in the US alone, and the cracker
gets cheaper every year. I know two other groups that are building
them today, and there undoubtedly more who haven't told me. I decided
to do IPSEC instead, and I still think it's a good decision, but I am
relying on *your* professional expertise to understand the threat
without having a physical hardware box shoved under your nose.
So, while I don't have the definitive expertise to say "I have run
3DES for years for all my packet traffic and it works great", all my
expertise says that even if it doesn't, next year or in 18 months it
will. And I have the same feeling about the DES search engines which
make 1DES a poor default.
John
To: Stephen Kent <kent@bbn.com>
cc: ipsec@TIS.COM
Subject: Re: Short keys * Options, combinations, and negotiations => simplicity
In-reply-to: Your message of "Fri, 11 Oct 1996 15:03:17 EDT."
<v0213051aae84420c326d@[128.89.0.110]>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 11 Oct 1996 23:19:06 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9610140719.aa16041@neptune.TIS.COM>
Stephen Kent writes:
> It is worth noting that single DES is widely used to provide
> confidentiality for a number of very substantial financial services
> apoplications. If the cost of breaking DES is sufficiently low, then
> organized criminals are missing a great opportunity to steal billions of
> dollars.
Its only because the mafia doesn't have the expertise in house --
yet. I feel that I could personally manage to earn a substantial
amount of ill gotten loot given the knowledge I have in my head right
now. As an exercise, I've gone so far as to try to figure out what
would be the way to do it. I'm not about to say how in detail, but I
suspect that it would not only be possible to make a considerable sum,
but one could also do it without being caught except by extreme
chance.
You are probably too used to thinking small, Steve. *Trillions* (not a
misprint) flow through the capital markets on a daily basis. Tiny
information advantages can be parlayed into large amounts of
money. Done quietly, carefully, and non-greedily over a long period,
and it would be possible to make a fortune. Not a small fortune -- a
real one.
I suspect that about half the people on this mailing list figure out
how to do this if they bothered to take about six months to study the
financial industry in detail and they had the courage.
>From what I can tell, all that stands between us and this sort of
thing happening regularly is a lack of smarts in our organized
criminal gangs. I do not think this is a good situation. We should
not be depending on the good will of the smart people of the world to
protect us.
> Because there are many ways to acquire sensitive information, not
> just via passive intercepts, a fair amount of thought has to go into
> analysis of what constitutes appropriate security technology,
> relative to various threats.
I've done consulting for a trader with a fairly famous hedge fund (I
won't name him, but he's the sort to have had his name on the front
page of the Journal) who I one day saw, without batting an eyelash,
accumulate an 18 Billion dollar Eurobond position. (That is not a
misprint). It took a team of about twenty people to work his trades in
the market quietly enough to prevent him from being noticed.
Do you know how much money could have been made if that information
had leaked out? Do you know how much money he could have *lost* if
that had leaked out?
Tell me, with a straight face, that someone in that position doesn't
need security every bit as good as the government. I mean, there is a
serious limit to what lengths someone will go to for their
country. Money, on the other hand, has a very powerful influence on
human behavior. People will do astounding things for money.
Honestly, I do not see any valid argument for why any financial
instutution should use single DES under any circumstances. It is
inadequate -- period. The data rates that the average institution
deals with are low, and the machines they have usually have plenty of
spare capacity. In software, the price difference between DES and 3DES
is nearly zero provided you weren't using the cycles anyway. In
hardware, the price is literally zero.
> In developing a standard like IPSEC, we can allow for various
> algorithms and key lengths to accommodate different threat
> environments. However, because more secure algorithms and longer
> key lengths often entail performance penalties, one should make an
> informed decision when selecting among multiple options.
A while back, I decided to see what it would be like to have to live
with a "fully encrypted" environment. All communications between my
company's machines -- ALL of it -- is encrypted. Backups, remote
logins, mail reading, everything. (I wish I could be using IPSEC --
instead I am using Tatu Ylonen's SSH package. I do not 100% trust its
security -- the package is too large to analyse -- but the exercise
has none the less been good.) All that data is encrypted with 3DES at
all times.
What has the result been? Well, frankly, I've barely noticed. I was
worried that my machines and communications would crawl, but they
don't. The only time I really notice cryptography delays is when I do
my mail downloads from my sacrificial machine (which accepts mail) to
my workstation -- the script that I wrote to do this unfortunately
invokes SSH three times, which means three RSA operations. The extra
delay of a few seconds is noticeable, as I've said, but just
barely. As I've noted, the delay is in doing the RSAs, not in 3DES.
When doing collaborative work with the NetBSD project, I do all my
remote CVS using RC4 with 128 bit keys. I would use 3DES, but the
machine used for the CVS repository until recently was very old and
had a very, very overloaded processor, so I decided to be kind to it.
Going from personal experience to theory, I will note:
1) 40 bit RC4 and 128 bit RC4 run at the same speed even in software.
2) In hardware, 3DES and DES run at about the same speed and both cost
about the same. (You need hardware anyway for serious bandwidths.)
3) In software, 3DES is often nearly as cheap as DES in practice, as
I've found. Unless you are pounding bits really hard, your
bottleneck is frequently not your data transmission speed.
Allow me to summarize.
1) Investment banks, trading houses, commercial banks and hedge funds
have *real* risk in using DES. The mere fact that many are foolish
enough to do it doesn't change that. Hell, I know of important
deals concluded IN THE CLEAR BY EMAIL. The fact that people are
often stupid doesn't mean they don't need real security.
2) The price of real security is very low -- frequently near zero.
Perry
Date: Mon, 14 Oct 1996 08:37:19 -0400
To: "ipsec@TIS.COM" <ipsec@TIS.COM>
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: European IPSec implementations
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9610140843.aa17259@neptune.TIS.COM>
I will be in Cologne, Germany Oct 28th & 29th for a meeting of ODETTE wg 4
(automotive).
It would be very valuable for this meeting to have at least a partial list
of non-US IPsec implementations (planned are accessaptable at this point)
that are targeting Oakley/ISAKMP and X.509 certs.
Thanks for your help.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212