> On 5. Aug 2020, at 00:08, Alessio Vanni <[email protected]> wrote: > > "Schanzenbach, Martin" <[email protected]> writes: > >> Before you look into such low level calls you should double and triple check >> our >> own code and data: > > I worded it poorly, but I meant that the error happens when we reach the > actual verification, not before and that I wouldn't be able to tell if > there was something going on there or not. > >> Is the data ("container") you are sending the same (output the hex) on >> both ends before hashing? > > Yes. In a normal communication this happens two times, and for two > times everything is the same. > >> Is the hash of the data the same on both ends? (this one is easier to >> check as you can print the hash using GNUNET_h2s). > > Unless GNUNET_h2s is lying, the hash is the same. I did a simple > `printf("%s\n", GNUNET_h2s(&sd->hash))' to see what is being computed. > >> Is the public key received the one to expect when deriving it from the >> private key? (again print the key). > > Yes, it's the same. I even checked with gnunet-identity and the printed > key is the same as the one generated by the identity service. > >> If you checked all of the above, and they ALL match, then we should consider >> looking at the crypto >> in more detail. > > I'll wait for more instructions if I need to do something in particular.
You could try to use the "GNUNET_CRYPTO_ecdsa_verify_" and "GNUNET_CRYPTO_ecdsa_sign_" functions in case there is a bug in the defines that wrap them. BR > > Thanks, > A.V.
signature.asc
Description: Message signed with OpenPGP
