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

Re: padding values



Bill,

	I've looked at all the message traffic since the Memphis meeting,
and I do not see any reference to padding being algorithm-specific, as you
suggest.  Putting random values in tbe padding field has the well-known
advantage that it helps counter known plaintext attacks that might result
from padding with a constant value, e.g., "0".  However, putting in the
integer values you cite seems to reintroduce this sort of problem, if
anyone didn't believe that known plaintext didn't exist from the
encapsulated payload (as Bellovin analyzed in the case of both tunneled and
transport mode uses of ESP).  I can imagine an integrity bebefit for
inclusion of such padding, in a cipher that provides error propogation to
the end of the block, but that is not the case for CBC.  It would seem that
the major benefit for the padding you describe is the ability to detect
mods to the last block (only) if no integrity service is elected, which
seems a rather slim rationale for this approach to padding.

	Still, the issue you raise is a good one, i.e., do we want to leave
definition of the contents of the padding field to the algorithm, or
standardize it in the ESP spec.  While I have cited one example of why
algorithm-specific padding might be useful, I'm not sure that there are
others.  Also, note that this makes the interface to the decryption module
slightly more complex, i.e., if one is to take advantage of the checking
done on t his field, one must be prepared to receive an error indication of
a sort that otherwise would be generated only by the
authentication/integrity portion of ESP processing.  With arbitrary
padding, the decryption module merely decrypts the buffer and returns the
purported plaintext, without trying to check for integrity (which is,
arguably, not a function for a decryption routine).

Steve




References: