Cross-posted from question

I've been working on writing a signer service for an Ethereum transaction manager and I need to sign Ethereum transactions using Google KMS Golang APIs. I'll try and summarise the problems I'm facing below.

Ethereum requires compact RLP encoded 65-byte ECDSA signatures in R || S || V format. ECDSA signatures by Google KMS on the other hand have extra header components (R length, S length, etc) along with variable length R and S components. This makes these signatures incompatible for use with Ethereum transaction signing.

A way to get around this is parsing the R and S bytes from the ecdsa signature obtained from Google KMS, compute and add the V byte to the end and use this signature to get a signed Ethereum transaction. Something like this:

var parsedSig struct{ R, S *big.Int }
_, err = asn1.Unmarshal(body, &parsedSig)
if err != nil {
    logger.WithError(err).Error("failed to parse signature bytes")
    return err

However this would possibly fail due to one or more of the following reasons:

  • Creating compact ECDSA signatures of 65-byte length by parsing out the R and S components and adding the V component is possibly as distrustful as it sounds. R and S components as mentioned above are not always of 32 byte length for standard ECDSA signatures, which means that the ECDSA signature created by concatenating the components might not always result in 64 bytes.
  • Currently signed transactions in Ethereum are created from Keccak-256 digest hashes after RLP encoding transactions as shown below:
    // from go-ethereum
    func rlpHash(x interface{}) (h common.Hash) {
        hw := sha3.NewLegacyKeccak256()
        rlp.Encode(hw, x)
        return h
    Asymmetric ECDSA key signing in Google KMS doesn’t have support for Keccak-256 SHA3 message digests. Would using a SHA-256 digest for ethereum transactions work? IMO this would fail since all transaction signature verification happens on RLP encoded Keccak hashes.
  • At this point I am not very sure how to compute the V component of the ECDSA signature after having checked the secp256k1 implementation of the secp256k1_ecdsa_sign_recoverable() function.

How do I go about solving these above issues to be able to create verifiable signed Ethereum transactions using asymmetric elliptic curve signing algorithm by Google KMS?

  • Do they support secp256k1? Until a few months ago it wasn't supported.
    – Ismael
    Aug 13, 2019 at 17:46
  • currently, it seems they support secp256k1, but there is no RLP message digest.
    – Lion.k
    Jan 13, 2022 at 3:08

2 Answers 2


I did some research regarding GCP KMS, unfortunately it does not support ECDSA secp256k1 which used in Ethereum, so it is not possible to use it in the case. You may find more details here https://stackoverflow.com/questions/58053715/how-to-set-up-a-keyvault-using-secp256k1-algorithm-in-gcp


You can use GCP to sign Ethereum transactions (with secp256k1).

https://pkg.go.dev/github.com/pascaldekloe/[email protected]/google

Would using a SHA-256 digest for ethereum transactions work?

I was having the same doubts there. The curve calculation does not care about the hash algorithm for as far as I know. Maybe Google uses the classification for the size only? Either way, SHA-256 works just fine here.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.