PKCS#5 padding is simple to code, however:
- having to pad at all is an inconvenience for some applications where
space is tight
- having to pad is inconvenent for streaming (need to know ahead when
the last block is)
- there are people who have used non-PKCS#5 padding, and instead made
up their own (clueless people, etc; but it's one more thing)
- the PKCS#5 padding end tag offers tends to encourage programmers to
make their implementations into decryption oracles which can be used
as an attack point (viz the interactive attack against block ciphers
using the misformed padding error)
- the psuedo-IV handling (requirement not repeat IV for same key) is a
non-issue in most contexts where the key changes everytime anyway
(symmetric key transport already covers cases in PGP where the
symmetric key is derived from a password)
Adam
On Thu, May 01, 2003 at 07:15:39PM +1200, Peter Gutmann wrote:
Adam Back <adam(_at_)cypherspace(_dot_)org> writes:
On use of CFB instead of CBC, I think this is actually goos because it avoids
the whole padding issue which people frequently get wrong with bad security
implications. Plus it's simpler to not have to pad. Error recovery is a
phantom property, as in no mode is it secure.
PKCS #5 padding is trivial to get right, any minor gains are more than made up
for by the painful and clunky pseudo-IV handling, particularly since most
crypto implementations have an "IV, data, go"-type interface which requires
error-prone manual handling of the pseudo-IV.
Peter.