Re: Signing encrypted data

Amir Herzberg writes:
> 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

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.

> 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...). 

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.

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.

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.

Hal Finney

Received on Tuesday, 20 March 2001 13:15:40 UTC