21-DOT-DEV / swift-secp256k1

Elliptic Curve, Schnorr, and ZKP for Bitcoin. Supports iOS macOS tvOS watchOS visionOS + Linux.
MIT License
107 stars 54 forks source link

Is there really a random k injected when calculating an ECDSA signature ? #468

Closed kanedaron closed 9 months ago

kanedaron commented 9 months ago

I have launched several times the example code on 0.10.0 and check the signature :

let privateBytes = try! "14E4A74438858920D8A35FB2D88677580B6A2EE9BE4E711AE34EC6B396D87B5C".bytes
let privateKey = try! secp256k1.Signing.PrivateKey(rawRepresentation: privateBytes)
let messageData = "We're all Satoshi.".data(using: .utf8)!
let signature = try! privateKey.ecdsa.signature(for: messageData)
print(try! signature.derRepresentation.base64EncodedString())

When I check the signature DER output, I always see the same value for each pass(something which doesn't happen with schnorr signatures), which means that the signature generation is completely deterministic and there is no randomness injected. I was certain that it was mandatory to input a random k or else the signature is easily crackable : https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Security

Since I am not an expert in cryptography, I don't know if it's by design, if it has been changed in recent versions or if I misunderstood the algorithm requirements. I wanted to be assured it doesn't threaten the security of the signature.

csjones commented 9 months ago

Hey @kanedaron :wave:

Thank you for reaching out regarding the deterministic generation of ECDSA signatures.

Your observation is accurate: the signatures generated by the example code you provided are indeed deterministic. Though, this behavior is intentional and aligns with RFC 6979, which is mentioned at the bottom of the Security section you linked to ("This issue can be prevented by deterministic generation of k, as described by RFC 6979.")

Additionally, RFC 6979 is exactly what is used by libsecp256k1 for ECDSA signatures by default.

If you're interested in contributing a change to allow randomness to be injected, I'd gladly review the changes for acceptance. 😁

Here is the section of code for your consideration: https://github.com/GigaBitcoin/secp256k1.swift/blob/main/Sources/zkp/ECDSA.swift#L162L184

kanedaron commented 9 months ago

Thank you very much ! 🙏

Then I’m reassured now, and this determinism actually helps with my own coding 😛

Le 25 déc. 2023 à 01:43, Chris @.***> a écrit :



Hey @kanedaronhttps://github.com/kanedaron 👋

Thank you for reaching out regarding the deterministic generation of ECDSA signatures.

Your observation is accurate: the signatures generated by the example code you provided are indeed deterministic. Though, this behavior is intentional and aligns with RFC 6979https://datatracker.ietf.org/doc/html/rfc6979, which is mentioned at the bottom of the Security section you linked to ("This issue can be prevented by deterministic generation of k, as described by RFC 6979.")

Additionally, RFC 6979 is exactly what is used by libsecp256k1https://github.com/bitcoin-core/secp256k1/blob/master/include/secp256k1.h#L638 for ECDSA signatures by default.

If you're interested in contributing a change to allow randomness to be injected, I'd gladly review the changes for acceptance. 😁

Here is the section of code for your consideration: https://github.com/GigaBitcoin/secp256k1.swift/blob/main/Sources/zkp/ECDSA.swift#L162L184

— Reply to this email directly, view it on GitHubhttps://github.com/GigaBitcoin/secp256k1.swift/issues/468#issuecomment-1868628352, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AOYUTUQIUX6AWE2VUXIVUKDYLDDZRAVCNFSM6AAAAABBB2GJG6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRYGYZDQMZVGI. You are receiving this because you were mentioned.Message ID: @.***>