RE: Xenc Requirements req - comments on security and other issu es

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 UTC