Do I need to provide entropy to secp256k1_ecdsa_sign() ?











up vote
2
down vote

favorite












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










share|improve this question


















  • 1




    you said yourself that it isn't random, so why are you asking where the randomness is coming from, if there is none? did you read rfc6979? it makes the nonce dependent on the message (it is a hash), so that you won't reuse a nonce with different messages and get a playstation3 situation.
    – Janus Troelsen
    4 hours ago















up vote
2
down vote

favorite












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










share|improve this question


















  • 1




    you said yourself that it isn't random, so why are you asking where the randomness is coming from, if there is none? did you read rfc6979? it makes the nonce dependent on the message (it is a hash), so that you won't reuse a nonce with different messages and get a playstation3 situation.
    – Janus Troelsen
    4 hours ago













up vote
2
down vote

favorite









up vote
2
down vote

favorite











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










share|improve this question













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







elliptic-curves cryptocurrency






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 5 hours ago









jaybny

1267




1267








  • 1




    you said yourself that it isn't random, so why are you asking where the randomness is coming from, if there is none? did you read rfc6979? it makes the nonce dependent on the message (it is a hash), so that you won't reuse a nonce with different messages and get a playstation3 situation.
    – Janus Troelsen
    4 hours ago














  • 1




    you said yourself that it isn't random, so why are you asking where the randomness is coming from, if there is none? did you read rfc6979? it makes the nonce dependent on the message (it is a hash), so that you won't reuse a nonce with different messages and get a playstation3 situation.
    – Janus Troelsen
    4 hours ago








1




1




you said yourself that it isn't random, so why are you asking where the randomness is coming from, if there is none? did you read rfc6979? it makes the nonce dependent on the message (it is a hash), so that you won't reuse a nonce with different messages and get a playstation3 situation.
– Janus Troelsen
4 hours ago




you said yourself that it isn't random, so why are you asking where the randomness is coming from, if there is none? did you read rfc6979? it makes the nonce dependent on the message (it is a hash), so that you won't reuse a nonce with different messages and get a playstation3 situation.
– Janus Troelsen
4 hours ago










1 Answer
1






active

oldest

votes

















up vote
3
down vote














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.

  • 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;






share|improve this answer























    Your Answer





    StackExchange.ifUsing("editor", function () {
    return StackExchange.using("mathjaxEditing", function () {
    StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
    StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
    });
    });
    }, "mathjax-editing");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "281"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    noCode: true, onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f64856%2fdo-i-need-to-provide-entropy-to-secp256k1-ecdsa-sign%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    3
    down vote














    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.

    • 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;






    share|improve this answer



























      up vote
      3
      down vote














      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.

      • 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;






      share|improve this answer

























        up vote
        3
        down vote










        up vote
        3
        down vote










        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.

        • 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;






        share|improve this answer















        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.

        • 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;







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 4 hours ago

























        answered 4 hours ago









        Maarten Bodewes

        52.2k676190




        52.2k676190






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Cryptography Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            Use MathJax to format equations. MathJax reference.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f64856%2fdo-i-need-to-provide-entropy-to-secp256k1-ecdsa-sign%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

            Mangá

            Eduardo VII do Reino Unido