Re: pgp, edi, s/mime

>S/MIME has come a _long_ way. An earlier version (now called S/MIME 1.0,
>although I'm not sure this is going to make it into any marketing
>materials) had a couple of cryptographic problems compared with PGP.
>Those problems have been fixed in version 2.0, which is expected shortly
>(as an internet draft).
>
>S/MIME 2.0 _defaults_ to 168-bit triple-DES, unless you're stupid enough
>to use the export version. RSA key sizes up to 2048 bits are supported,
>as are a number of alternate symmetric algorithms. In addition, digital
>signatures are based on 160-biy SHA1, rather than 128-bit MD5, which is
>half broken anyway.
>
>In the meantime, Deming software is shipping a slick Windows
>implementation of S/MIME, which integrates nicely with Eudora. Netscape
>is expected to ship cross-platform S/MIME capability in version 4.0 of
>Navigator (their original publicity materials were only off by a factor
>of two ;-), and that will make a huge dent in the market.
>
>In sum, S/MIME leaves PGP in the dust, both techically and as a market
>force. There's still a lot of sentiment that PGP is one of "ours" and
>S/MIME is one of theirs, but at this point it's the latter that has the
>most promise of bringing encrypted e-mail to the masses.
>
>If only X.509 weren't so darned ugly :-)
>
>Raph

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)?




PGP Fingerprint: FE 90 1A 95 9D EA 8D 61  81 2E CC A9 A4 4A FB A9
---------------------------------------------------------------------
Snoop Daty Data           | Internet: azur@netcom.com
Grinder                   |
Sacred Cow Meat Co.       |
---------------------------------------------------------------------

Counter-cultural technology development our specialty.

Vote Libertarian.

Just say NO to prescription DRUGS.

"Of all tyrannies, a tyranny sincerely exercised for
 the good of its victims may be the most oppressive."
    -- C.S. Lewis

"Surveillence is ultimately just another form of media, and thus, potential
entertainment."
    -- G. Beato

> 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

Raph Levien wrote:

| 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.

	I've been doing a lot of work recently for an organization
that does a lot of code reviewing.  The technique, while very useful
(we find security & reliability bugs at about one per 20-50 lines of
code, which is dropping to closer to one per hundred as I distribute
copies of code review guidelines I wrote. (available for comment at
www.homeport.org/~adam/review.html)

	However, reviewing superficially takes about an hour for
500-1000 lines of commented code.  A deep review to find tricky
problems can take much longer.  (I would expect that a review that
moved at 600 lines/hour would have missed the xor bug in PGP's key
generation code in 2.6.0)

	We've found that a review team of fewer than 4 people is less
effective at finding problems, and haven't had more than about 8 in a
review, so I can't offer an upper bound.  Reviewing more than about
2000 lines of code (2-3 hours) in a day burns me out.

	SSH has 16 000 lines of code.  PGP has about 30k, not
including RSAref.

	Incidentally, if someone wants to contract to review ssh, I'd
be interested in talking to you.


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

	QA does not always assure security.  You need a team dedicated
to security QA, although getting code thats been worked over for
reliability is always a win.

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

Yep.  I figured I'd share my real world experience in getting secure
code deployed.

Adam

-- 
"Every year the Republicans campaign like Libertarians, and then go to
Wasthington and spend like Democrats."

Vote Harry Browne for President.  http://www.harrybrowne96.org