1996-10-10 - Re: pgp, edi, s/mime

Header Data

From: Raph Levien <raph@cs.berkeley.edu>
To: Steve Schear <azur@netcom.com>
Message Hash: 7ec3b3c70819b27add8ead6cd2d4282d875eb2b6b99327e5139240fd254a095b
Message ID: <325D21FD.75BFB75B@cs.berkeley.edu>
Reply To: <v02130501ae825f741356@[10.0.2.15]>
UTC Datetime: 1996-10-10 16:19:42 UTC
Raw Date: Thu, 10 Oct 1996 09:19:42 -0700 (PDT)

Raw message

From: Raph Levien <raph@cs.berkeley.edu>
Date: Thu, 10 Oct 1996 09:19:42 -0700 (PDT)
To: Steve Schear <azur@netcom.com>
Subject: Re: pgp, edi, s/mime
In-Reply-To: <v02130501ae825f741356@[10.0.2.15]>
Message-ID: <325D21FD.75BFB75B@cs.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


> How will users be made confident that the S/MIME crypto isn't somehow
> compromised in these products?  Vendor trust (I think not, with all the
> government pressures)?

First, the S/MIME _spec_ is a matter of public record. In addition,
RIPEM is a free software, source code available, implementation of
S/MIME's crypto parts. So if you use RIPEM, you're in pretty much the
same position as using PGP (which, unfortunately, includes the
ease-of-use issues).

But how can you be sure that _any_ software does what it's supposed to
do? As someone (I don't remember who) pointed out a few days ago,
Kerberos 4 was available in source form for a long time, and it had a
really weak PRNG.

How many people have really looked critically at the PGP 2.6.2 sources?
The key management code, in particular, is pretty bad. I didn't find any
actual bugs (I wasn't looking for them - I was just trying to understand
how it worked), but it didn't leave me with much confidence that it's
completely robust code.

At least with products like Netscape, money is being spent on quality
assurance.

You've raised a good question here. It's just that there are no easy
answers.

Raph





Thread