[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compression, privacy, and authenticity transforms
Phil:
I strongly disagree. We can take advantage of the properties of the
encryption algorithm and mode to reduce the requirements on the complexity
of the integrity mechanism iff the integrity check value is protected by
the encryption. This also means that one key can be used to provide
confidentiality and integrity.
The reduced computation and reduced key management complexity make this
type of combination very attractive.
Russ
______________________________ Reply Separator _________________________________
Subject: compression, privacy, and authenticity transforms
Author: rogaway@cs.ucdavis.edu (Phil Rogaway) at internet
Date: 5/5/95 5:25 PM
Paul writes:
> The use of compression with encryption needs to be defined as a new security
> transformation. These transformations are currently identified in the
> documentation as a arbitrary string of characters (e.g. DES-CBC-FOO). It
migh
t
> be reasonable to define for your needs a DES-CBC-MD5-LZ77 transformation.
I don't quite agree.
Encryption, authentication, and compression are mechanisms intended for three
orthogonal purposes. When (i) the individual mechanisms are correct, (i)
key-se paration
has been properly performed (for encryption and authentication), and (iii) the
mechanisms are applied in the correct order, these mechanisms can not
"interfere"
with one another. So wouldn't it be better to treat all of these types of
trans forms
completely separately -- i.e., no "composite" transforms? If we start
supporting
transforms like DES-CBC-MD5-LZ77, we're going to get a real explosion in the
number of transforms we'd feel it useful to provide. We're also unlikely to
"get right" these composite transforms. Better is to regard "DES-CBC-MD5-LZ77"
a s
three different transforms: first an LZ77 Transform (used in the context of
<TBD >);
then a DES-CBC Transform (used in the context of an ESP); then an MD5-KXK
Transfo rm (for
example) (used in the context of an AH). The only "integration" issue we would
h ave
to worry about is (key separation and) a statement in the architecture document
explaining that you should not use a compression transform after an encryption
transform, and you should not use an encryption transform after an
authentication
transform.
Phil