Re: block encryption algorithm padding

----- Original Message -----
From: "Tom Gindin" <tgindin@us.ibm.com>

>       Perhaps I should have been more explicit.  IMHO PKCS#5 (or X.923)
> causes less additional harm when the item encrypted is XML or ASN.1
BER/DER
> than when the data encrypted is arbitrary binary data, because you already
> have known text near the front of those message formats.  While I don't
see
> any reason to prefer the two deterministic paddings to ISO 10126, XML
> encryption is one of the places where not permitting PKCS#5 has the least
> point.

But also one of those places where simplicity is greatly encouraged, and
adding another mode for padding would raise the complexity.

>       Just speaking as a sometime implementor, I would use PKCS#5 or X.923
> if they were what my encryption library supported, but if I had a choice
of
> all three modes I'd use ISO 10126.

As someone who has implemented encryption in very large quantities, I use
other termination modes whenever possible, but the random padding is among
the best of this type of termination mode.

> I don't see the point in banning the
> use of those modes, especially since I know of commercially available
> libraries whose only padding mode for Triple-DES is PKCS#5 (yes, I know
how
> to code ISO 10126 as a separate layer of code, but it's unrealistic to
> expect most implementors to do that).

Instead you'd prefer to add less secure modes of operation? As far as I'm
concerned people should start putting 3DES out to pasture, it's slow, and
it's security is becoming borderline. Supporting an alternate padding mode
simply because it's convenient for a few implementations of an algorithm
that is slowly falling down the foodchain, does not seem like the wisest
option.

> The only thing in favor of leaving
> them out of the specification is that because PKCS#5 and X.923 are legal
> (if peculiar) cases of ISO 10126 it is not strictly necessary to put them
> into the encryption method -

And because they are less secure, and because that would require changing
the spec, and because adding them would increase the complexity of an
implementation. A better argument could be made to add ciphertext-stealing
to the spec, it's just as simple, offers security that's at least as good,
adds only the same amount of complexity and requires the same scale of spec
changes. There's a reason not to add that to the spec though, because of
those complexity changes, and because of the spec inflation. We are not
condemning these other modes, they can still be added by an implementation,
it's just that a single simple, well reviewed, padding mode has been
selected for the official requirements. If you happen to have enough
cryptanalytic ability at your desposal to determine that X is superior to Y,
you can enlarge your own implementation to make use of X regardless of
whether it's in the spec or not.

> you'll just get failed decryptions when the
> encryptor didn't use the padding which your library supports.  The worst
> problem caused by this would be if the decryptor's library supported
PKCS#5
> and X.923 separately, but not ISO 10126, and the decryptor picked the
wrong
> padding mode because he couldn't tell which one was used by the encryptor
> (who had used one of the two weaker modes).

This is exactly the reason why only a single mode was chosen, there is
precisely 0 chance of picking the wrong padding mode for decryption,
simplifying the implementation requirements.

>       In short, while only inertia keeps PKCS#5 and X.923 in use, the
> particular type of inertia which does so is the existence of well-tested
but inferior
> and trusted

For no good reason

> code libraries which use one of these methods in preference to
> ISO 10126, and we can't just wish that away.

But since we control the specification we can dictate whatever desires we
have. Since our collective desire is primarily to make this as secure as
possible (even at the potential cost of eliminating some sources for
libraries initially) the group as a whole has decided to use random padding
because of this. Over time the libraries will support it as it becomes
necessary for them to make sales, or even since it's such an easy thing to
program, before then. It is not a matter of wishful thinking, it's a matter
of deciding of making a decision that offers what has been judged as the
best security-ease of implementation trade-off. It can be easily learned
from prior experience (particularly with PKCS implementations) that only
required portions are implemented in many libraries, so making this optional
would only increase the size and complexity of the spec, where no one would
be able to use it (just as 40-bit RC2 is still the default standard for
S/MIME), making it required would unnecessarily raise the complexity of all
implementation with the potential to risk the security of the communications
when a poor choice is made by the implementer.

So when it comes down to it, the only reason to add this is to support
libraries that were designed poorly from the beginning. If we're going to
start doing that there are several libraries out there that have
implementations of DES that we have to add, more than a few homebrew
ciphers, a number of obscure termination modes, and of course all the bad
implementations of ciphers that are out there. I'd be against any of these
additions for the same reasons, they are bad for security, and they raise
complexity of both the spec and implementation.
                        Joe

Received on Friday, 19 April 2002 04:17:22 UTC