Signing encrypted data from Amir Herzberg on 2001-03-20 (xml-encryption@w3.org from March 2001) (original) (raw)

Hi folks,

As some of you know, our payment project was recently spun-off from IBM. Since then, most of my technical work is on a new release of our secure payment protocols. (BTW, my overviews/tutorial/lectures on crypto, secure e-commerce etc., are now in the demo and library areas of our new site www.NewGenPay.com). We hope to create infrastructure to many payment instruments, so the system is very open and extendible, with APIs and also using XML and standards as much as possible. In particular, we think of using DSIG and XML encryption, if we can work it out.

I hope you will be understanding to some issues, questions and comments I have about the current spec (which I read quite carefully). I looked up the archive a bit, but of course many of the issues may be long dead dogs by now, again I appreciate your understanding.

For efficiency I think I'll better introduce my questions and issues one by one. So let me begin...

The first issue I'm interested in is signing encrypted objects. A comment towards the end of section 2.6 says:

A separate, but important, issue is introducing cryptographic vulnerabilities when combining digital signatures and encryption over a common XML fragment. Hal Finney has suggested that encrypting digitally signed data, while leaving the digital signature in the clear, may allow plaintext guessing attacks. To address this vulnerability, one should encrypt the digital signature whenever the signed data is encrypted. As noted above however, that this may be impossible as the encryptor can not determine all digital signatures over a given fragment with any certainty. Hence, we recommend, but don't mandate, encryption of the appropriate Signature element(s) when encrypting signed data.

The standard solution for signing secret data is to include a random salt field in the signed data. This puts only the hash of the content together with the random salt in public domain, and therefore prevents guessing attacks. This is cleaner and more efficient than encrypting the signature block. Furthermore and more important, it allows using a signature containing encrypted objects to be validated by agents which do not have access to the decryption key, which is required by some (many?) applications (e.g. secure payments...).

It would be easy to define such a salt tag, which is used just for this purpose (and application can ignore).

What do you say?

Best regards, Amir Herzberg CTO, NewGenPay Inc.

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

Received on Tuesday, 20 March 2001 09:35:34 UTC