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
elliptic-curves cryptocurrency
add a comment |
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
elliptic-curves cryptocurrency
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
5 hours ago
add a comment |
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
elliptic-curves cryptocurrency
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
elliptic-curves cryptocurrency
asked 6 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
5 hours ago
add a comment |
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
5 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
5 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
5 hours ago
add a comment |
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;
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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;
add a comment |
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;
add a comment |
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;
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;
edited 4 hours ago
answered 4 hours ago
Maarten Bodewes
52.2k676190
52.2k676190
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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
5 hours ago