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
or
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.
                            Joe


----- Original Message -----
From: "Amir Herzberg" <AMIR@newgenpay.com>
To: <xml-encryption@w3.org>
Sent: Tuesday, March 20, 2001 8:38 AM
Subject: 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 15:35:57 UTC