RE: Signing encrypted data

Joe Ashwood replied to my note as follows: 

> 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

This is correct - but only a part of the potential use I seek. I want to
allow a signature application to be applied to a complex message containing
unencrypted as well as encrypted objects, and signing (optionally) a
combination of unencrypted objects as well as plaintext, ciphertext or both
versions for encrypted objects. This is important for many applications,
esp. electronic commerce e.g. payments (in particular, I am quite sure an
implementation of SET requires this feature; and certainly the more general
and extendible payment protocols we develop require such features). 
> 
> 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.
Which reasons? Again excuse me if this issue was throughly discussed
previously. 
> 
> 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. 

Signature algorithms often use indeed a randomizer, but this is a public
randomizer (always sent with the signature) and its goal is to prevent
choosen-plaintext attacks. This does not prevent a guessing attack against a
signature of the plaintext. 

Furthermore, my concern is not so much about security. First, in the secure
electronic commerce and payment applications we work on, this is not a
likely threat (as the plaintext has substantial redundancy anyway).
Secondly, were I concerned, I could always easily add a randomizer in my
application. My concern is about the recommendation in the spec, which I
find misleading. Furthermore and more important, I think that the spec
_should_ define mechanisms to allow the needed interactions between
signature and encryption (including signing a message with unencrypted,
plaintext and ciphertext). 

Best regards, 
Amir Herzberg
CTO, NewGenPay Inc.  

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

Received on Wednesday, 21 March 2001 02:54:24 UTC