- From: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
- Date: Tue, 15 Jan 2002 13:36:59 +0100
- To: Tom Gindin <tgindin@us.ibm.com>, reagle@w3.org
- Cc: XML Encryption WG <xml-encryption@w3.org>
--On Montag, 14. Januar 2002 18:52 -0500 Tom Gindin <tgindin@us.ibm.com> wrote: > Since I'm not a subscriber to xmlenc (maybe I should become one), I > wandered into this a little inadvertently. My posting of Friday afternoon > didn't make it to the group, but I'll send you a copy shortly. Briefly, > Christian is right about the behavior of CBC mode, which is an argument > for XMLENC encouraging CBCC or BC instead - the IV or nonce doesn't go > far. > Tom Gindin Tom, we are fighting in different fields: I say that the Nonce is not necessary for _ALL_ block cipher modes that use an IV, because the IV brings entropy into the internal state of the mode and the Nonce cannot bring more entropy than the IV. So what I want is the Nonce removed from the processing model. You say that CBC in general is not the best solution because for XML Encryption it would be nice to have a cipher with infinite error propagation. What you want (as far as I understood) is to introduce new block algorithms. These both topics are independant of each other. Implementors can easily introduce a new xenc:EncryptionMethod using an own algorithm URI like http://www.ibm.com/XML/Encryption/#aes128-cbcc but the processing model with Nonce handling is something which is nested deep in our spec. From what I see, CBC is not a bad idea as a basic REQUIRED algorithm, because it is used very often in existing systems and people have experience using it. So I would mandate against _substituting_ CBC through other modes like BC or CBCC, because CBC is the workhorse for many existing systems. Christian
Received on Tuesday, 15 January 2002 07:33:40 UTC