From: Raph Levien <raph@cs.berkeley.edu>
Date: Tue, 4 Jun 1996 09:41:53 +0800
To: Lucky Green <shamrock@netcom.com>
Subject: Re: NRC Session Hiss
In-Reply-To: <199606030150.BAA27932@pipe2.t1.usa.pipeline.com>
Message-ID: <31B34402.3B2C@cs.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


Lucky Green wrote:
> That PGP is ubiquitous is subject to discussion. PGP is widely available,
> but that doesn't mean that it is widely used. What percentage of email is
> PGP encrypted? Less than half a percent?

   Full agreement here. Further, nothing that the PGP people are doing 
seems likely to fundamentally change this fact.

> PGP was a failure in the mass market, regardless how popular it may be
> with some subscribers of this list. The email encryption method that *will*
> be ubiquitous and that will cause PGP to be used only by a relatively
> small fringe is S/MIME. Within a few months, S/MIME will be on the
> desktops of some 20 million people. It, not PGP is the future standard.

   Yes.

> Of course S/MIME will default to 40 bit RC-4 and carry the signatures
> outside the encryption envelope. There is little doubt in my mind that
> the pannel will find it much easier to support than PGP.

   Actually, this is the case in the current standard, but in the next 
one, it might change.
   I'll try to bring cypherpunks up to date - the debate is still 
happening on the smime-dev mailing list.

   A couple of weeks ago, one of RSA's consultants in Washington got what 
appears to be approval for certain relaxation of the export rules for 
S/MIME. The rules themselves apply to S/MIME only. They are also quite 
confusing, mostly because capabilities for message sending and message 
receiving are so asymmetric. I'll try to briefly summarize the 
characteristics of exportable S/MIME clients here.
   Signature generation is quite good - signatures can be generated and 
verified at 2048 bits. This applies both to messages and certificates. The 
limitations apply to encryption only.
   Basically, an exportable S/MIME client can transmit messages up to 
1024/40 bit RSA/RC2 (or RSA/DES), and receive messages up to 512/64 bit 
RSA/RC2 (or RSA/DES, but in the latter case I would imagine it's actually 
restricted to 512/56 because of the keysize of DES). Note that the 
asymmetry actually points in different directions for the public and 
symmetric keysizes.
   Most users of exportable clients will want to generate separate RSA 
keys for signatures and encryption, otherwise signatures would be limited 
to 512 bits.

   In any case, the fact that RSA keysizes are linked to symmetric 
keysizes is _extremely_ good news. It means that that it is possible to 
tell whether the recipient is an export version or not. If the keysize is 
512 bits or less, the default algorithm should be 64-bit RC2. Otherwise, 
it should be 168-bit Triple-DES. If you work it out, you'll see that this 
policy will not cause any interoperability problems. For example, if the 
default encryption algorithm were simply changed to Triple-DES, then 
export clients would be unable to read the message at all.

   I'm pushing to get this policy codified in the S/MIME implementation 
guidelines and also widely implemented. If this happens, there really 
wouldn't be much point in trying to keep PGP alive.

   Of course, the division into export and domestic versions would still 
probably ensure that most of the clients in the field were restricted to 
export-grade, but I think it's likely that the population of non-export 
clients will far exceed that of PGP, so it's progress in any case. Also, 
if S/MIME catches on, it creates a fabulous opportunity for a company 
outside the US to market good S/MIME clients.

Raph