From: Joseph M. Reagle Jr. <reagle@w3.org>

Date: Thu, 29 Mar 2001 17:24:14 -0500

Message-Id: <4.3.2.7.2.20010329155939.02ea1008@rpcp.mit.edu>

To: Amir Herzberg <AMIR@newgenpay.com>

Cc: "XML Encryption WG " <xml-encryption@w3.org>

Date: Thu, 29 Mar 2001 17:24:14 -0500

Message-Id: <4.3.2.7.2.20010329155939.02ea1008@rpcp.mit.edu>

To: Amir Herzberg <AMIR@newgenpay.com>

Cc: "XML Encryption WG " <xml-encryption@w3.org>

At 16:09 3/29/2001 +0100, Amir Herzberg wrote: > > >1. In section 5 (Security), item 3.2: I believe there is a bigger > potential > > >security exposure using `encrypt before you sign`, specifically that ... > > > > The non-repudiation for signing (E_k1(m1)) stands if that is what is > signed. > > Of course, what that blob means is an issue of the transforms and how they > > are written; this is addressed in the signature spec. (There are XSLT > > transforms one could do before signature which has a similar problem.) As > > you suggest, doing the transforms well mitigates this problem, if you want > > to suggest some text for the spec, I think that would be a > > good thing. > >The problem is beyond that of a transform, since it is the result of the >encryption itself This is really an aside, but that is what I mean and we agree. If you have a message, you transform it (via encryption or XSLT) and sign the result, you *really only* signed the result. However, given user cognizance and designer care, applications will want to argue that a signature on the result also implies intent on behalf of the signer about the original message as well. What that implies is partly dependent on the users' awarness (did they know they were signing a document with an XSLT style sheet that made fine print white on white, or the data when decrypted?), logic (how does the result formally relate to the original), and security (does the transform introduce the likelihood of replacement or birthday attacks where alternative messages can be substituted in place of the original and still yield the same result?). (Traditionally, people haven't thought of encryption as a transform on signed data, but in xmldsig we generalized transforms. Encryption is an important transform, but it should be thought of as a transform none-the-less -- all the warnings about transforms apply.) >Sure. I'll provide it together with my recommended change to item 1 as well >(see discussion below): > >sign before you encrypt: weaknesses if a plaintext hash (inside an XML >Signature) is provided along with the encrypted data, unless proper >precautions are taken (such as properly adding an encrypted random string >to the plaintext before hashing). {List: Finney} What does the text in the parenthesis mean? (Which email in the archive (or spec) specified this?) >encrypt before you sign: potential for fraud if one is induced to digitally >sign encrypted data that may not be what the user expected. Also, there may >be more than one <data,key> pairs resulting in the same encrypted data, >therefore special care must be taken in the selection of the encryption >function or in the signature process to provide non-repudiation of the >data. .{List: Wang, Ashwood} Ok, see (includes additional tweaking): http://www.w3.org/Encryption/2001/03/21-xml-encryption-req#sec-Security > > >2. Ditto, item 2: I think this volunerability implies there should be an > > >integrity check mechanism as part of XENC, which I believe is not in > the doc > > >(section 3) presently. > > > > 3.4.7 states: > > Message Authentication {FTF1}: AES/3DES with SHA1 is optional to > implement. > >Yes, but that's authentication, where for that voluerability authentication >may be sufficient; furthermore using MAC may not be feasible if we use >public key encryption and the parties do not (wish to) share a key. Ok [def:MAC]. You want a 'encryption checksum'. Unfortanately, I've been unable to find a reference and specification for OEAP. Because of this, my hope to publish ASAP, and because I've been able to vet the other algorithm choices with the WG, I don't think OEAP will make it into the first draft, but its open for consideration by the WG for your stated purposes. [def:MAC] http://www.garlic.com/~lynn/secgloss.htm#t136 message authentication code vs. Message Authentication Code (N) Capitalized: '(The) Message Authentication Code' refers to an ANSI standard for a checksum that is computed with a keyed hash that is based on DES. (Also known as the U.S. Government standard Data Authentication Code.) (C) The ANSI standard MAC algorithm is equivalent to cipher block chaining with IV = 0. (D) Not capitalized: ISDs SHOULD NOT use the uncapitalized form 'message authentication code', because this term mixes concepts in potentially misleading way. Instead, use 'checksum', 'error detection code', 'hash', 'keyed hash', 'Message Authentication Code', or 'protected checksum', depending on what is meant. > > At the FTF we said: > > Resolution: If anyone is an advocate of specifying encryption with a > > corresponding integrity algorithm, please write up a proposal - the > > workgroup is amenable to it, but it is not required. ... > >I'll give a try at providing something later, if time permits. Ok, Eastlake has volunteered to work on the algorithm section, so please coordinate with him. >[1] Handbook of applied cryptogrpahy, Menezes, van Oorschot and Venstone, >section 8.7.3, p. 311. Excerpted for future reference: http://cacr.math.uwaterloo.ca/hac/ 8.47 Definition A public-key encryption scheme is said to be *semantically secure* if, for all probability distributions over the message space, whatever a passive adversary can compute in expected polynomial time about the plaintext given the ciphertext, it can also compute in expected polynomial time without the ciphertext. Intuitively, a public-key encryption scheme is semantically secure if the ciphertext does not leak any partial information whatsoever about the plaintext that can be computed in expected polynomial time. 8.7.3 Plaintext-aware encryption While *semantic security* (Definition 8.47) is a strong security requirement for public-key encryption schemes, there are other measures of security. 8.60 Definition A public-key encryption scheme is said to be *non-malleable* if given a cipher-text, it is computationally infeasible to generate a different ciphertext such that the respective plaintexts are related in a known manner. 8.61 Fact If a public-key encryption scheme is non-malleable, it is also *semantically secure*. Another notion of security is that of being plaintext-aware. In Definition 8.62, valid ci-phertext means those ciphertext which are the encryptions of legitimate plaintext messages (e.g. messages containing pre-specified forms of redundancy). 8.62 Definition A public-key encryption scheme is said to be *plaintext-aware* if it is computa-tionally infeasible for an adversary to produce a valid ciphertext without knowledge of the corresponding plaintext. In the random oracle model, the property of being *plaintext-aware* is a strong one coupled with semantic security, it can be shown to imply that the encryption scheme is *non-malleable* and also secure against adaptive chosen-ciphertext attacks. Note 8.63 gives one method of transforming any k-bit to k-bit trapdoor one-way permutation (such as RSA) into an encryption scheme that is plaintext-aware and semantically secure. 8.48 Remark (perfect secrecy vs. semantic security) In Shannon's theory (see x1.13.3(i)), an encryption scheme has *perfect secrecy* if a passive adversary, even with infinite computa-tional resources, can learn nothing about the plaintext from the ciphertext, except possibly its length. The limitation of this notion is that perfect secrecy cannot be achieved unless the key is at least as long as the message. By contrast, the notion of *semantic security* can be viewed as a polynomially bounded version of perfect secrecy -- a passive adversary with polynomially bounded computational resources can learn nothing about the plaintext from the ciphertext. It is then conceivable that there exist semantically secure encryption schemes where the keys are much shorter than the messages. Although Definition 8.47 appears to be stronger than Definition 8.46, the next result asserts that they are, in fact, equivalent. 8.49 Fact A public-key encryption scheme is semantically secure if and only if it is polynomi-ally secure. __ 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 Thursday, 29 March 2001 17:24:35 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Tuesday, 27 October 2009 08:42:18 GMT
*