Add ECDSA over secp256k1 signatures and verification #490

Vindaar · 2024-12-12T19:03:45Z

This adds support for the Elliptic Curve Digital Signature Algorithm (ECDSA) defined over secp256k1.

The current API supports:

Currently still missing:

batch verification
~~public key recovery~~ ⇒ will be part of PR Add ECRecover EVM precompile #504
more test cases (currently: script to generate signatures using OpenSSL and verify those with Constantine). Maybe sign messages with CTT & verify using OpenSSL

In addition, there are a few minor things I'm unsure about. Will highlight them below.

Vindaar · 2024-12-12T19:04:23Z

constantine/ecdsa/ecdsa.nim

+    ## XXX: raise / what else to do if `sysrand` call fails?
+    doAssert b.limbs.sysrand()


In case this were to fail, do we want a different failure mode?

For now it's fine not to address this, AFAIK most protocols use RFC6979 to avoid adding the RNG to the attack surface. If the RNG fails to produce data, I'm not even sure what it means at the OS level, no more entropy maybe?

Not sure either to be honest, but given that we do return a bool I didn't just want to discard it.

Vindaar · 2024-12-12T19:05:23Z

constantine/ecdsa/ecdsa.nim

+    ## XXX: smarter way for this?
+    let r = Fr[C].fromBig(rx.toBig())


We need to convert the coordinate in Fp to a scalar in Fr. The "best" way I could come up with is this to big / from big conversion. Is there a cleaner way?

This is the best generic conversion.

