W3C home > Mailing lists > Public > xml-encryption@w3.org > March 2001

RE: Signing encrypted data

From: Ed Simon <ed.simon@entrust.com>
Date: Wed, 21 Mar 2001 12:03:04 -0500
Message-ID: <A0E1DEC54ED42F4884DD9EEA00ACE37106D187@sottmxs08.entrust.com>
To: xml-encryption@w3.org
Though Joseph's shorthand is appropriate, I just want to remind everyone
that just encrypt the content of the <DigestValue> elements in the XML 
Signature rather than encrypting the whole <Signature> element. 

This may be done before or after calculating the content of the 
<SignatureValue> element. If one did choose to encrypt the content 
of the <DigestValue> element AFTER calculating the signature value, 
I think it may then be necessary to encrypt the resultant content 
of the <SignatureValue> element to ward off the attack being discussed.

-----Original Message-----
From: Joseph Ashwood [mailto:jashwood@arcot.com]
Sent: Tuesday, March 20, 2001 3:19 PM
To: Amir Herzberg; xml-encryption@w3.org
Subject: Re: Signing encrypted data

Let me first attempt to clarify what I think you said (because there is
certainly a misunderstanding)
What you are discussing is:
Enc = Encrypt(data)
Sig = Sign(Enc)
publish Enc and Sig

What was being discussed in the portion you quoted was:
Sig = Sign(Data)
Enc = Encrypt(Data)
publish Enc and Sig
Sig = Sign(Data)
Enc = Encrypt(Data, Sig)
Publish Enc

Where the second is cryptographically superior for various reasons.

As to the suggestion of adding a salt. I think that it has merit in certain
limited situations, however as long as modern signature algorithms are used
(specifically non-deterministic ones) there is already a salt embedded in
the signature algorithm itself, in the DSA specification this is
specifically called k. Given this I do not see any general purpose reason to
add a salt. However there are certain situations where a salt-like value may
still be extremely desireable (e.g. audit logs where it can lead to provable
security), but I think those should be considered out of scope for
encryption/signing in general and are best dealt with by the field dealing
with exactly those issues.

Received on Wednesday, 21 March 2001 12:03:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:00 UTC