NRC Session Hiss

During the Q&A of the NRC public session, it was asked why 
   56-bit DES was selected as the standard of export over 
   other widely distributed programs such as PGP. 
 
   The panelists seemed to me uneasy in answering this. 
   Primarily their view was that DES was "ubquitious," well- 
   known and tested by use. 
 
   However, when pressed by later questioners on this topic, 
   they expanded their view: that if another, stronger, 
   program became "ubiquitous" -- in wide use -- they would 
   support it as the standard of export. When it was pointed 
   out that PGP now fit this definition, the panel merely 
   repeated the statement about ubiquity without specifically 
   affirming or denying the PGP claim. Their poker faces 
   seemed uniformly in place to dampen a potential 
   inflammatory topic. 
 
   Perhaps other attendees will amplify this odd demeanor, but 
   it seems to me that the panel was attempting to avoid 
   commenting one way or the other on PGP's worldwide ubiquity 
   for unstated reasons. 
 
   I wonder if this was a nudge to the audience that the 
   informal spread of unapproved encryption is the best way to 
   establish its ubiquity and thereby to set a new standard 
   for export, sort of under the noses of the authorities -- 
   as if PGP was exemplary. 
 
   Recall that this fits the Clinton administration's way of 
   getting around the Croatian arms embargo -- the "no 
   position" position of sidestepping legality. 
 
   Also, I wonder if the panel wants avoid an open conflict 
   with the administration, the LEAs and the security agencies 
   about PGP. (Or do they know something about PGP that we 
   don't know, or have been led to think they do?) 
 
   Peter Neumann had pointed out earlier that crypto was going 
   to be ubiquitous, and fairly soon, no matter what. He noted 
   that it is the NRC's recommendation that LEAs take the 
   "long-term, pro-active" view about this and get on with 
   developing other technologies, and training personnel in 
   them, to fight computer crime -- like traffic analysis, 
   packet trace, etc. -- and to accept that prohibiting and 
   cracking crypto is not effective. (This may have been 
   diversionary, but he seemed sincere.) 
 
   Perhaps the panel is agreeing the crypto genie is out of 
   the bottle, and are advising the authorities to recognize 
   that stronger and stronger crypto is going to become 
   ubiquitous, and it's time to move on to other, presumably 
   less ubiquitious, cyber-crime fighting technolgies. 
 
   Perhaps the committee was briefed on these technolgies, or 
   maybe some members are even developing them -- Mr. Neumann, 
   for example, in conjunction with Ms. Denning, et al. 
 
   Those who plan to attend the June 6 session might want to 
   pursue the "no position" position about PGP's ubiquity, and 
   why. Diversionary sop, say, to cover the promotion of non- 
   crypto invasion of privacy. 
 
   Further, it would be helpful to learn more about what the 
   the committee members were told about "long-term" cyber- 
   surveillance technologies in the pipeline. 
 
   What bothered me more than anything else about the session 
   was that individual privacy got such short shrift by 
   panelists and by the audience.  While there was a bit of 
   discussion on personal privacy protection, government and 
   business, and their mutual back-scratching, seemed to the 
   the primary focus. 
 
   Pretty Lousy Privacy appears to be in the works, judging 
   from what was not disclosed in the session (and in the 
   report) about two 800-pounders working in concert at 
   citizen data gathering, mining, selling, controlling, 
   dominating -- at the expense of individual privacy, and, 
   shout it, liberty. 
 
   Peter Neumann got to me when he described the "downside" of 
   anonymity, encryption and security: how can we know who are 
   the criminals if we don't for sure who is who and know for 
   sure who is doing what? Not a single panelist disagreed 
   with his statement about this, but then I heard only a few 
   snorts from the criminal-fraught-fed audience. 
 
   I kept mum. Jesus, who knows who was recording every 
   titter and hiss -- besides anonymous beside me and me.

On Mon, 3 Jun 1996, John Young wrote:

>    However, when pressed by later questioners on this topic, 
>    they expanded their view: that if another, stronger, 
>    program became "ubiquitous" -- in wide use -- they would 
>    support it as the standard of export. When it was pointed 
>    out that PGP now fit this definition, the panel merely 
>    repeated the statement about ubiquity without specifically 
>    affirming or denying the PGP claim. Their poker faces 
>    seemed uniformly in place to dampen a potential 
>    inflammatory topic. 

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?

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.

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.

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