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

Padding complexities



Steve,

I think the padding issue may be a bit more complicated than might be first
thought. The implicit padding rules of AH and ESP (for ICV computation)
specify padding the message to equal the blocksize of the message digest
algorithm. However, at least MD5 (I don't have FIPS 180-1 in front of me at
the moment) will add an additional 448 bits (the first being a 1 and the
remainder a 0) onto the end of a presented message with a length that is a
multiple of 64 bytes, then add 64-bits that encode the length of the
message to the end of that. Consequently, if an implementation strictly
follows the existing internet drafts, it  zero pads for AH/ESP then pads
another 64 bytes according to the MD5 algorithm specification. Both the
AH/ESP zero padding and the MD5 padding are not transmitted.

While I agree that both AH and ESP should be changed so that the padding
rules specified in the authentication algorithms are followed, a big
question is what do existing implementations do? If they follow the
existing AH and ESP specs and use a standard implementation of either MD5
or SHA-1, they would add an additional 64 bytes onto the end of a padded
message.

I am surprised that no implementors have addressed this issue on the list,
since changing the AH and ESP specs could mean deployed implementations
would fail to interoperate with those following the eventual standard.

Dan




Follow-Ups: