I am a developer trying to follow best practice guidance as established by the IETF for my applications. I was researching standards for ECDSA key generation for some work that I have to do in the blockchain industry.
I am tasked with creating a unique, less complex zero-knowledge based scheme.
RFC Draft Indicating Deterministic ECDSA + EDDSA Signatures Were Still Insecure Without Supplemental Actions
I know eddsa signatures are deterministic by design, please ignore any references to that portion going forward. My question deals squarely with multi-signature creation with ecdsa keys (secp256k1) using a deterministic 'k' (per RFC6979) but no Schnorr's
My research led me to a published draft here giving guidance on generating signatures with ecdsa & eddsa keys in a more secure manner: https://www.ietf.org/id/draft-irtf-cfrg-det-sigs-with-noise-00.html
Even though this draft was submitted a year ago, it caught me off guard slightly because my understanding of ecdsa was that the issue of key recovery via issues w random nonce generation were addressed via the introduction of deterministic signatures by deriving 'k' in a pseudo-random fashion.
Other issues like nonce leakage and ladder attacks notwithstanding
Reading this draft though informed me that my assumptions were false.
What I want to ask you all about is one particular statement about midway through where it reads, "Note that deriving per-message secret number deterministically, is also insecure in a multi-party signature setting". There's an accompanying footnote that cites another draft RFC titled, "Two-Round Threshold Schnorr Signatures with FROST" (for convenience: https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-02.txt).
Does the paper's declaration about multi-signature generation (deterministic) hold true for Ethereum though
I don't mean to assume that you all are familiar with Ethereum or what I mean, so I'll be specific:
Ethereum uses the same key generation method as Bitcoin (ecdsa; secp256k1)
Ethereum signatures adhere to the RFC6769 deterministic standard for ecdsa signatures
Like Bitcoin, the message to be hashed in the signing scheme is hashed with keccak256
On the basis of those facts alone, I would imagine any multi-signature scheme imputing the same method in a single round would be applicable to the statement: "Note that deriving per-message secret number deterministically, is also insecure in a multi-party signature setting"
However, the guidance in this draft suggests that additional random/pseudo-random data attached to the signing process could mitigate this
Continuing from above
- One major difference between Ethereum & Bitcoin is that ETH transactions contain "nonces" & they are part of the data that gets signed. The nonce is a simple counter that increments by '1' for every transaction. So when user A sends their first transaction, their nonce is 0. Second transaction, nonce is 1. Third, nonce is 2...and so forth. This does technically satisfy the criteria that the nonce be associated with the message in some capacity, albeit it doesn't have anything to do with the actual contents of said message (which is what I believe the RFC authors were referring to). It also is unique for every message signed (that will be publicly viewed) since the nonce is incremented for each transaction.
Despite what I mentioned in #4, I have the impression that's inadequate to provide the type of security assurances this draft RFC calls for.
All Feedback Welcome
Beyond the question I asked via the previous heading, I'd appreciate any and all insight from you all. I'm a bit confused about the part of the RFC where it states:
When ECDSA is used with SHAKE [SHA3] the HMAC construction above MAY be used but it is RECOMMENDED to use the more efficient KMAC construction [KMAC]. SHAKE is a variable-length hash function defined as SHAKE(M, d) where the output is a d-bits-long digest of message M. When ECDSA is used with SHAKE128(M, d), it is RECOMMENDED to replace HMAC(K, M) with KMAC128(K, M, d, ""). When ECDSA is used with SHAKE256(M, d), it is RECOMMENDED to replace HMAC(K, M) with KMAC256(K, M, d, "").
What is it that the authors of this RFC have discovered about using the HMAC method as defined in RFC6979 that makes it insecure? Alternatively, what benefits are gleaned from using SHA3 specifically in place of the prior proposed hash algo (SHA256/512)? The wording in the draft that this swap was necessary to make HMAC acceptable for use strongly implies the issue is in the use of HMAC. However, if that issue was restricted to its proposed implementation, then they'd just propose modifying the parameters of its use. Above, they ultimately advocate for swapping it out entirely. The SHA3 swap suggestion here seems like a band-aid for w/e weaknesses in HMAC within this scheme they've found rather than a fix.
Secondly, the draft proposes that when using either SHAKE128 or SHAKE256, KMAC should be used in lieu of HMAC in order to ensure safe deterministic signatures are produced with ecdsa-based keys. Why? If anyone can read between the lines to help me understand what inherent weaknesses there are in SHAKE that would make deterministic sig schemes employing this hash vs. sha3 uniquely vulnerable when employed with HMAC, I would sincerely appreciate. I know that shake is an XOF, but my understanding was the genius in SHAKE was that it imputed hashes of different lengths from the same input w/o a compromise in security, assuming the input is of a certain length.
Any and all guidance, insight or correction of my assumptions or understanding is greatly appreciated. Even if you only have time or can answer one portion of this question, that would help greatly. Thank you!
^^ My ultimate question = Is the predictable, yet ancillary inclusion of a "nonce" in the ETH signature scheme enough to mitigate the risk of key recovery / insecurity that you mentioned if one were to employ a multi-signature scheme?
