Les services Go qui traitent des signatures Ethereum importent généralement github.com/ethereum/go-ethereum/crypto et accounts. Avec cgo activé, le paquet utilise la copie de libsecp256k1 embarquée dans go-ethereum ; avec CGO_ENABLED=0, il se rabat sur l’implémentation decred en pur Go. Les essais ont porté sur les deux builds, et chaque constat était identique de l’un à l’autre.
crypto.Sign(hash, key) prend exactement 32 octets (sinon, il échoue avec hash is required to be exactly 32 bytes) et n’effectue ni hachage ni ajout de préfixe. Un message de connexion doit d’abord passer par accounts.TextHash, qui ajoute le préfixe EIP-191 et hache avec keccak-256 ; les essais l’ont confirmé avec un keccak indépendant. Signer à la place le simple keccak du message produit une signature qui ne correspondra jamais à celles d’ethers, de viem et des portefeuilles.
La signature fait 65 octets, avec l’identifiant de récupération sous la forme v = 0 ou 1, alors que les portefeuilles, ethers, viem et web3.py y placent 27 ou 28. crypto.Ecrecover a rejeté v = 27/28 avec invalid signature recovery id : soustrayez donc 27 à l’entrée et rajoutez-le à la sortie, comme le fait l’exemple. Les nonces suivent la RFC 6979 (la signature correspondait à celle d’une implémentation de référence indépendante) et s est toujours dans la moitié inférieure.
Les deux chemins de vérification divergent sur high-S. crypto.VerifySignature, qui prend 64 octets sans v, a rejeté la signature miroir (r, n − s), mais crypto.Ecrecover et crypto.SigToPub en ont récupéré la bonne clé publique, comme le fait le contrat précompilé ecrecover de l’EVM. Les contrats et les services qui récupèrent des adresses doivent donc rejeter eux-mêmes les signatures high-S s’ils traitent une signature comme un identifiant unique.
Les clés publiques circulent sous forme de point SEC1 non compressé de 65 octets ou de point compressé de 33 octets, et les clés privées sous forme de scalaires de 32 octets. Pour savoir quelle convention suit une signature, collez-la dans le vérificateur de signatures Ethereum ; les nonces répétés entre les transactions d’une même adresse apparaissent dans le vérificateur de réutilisation de nonce Ethereum.