Signing encrypted data

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