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
participants (3)
-
Adam Shostack -
azur＠netcom.com -
Raph Levien