RE: Signing encrypted data

Re Ed's messsage below...
 
Providing an plaintext <SignatureValue> computed over the plaintext
<DigestValue> may allow a guessing attack, if no encrypted randomization is
used, against a low-entropy message. Therefore, one should either:
 
-- Encrypt both <SignatureValue> and <DigestValue> 
-- If the signature should be verifiable by entities without access to the
plaintext (& decryption key): sign (and digest) the ciphertext, not
plaintext. If furthermore a signature is needed also on the plaintext (e.g.
for non-repudiation), use an appropriate secure (non-revealing) commitment. 
 
The second option is what I'm interested in as it is needed for e-commerce
(and in particular e-payments) applications.
 
BTW: why can't you encrypt the whole <Signature> element, if verification
requires decryption capability anyway?
 
Best regards,
Amir Herzberg
CTO, NewGenPay Inc. 

See our demo and overview/tutorials on secure e-commerce in
http://www.NewGenPay.com <http://www.newgenpay.com/>  

-----Original Message-----
From: Ed Simon [mailto:ed.simon@entrust.com]
Sent: Wednesday, March 21, 2001 7:03 PM
To: xml-encryption@w3.org
Subject: RE: Signing encrypted data



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. 

Ed