Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EcRecover #3633

Open
wants to merge 12 commits into
base: HF_Echidna
Choose a base branch
from
Open

EcRecover #3633

wants to merge 12 commits into from

Conversation

shargon
Copy link
Member

@shargon shargon commented Dec 18, 2024

Description

Close #3628

Type of change

  • Optimization (the change is only an optimization)
  • Style (the change is only a code style for better maintenance or standard purpose)
  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

  • Crypto tests

Test Configuration:

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules

@shargon shargon requested a review from Jim8y December 18, 2024 12:06
@shargon shargon changed the base branch from master to HF_Echidna December 18, 2024 12:07
var messageHash = message.Sha256();
var recover = Crypto.ECRecover(Neo.Cryptography.ECC.ECCurve.Secp256k1, signature, messageHash, SignatureFormat.Fixed32);

recover.Length.Should().Be(2);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without V we can get more than one address


// TODO: Not tested, check if it works
case NamedCurveHash.secp256r1Keccak256:
case NamedCurveHash.secp256r1SHA256:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if it will work with these curves

@shargon shargon marked this pull request as ready for review December 18, 2024 12:09
@shargon shargon changed the title Ec recover EcRecover Dec 18, 2024
/// <param name="curveHash">A pair of the curve to be used by the ECDSA algorithm and the hasher function to be used to hash message.</param>
/// <returns><see langword="true"/> if the signature is valid; otherwise, <see langword="false"/>.</returns>
[ContractMethod(Hardfork.HF_Aspidochelone, CpuFee = 1 << 10)]
public static ECPoint[] ECrecover(byte[] message, byte[] signature, NamedCurveHash curveHash)
Copy link
Member Author

@shargon shargon Dec 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we don't have the v we can get multiples public keys

case NamedCurveHash.secp256k1SHA256:
{
return Crypto.ECRecover(ECCurve.Secp256k1, signature, messageHash,
// TODO: only accept 65?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

64bytes signatures MAY store a parity bit in the first bit of the s value which is always 0.
From what I deduce, you assume the parity value to be 0 if the size is 64 so checking the first bit of s will not change the current behavior if this is not a compressed signature (i.e. parity will always be 0) But in case it is a compressed ERC-2098 signature, it will be supported out-of-the-box

Note: this is predicated on the assumption that N3 contracts might need to verify signatures that originate in NEOX where EIP standards might apply (eg: someone migrates a platform written for Ethereum to NeoX)
for reference, this is the compressed signature standard I am referring to: https://eips.ethereum.org/EIPS/eip-2098

default: throw new InvalidOperationException("Invalid signature format");
}

// Validate values

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

on the topic of validation, maybe having the s value in the lower half of the domain would be a good guard against signature maleability. At least that's how that was addressed in ethereum where the wallets only generate (r,s) pairs with s lower than n/2 (where n is the order of the curve). Because a pair (r, n-s) is also a valid solution leading to possible issues.

src/Neo/SmartContract/Native/CryptoLib.cs Outdated Show resolved Hide resolved
}
}
}
catch { }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Several lines below we do throw new NotSupportedException(nameof(ch.Hasher)); if hashing algorythm is not supported. This exception should be properly thrown, so we don't need to catch it here.

@Jim8y
Copy link
Contributor

Jim8y commented Dec 19, 2024

Maybe we can actually have two methods:

==Specification==

===Native Contract Interface===

Two methods will be added to CryptoLib in HF_Echidna:

====Method 1: Recovery from Signature====

{
    "name": "secp256k1Recover",
    "safe": true,
    "parameters": [
        {
            "name": "message",
            "type": "ByteArray"
        },
        {
            "name": "hasher",
            "type": "Integer"
        },
        {
            "name": "signature",
            "type": "ByteArray"
        }
    ],
    "returntype": "ByteArray"
}

====Method 2: Recovery from Components====

