Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Hope it will be clear.

I need to digitally sign pieces of information. What I'm currently doing is the following (for each piece of information):

  1. Run SHA1 on the information
  2. Encrypt the result with RSA
  3. Store both of them together Now, I can say for sure if someone altered the information.

My problem is that I don't want to run the RSA encryption on each one of the pieces since it has some performance hit on my system.

I thought of doing the following:

  1. Generate a seed for the SHA1
  2. Encrypt the seed with RSA
  3. Store the encrypted seed.
  4. Now I can only run the SHA1 (+seed) on each piece of information.

I don't find any reason for why it should be less safe than what I'm doing today. Is it true? any thoughts about it?


share|improve this question

migrated from Jan 26 '14 at 5:21

This question came from our site for professional and enthusiast programmers.

This question appears to be off-topic because it is about security or cryptography and doesn't include a programming problem. – Duncan Jan 6 '14 at 10:41

Your scheme doesn't appear to provide any authentication whatsoever.

For a normal RSA digital signature the intended recipient can calculate the hash of the message, decrypt the signature using the public key to get the original hash, and compare them to authenticate the message. If an attacker is to tamper with the message, then in order to change the signature so that it matches the tampered message they would require access to the private key (which we assume they do not have).

In your scheme, an attacker can simply modify the message and update the "signature" by recalculating the hash of [tampered message + seed]. The attacker must have access to the (unencrypted) seed because it was encrypted with the private key, and so can be decrypted with the public key which we assume the attacker has. If the seed was instead encrypted with the public key, then the attacker would not be able to decrypt it to get the original seed in order to calculate a new hash, but nobody else would be able to either so it would be impossible for the intended recipient to verify the signature is correct.

share|improve this answer
Thank you for the detailed comment. You total right except for the fact that I'm the one who is supposed to tell eventually if the data was altered. Me and only me hold the private key. – Lior Ohana Jan 6 '14 at 17:04
@LiorOhana - Digital signature schemes are in part intended to permit others to authenticate the message is from you, and has not been altered. If you are trying to prove to yourself that nothing has changed, there's not really any need for a digital signature at all - simply store the hash. Obviously the hash must be stored in such a way that a potential attacker cannot modify, but the same requirement holds true for the private key in a digital signature scheme, so you must already have the ability to do this. – Iridium Jan 6 '14 at 17:23
In general you're right, however, in my case, I have nowhere to store the hash except for being part of the data itself. The private key is stored in the source code (obstructed and encrypted). The purpose of the signature is to prove (at court, for example) that the data was not altered. – Lior Ohana Jan 7 '14 at 21:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.