--- begin forwarded text
Date: Mon, 01 Nov 1999 19:21:56 -0800
From: Will Price <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: 56 Bits?????
Sender: <[EMAIL PROTECTED]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
That solution has essentially the same problem in my view.
When a protocol becomes part of the Internet infrastructure (or
simply a file format) and the protocol is designed to support weak
crypto along with strong crypto, what ends up happening is that the
users really have no idea which one they are using, and the lines
become blurred. The user doesn't know whether they are using toy
crypto or good crypto. If I receive a file from someone else
encrypted, is that file going to be encrypted with toy crypto or real
crypto? If I connect to a weak crypto SSL webserver, is that page
using weak or strong crypto? In the case of MacOS 9, clearly the
answer is the former at the moment, but even if they begin to
distribute a strong version that doesn't really change anything.
Most people are way too oblivious to go download and install strong
crypto patches. Even in the best case scenario where new crypto regs
eventually allowed worldwide distribution of the strong version, the
game is already up because all the copies of MacOS 9 that sell in the
next few months during the prime buying time for the product will be
sold as weak crypto. We'll have millions of weak crypto installed
base users.
A file format or protocol is used for *exchange*, and thus it
requires more than one party to participate. Once you build an
infrastructure that supports weak crypto, the weak crypto spreads
like a virus due to the built-in user oblivion.
The classic example of this is how SSL has been completely ruined.
Virtually everything out there that supports SSL is weak crypto only.
I'm sure most members of this list probably have gone to the trouble
of downloading a strong crypto browser, but in the face of the tens
of millions of weak browsers and servers out there, SSL will never
recover from this virus. S/MIME has the same problem for the same
reason of course (but who cares because nobody uses it anyway!)
Thankfully, before IPSec becomes widespread the IETF recently
acquired a clue and has begun issuing RFCs eliminating weak crypto
from it -- although not soon enough to stop Windows 2000 from
shipping with weak crypto IPSec I suspect.
Has anyone ever used their strong browser to connect to various
e-commerce sites and checked the actual encyrption strength? You'll
find that many of those sites use weak crypto servers. It's not just
the masses of users who don't get it, it's the sites as well. The
way I see it, the entire e-commerce infrastructure has been infected
with a built-in backdoor.
FWIW PGP has never supported any kind of weak crypto, and the OpenPGP
RFC has no support for it whatsoever. There have been all sorts of
marketing people, government people, and standards bodies that have
urged us to support weak crypto for various reasons. It's always fun
to tell such nitwits where they can go.
Leonard Rosenthol wrote:
>
> At 3:02 PM -0500 11/1/99, Robert Hettinga wrote:
> >>Key lengths are perhaps the easiest parameter for a manufacturer
> >>to change at a later date. Incorporating a useful and usable
> >>cryptographic architecture is much harder. Apple deserves credit
> >>for taking a serious stab at the later.
> >
> >I realize this, and I also realize that once a piece of software
> >gets out and widely used, its a real pain in the ass to get
> >everyone to switch; meaning if we laid down a 56-bit crypto
> >architecture, and the export regs vanished the world over 10 years
> >from now, after our arch had taken off .. we'd still have to live
> >with weak crypto for a number of years just to maintain backward
> >compatibility.
>
> That's not necessary true...
>
> When I did Aladdin's Private File, one thing that I did in
> the file format was to include the key length, so that we could
> have different encoders (128bit domestic, 40 bit int'l) but a
> single
> expander. Same could well hold true for Apple - but we don't know
> since their format is proprietary :(.
>
> Leonard
- --
Will Price, Architect/Sr. Mgr., PGP Client Products
Total Network Security Division
Network Associates, Inc.
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.2
iQA/AwUBOB5YVKy7FkvPc+xMEQK+KACgjMkuvtGI+KduxqRp8xKcAjXLLaIAoIQw
Tiq6KcQp3iSAZwsOaHH0T9zi
=9mfi
-----END PGP SIGNATURE-----
--- end forwarded text
-----------------
Robert A. Hettinga <mailto: [EMAIL PROTECTED]>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
