RE: Pre-encrypted data

>From: 	timd@consensus.com[SMTP:timd@consensus.com]
>
>- Pre-encrypted data: I don't think pre-encrypted data is a good idea
>for
>the following reasons:
> 1) It violates the layer abstraction of the protocol as a transport;
>you've got a server feeding pre-encrypted data into the layer, and the
>client pulling decrypted data out of it. This seems like a fundamental
>complication of the model, and just feels wrong.
> 2) It's vulnerable to traffic analysis. Since any particular piece of
>pre-encrypted data, when transmitted, will have the same representation
>on
>the wire, I can determine what data people are accessing by watching
>their
>transactions and correlating the results.

There is no question that pre-encryption of data is ugly, both
aesthetically and cryptographically speaking.  It does indeed tend to
violate layering boundaries, and the mere act of handing out the same
key to many recipients smacks of bad cryptographic hygiene.  (On the
other hand, handing out the same data, pre-encrypted or not, to many
recipients is unlikely to do wonders for its confidentiality in any
event.)  The question is whether some people would be willing to accept
these penalties in order to reduce server CPU loads.

My understanding is that the number one complaint of secure server
operators is the enormous CPU drain (and consequently huge throughput
reduction) caused by the public-key operations associated with
transport-layer protocols.  There is little that can be done about this
problem, but for servers that send out large data streams,
pre-encryption would at least avoid exacerbating it.

Consider, for instance, a server with a mixed clientele requesting both
large data streams and small ones.  Using the figures that Tatu Yllonen
and I were batting around, a megabyte of data requires about a second of
CPU time on a Pentium to process--about the same as ten RSA decryptions.
 Hence every megabyte of (non-pre-encrypted) data sent reduces by about
ten the number of "low-volume" clients who may connect to the server
during that transmission.  This seems to me like a performance problem
that many servers would be willing to pay a substantial price to
alleviate.

It would be nice if we could simply delay this decision until after the
working group has produced an initial protocol; unfortunately, if
pre-encrypted data is *ever* to be supported, then a MAC method must be
chosen *now* which makes the later specification of a pre-encryption
feature possible.  I strongly recommend that this, at the very least, be
done.


				Daniel Simon
				Cryptographer, Microsoft Corp.
				dansimon@microsoft.com


>
>
>
>

Received on Friday, 26 April 1996 15:11:37 UTC