CIP-0049? | ECDSA and Schnorr signatures in Plutus Core #250

kozross · 2022-04-26T21:00:40Z

This CIP describes the (recently merged) support for ECDSA and Schnorr signatures over the SECP256k1 curve. I've tried to include all the detail I can - any fields I am not sure about, I have left blank.

@michaelpj - does this seem like what you were looking for?

CIP-0042/README.md

…o costing

iquerejeta

This looks good. I would, however, give a little more information on how the builtins work. I suggested that we add some further details on the serialisation format. I think it would also be useful to provide some detail on how the verification works. For Schnorr, it is sufficient to say that we are compatible with BIP340, and for ECDSA I would put somewhere more explicit that the function takes as input the hash of the message. It is important to insist that the verifier must hash the 'claimed' message before verification, and not accept the hash directly from the signer (maybe point to this explanation of why?)

iquerejeta · 2022-07-21T14:51:16Z

CIP-0043/README.md

+provides us with improved interoperability with systems based on Bitcoin, but
+also compatibility with other interoperability systems, such as Wanchain and
+Renbridge, which use SECP256k1 signatures for verification.
+


Suggested change

Moreover, introducing Schnorr signature verification would enable verification of Schnorr compatible multi/threshold signatures such as [MuSig2](https://eprint.iacr.org/2020/1261.pdf) or [Frost](https://eprint.iacr.org/2020/852) among others.

iquerejeta · 2022-07-21T14:52:16Z

CIP-0043/README.md

+* A verification function for ECDSA signatures using the SECP256k1 curve; and
+* A verification function for Schnorr signatures using the SECP256k1 curve.
+
+These would be based on `libsecp256k1`, a reference implementation of both kinds


Suggested change

These would be based on `libsecp256k1`, a reference implementation of both kinds

These would be based on `[bitcoin-core/libsecp256k1](https://github.com/bitcoin-core/secp256k1)`, a reference implementation of both kinds

iquerejeta · 2022-07-21T14:53:55Z

CIP-0043/README.md

+
+More specifically, Plutus would gain the following primitive operations:
+
+* ```verifyEcdsaSecp256k1Signature :: BuiltinByteString -> BuiltinByteString ->


This doesn't parse nicely. I believe we only need one `

Suggested change

* ```verifyEcdsaSecp256k1Signature :: BuiltinByteString -> BuiltinByteString ->

* `verifyEcdsaSecp256k1Signature :: BuiltinByteString -> BuiltinByteString ->

iquerejeta · 2022-07-21T14:54:18Z

CIP-0043/README.md

+More specifically, Plutus would gain the following primitive operations:
+
+* ```verifyEcdsaSecp256k1Signature :: BuiltinByteString -> BuiltinByteString ->
+  BuiltinByteString -> BuiltinBool```, for verifying 32-byte message hashes signed 


Suggested change

BuiltinByteString -> BuiltinBool```, for verifying 32-byte message hashes signed

BuiltinByteString -> BuiltinBool`, for verifying 32-byte message hashes signed

iquerejeta · 2022-07-21T14:55:05Z

CIP-0043/README.md

+  BuiltinByteString -> BuiltinBool```, for verifying 32-byte message hashes signed 
+  using the ECDSA signature scheme on the SECP256k1 curve; and
+* ```verifySchnorrSecp256k1Signature :: BuiltinByteString -> BuiltinByteString
+  -> BuiltinByteString -> BuiltinBool```, for verifying arbitrary binary messages 


Same as above

iquerejeta · 2022-07-21T15:15:47Z

CIP-0043/README.md

+  correspond to the result produced by
+  [``secp256k1_xonly_pubkey_serialize``](https://github.com/bitcoin-core/secp256k1/blob/master/include/secp256k1_extrakeys.h#L61).
+* The message can be of any length, and can contain any bytes in any position.
+* The signature must be 64 bytes.


Suggested change

* The signature must be 64 bytes.

* The signature must be 64 bytes. Again this follows the bip340 standard, and the 64 bytes correspond to:

* 32 bytes for the big-endian representation of the `x` coordinate of `R`, and

* 32 bytes for the big-endian representation of `s`

iquerejeta · 2022-07-22T06:59:30Z

CIP-0043/README.md

+
+We consider the implementation trustworthy: `libsecp256k1` is the reference
+implementation for both signature schemes, and is already being used in
+production by Bitcoin. 


is it the reference implementation for both signature schemes over secp256k1? And regarding being used in production by bitcoin, I think it is of interest to say that both primitives have been used in bitcoin. ECDSA before taproot and Schnorr BIP340 after that.

I am fairly sure that it is the reference implementation for both. I agree about the history of use notes, will add those.

iquerejeta · 2022-07-22T07:00:14Z

CIP-0043/README.md

+
+* It requires 'rolling your own crypto', rather than re-using existing
+  implementations. This has been shown historically to be a bad idea;
+  furthermore, if existing implementations have undergone review and audit, and


Suggested change

furthermore, if existing implementations have undergone review and audit, and

furthermore, if existing implementations have undergone review and audit,

iquerejeta · 2022-07-22T07:12:45Z

CIP-0042/README.md

@@ -1,4 +1,3 @@
---


Was this intentional?

Indeed, this seems like an error.

iquerejeta · 2022-07-22T07:13:21Z

CIP-0043/README.md

@@ -0,0 +1,153 @@
+CIP: ?0043 


I think you are missing the --- before the first line for this to parse correctly.

Indeed I am! This is because of a dirty merge.

Please, rename the supporting folder and change the CIP number to 49 (without leading-zeros, otherwise Github markdown renderer has the brilliant idea to interpret those numbers in octal base 😬 ).

iquerejeta

Looks good. Just some minor comments.

iquerejeta · 2022-07-27T07:51:30Z

CIP-0043/README.md


+* The verification key must correspond to the _(x, y)_ coordinates of a point 


This bullet point and the next one might confuse the reader, as we say that a verification key "must correspond" to two different format. I would differentiate this bullet point with the next one using phrasing as follows:

* A verification key corresponds to the _(x, y)_ coordinates of a point in the SECP256k1 curve, where _x, y_ are unsigned integers in big-endian form. * The serialised (compressed) verification key format accepted by the builtins must correspond [...]

iquerejeta · 2022-07-27T07:52:22Z

CIP-0043/README.md

 * The input to verify must be a 32-byte hash of the message to be checked. We 
  assume that the caller of `verifyEcdsaSecp256k1Signature` receives the 
  message and hashes it, rather than accepting a hash directly: doing so 
  [can be dangerous](https://bitcoin.stackexchange.com/a/81116/35586).
  Typically, the hashing function used would be SHA256; however, this is not
  required, as only the length is checked.
+* The signature must correspond to two unsigned integers in big-endian form;


Same as above. In this case it is a bit less confusing as both formats match, but maybe I would again rephrase in that the first bullet point is what the signature is, and the second is the compressed format accepted by the builtins.

iquerejeta · 2022-07-27T07:53:02Z

CIP-0043/README.md

-* The verification key must follow the
-  [BIP-340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki)
-  standard for encoding, as emboded by the [``secp256k1_xonly_pubkey_serialize``](https://github.com/bitcoin-core/secp256k1/blob/master/include/secp256k1_extrakeys.h#L61).
+* The verification key must correspond to the _(x, y)_ coordinates of a point 


The same as above. Probably similar phrasing to that of the ECDSA verification keys would be good.

KtorZ · 2022-09-06T07:07:14Z

CIP-0043/README.md

+For the [ECDSA signature
+scheme](https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm),
+the requirements are as follows. Note that these differ from the serialization
+used by Bitcoin.


Note that these differ from the serialization used by Bitcoin

Why is that? May we justify this choice under the Rationale section?

KtorZ · 2022-09-06T07:12:00Z

CIP-0043/README.md

+  This implies all of the following:
+    * The signature is 64 bytes long.
+    * The first 32 bytes are the bytes of _r_.
+    * The last 32 bytes are the bytes of _s_.


Suggestion: some visual support to summarize the few points above.

┏━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━┓ ┃ r <32 bytes> │ s <32 bytes> ┃ ┗━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━┛ <--------- signature ---------->

KtorZ · 2022-09-06T07:19:41Z

CIP-0043/README.md

+workflow involving interoperability services like Wanchain and Renbridge. An
+example of such a workflow would be: given some Cardano assets, their Bitcoin
+equivalent could be minted, but only if the correct Schnorr signature can be
+provided. 


This paragraph seems redundant with the Motivation section.

KtorZ · 2022-09-06T07:22:53Z

CIP-0043/README.md

+Plutus](https://github.com/input-output-hk/plutus/pull/4368). Tests of the
+functionality have also been included, although costing is currently
+outstanding, as it cannot be done by MLabs due to limitations in how costing is
+calculated. Costing will instead be done by the Plutus Core team.


👍 cc @michaelpj, I assume you are aware of this.

KtorZ · 2022-09-06T07:23:20Z

CIP-0042/README.md

@@ -1,4 +1,3 @@
---


Indeed, this seems like an error.

KtorZ · 2022-09-06T07:25:10Z

CIP-0043/README.md

@@ -0,0 +1,153 @@
+CIP: ?0043 


Please, rename the supporting folder and change the CIP number to 49 (without leading-zeros, otherwise Github markdown renderer has the brilliant idea to interpret those numbers in octal base 😬 ).

rphair · 2022-09-13T17:02:50Z

@kozross this was on the CIP Editors' Meeting agenda today where it was suggested this proposal is being discussed, audited, or somehow moving forward in other channels. If so, could you please update the status here so editors know how to move forward with this (or what we are waiting for)?

Also can you please renumber the CIP and its directory name as requested here (#250 (comment)), so that we can merge this proposal when it becomes ready?

iquerejeta · 2022-09-29T14:52:53Z

The bindings for Schnorr and ECDSA signatures are currently being audited by bcryptic. We will soon have a report for it (ETA next week). The bindings have also been merged to cardano-base master (PRs 252, 258, 262 and 289). I'll try to talk with Koz to modify the suggested changes.

iquerejeta · 2022-10-18T10:43:01Z

@rphair , @KtorZ , is there anything we can do to move this forward?

rphair · 2022-10-18T16:55:57Z

@iquerejeta apologies for the distracting references above (from someone else's CIP using your earlier assigned # 49).

We've put this on the agenda as "Last Check" for CIP meeting # 56 (theme: "Plutus core changes") (invite) (2022-10-25 at 08:30 UTC). It would be great if you and/or @kozross could be there: in any case it seems to me (@KtorZ?) like this will be merged unless there are any objections at the meeting.

iquerejeta · 2022-10-19T07:29:35Z

Great, I'll try to be there! 👍

SECP proposal

98e19b0

michaelpj approved these changes Apr 27, 2022

View reviewed changes

CIP-0042/README.md Outdated Show resolved Hide resolved

Change to 'Path to Active' heading, note that Plutus Core team will d…

171f0cc

…o costing

michaelpj mentioned this pull request May 9, 2022

Ethereum ecrecover support IntersectMBO/plutus#4575

Closed

KtorZ changed the title ~~SECP proposal~~ CIP-0049? | SECP proposal May 11, 2022

KtorZ changed the title ~~CIP-0049? | SECP proposal~~ CIP-0049? | ECDSA and Schnorr signatures in Plutus Core May 11, 2022

KtorZ added tentative CIP labels May 11, 2022

bezirg mentioned this pull request May 25, 2022

PLT-174: add some basic documentation on Plutus language versions IntersectMBO/plutus#4646

Merged

kozross added 2 commits July 19, 2022 08:46

Merge branch 'master' into koz/secp

f72e1b8

Amend CIP-0043 to note serialized forms

701b75f

iquerejeta reviewed Jul 22, 2022

View reviewed changes

kozross added 2 commits July 25, 2022 10:18

Merge branch 'master' into koz/secp

6f80bd9

Address feedback

26163a4

kozross mentioned this pull request Jul 25, 2022

Update cardano-base to fix SECP verification primitives IntersectMBO/plutus#4786

Merged

10 tasks

More wording changes, add Inigo as an author

0c55134

iquerejeta reviewed Jul 27, 2022

View reviewed changes

KtorZ reviewed Sep 6, 2022

View reviewed changes

kozross added 2 commits September 30, 2022 09:34

Changes by Inigo

9f42d04

Move CIP to proper folder name

c5bdd66

Benjmhart mentioned this pull request Oct 2, 2022

Priority CIP's for late 2022/Early 2023 input-output-hk/Developer-Experience-working-group#20

Closed

This was referenced Oct 11, 2022

NFT metadata extension tag #343

Closed

CIP-0048? | NFT metadata references and payloads #249

Closed

KtorZ approved these changes Oct 25, 2022

View reviewed changes

crptmppt approved these changes Oct 25, 2022

View reviewed changes

rphair merged commit 4c3c4c3 into cardano-foundation:master Oct 25, 2022

rphair mentioned this pull request Dec 11, 2022

Post-quantum Signatures #413

Open

iquerejeta mentioned this pull request Jun 14, 2023

CIP-0101 | Integration of keccak256 into Plutus #524

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CIP-0049? | ECDSA and Schnorr signatures in Plutus Core #250

CIP-0049? | ECDSA and Schnorr signatures in Plutus Core #250

kozross commented Apr 26, 2022

iquerejeta left a comment

iquerejeta Jul 21, 2022

iquerejeta Jul 21, 2022

iquerejeta Jul 21, 2022

iquerejeta Jul 21, 2022

iquerejeta Jul 21, 2022

iquerejeta Jul 21, 2022

iquerejeta Jul 22, 2022

kozross Jul 24, 2022

iquerejeta Jul 22, 2022

iquerejeta Jul 22, 2022

KtorZ Sep 6, 2022

iquerejeta Jul 22, 2022

kozross Jul 22, 2022

KtorZ Sep 6, 2022

iquerejeta left a comment

iquerejeta Jul 27, 2022

iquerejeta Jul 27, 2022

iquerejeta Jul 27, 2022

KtorZ Sep 6, 2022

KtorZ Sep 6, 2022

KtorZ Sep 6, 2022

KtorZ Sep 6, 2022

michaelpj Sep 6, 2022

KtorZ Sep 6, 2022

KtorZ Sep 6, 2022

rphair commented Sep 13, 2022

iquerejeta commented Sep 29, 2022

iquerejeta commented Oct 18, 2022

rphair commented Oct 18, 2022 •

edited

Loading

iquerejeta commented Oct 19, 2022


	Moreover, introducing Schnorr signature verification would enable verification of Schnorr compatible multi/threshold signatures such as [MuSig2](https://eprint.iacr.org/2020/1261.pdf) or [Frost](https://eprint.iacr.org/2020/852) among others.

	These would be based on `libsecp256k1`, a reference implementation of both kinds
	These would be based on `[bitcoin-core/libsecp256k1](https://github.com/bitcoin-core/secp256k1)`, a reference implementation of both kinds


		More specifically, Plutus would gain the following primitive operations:

		* ```verifyEcdsaSecp256k1Signature :: BuiltinByteString -> BuiltinByteString ->

	* ```verifyEcdsaSecp256k1Signature :: BuiltinByteString -> BuiltinByteString ->
	* `verifyEcdsaSecp256k1Signature :: BuiltinByteString -> BuiltinByteString ->

	BuiltinByteString -> BuiltinBool```, for verifying 32-byte message hashes signed
	BuiltinByteString -> BuiltinBool`, for verifying 32-byte message hashes signed

-* The signature must be 64 bytes.
+* The signature must be 64 bytes. Again this follows the bip340 standard, and the 64 bytes correspond to:
+    * 32 bytes for the big-endian representation of the `x` coordinate of `R`, and
+    * 32 bytes for the big-endian representation of `s`

	furthermore, if existing implementations have undergone review and audit, and
	furthermore, if existing implementations have undergone review and audit,


		* The verification key must correspond to the _(x, y)_ coordinates of a point

CIP-0049? | ECDSA and Schnorr signatures in Plutus Core #250

CIP-0049? | ECDSA and Schnorr signatures in Plutus Core #250

Conversation

kozross commented Apr 26, 2022

iquerejeta left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

iquerejeta left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rphair commented Sep 13, 2022

iquerejeta commented Sep 29, 2022

iquerejeta commented Oct 18, 2022

rphair commented Oct 18, 2022 • edited Loading

iquerejeta commented Oct 19, 2022

rphair commented Oct 18, 2022 •

edited

Loading