mjhjmtu

using secp256k1_ecdsa_sign() I noticed the same data signed multiple times, coming back with the same signature. I always thought that signatures are different because random data is somehow involved.

looking at my (production) code, this is my call:

 secp256k1_ecdsa_signature sign(const pb::sha256 &in) 
 secp256k1_ecdsa_signature sig;
 if ( 1 != secp256k1_ecdsa_sign(pb::TheCTX::instance()->CTX(), 
 &sig, in.data, key_data, NULL, NULL) ) 
 qDebug() << " error sig";
 
 return sig;
 

This is the function signature:

int secp256k1_ecdsa_sign(const secp256k1_context* ctx, 
 secp256k1_ecdsa_signature *signature, 
 const unsigned char *msg32, const unsigned char *seckey, 
 secp256k1_nonce_function noncefp, const void* noncedata) 

Question1: Where is randomness coming from? The default secp256k1_nonce_function, when i pass in NULL is nonce_function_rfc6979.

Question2: Did I do something wrong? Can my private-keys be derived from my signed messages?

Please help... kinda freaking out.. ty

Question1: Where is randomness coming from? The default secp256k1_nonce_function, when i pass in NULL is nonce_function_rfc6979.

Obviously, there is no randomness involved when RFC 6979 is used. The title of that RFC is "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)". In this case identical messages will generate the same signature value.

As the RFC reads: "Even slight biases in that process may be turned into attacks on the signature schemes." So the deterministic signature scheme makes sure that the replacement of the random value doesn't have any bias. Fortunately, this is exactly what a pseudo-random-generator (PRG) is able to generate when the hash over the message is used as key. In the RFC a HMAC algorithm is used as PRG. So the true random value is replaced by a pseudo random value that depends on the message.

Question2: Did I do something wrong? Can my private-keys be derived from my signed messages?

No, as long as the security considerations in section 4 of the RFC holds you should be fine.

Notes:

• Generating the same signature value for message input is not necessarily a problem and it is not a generic requirement for signature schemes. For instance, the PKCS#1 v1.5 signature scheme is fully deterministic. However, for ECDSA, it is possible to calculate the private key value using simple mathematical equations if no (pseudo-)random value is present.


• You should consider if deterministic signature generation is OK for your specific protocol. For instance, if sign-and-encrypt is used then a deterministic signature may give information about the plaintext message, breaking the confidentiality requirement (although if the signature is verifiable, this is already the case if the signature and public key is available to an adversary).


• Other API's may choose to use some kind of default secure random generator instead of deterministic signature generation. For instance, Java will use the highest priority secure random generator if no specific random generator is explicitly indicated during initialization of signature generation algorithm;