W3C home > Mailing lists > Public > xml-encryption@w3.org > September 2000

Re: encryption in XML & in SMIME

From: Don Davis <dtd@world.std.com>
Date: Thu, 21 Sep 2000 14:28:53 -0500
Message-Id: <l03110709b5efd3b5d14c@[208.192.101.178]>
To: "PJM Veugen" <Veugen@fel.tno.nl>, Ed Simon <ed.simon@entrust.com>
Cc: Don Davis <dtd@world.std.com>, xml-encryption@w3.org
dear mr. veugen and mr. simon --

mr. veugen is right;  the double-hash signature
is as weak as Sign( Encrypt( Msg)).  the only
repair that i can discover is roughly equivalent,
in complexity and in security, to:

	Encrypt( Sign( Encrypt( Msg))).

on the other hand, i think ed's repair (adding a
name to the signed plaintext) is perhaps overkill.
if you're willing to include names in the hashed
plaintext, then neither double-signing nor double-
hashing is necessary, anyway.  that is, A can just
send:

	Sign( Encrypt( From: A, msg-body)) ,

the recipient B must check that the signer's name
matches the "From: A" line, so as to be sure that
A encrypted the message for B's eyes, i.e., that
A wanted B to see the message.

i'm disappointed that the double-hash signature
doesn't work.  it seemed to be a good alternative
solution, for applications that don't want to put
names inside the message-body.

				- don davis, boston

-----------------------------------------------------------------
Ed Simon wrote:
>>> Just had a thought as to how one can get the same
>>> effect of sign/wrap/sign without actually having to
>>> sign twice.

	[hash    plaintext message-body,
	 encrypt plaintext message-body,
	 hash    ciphertext with mail-header,
	 sign    both hashes]

Thijs Veugen replied:
>> I noticed your elegant solution to the sign/wrap/sign problem
>> but found a potential flaw. What about the following "attack":
>> 1. A sends a message to B using your method of signing the two
>>    digests.
>> 2. C intercepts the message, and obtains the two digests by
>>    decrypting the signature.
>> 3. C creates a new <EMAIL> element by changing <From>A</From>
>>    into <From>C</From> and computes a new digest for it.
>> 4. C makes a new <SignedInfo> element by combining the new
>>    digest and the other old plain text digest.
>> 5. C completes his XML signature.
>> 6. C sends the adjusted message to B and has stolen the
>>    contents from A (without actually knowing the contents).

Ed Simon eplied in turn:
> To avoid the second signing, one could (as you suggest) include
> the <From> element as input to the digest of the message to be
> encrypted.
Received on Thursday, 21 September 2000 14:31:58 GMT

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