RE: Signing encrypted data

Hal Finney wrote:

> Salt only stops dictionary attacks, where someone wants to 
> test a single
> plaintext against millions of hashed messages.  It does not 
> stop guessing
> attacks, where someone wants to verify whether a particular plaintext
> is what is hashed/signed.  Given that the salt is public, 
> anyone can hash
> the salt with the guessed plaintext and see if the signature verifies.

I (and others) use the term `salt` to refer to a randomizer, which may not
necessarily be a public value applied to many hashs. Maybe that's a
misleading use, so let's use the term `randomizer` instead. Such a
randomizer is used in the digital signature process (e.g. by prepending to
the data signed before hashing). To protect the confidentiality of the
signed data, the randomizer is not made public. That allows a single
signature to be applied to a message containing any combination of plaintext
and ciphertext of encrypted objects, as well as unencrypted objects. A
verifier knows that the message was not changed, including components of it
that the verifier cannot know the contents of. 
> 
> I suspect that we are miscommunicating, because I don't see 
> how you could
> expect any agents to verify a signature if they lack the 
> decryption key.
> The signature is on the plaintext.  Without the decryption key, these
> agents can't recover the plaintext, and therefore they can't verify
> the signature.

Yes, we were miscommunicating. I hope my goal, of allowing signature to a
message containing encrypted and non-encrypted objects, and of signing
(potentially) both ciphertext and plaintext, and allowing verification of a
signature by agents which do not have access to some encrypted objects, is
now clear. 
> 
> Of course you can sign AFTER encrypting; that has never been 
> a security
> issue.  The only question in that case is to design data structures
> that allow you to indicate whether the signature is on the ciphertext
> or the plaintext.  But if that is all you want to do, there is no need
> for salt and no need to encrypt the signature.

If your signature is (also) on the plaintext, the concerns are the same as
before. 
> 
> The issue arises when you sign BEFORE encrypting, but want to 
> leave the
> signature in the clear.  This is a security issue and allows guessing
> of plaintext.  That is the problem I was raising, and salt is of no
> value then.

I believe your statement applies to public salt value (as in Unix...). I am
not aware of any cryptographical 
problem in leaving the signature in the clear, if a randomizer is appended
to the plaintext portions before hashing them, and this randomizer is made
available only to entities which have the decryption key - other parties
only see the result of the hash. Any problem with this approach, which
supports important additional applications? 

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:39:44 UTC