W3C home > Mailing lists > Public > xml-encryption@w3.org > January 2002

Re: Encryption code-set issues (Was Re: WOOPS: xmlenc Call 13:00 EST 20020107)

From: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
Date: Fri, 11 Jan 2002 10:25:58 +0100
To: Tom Gindin <tgindin@us.ibm.com>
Cc: xml-encryption@w3.org
Message-id: <1427443461.1010744758@crypto>
Hi Tom

--On Donnerstag, 10. Januar 2002 18:41 -0500 Tom Gindin 
<tgindin@us.ibm.com> wrote:

>       Sorry, I misremembered my reading of Schneier on the subject, and
> have just reviewed it.  I'm not sure why error extension is always a bad
> thing - I would think that it would be useful for transmissions on
> error-free channels.  In such a case, I don't see why PCBC mode is weaker
> than CBC, and CBCC seems to be stronger.
>       On error-free channels, for the reasons I gave, CBCC looks like the
> hardest mode to manipulate, with BC also better than CBC.  What do you
> think?

You're right that error-propagation in general is bad for communication 
links (link encryption) and would be desirable for XML encryption (where 
modifications -- by definition -- would only be made by attackers and not 
by noisy channels).

From what I see about history [Schneier], PCBC was used in Kerberos 4 but 
after discovering that the swapping of two ciphertext blocks can be 
undetected, they changed back to plain CBC in Kerberos 5.

CBCC looks nice and it could be made even harder if a cryptographic 
hashfunction instead of a CRC would be used for the check sum. In that 
case, the block encryption look be the same 'flavour' like the 
#kw-tripledes  key wrap where a hash is included in the ciphertext.

But - from what i thing the working group wanted to define, signcryption or 
similar things should be out of scope - always with the pointer: "Hey, if 
you wanna integrity, use XML Signature".

The reason why I raised the complete issue is that the Nonce attribute made 
no sense and I wanted an easy tweak to prevent the most obvious attack.

> Furthermore, if you're looking at UTF-8 data with an IV up front,
> the likelihood of failing to detect a single-block manipulation is 2**-8
> for ASCII with CBC and 8 byte blocks, 2**-36 for most non-Latin alphabets
> (Latin-1 and Latin-2 are slightly less sensitive than ASCII, but depend on
> the language), and 2**-27 or so for CJK.  For CJK in UCS-2 it's 2**-8,
> just like ASCII.  For CBCC the same values multiply with each subsequent
> block, and get a final 1/255 from PKCS-5 padding.
>
>             Tom Gindin

Hm, what does that mean? Are these the probabilities that a decrypted 
plaintext block with 50% bit errors does not result in a parsing error but 
in valid UTF-8? I can't follow the Latin/CJK stuff because I'm not a I18n 
guru, but for the PKCS5 padding, this depends on two factors:

1: What's the size of the last block: If the last block is a full block (so 
that you have to pad a full block) which means that the padding block 
contains no plaintext, you're right with your 2**-8 _IF_

2: You're padding properties are choosen well. If we look on how padding 
according to our spec, there's written:

The padded plain text would then be 0x616263????????05 where the "??" bytes 
can be any value

Well, we have different padding mechas with this property:

Plaintext           FF FF FF FF FF FF FF FF FF
padded Plaintext    FF FF FF FF FF FF FF FF FF ?? ?? ?? ?? ?? ?? 07

mechas to fill: ISO 10126d2 fills with random bytes, PKCS-7 with the value 
from the length field and X.923 uses zeroes. If you use ISO10126d2, I agree 
that the probability is that low because due to the random fill, there's no 
integrity check. But if the  PKCS-7 or X.923 padding are used and the 
decryptor checks that the pad-bytes are according to the used padding, the 
probability is no longer 2**-8:

ISO10126d2 Padding  FF FF FF FF FF FF FF FF FF 8C 39 16 BD 69 DB 07
PKCS-7 Padding      FF FF FF FF FF FF FF FF FF 07 07 07 07 07 07 07
X.923 Padding       FF FF FF FF FF FF FF FF FF 00 00 00 00 00 00 07


Christian
Received on Friday, 11 January 2002 04:25:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:02 UTC