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

RE: Signing encrypted data

From: Amir Herzberg <AMIR@newgenpay.com>
Date: Thu, 22 Mar 2001 11:18:37 -0000
Message-ID: <078EE8822DCFD411AAA1000629D56ADC05226F@IMP01>
To: xml-encryption@w3.org
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. 

Received on Thursday, 22 March 2001 04:15:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:02 UTC