- From: Blair Dillaway <blaird@microsoft.com>
- Date: Wed, 30 Jan 2002 10:18:47 -0800
- To: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>, <reagle@w3.org>
- Cc: "Christian Geuer-Pollmann" <geuer-pollmann@nue.et-inf.uni-siegen.de>, "Dan Lanz" <lanz@zolera.com>, <xml-encryption@w3.org>
Hi all, Its been an interesting discussion on theoretical attacks and the value of integrity checks or encryption of the block cipher IV. I'm still not convinced of the true value in adding ECB-mode encryption of the IV. But, I can live with it so long as its optional and not mandatory. In most cases I believe the IV encryption buys you nothing and is just extra processing overhead. First, we should be clear that ECB-mode encrypting the IV does not prevent substitution attacks. I can replace the ECB-encrypted octets and the recipient will use the wrong IV on decrypt. The only difference between this and a clear-text IV is that the attacker can't control what IV value is actually used. Second, I believe the primary use of XML Enc will be to encrypt XML. Altering the IV to twiddle the bits in the first block of encrypted XML will result in invalid XML in almost every case. In some corner cases, it could result in an unexpected tag name or possible a scrambled first word in a text string. These amount to potential DOS attacks, but will not cause an app to misbehave in some insecure manner controllable by the attacker. Third, if someone is concerned about IV substitution attacks then we have a defined mechanism (XML Sig) for protecting the integrity of the IV and other data in the XML document. Many apps do have requirements for protecting the overall integrity of their XML docs and they shouldn't be required to also encrypt IVs. So let's give apps the flexibility to: 1) include the IV in the clear (REQUIRED); 2) include the IV in the clear and apply integrity seals(OPTIONAL); 3) ECB-mode encrypt the IV(OPTIONAL). Blair P.S. I have also pinged a couple of cryptographers about this issue and the response was a uniform - "Why, what are you gaining?". -----Original Message----- From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com] Sent: Monday, January 28, 2002 8:52 PM To: reagle@w3.org Cc: Christian Geuer-Pollmann; Dan Lanz; xml-encryption@w3.org; Blair Dillaway Subject: Re: Encrypting the IV - again. Was: Re: nonce length Hi, Last week I was at the IEEE 802.11 meeting in Dallas, particularly 802.11 Task Group i, which is working on security. I took the opportunity to ask several professional cryptographers about this. One suggested the same idea as I started to describe the problem, all the others supported encrypting the IV except one who declined to make any spur of the moment recommendations. Based on that, I'm in favor of going for ECB encrypting the IV. Donald From: Joseph Reagle <reagle@w3.org> Message-Id: <200201282254.RAA14246@tux.w3.org> Organization: W3C To: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>, "Donald E. Eastlake 3rd" <dee3@torque.pothole.com> Date: Mon, 28 Jan 2002 17:54:47 -0500 Cc: Dan Lanz <lanz@zolera.com>, xml-encryption@w3.org, blaird@microsoft.com References: <2942038760.1012259353@crypto> In-Reply-To: <2942038760.1012259353@crypto> >On Monday 28 January 2002 17:09, Christian Geuer-Pollmann wrote: >> Well, it seems to me that I do not need obvious facts to introduce >> necessary changes into the spec but well-known names ;-(( > >Hi Christian, I'm not advocating that necessarily, nor that we just >need a >reference in order to accept it. In fact, I'm not opposed to encrypting the >IV. I'm just saying that I prefer that *this* WG not take it upon itself to >introduce a "new mode". I'm most comfortable if the issue has >been addressed by others and it's been vetted/discussed/standardized, etc. >That's that. > >So, what do others people think? Should we encrypt the IV? (If so, >we'll do >it.) > >-- > >Joseph Reagle Jr. http://www.w3.org/People/Reagle/ >W3C Policy Analyst mailto:reagle@w3.org >IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature/ >W3C XML Encryption Chair http://www.w3.org/Encryption/2001/
Received on Wednesday, 30 January 2002 13:19:22 UTC