RSA message integrity I wish to send some small data that RSA alone can encrypt, and I send a shared secret along with it.

A --&gt; B ; RSA(data||shared_secret)  // B will verify the shared_secred and authenticate A;


vs

A --&gt; B ; RSA(data||shared_secret) || SHA-256(data||shared_secret)


RSA is RSA-OEAP, not something home grown.

Will verifying the shared secret be enough for message integrity and authenticity? Or, should I also send a hash of the message?
I wish to ask because it seems redundant to send twice as much data if I do not need the hash.
If shared_secret is a plain text password as we are told, then the second method, which sends
 &nbsp; RSA-OAEP(data||shared_secret) || SHA-256(data||shared_secret)
is unsafe.

That's because a guess of data allows to mount an off-line check of the password by comparison to the known SHA-256(data||shared_secret). That's ideal for password cracking. That also applies if we change SHA-256(data) to HMAC-SHA-256(shared_secret, data), which is a way of constructing a MAC from a hash with a security proof/argument.

For the same reason, that construction also compromises the confidentiality of data.



It remains to determine if A sending
 &nbsp; RSA-OAEP(data||shared_secret)
to B (computed with B's public key), and having B decipher (with B's private key) and verify shared_secret, is enough for insuring integrity and authenticity of data; assuming of course, that no adversary could have learned shared_secret.

My answer is: no, that does not give the desired insurance of integrity and authenticity, at least for some possible ways of establishing or using shared_secret. In particular:


If there was any prior use of shared_secret by any party knowing it, that involved sending
&nbsp; RSA-OAEP(something||shared_secret)
per B's public key, then poof goes the desired integrity and authenticity of data, because an adversary can reuse that cryptogram to abuse B into believing that data is that unrelated something.
That includes if shared_secret is merely used for several iterations of the protocol involving different values of data.
Independently, it is quite possible that the check B makes of that message can be used as an oracle to test shared_secret; if that is a password (as we are told), this is bad (though not nearly as bad as with the other protocol, because that's an online attack). Then, after shared_secret leaked, the sky is the limit.


On the other hand, if shared_secret was a wide secret of fixed length established by XOR of secrets chosen by authenticated parties, and RSA-OAEP(data||shared_secret) was the only time shared_secret is used other than as the key of a symmetric algorithm, then I see no reason why the objective would not be met. This is no insurance.