Pre-encrypted data

In the recent discussion of the STLP "strawman", several issues have come
up; here are my thoughts on a few. For what it's worth, I'm in the middle
of implementing SSL 3.0 right now.

- 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.
 3) It offers minimal benefit. I don't see how it can offer any security
benefit, since the information on how to decrypt the data has to be
available to the client anyway. I think the performance benefits are
minimal; some stream ciphers (such as RC4) are very fast, and if that's too
much to pay, or if the MACing is too expensive, I think the right thing to
do is to allow that to be driven by better implementations or improved
algorithms. For the hypothetical servers which are supplying a large
quantity of secure data, it doesn't seem inappropriate to require them to
make an investment in hardware encryption support to deliver high
performance.

 - Tim Dierks

Tim Dierks  --  timd@consensus.com  --  www.consensus.com
Head of Thing-u-ma-jig Engineering, Consensus Development

Received on Thursday, 25 April 1996 22:50:10 UTC