📅 Original date posted:2020-02-28
📝 Original message:Dear ZmnSCPxj,
> I think it would be unsafe to use a deterministic scheme, that takes as
input the message m and the privkey only.
Yes, using only the message and the private key is unsafe. Signer should
use all the data coming from the host, so f(sha256(n), m, privkey) is a
good candidate. If more than one blinding factor is sent - all of them
should be used as well.
> Otherwise a completely-random `k` would be much better, but the signer
might not have enough resources to gather sufficient entropy.
I am not a big fan of pure RNG-generated nonces, so I would suggest to use
this entropy only as additional data for a deterministic scheme.
For example, Yubikey had a problem with RNG initialization that caused
leakage of the private key [1].
If the signer has any source of entropy, even if it is not a very good one,
the entropy from this source can be mixed into the nonce generation
function:
f(sha256(n),m,privkey,entropy).
Another issue is that deterministic nonce generation is vulnerable to
glitch attacks - if I ask the wallet to sign the same message twice but
after nonce generation I glitch and flip a bit in the message, I will get
two signatures with the same nonce but with different messages - from these
signatures I can calculate the private key.
So I would recommend to include a monotonic counter into the nonce
generation function as well: f(sha256(n), m, privkey, entropy, counter)
As usual, counter should be increased _before_ signing.
Ref: [1]
https://www.yubico.com/support/security-advisories/ysa-2019-02/#technical-details
Best,
Stepan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200228/4e3805b4/attachment-0001.html>;
Stepan Snigirev [ARCHIVE] /
npub1xz…czrtg
2023-06-07 18:23:08
in reply to nevent1q…23gz
Author Public Key
npub1xzl2lq5eguuel0htwdy2s6lrjype7kdye6vhp4j60t79fmrtna5qcczrtgPublished at
2023-06-07 18:23:08Event JSON
{
"id": "8d7a61e710af098255e811e59166cfe4c8d711788186e7031f6ee9311516e322",
"pubkey": "30beaf829947399fbeeb7348a86be391039f59a4ce9970d65a7afc54ec6b9f68",
"created_at": 1686162188,
"kind": 1,
"tags": [
[
"e",
"3bd691ab84dbd779874a9fcb3a0c56acf7354668182306535dabe3cfba04c1ed",
"",
"root"
],
[
"e",
"92ac33fb77a873679b2a2c57bf426e8db39e1c8b56793a297ec532b383f76452",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2020-02-28\n📝 Original message:Dear ZmnSCPxj,\n\n\u003e I think it would be unsafe to use a deterministic scheme, that takes as\ninput the message m and the privkey only.\n\nYes, using only the message and the private key is unsafe. Signer should\nuse all the data coming from the host, so f(sha256(n), m, privkey) is a\ngood candidate. If more than one blinding factor is sent - all of them\nshould be used as well.\n\n\u003e Otherwise a completely-random `k` would be much better, but the signer\nmight not have enough resources to gather sufficient entropy.\n\nI am not a big fan of pure RNG-generated nonces, so I would suggest to use\nthis entropy only as additional data for a deterministic scheme.\nFor example, Yubikey had a problem with RNG initialization that caused\nleakage of the private key [1].\nIf the signer has any source of entropy, even if it is not a very good one,\nthe entropy from this source can be mixed into the nonce generation\nfunction:\nf(sha256(n),m,privkey,entropy).\n\nAnother issue is that deterministic nonce generation is vulnerable to\nglitch attacks - if I ask the wallet to sign the same message twice but\nafter nonce generation I glitch and flip a bit in the message, I will get\ntwo signatures with the same nonce but with different messages - from these\nsignatures I can calculate the private key.\nSo I would recommend to include a monotonic counter into the nonce\ngeneration function as well: f(sha256(n), m, privkey, entropy, counter)\nAs usual, counter should be increased _before_ signing.\n\nRef: [1]\nhttps://www.yubico.com/support/security-advisories/ysa-2019-02/#technical-details\n\nBest,\nStepan\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200228/4e3805b4/attachment-0001.html\u003e",
"sig": "1f643d99f0296203a2e575a3feb96f74ba3b5f529a542c2105f7fb923effd0836eef755bfb99e5b6a177ec66d42976a0fc00aff729f1eff21c413db716501119"
}