Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming > #12000

Re: an ethereum ECDSA-difficulty

From Boris Dorestand <bdorestand@example.com>
Newsgroups comp.programming
Subject Re: an ethereum ECDSA-difficulty
Date 2021-01-29 13:06 -0300
Organization Aioe.org NNTP Server
Message-ID <864kiz3eyd.fsf@example.com> (permalink)
References <868s8c4zyu.fsf@example.com> <87im7fooo6.fsf@LkoBDZeT.terraraq.uk>

Show all headers | View raw


Richard Kettlewell <invalid@invalid.invalid> writes:

> Boris Dorestand <bdorestand@example.com> writes:
>> The nonce is 1, the gas price is 20 gwei, the maximum gas units is
>> 21000, the to-address is correct, the amount is 1 ether = 10^18 wei, the
>> data payload is empty, the v value of the signature is 46, as I intended
>> and the r, s values of the signature are precisely those I intended to
>> encode.  Everything looks perfectly as it should.
>>
>> --8<---------------cut here---------------start------------->8---
>> out.rkt> r
>> 30190652438768558380735263684943397541547868147655542157485309011183437025247
>> out.rkt> s
>> 93620689063899170013813414230496747665687050654128603934107115817203536307811
>> --8<---------------cut here---------------end--------------->8---
>
> That does not meet Ethereum’s signature canonicalization requirements.
>
>     $ python3
>     Python 3.7.3 (default, Jul 25 2020, 13:03:44) 
>     [GCC 8.3.0] on linux
>     Type "help", "copyright", "credits" or "license" for more information.
>     >>> n=115792089237316195423570985008687907852837564279074904382605163141518161494337
>     >>> r=30190652438768558380735263684943397541547868147655542157485309011183437025247
>     >>> s=93620689063899170013813414230496747665687050654128603934107115817203536307811
>     >>> s<(n//2)+1
>     False
>     >>> 
>
> See https://files.gitter.im/ethereum/yellowpaper/VIyt/Paper.pdf (212), p21.

Thank you, Richard.  That was part of the problem.

I also went through another problem which is the fact that I don't have
the full point r, only its x-coordinate, shown above.  I don't think the
package crypto-lib (https://pkgs.racket-lang.org/package/crypto-lib)
exposes the full point r, so I was left with calculating the
y-coordinate of r.  However, there are at least two possibilities for
such y-coordinate:

   sqrt(r^3 + 7)
  -sqrt(r^3 + 7) == -sqrt(r^3 + 7) + p,

where p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F.

So I essentially need to try both and see which ones match the signer
when I recover the public key from the signature.  I know the signer
(it's myself) and so I look at both public keys and see which one is
really mine, that is, I brute-force the v value.

I must still learn to recover public keys from signatures.

There are some details I might still not quite understand.  Perhaps
there are 4 possible public keys, instead of 2.  Perhaps 2 of these 4
are very unlikely to come up.  I'm studying these bits still.

Thanks very much for your attention.

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

an ethereum ECDSA-difficulty Boris Dorestand <bdorestand@example.com> - 2021-01-28 16:35 -0300
  Re: an ethereum ECDSA-difficulty Richard Kettlewell <invalid@invalid.invalid> - 2021-01-29 13:31 +0000
    Re: an ethereum ECDSA-difficulty Boris Dorestand <bdorestand@example.com> - 2021-01-29 13:06 -0300
  Re: an ethereum ECDSA-difficulty "Dirk T. Verbeek" <dverbeek@xs4all.nl> - 2021-01-30 18:10 +0100

csiph-web