RE: Comments on the 6 Apr Draft

The draft specification provides info on this, though it may not be very
clearly worded in the current draft.  

The EncryptedData elements contain the octet sequence corresponding to
the encrypted,  serialized representation of one or more child nodes of
the element <1>.  That is all the recipient knows.  In the below
example, the first encrypted data holds E("<a/>"), where E is the
encryption transform.  When you decrypt, you get back the XML source of
"<a/>".  You then need to parse this source to get back the child
element <a/>.  But, the first EncryptedData could just as easily contain
E("here is some element text<a/><c/>").  The recipient won't know until
they decrypt.

Depending on the schema for the element <1>, the presence of 2
EncryptedData child element may, or may not, give you useful knowledge
about what has been encrypted.  Possible known plain-text attacks on the
EncyrptedData is something the WG has agreed will be discussed in the
specification.

Hope this explaination helps.

-----Original Message-----
From: Al Sutton [mailto:al@alsutton.com]
Sent: Thursday, May 17, 2001 11:24 AM
To: Blair Dillaway; Joseph M. Reagle Jr.
Cc: xml-encryption@w3.org; Philippe Le Hegaret
Subject: Re: Comments on the 6 Apr Draft


Hi,

I've just read the last message in this thread and I have a couple of
questions.

 If

<1>
    <a/>
    <b/>
</1>

goes to...

<1>
    <EncryptedData/>
    <EncryptedData/>
</1>

Then how can a and b be reconstructed as a and b during the decryption
process?, and if there is some method then shouldn't the encrypted
version
of the children not give any clue as to the number of children that are
encyrpted in order to limit the information given to a potential
attacker?

Hope these aren't stupid,

Al.

Received on Thursday, 17 May 2001 17:09:14 UTC