compression, privacy, and authenticity transforms

[rogaway@cs.ucdavis.edu (Phil Rogaway)]

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 might 
 > 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-separation 
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 transforms 
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" as 
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 Transform (for 
example) (used in the context of an AH).  The only "integration" issue we would have 
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

---

• Prev by Date: Re: Comments on latest IPSP
• Next by Date: compression, responses to q's
• Prev by thread: Re[2]: ipsec compression support
• Next by thread: Re: compression, privacy, and authenticity transforms
• Index(es):
  • Main
  • Thread