I'm using the example given in msdn article about the DSACryptoServiceProvider Class. The problem is that I get a different signature each time I run the code. I tried OpenSSL and didn't get this problem but I need to work with System.Security.Cryptography this time.

This is some source code: this is the hashed value to be signed

byte[] HashValue =
            59, 4, 248, 102, 77, 97, 142, 201,
            210, 12, 224, 93, 25, 41, 100, 197,
            213, 134, 130, 135

and this is where the problem lies

 // The value to hold the signed value.
        byte[] SignedHashValue1 = DSASignHash(HashValue, privateKeyInfo, "SHA1");
        byte[] SignedHashValue2 = DSASignHash(HashValue, privateKeyInfo, "SHA1");

I used the debugger to figure out the SignedHashValue1 doesn't equal SignedHashValue2

  • 1
    Don't cross-post – CodesInChaos Dec 14 '13 at 19:01
  • I would have migrated this but I see you are blocked from posting on SO currently. Please don't use posting on an alternative site as a way to get around blocks and suspensions. – Rory Alsop Dec 15 '13 at 16:39
  • @RoryAlsop He managed to post the same question on stackoverflow, so it wasn't a ban circumvention. I'd like to merge them, but for that we first need to migrate on of them. – CodesInChaos Dec 16 '13 at 10:26
  • Can't migrate, the message back is that he is blocked. – Rory Alsop Dec 16 '13 at 10:29

Traditional implementations of DSA choose a random nonce for each signature operation. This leads to a different signature, even when signing the same data. The problem is not that the signature is different each time, it's your wrong expectation that it should be the same.

Check Wikipedia on DSA for details:


  • Generate a random per-message k
  • Calculate r from k
  • Calculate s from r and the private key
  • The signature is (r,s)

Since k differs for each message, the signature is different as well. This random k is essential to the security of DSA.

A nice alternative to a random $k$ is deriving it from the private key and the message hash via hashing. This behaves like a random value from an attacker's point of view, but prevents catastrophic failure when generating a signature using a weak PRNG. This approach will result in the same signature when signing the same data. RFC6979 - Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) specifies a way for doing this.

You shouldn't try to verify a DSA signature by signing again and comparing. You should use the specialized verification operation using the public key. Signatures are useful because you don't need the private key in order to verify a signature.

If you can use the same key for signing and verification, you should consider using a MAC instead of a signature. HMAC-SHA-2 is the one I recommend.

| improve this answer | |
  • I'm trying to sign a file (using its name and the lastaccess property) and store this signature. later I will sign this file again and compare the tow signatures to assure that this file hasn't been accessed by someone else. so I'm having a huge problem if DSA generates a different signature each time even with the same data and parameters – Ibrahim.I Dec 13 '13 at 16:39
  • 1
    @Ibrahim.I In that case you have two choices: 1) Use the DSA verification operation with the public key instead of the private key. 2) Use a MAC like HMAC instead of a digital signature. Signatures are useful because you don't need the private key in order to verify a signature. – CodesInChaos Dec 13 '13 at 16:41
  • I'm obliged to use digital signatures. so I'm gonna talk about the first solution. I need to verify that the file hasn't been accessed by anybody we use DSA verification with the public key when we have a message and we want to ensure that this message is really sent from the right source depending on the source private/public key and his signature how can I use this mechanism in my problem – Ibrahim.I Dec 13 '13 at 16:48
  • 2
    @Ibrahim.I You need to use the DSAVerifyHash function from that code example. You pass in the message and signature and you get back a boolean that tells you if they matched. – CodesInChaos Dec 13 '13 at 16:59
  • @Ibrahim to check whether the file is still the same as during your first signing, you don't need to sign it a second time but instead have to verify the signature with the data from the file now. – mkl Dec 14 '13 at 10:59

Not the answer you're looking for? Browse other questions tagged or ask your own question.