Re: block encryption algorithm padding

----- Original Message -----
From: "Aleksey Sanin" <aleksey@aleksey.com>
> I am not sure I have enough expertise in block ciphers attacks but I did
> heard
> nothing about possible "padding  guess" attack and I have no reasons not
> to trust smart guys from OpenSSL, BSAFE and NSS teams.

As a cryptanalyst I can explain the decisions. By padding with random data,
no information about the final block can be verified. This has obvious
benefits in reducing the amount of known/guessed-plaintext that is available
to an attacker. That is the benefit, and it is a good one.

The only benefit of the pad with N method, is that it allows better
verification. This is purely mythical. Let's take for example a block cipher
in CBC mode. The attacker intercepts this, so we're going to alter it. It's
a number of blocks long. For the sake of simplicity it is only desirable to
alter block K (K <= N-2). It's simple enough to alter in any way desired
that block, for the sake of argument, let's simply set it to all 0s. As a
side benefit I corrupt the K+1 block as well. After that K+1 block though,
everything will decrypt normally. So unless you want to believe that all
alterations must occur in the last 2 blocks, there is little reason to use
the pad with N method.

Now are the OpenSSL, BSAFE, and NSS teams really all that smart? Of those
only the BSAFE team had assumedly direct access to a substantial
cryptographic mind (BSAFE had access to Rivest). As it turns out Rivest
actually has very little to do with BSAFE besides clearing the cipher-choice
(and most of the time he doesn't even do that), he spends his time on other
pursuits of more interest to himself and the company.

If you'd like to use one of those libraries, I'd suggest doing the
following:
Padding according to our spec
submitting the padded version to the library
chopping the last block off the encrypted text received back from the
library

This will address the problem completely, assuming that they do in fact meet
the RFC you stated.
                Joe

Received on Thursday, 11 April 2002 14:06:36 UTC