Re: block encryption algorithm padding

Joseph,

Thanks for your suggestion but the problem arrives when you are decrypting
the message and not when you are encrypting it (the libraries do padding
check before returning the result). In my case, I have less problems because
I have access to OpenSSL source code and the problem could be fixed
by partial re-writing a couple functions.
Personally I am not sure that you argument about "reducing the know/guessed
plaintext" is less mythical than "better verification" (this plain text 
is at the
end of the message, XML content has a lot of "guessable" test itself, 
etc.).
As I said before from my point of vew the current proposed padding makes
XML Enc non-interop with RFC1423 and from my expirience it makes
harder to follow XML Enc standard for implementors.

Aleksey



Joseph Ashwood wrote:

>----- 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
>