RE: encryption in XML & in SMIME

ed simon wrote:
>>>> one could... include the <From> element as input to the
>>>> digest of the message to be encrypted... using XML
>>>> Signature's Transform facility.

ed simon continued:
>>> the Transform... just makes the digest be calculated over
>>> both the sender's identity and the pre-encrypted message.

i replied:
>> the Transform fixes the "unauthenticated encryptor" problem
>> handily, [but] the double-hash adds no security at all.

ed simon replied:
> such a hash could be useful for system elements that need
> to verify the <From> field without decrypting the message.

hi, ed --

i think then that your Transform should be applied twice,
to incorporate the <From> element:
	1. with the plaintext,  as input to the encryption;
	2. with the ciphertext, as input to the signature.

in this version, no double-hash is necessary.  the blocker
and the recipient both apply the second Transform, so as
to verify the signature without seeing the plaintext.  when
the recipient decrypts the ciphertext, he sees the first
Transform's <From> element, compares this to the signed
external <From> element, and if they match, he concludes
that the message was not surreptitiously forwarded.

you could instead use the Transform to prepare two hashes
as above, and then sign the hashes.  but this requires
the creation and specification of this new "double hash"
mechanism, which isn't particularly necessary for any
security purpose besides your e-mail application.
i'm sure still other mechanisms can achieve the same goals
for email, but i just want to show that the double-hash
signature, despite its elegance, isn't really necessary
in this case.

also, please note that double-hashing is simplest when one
uses RSA to calculate signatures, because then one can put
the two 100+ bit hashes side-by-side into the 500+ bit RSA
input buffer.  for DSA signatures, it's not so simple,
because DSA uses a 160-bit input, which is too small for
two SHA-1 hashes concatenated together.  an extra hashing
step could solve this DSA problem, but of course the extra
step mars the elegance of double-hashing.

				- don davis, boston



--------------------------------------------------------------

At 9:39 AM -0400 9/22/00, Ed Simon wrote:
>You are right that the hash over the entire <EMail> does not
>add to securing wrt the "unauthenticated encryptor".
>
>However, I think such a hash could be useful for system
>elements that need to verify the <From> field without
>decrypting the message.  I am thinking, for example, of
>a module for blocking certain senders that wants to have
>the <From> field signed (and verifiable without having to
>read the message) so that it can block the kind of faked
>sender emails we discussed way back in August; the type
>where receiver B has blocked sender C so sender C creates
>an e-mail field to look like the sender is really A.
>(Note:  Requiring the blocker to be able to read the message
>simply to verify the sender could be a security loophole
>in itself.  The double-hash overcomes this.)
>
>Does the above example seem to be a plausible reason for
>having a double hash?  I ask this as someone who is not
>an email expert.
>
>Ed



-

Received on Friday, 22 September 2000 15:23:57 UTC