In theory for secp256k1, you could take mod r because Fp/Fr can be both use canonical representation and still have a fast reduction (#445) however at the moment only Fp uses canonical repr and fast reduction while Fr uses Montgomery representation and Montgomery reduction.

mratsim

Note that for Ethereum the hash function is Keccak. But it's good to have both and be hash agnostic to help test.

The out-of-place function will need to be replaced by in-place.

You can check constantine/signatures/bls_signatures.nim in general for API guidance.
Also https://github.com/bitcoin-core/secp256k1 which is the reference implementation for Bitcoin and Ethereum to implement serializer without dynamic allocation.
And https://github.com/status-im/nim-eth/blob/master/eth/common/keys.nim for how secp256k1 is actually used in Ethereum

The PEM/DER part is unused in blockchain, but it's helpful for testing against OpenSSL, and if we ever want to add TLS/QUIC support to Constantine, it wil be necessary.

Regarding testing vs openssl if the API for ECDSA is less messy than hashes, it can be used as a library like so

constantine/tests/t_hash_sha256_vs_openssl.nim

Lines 8 to 54 in 13d5bb7

    
           # Deal with platform mess 
        
           # -------------------------------------------------------------------- 
        
           when defined(windows): 
        
             when sizeof(int) == 8: 
        
               const DLLSSLName* = "(libssl-1_1-x64|ssleay64|libssl64).dll" 
        
             else: 
        
               const DLLSSLName* = "(libssl-1_1|ssleay32|libssl32).dll" 
        
           else: 
        
             when defined(macosx) or defined(macos) or defined(ios): 
        
               const versions = "(.1.1|.38|.39|.41|.43|.44|.45|.46|.47|.48|.10|.1.0.2|.1.0.1|.1.0.0|.0.9.9|.0.9.8|)" 
        
             else: 
        
               const versions = "(.1.1|.1.0.2|.1.0.1|.1.0.0|.0.9.9|.0.9.8|.48|.47|.46|.45|.44|.43|.41|.39|.38|.10|)" 
        
             when defined(macosx) or defined(macos) or defined(ios): 
        
               const DLLSSLName* = "libssl" & versions & ".dylib" 
        
             elif defined(genode): 
        
               const DLLSSLName* = "libssl.lib.so" 
        
             else: 
        
               const DLLSSLName* = "libssl.so" & versions 
        
           # OpenSSL wrapper 
        
           # -------------------------------------------------------------------- 
        
           # OpenSSL removed direct use of their SHA256 function. https://github.com/openssl/openssl/commit/4d49b68504cc494e552bce8e0b82ec8b501d5abe 
        
           # It isn't accessible anymore in Windows CI on Github Action. 
        
           # But the new API isn't expose on Linux :/ 
        
           # TODO: fix Windows 
        
           when not defined(windows): 
        
             proc SHA256[T: byte|char]( 
        
                   msg: openarray[T], 
        
                   digest: ptr array[32, byte] = nil 
        
                 ): ptr array[32, byte] {.noconv, dynlib: DLLSSLName, importc.} 
        
             # proc EVP_Q_digest[T: byte|char]( 
        
             #                 ossl_libctx: pointer, 
        
             #                 algoName: cstring, 
        
             #                 propq: cstring, 
        
             #                 data: openArray[T], 
        
             #                 digest: var array[32, byte], 
        
             #                 size: ptr uint): int32 {.noconv, dynlib: DLLSSLName, importc.} 
        
             proc SHA256_OpenSSL[T: byte|char]( 
        
                   digest: var array[32, byte], 
        
                   s: openArray[T]) = 
        
               discard SHA256(s, digest.addr) 
        
               # discard EVP_Q_digest(nil, "SHA256", nil, s, digest, nil)

and we can remove the random messages json

mratsim · 2024-12-12T19:49:27Z

constantine/ecdsa/ecdsa.nim

@@ -0,0 +1,356 @@
+import


ECDSA should be in the constantine/signatures folder

mratsim · 2024-12-12T19:51:30Z

constantine/ecdsa/ecdsa.nim

@@ -0,0 +1,356 @@
+import
+  ../hashes/h_sha256,


It should be hash agnostic, with it's actual instantiation using a predefined hash.

See the function signature of BLS signatures

constantine/constantine/signatures/bls_signatures.nim

Lines 51 to 88 in 13d5bb7

func coreSign*[Sig, SecKey](

signature: var Sig,

secretKey: SecKey,

message: openArray[byte],

H: type CryptoHash,

k: static int,

augmentation: openArray[byte],

domainSepTag: openArray[byte]) {.genCharAPI.} =

## Computes a signature for the message from the specified secret key.

##

## Output:

## - `signature` is overwritten with `message` signed with `secretKey`

##

## Inputs:

## - `Hash` a cryptographic hash function.

## - `Hash` MAY be a Merkle-Damgaard hash function like SHA-2

## - `Hash` MAY be a sponge-based hash function like SHA-3 or BLAKE2

## - Otherwise, H MUST be a hash function that has been proved

## indifferentiable from a random oracle [MRH04] under a reasonable

## cryptographic assumption.

## - k the security parameter of the suite in bits (for example 128)

## - `output`, an elliptic curve point that will be overwritten.

## - `augmentation`, an optional augmentation to the message. This will be prepended,

## prior to hashing.

## This is used for building the "message augmentation" variant of BLS signatures

## https://www.ietf.org/archive/id/draft-irtf-cfrg-bls-signature-05.html#section-3.2

## which requires `CoreSign(SK, PK || message)`

## and `CoreVerify(PK, PK || message, signature)`

## - `message` is the message to hash

## - `domainSepTag` is the protocol domain separation tag (DST).

type ECP_Jac = EC_ShortW_Jac[Sig.F, Sig.G]

var sig {.noInit.}: ECP_Jac

H.hashToCurve(k, sig, augmentation, message, domainSepTag)

sig.scalarMul(secretKey)

signature.affine(sig)

mratsim · 2024-12-12T19:53:05Z

constantine/ecdsa/ecdsa.nim

+# For easier readibility, define the curve and generator
+# as globals in this file
+const C* = Secp256k1
+const G = Secp256k1.getGenerator("G1")


The signature scheme itself should be generic in constantine/signatures and concrete implementations should appear in constantine/my_protocol.nim

Yup, fair enough. I wrote it by defining the curve like this so that the code itself is already an (almost) valid generic / static proc. Didn't know if we want to make it fully generic immediately or start with secp256k1 only. Will address it.

mratsim · 2024-12-12T19:54:17Z

constantine/ecdsa/ecdsa.nim

+  var h {.noinit.}: sha256
+  h.init()
+  h.update(message)
+  h.finish(result)


This duplicates constantine/hashes.nim

constantine/constantine/hashes.nim

Lines 17 to 54 in 13d5bb7

type

CryptoHash* = concept h, var ctx, type H

## Interface of a cryptographic hash function

##

## - digestSizeInBytes is the hash output size in bytes

## - internalBlockSize, in bits:

## hash functions are supposed to ingest fixed block size

## that are padded if necessary

## - SHA256 block size is 64 bits

## - SHA512 block size is 128 bits

## - SHA3-512 block size is 72 bits

# should we avoid int to avoid exception? But they are compile-time

H.digestSize is static int

H.internalBlockSize is static int

# Context

# -------------------------------------------

ctx.init()

ctx.update(openarray[byte])

ctx.finish(var array[H.digestSize, byte])

ctx.clear()

func hash*[DigestSize: static int](

HashKind: type CryptoHash,

digest: var array[DigestSize, byte],

message: openArray[byte],

clearMem = false) {.genCharAPI.} =

## Produce a digest from a message

static: doAssert DigestSize == HashKind.type.digestSize

var ctx {.noInit.}: HashKind

ctx.init()

ctx.update(message)

ctx.finish(digest)

if clearMem:

ctx.clear()

mratsim · 2024-12-12T19:58:28Z

constantine/ecdsa/ecdsa.nim

+  h.update(message)
+  h.finish(result)
+
+proc toBytes(x: Fr[C] | Fp[C]): array[32, byte] =


Suggested change

proc toBytes(x: Fr[C] | Fp[C]): array[32, byte] =

proc toBytes(x: Fr[C] | Fp[C]): array[32, byte] {.noInit.} =

I assume this is temporary for debugging? Returning big arrays tends to generate bad code:

Out-of-place functions lead to bad codegen #145

Internal API: in-place vs result #21
It's also a recommendation in C / C++ to avoid return values that don't fit in registers.

Ah, that either slipped my mind or I just wasn't aware of it! Good to know. Will change it to an in-place variant.

mratsim · 2024-12-12T20:13:17Z

constantine/ecdsa/ecdsa.nim

+    ## XXX: smarter way for this?
+    let r = Fr[C].fromBig(rx.toBig())


This is the best generic conversion.

In theory for secp256k1, you could take mod r because Fp/Fr can be both use canonical representation and still have a fast reduction (#445) however at the moment only Fp uses canonical repr and fast reduction while Fr uses Montgomery representation and Montgomery reduction.

mratsim · 2024-12-12T20:17:51Z

constantine/ecdsa/ecdsa.nim

+proc getPublicKey*(pk: Fr[C]): EC_ShortW_Aff[Fp[C], G1] =
+  ## Derives the public key from a given private key,
+  ## `privateKey · G` in affine coordinates.
+  result = (pk * G).getAffine()


Can reuse

constantine/constantine/signatures/bls_signatures.nim

Lines 37 to 49 in 13d5bb7

func derivePubkey*[Pubkey, SecKey](pubkey: var Pubkey, seckey: SecKey) =

## Generates the public key associated with the input secret key.

##

## The secret key MUST be in range (0, curve order)

## 0 is INVALID

const Group = Pubkey.G

type Field = Pubkey.F

const EC = Field.Name

var pk {.noInit.}: EC_ShortW_Jac[Field, Group]

pk.setGenerator()

pk.scalarMul(seckey)

pubkey.affine(pk)

mratsim · 2024-12-12T20:24:19Z

constantine/ecdsa/ecdsa.nim

+  # 6. Verify r_computed equals provided r
+  result = bool(r_computed == signature.r)
+
+proc generatePrivateKey*(): Fr[C] =


This is not needed at this level, except maybe for testing.

Blockchain protocols have special ways to generate a private key usually from a mnemonic or via a HD derivation path (hierarchical deterministic) like BIP32 https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki or EIP-2333 (https://github.com/mratsim/constantine/blob/13d5bb7/constantine/ethereum_eip2333_bls12381_key_derivation.nim)

Yeah, I assumed having a way to generate a random private key might be useful. For testing we can just move it to a test file of course.

mratsim · 2024-12-12T20:25:28Z

constantine/ecdsa/ecdsa.nim

+  # Combine all parts
+  let contents = algoId & pubKeyEncoded
+  result.add(byte(contents.len))
+  result.add(contents)


For constantine/serialization and without dynamic alloc

mratsim · 2024-12-12T20:45:24Z

constantine/ecdsa/ecdsa.nim

+    # with `h`: message hash as `Fr[C]` (if we didn't use SHA256 w/ 32 byte output
+    # we'd need to truncate to N bits for N being bits in modulo `n`)
+    k.inv()
+    var s = (k * (message_hash + r * privateKey))


It might be faster to do k*privateKey and then a multiscalarmul([k, k*privkey], [message_hash, r]).

Note that the out-of-place functions are for convenience when debugging/testing/developping but not for production code (#413)

I understand. Still hasn't fully sunk in (intuitively) to avoid out-of-place procs! My bad. 😁

Vindaar · 2024-12-24T11:18:16Z

Vindaar · 2024-12-28T13:00:20Z

Mostly done now, I'd say. Addressed everything I could think of. The public API for ECDSA over secp256k1 could be extended a bit more, I suppose.

I wanted to use OpenSSL for PEM file writing as part of the tests to verify our serializers, but ended up giving up after wasting 2 hours or so with either getting segfaults in OpenSSL procedures or only having empty PEM files. So instead for that we still call to an external process to generate PEM files from our private and public keys, sign and verify a message.

I'll rebase and fix the conflict of the two files later. I pulled out the OpenSSL wrapper into a single file. Guess the files were updated on master.

The two main features lacking are public key recovery and batch verification.

(We might want to take this out before we merge?)

Adds a test vector generator and a test case (and test vectors) for verification of OpenSSL generated signatures.

Inspired by Bitcoin's implementation: https://github.com/bitcoin-core/secp256k1/blob/f79f46c70386c693ff4e7aef0b9e7923ba284e56/src/ecdsa_impl.h#L171-L193 Essentially, we just have a 72 byte buffer and only fill it up to `len` bytes.

The size is now a static argument of the type, depending on the curve. `DERSigSize` can be used to calculate the size required for the given curve.

Also cleans up the imports of the ECDSA file and adds the copyright header

…rrays Written for OpenSSL interop for test suite (to be moved to serialization with the other related procs).

Vindaar · 2024-12-30T14:45:01Z

Just rebased and force pushed the changes to fix the merge conflict.

Not sure what's happening here. Never seen that with any C wrappers.

API not currently available in the OpenSSL version on GH actions

...

mratsim · 2024-12-31T18:54:38Z

From testing with OpenSSL for hash functions:

On MacOS, OpenSSL isn't shipped it's LibreSSL instead so APIs can change, and they did because OpenSSL 3.0 was a big break.
On Windows, I'm not sure if we're dealing with 1..x or LibreSSL or yet another fork

but it's fine to skip testing vs OpenSSL on non-linux platforms for now.

mratsim

Review part 1.

We will need a followup refactoring on serialization to remove stdlib dependencies and ideally allocation as well.

Part 2 next year.

mratsim · 2024-12-31T18:58:53Z

constantine/serialization/codecs_ecdsa.nim

+  ## Has a `data` buffer of 72 bytes (maximum possible size for
+  ## a signature for `secp256k1`) and `len` of actually used data.
+  ## `data[0 ..< len]` is the actual signature.
+  DERSignature*[N: static int] = object


Mmmh, similar to Ecc or Kzg, I would capitalize as Der but DerSignature feels wrong in German xD

Haha, I think we can live with that. ;) We speak perfect German anyway, so no one would confuse 'DerSignature' with 'Der Signatur'. Only the latter would be wrong German after all!

mratsim · 2024-12-31T19:04:09Z

constantine/serialization/codecs_ecdsa_secp256k1.nim

+  constantine/math/io/io_bigints,
+  constantine/ecdsa_secp256k1
+
+import std / [strutils, base64, math, importutils]


This needs a follow up issue to remove the dependencies

Yes, as also mentioned in the docstring at the top. I'll open an issue for it!

Issue: #506

mratsim · 2024-12-31T19:07:25Z

constantine/serialization/codecs_ecdsa_secp256k1.nim

+proc wrap(s: string, maxLineWidth = 64): string =
+  ## Wrap the given string at `maxLineWidth` over multiple lines
+  let lines = s.len.ceilDiv maxLineWidth
+  result = newStringOfCap(s.len + lines)


In the refactoring issue, we should also remove the allocation.

ECDSA is used in embedded devices and in context where memory cannot be allocated dynamically like trusted enclaves or smart-cards, and I'd like constantine to be alloc-free for those use-cases

mratsim · 2024-12-31T19:07:56Z

constantine/serialization/codecs_ecdsa_secp256k1.nim

+    if i < lines-1:
+      result.add "\n"
+
+proc toPemFile*(publicKey: PublicKey): string =


This is not a file

mratsim · 2024-12-31T19:10:35Z

constantine/serialization/codecs_ecdsa_secp256k1.nim

+  # 3. Wrap in begin/end public key template
+  result = "-----BEGIN PUBLIC KEY-----\n"
+  result.add der64 & "\n"
+  result.add "-----END PUBLIC KEY-----\n"


It seems like the length of the result is fixed?
So in the refactoring issue for ECDSA serialization, we should replace the string output with a var array or var openarray (+ size check)

Yes, the length is fixed (in contrast to DER encoded signatures). The newStringOfCap was partially out of laziness as the inclusion of the stdlib base64 encoder renders the code anyhow in need of an overhaul. Will add as part of the issue I'll open.

edit: Issue #506

mratsim · 2024-12-31T19:12:48Z

constantine/signatures/common_signature_ops.nim

+
+  var pk {.noInit.}: EC_ShortW_Jac[Field, Group]
+  pk.setGenerator()
+  pk.scalarMul(seckey)


I'm pretty sure lattices don't derive public keys the same way ;).

Probably better to rename the file ecc_sig_ops.nim or something.

to clarify that these are only for EC based signatures.

mratsim

Review part 2. LGTM

mratsim · 2025-01-02T11:16:34Z

constantine/signatures/ecdsa.nim

+
+  result.fromBig(b)
+
+proc arrayWith[N: static int](res: var array[N, byte], val: byte) =


Suggested change

proc arrayWith[N: static int](res: var array[N, byte], val: byte) =

proc byteArrayWith(N: static int, val: byte): array[N, byte] {.noInit, inline.} =

This is only used twice and just after initialization. We can avoid bad codegen with {.inline.} and we can avoid avoid an extra memset(0) with {.noInit.}

mratsim · 2025-01-02T11:18:58Z

constantine/signatures/ecdsa.nim

+  # Step b: `V = 0x01 0x01 0x01 ... 0x01`
+  var v: array[N, byte]; v.arrayWith(byte 0x01)
+  # Step c: `K = 0x00 0x00 0x00 ... 0x00`
+  var k: array[N, byte]; k.arrayWith(byte 0x00)


awkward, see change to arrayWith to do declaration and init.

mratsim · 2025-01-02T11:25:30Z

constantine/signatures/ecdsa.nim

+  point1.scalarMul(u1, G)
+  point2.scalarMul(u2, publicKey)
+  var R {.noinit.}: EC_ShortW_Jac[Fp[Name], G1]
+  R.sum(point1, point2)


As mentioned in #504 (comment) this should be a dedicated proc, which would be subject to optimization in a later PR as it's a bottleneck for blockchain (signatures are verified all the time) and TLS.

Yup. I'll open an issue about these two cases (here and the other PR).
edit: #507

mratsim

LGTM, merging

mratsim · 2025-01-05T14:07:19Z

constantine/ecdsa_secp256k1.nim

+  ## Sign `message` using `secretKey` and store the signature in `sig`. The nonce
+  ## will either be randomly sampled `nsRandom` or deterministically calculated according
+  ## to RFC6979 (`nsRfc6979`)
+  sig.coreSign(secretKey.raw, message, sha256, nonceSampler)


I think it's Bitcoin protocol that uses SHA256?

We can rename the file btc_ecdsa_secp256k1.

Vindaar commented Dec 12, 2024

View reviewed changes

mratsim reviewed Dec 12, 2024

View reviewed changes

Vindaar added 25 commits December 30, 2024 15:41

[zoo] add generator for secp256k1

f43a97c

[ECDSA] add initial ECDSA signing / verifying implementation

6434eba

[ecdsa] fix imports

e8540b6

[ecdsa] export Secp256k1 as C for convenience

41d502d

(We might want to take this out before we merge?)

[ecdsa] export toDER proc

2760af4

[ecdsa] use isZero instead of old zero comparison

9f31c38

[ecdsa] rename private key generator & add private -> public key

5862d43

[tests] add test cases for ECDSA signature verification

4fd34e2

Adds a test vector generator and a test case (and test vectors) for verification of OpenSSL generated signatures.

[ecdsa] handle some .noinit. cases

a4ca057

[ecdsa] turn toBytes, arrayWith into in-place procedures

22bd57b

[ecdsa] clean up comment about Fp -> Fr conversion

4e17514

[ecdsa] replace toPemPrivateKey/PublicKey by in-place array variants

46d8f92

[ecdsa] replace toDER by non allocating variant

7164f07

Inspired by Bitcoin's implementation: https://github.com/bitcoin-core/secp256k1/blob/f79f46c70386c693ff4e7aef0b9e7923ba284e56/src/ecdsa_impl.h#L171-L193 Essentially, we just have a 72 byte buffer and only fill it up to `len` bytes.

[ecdsa] replace out-of-place arithmetic by in-place

890b185

[ecdsa] move ECDSA implementation to ~signatures~ directory

50de116

[ecdsa] remove dependence on explicit SHA256 hash function

931044d

[ecdsa] make DERSignature generic under curve by having static size

fe8a8aa

The size is now a static argument of the type, depending on the curve. `DERSigSize` can be used to calculate the size required for the given curve.

[ecdsa] turn more procs generic over curve and hash function

bec1536

[ecdsa] replace sign/verify API by one matching BLS signatures

34442fa

[ecdsa] remove global curve & generator constants

06f7a5f

[ecdsa] correctly handle truncation of digests > Fr BigInts

ad16403

create file for common signature ops, derivePubkey for ECDSA & BLS

e9174e6

Also cleans up the imports of the ECDSA file and adds the copyright header

create file specifically for ECDSA over secp256k1

4d72a6b

[ecdsa] add fromDER to split DER encoded signature back into r, s a…

a8ecd59

…rrays Written for OpenSSL interop for test suite (to be moved to serialization with the other related procs).

[tests] add OpenSSL wrapper intended for test cases

828189c

Vindaar added 7 commits December 30, 2024 15:42

[codecs] move serialization logic to ecdsa secp256k1 submodule

04ce1c8

[codecs] move DER signature serialization to codecs_ecdsa submodule

0c5195f

[ecdsa] adjust ECDSA secp256k1 API & test cases

89688ba

[ecdsa] add mini docstring for verify

5011fe3

[codecs] clean up imports in codecs_ecdsa.nim

fa5a5eb

[ecdsa] clean up imports of ecdsa_secp256k1.nim

2f6a897

[ecdsa] do not export raw field in ecdsa_secp256k1

2693aec

Vindaar force-pushed the ecdsaSecp256k1 branch from b8c972e to 2693aec Compare December 30, 2024 14:44

Vindaar mentioned this pull request Dec 30, 2024

Add ECRecover EVM precompile #504

Merged

Vindaar added 4 commits December 30, 2024 20:53

[CI] fix CI failures by including OpenSSL wrapper instead of import

1b44a8f

Not sure what's happening here. Never seen that with any C wrappers.

[bench] disable OpenSSL bench for sha256 on windows

c2c39af

API not currently available in the OpenSSL version on GH actions

[nimble] add ECDSA signature test to nimble task

fa9e0ab

[ecdsa] replace brainfart using pointer size for bits in byte

4cac2ec

...

[ecdsa] fix final related brainfart :)

30285ff

mratsim reviewed Dec 31, 2024

View reviewed changes

Vindaar added 5 commits December 31, 2024 20:48

[tests] when the brainfart infects the test cases too! 🤯

901597e

replace DERSig* by DerSig*

6c09fe1

replace toPemFile by simply toPem

0bbc839

rename common_signature_ops to ecc_sig_ops

20057e0

to clarify that these are only for EC based signatures.

[tests] disable ECDSA test for Windows

9642ca6

Vindaar mentioned this pull request Jan 1, 2025

Implement base64 encoder, avoid allocation in codecs_ecdsa_secp256k1.nim #506

Open

4 tasks

mratsim reviewed Jan 2, 2025

View reviewed changes

[ecdsa] avoid awkward arrayWith declaration & call

2fd2bb2

mratsim reviewed Jan 5, 2025

View reviewed changes

mratsim merged commit dca3a85 into master Jan 5, 2025
10 of 12 checks passed

mratsim deleted the ecdsaSecp256k1 branch January 5, 2025 14:08

mratsim added a commit that referenced this pull request Jan 6, 2025

ECDSA: OpenSSL skip MacOS test - followup #490 and #508

2f1498d

mratsim added a commit that referenced this pull request Jan 6, 2025

ECDSA: OpenSSL skip MacOS test - followup #490 and #508

787e776

		## XXX: raise / what else to do if `sysrand` call fails?
		doAssert b.limbs.sysrand()

		## XXX: smarter way for this?
		let r = Fr[C].fromBig(rx.toBig())

	# Deal with platform mess
	# --------------------------------------------------------------------
	when defined(windows):
	when sizeof(int) == 8:
	const DLLSSLName* = "(libssl-1_1-x64\|ssleay64\|libssl64).dll"
	else:
	const DLLSSLName* = "(libssl-1_1\|ssleay32\|libssl32).dll"
	else:
	when defined(macosx) or defined(macos) or defined(ios):
	const versions = "(.1.1\|.38\|.39\|.41\|.43\|.44\|.45\|.46\|.47\|.48\|.10\|.1.0.2\|.1.0.1\|.1.0.0\|.0.9.9\|.0.9.8\|)"
	else:
	const versions = "(.1.1\|.1.0.2\|.1.0.1\|.1.0.0\|.0.9.9\|.0.9.8\|.48\|.47\|.46\|.45\|.44\|.43\|.41\|.39\|.38\|.10\|)"

	when defined(macosx) or defined(macos) or defined(ios):
	const DLLSSLName* = "libssl" & versions & ".dylib"
	elif defined(genode):
	const DLLSSLName* = "libssl.lib.so"
	else:
	const DLLSSLName* = "libssl.so" & versions

	# OpenSSL wrapper
	# --------------------------------------------------------------------

	# OpenSSL removed direct use of their SHA256 function. https://github.com/openssl/openssl/commit/4d49b68504cc494e552bce8e0b82ec8b501d5abe
	# It isn't accessible anymore in Windows CI on Github Action.
	# But the new API isn't expose on Linux :/

	# TODO: fix Windows
	when not defined(windows):
	proc SHA256[T: byte\|char](
	msg: openarray[T],
	digest: ptr array[32, byte] = nil
	): ptr array[32, byte] {.noconv, dynlib: DLLSSLName, importc.}

	# proc EVP_Q_digest[T: byte\|char](
	# ossl_libctx: pointer,
	# algoName: cstring,
	# propq: cstring,
	# data: openArray[T],
	# digest: var array[32, byte],
	# size: ptr uint): int32 {.noconv, dynlib: DLLSSLName, importc.}

	proc SHA256_OpenSSL[T: byte\|char](
	digest: var array[32, byte],
	s: openArray[T]) =
	discard SHA256(s, digest.addr)
	# discard EVP_Q_digest(nil, "SHA256", nil, s, digest, nil)

	func coreSign*[Sig, SecKey](
	signature: var Sig,
	secretKey: SecKey,
	message: openArray[byte],
	H: type CryptoHash,
	k: static int,
	augmentation: openArray[byte],
	domainSepTag: openArray[byte]) {.genCharAPI.} =
	## Computes a signature for the message from the specified secret key.
	##
	## Output:
	## - `signature` is overwritten with `message` signed with `secretKey`
	##
	## Inputs:
	## - `Hash` a cryptographic hash function.
	## - `Hash` MAY be a Merkle-Damgaard hash function like SHA-2
	## - `Hash` MAY be a sponge-based hash function like SHA-3 or BLAKE2
	## - Otherwise, H MUST be a hash function that has been proved
	## indifferentiable from a random oracle [MRH04] under a reasonable
	## cryptographic assumption.
	## - k the security parameter of the suite in bits (for example 128)
	## - `output`, an elliptic curve point that will be overwritten.
	## - `augmentation`, an optional augmentation to the message. This will be prepended,
	## prior to hashing.
	## This is used for building the "message augmentation" variant of BLS signatures
	## https://www.ietf.org/archive/id/draft-irtf-cfrg-bls-signature-05.html#section-3.2
	## which requires `CoreSign(SK, PK \|\| message)`
	## and `CoreVerify(PK, PK \|\| message, signature)`
	## - `message` is the message to hash
	## - `domainSepTag` is the protocol domain separation tag (DST).

	type ECP_Jac = EC_ShortW_Jac[Sig.F, Sig.G]

	var sig {.noInit.}: ECP_Jac
	H.hashToCurve(k, sig, augmentation, message, domainSepTag)
	sig.scalarMul(secretKey)

	signature.affine(sig)

	type
	CryptoHash* = concept h, var ctx, type H
	## Interface of a cryptographic hash function
	##
	## - digestSizeInBytes is the hash output size in bytes
	## - internalBlockSize, in bits:
	## hash functions are supposed to ingest fixed block size
	## that are padded if necessary
	## - SHA256 block size is 64 bits
	## - SHA512 block size is 128 bits
	## - SHA3-512 block size is 72 bits

	# should we avoid int to avoid exception? But they are compile-time
	H.digestSize is static int
	H.internalBlockSize is static int

	# Context
	# -------------------------------------------
	ctx.init()
	ctx.update(openarray[byte])
	ctx.finish(var array[H.digestSize, byte])
	ctx.clear()

	func hash*[DigestSize: static int](
	HashKind: type CryptoHash,
	digest: var array[DigestSize, byte],
	message: openArray[byte],
	clearMem = false) {.genCharAPI.} =
	## Produce a digest from a message
	static: doAssert DigestSize == HashKind.type.digestSize

	var ctx {.noInit.}: HashKind
	ctx.init()
	ctx.update(message)
	ctx.finish(digest)

	if clearMem:
	ctx.clear()

	proc toBytes(x: Fr[C] \| Fp[C]): array[32, byte] =
	proc toBytes(x: Fr[C] \| Fp[C]): array[32, byte] {.noInit.} =

	func derivePubkey*[Pubkey, SecKey](pubkey: var Pubkey, seckey: SecKey) =
	## Generates the public key associated with the input secret key.
	##
	## The secret key MUST be in range (0, curve order)
	## 0 is INVALID
	const Group = Pubkey.G
	type Field = Pubkey.F
	const EC = Field.Name

	var pk {.noInit.}: EC_ShortW_Jac[Field, Group]
	pk.setGenerator()
	pk.scalarMul(seckey)
	pubkey.affine(pk)


		result.fromBig(b)

		proc arrayWith[N: static int](res: var array[N, byte], val: byte) =

	proc arrayWith[N: static int](res: var array[N, byte], val: byte) =
	proc byteArrayWith(N: static int, val: byte): array[N, byte] {.noInit, inline.} =

Add ECDSA over secp256k1 signatures and verification #490

Add ECDSA over secp256k1 signatures and verification #490

Conversation

Vindaar commented Dec 12, 2024 • edited Loading

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

mratsim 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

mratsim Dec 12, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Vindaar commented Dec 24, 2024 • edited Loading

Vindaar commented Dec 28, 2024

Vindaar commented Dec 30, 2024

mratsim commented Dec 31, 2024

mratsim 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

Vindaar Jan 1, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mratsim 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

Vindaar Jan 4, 2025 • edited Loading

Choose a reason for hiding this comment

mratsim left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Vindaar commented Dec 12, 2024 •

edited

Loading

mratsim Dec 12, 2024 •

edited

Loading

Vindaar commented Dec 24, 2024 •

edited

Loading

Vindaar Jan 1, 2025 •

edited

Loading

Vindaar Jan 4, 2025 •

edited

Loading