Do I need to provide entropy to secp256k1_ecdsa_sign() ?












3














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


















  • 2




    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
    Dec 14 at 0:03
















3














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


















  • 2




    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
    Dec 14 at 0:03














3












3








3







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 Dec 13 at 23:00









jaybny

1337




1337








  • 2




    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
    Dec 14 at 0:03














  • 2




    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
    Dec 14 at 0:03








2




2




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
Dec 14 at 0:03




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
Dec 14 at 0:03










1 Answer
1






active

oldest

votes


















5















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;






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',
    autoActivateHeartbeat: false,
    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









    5















    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;






    share|improve this answer




























      5















      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;






      share|improve this answer


























        5












        5








        5







        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;






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







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Dec 15 at 18:01

























        answered Dec 14 at 0:39









        Maarten Bodewes

        52.7k677191




        52.7k677191






























            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

            How do I know what Microsoft account the skydrive app is syncing to?

            When does type information flow backwards in C++?

            Grease: Live!