{
    "name": "secp256k1Recover",
    "safe": true,
    "parameters": [
        {
            "name": "message",
            "type": "ByteArray"
        },
        {
            "name": "hasher",
            "type": "Integer"
        },
        {
            "name": "r",
            "type": "ByteArray"
        },
        {
            "name": "s",
            "type": "ByteArray"
        },
        {
            "name": "v",
            "type": "Integer"
        }
    ],
    "returntype": "ByteArray"
}

===Method Specification===

Both methods MUST follow these rules:

  1. Input Requirements for secp256k1Recover:

    • message: Original message bytes
    • hasher: Hash function ID
      • 1: SHA256
      • 2: RIPEMD160
      • Others: Reserved for future use
    • signature: 65 bytes (32 bytes r + 32 bytes s + 1 byte v)
  2. Input Requirements for secp256k1Recover (components):

    • message: Original message bytes
    • hasher: Hash function ID (same as above)
    • r: 32 bytes
    • s: 32 bytes
    • v: Recovery ID (27 or 28)
  3. Return Value (both methods):

    • Success: 33-byte compressed public key in SEC format
    • Failure: Returns null if:
      • Invalid signature/component length
      • Invalid recovery value (v)
      • Invalid signature format
      • Recovery failure

Comment on lines 159 to 160
if (r.SignValue < 0) throw new ArgumentException("r should be positive");
if (s.SignValue < 0) throw new ArgumentException("s should be positive");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/Hecate2/ECrecover/blob/c3ec9b4ca4f74e66c426b48452f86cf643a9f6fb/Program.cs#L83-L84

        if (r.CompareTo(BigInteger.One) < 0 || r.CompareTo(curve.N) > 0) throw new ArgumentException($"Invalid r value {r}; expected [1, {curve.N}]");
        if (s.CompareTo(BigInteger.One) < 0 || s.CompareTo(curve.N) > 0) throw new ArgumentException($"Invalid s value {s}; expected [1, {curve.N}]");

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Optionally we can require s < n / 2 if v is not specified, for Ethereum

@shargon
Copy link
Member Author

shargon commented Dec 19, 2024

Maybe we can actually have two methods:

==Specification==

===Native Contract Interface===

Two methods will be added to CryptoLib in HF_Echidna:

====Method 1: Recovery from Signature====

{
"name": "secp256k1Recover",
"safe": true,
"parameters": [
{
"name": "message",
"type": "ByteArray"
},
{
"name": "hasher",
"type": "Integer"
},
{
"name": "signature",
"type": "ByteArray"
}
],
"returntype": "ByteArray"
}
====Method 2: Recovery from Components====

{
"name": "secp256k1Recover",
"safe": true,
"parameters": [
{
"name": "message",
"type": "ByteArray"
},
{
"name": "hasher",
"type": "Integer"
},
{
"name": "r",
"type": "ByteArray"
},
{
"name": "s",
"type": "ByteArray"
},
{
"name": "v",
"type": "Integer"
}
],
"returntype": "ByteArray"
}
===Method Specification===

Both methods MUST follow these rules:

  1. Input Requirements for secp256k1Recover:

    • message: Original message bytes

    • hasher: Hash function ID

      • 1: SHA256
      • 2: RIPEMD160
      • Others: Reserved for future use
    • signature: 65 bytes (32 bytes r + 32 bytes s + 1 byte v)

  2. Input Requirements for secp256k1Recover (components):

    • message: Original message bytes
    • hasher: Hash function ID (same as above)
    • r: 32 bytes
    • s: 32 bytes
    • v: Recovery ID (27 or 28)
  3. Return Value (both methods):

    • Success: 33-byte compressed public key in SEC format

    • Failure: Returns null if:

      • Invalid signature/component length
      • Invalid recovery value (v)
      • Invalid signature format
      • Recovery failure

@Jim8y could you change it?

@Jim8y Jim8y mentioned this pull request Dec 19, 2024
11 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Recover Public Key from Signature for Secp256k1
5 participants