- From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
- Date: Mon, 14 May 2001 23:39:52 -0400
- To: "Frederick J. Hirsch" <hirsch@zolera.com>
- cc: <xml-encryption@w3.org>
From: "Frederick J. Hirsch" <hirsch@zolera.com> To: <xml-encryption@w3.org> Date: Mon, 14 May 2001 15:24:56 -0400 Message-ID: <NEBBLPMKCKBLFHBJIHPCAEJMCOAA.hirsch@zolera.com> In-Reply-To: <034e01c0dca9$57ccd7c0$2a0210ac@livermore> >I have a couple of questions and comments on the encryption algorithms section. > >1. What advantage is there from the "integrity versions" of the alorithms, where >the SHA1 digest of the >encryption result (and possibly IV) is appended to the encryption value? Sorry if the description isn't clear. The hash in appended to the plaintext before encrption. The concept is that any tampering with the cipherdata or any attempt to decrypt with the wrong key will give output where the hash will not check. Of course, someone in the middle could change the algorithm identifier, so if you are going to depend on this, the application needs to require that it always be used and a change to an algorithm identifier which does not provide for the hash is interpretated as a fatal error. >>From a security standpoint, an attacker could simply generate a new encryption >result and associated digest and replace the entire value. > >So is this a traditional "checksum" simply to ensure against errors? But doesn't >an inability to decrypt accomplish the same thing? > >I think the document needs to explain the intent - I must have missed something >in the earlier discussions. See above. >3. Typos in 5.5.2 CMS Triple DES Key Wrap - encryptes -> encrypts, #6 "Left" -> >Let >Typo in 5.5.3 "sepcified" -> specified Sorry about the typos, Donald
Received on Monday, 14 May 2001 23:40:33 UTC