[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Photuris - deriving per-algorithm keys

 > "Slightly different keys" for different algorithms is not enough!!!
 > 
 > Such keys have to be "independent and random". In particular, knowing
 > One of the keys (e.g., for DES) should leak nothing about the other key
 > (e.g., for keyed-MD5).
 
Hugo is, of course, absolutely right.  

Performing key separation is essential; in its absence, the architecture 
should not claim to be transform non-specific.   

I have earlier tried (unsuccessfully) to draw attention to this gap. 
Perhaps Hugo's note will be more successful.

   ... 

 > Have you ignored key separation?  It wasn't clear to me if you expect
 > key separation to be done by the key-distribution mechanism or within
 > the various AH and ESP mechanisms.   In the first case this is an
 > architectural requirement which you are effectively levying on the key
 > distribution mechanism, so you should say so; in the second case, you
 > are levying this requirement on each MAC and encryption mechanism, and
 > you should say that.
 >
 > Eg:  Suppose you distribute a session key for A-->B and you use this
 > SAME session key for DES-CBC-MAC authentication and DES-CBC encryption
 > (in an AH and ESP mechanism, respectively).  Then clearly the
 > encryption mechanism destroys the authenticity you thought you were
 > getting from the authentication mechanism.  There are two outs:  the
 > architecture specifies that distinct session key distributions are
 > used for each mechanism; or else the architecture lets mechanisms
 > share distributed keys, but each mechanism is expected to produce and
 > act using its own key variant, said key variants not being related to
 > one another by any efficiently-computable means.

   ...
 
 > Key separation is very important.  A failure to perform proper key
 > separation will almost certainly cause security "interaction" problems
 > if the set of supported MAC and encryption mechanisms becomes
 > reasonably populated.  If the architecture document doesn't mandate
 > who does this, no one will do it.
 > 

                                 2/16/95
                                 e-mail to Atkinson et. al.