RE: encryption in XML & in SMIME

The double hash solution (with the Transform fix) is
quite feasible for our XML e-mail with XML Signature
scenario. (Transforms are an integral part of XML 
Signatures).  Note: that the Transform does not force
the sender name to be part of the message, it just makes
the digest be calculated over both the sender's identity
and the pre-encrypted message.  

Ed Simon
Software Engineer, Entrust Technologies
ph: (613) 247-2583

-----Original Message-----
From: Don Davis []
Sent: Thursday, September 21, 2000 3:29 PM
To: PJM Veugen; Ed Simon
Cc: Don Davis;
Subject: Re: encryption in XML & in SMIME

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

	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:50:19 UTC