Skip to content
Love & Improve Life
  • Game
  • DIY
  • Use English
  • Learn English
  • Cooking

[Ethereum] How are ethereum addresses generated

account-generationaccountsaddressescryptography

What criteria does a valid Ethereum address need to fulfill? Is it just a random number in hexadecimal? Or does it need to be derived in a specific way, according to some cryptographic algorithms? What algorithms and standards are used to generate the key-pair?

Best Answer

Recently this article came to my attention that is way more in depth and technical than my more accessible version below. It also walks you through how to generate one on your own. I highly recommend it: https://kobl.one/blog/create-full-ethereum-keypair-and-address/


From the Yellow Paper

yellow paper

There are three main steps to get from private -> address:

  1. Create a random private key (64 (hex) characters / 256 bits / 32 bytes)

  2. Derive the public key from this private key (128 (hex) characters / 512 bits / 64 bytes)

  3. Derive the address from this public key. (40 (hex) characters / 160 bits / 20 bytes)

Even though a lot of people call the address the public key, it's actually not the case in Ethereum. There is a separate public key that acts as a middleman that you won't ever see, unless you go poking around a pre-sale wallet JSON file.

1. Generating private key

The private key is 64 hexadecimal characters. Every single string of 64 hex are, hypothetically, an Ethereum private key (see link at top for why this isn't totally accurate) that will access an account. If you plan on generating a new account, you should be sure these are seeded with a proper RNG. Once you have that string..

2. Private Key -> Public Key

This is hard and beyond me. There is something with Elliptic Curve Digital Signature Algorithm (ECDSA) and stuff. But in the end you end up with a public key that is 64 bytes.

3. Public key -> Address

  1. Start with the public key (128 characters / 64 bytes)

  2. Take the Keccak-256 hash of the public key. You should now have a string that is 64 characters / 32 bytes. (note: SHA3-256 eventually became the standard, but Ethereum uses Keccak)

  3. Take the last 40 characters / 20 bytes of this public key (Keccak-256). Or, in other words, drop the first 24 characters / 12 bytes. These 40 characters / 20 bytes are the address. When prefixed with 0x it becomes 42 characters long.

Definitions

Address: An Ethereum address represents an account. For EOA, the address is derived as the last 20 bytes of the public key controlling the account, e.g., `cd2a3d9f938e13cd947ec05abc7fe734df8dd826. This is a hexadecimal format (base 16 notation), which is often indicated explicitly by appending 0x to the address. Web3.js and console functions accept addresses with or without this prefix but for transparency we encourage their use. Since each byte of the address is represented by 2 hex characters, a prefixed address is 42 characters long. Several apps and APIs are also meant to implement the new checksum-enabled address scheme introduced in the Mist Ethereum wallet as of version 0.5.0. - Homestead Docs

Private Key: A randomly selected positive integer (represented as a byte array of length 32 in big-endian form) in the range [1, secp256k1n − 1]. - Yellow Paper

Related Solutions

[Ethereum] use the same private key for Ethereum and Bitcoin

Yes, both cryptocoins use the same elliptic curve SECP256K1.

Perhaps a better alternative is to use a BIP32 wallet. You have a master key that is not directly used for transactions, but it is used to derive child keys than can be used.

You can derive separate keys for bitcoin and ethereum. You will always be able to use the master key to sign transactions for both keys.

[Ethereum] Is each Ethereum address shared by (theoretically) 2 ** 96 private keys

Your calculations are right, except there aren't exactly 2^256 private keys -- there are "FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141" (this number is named N in the ETH source code, and is the order of the generator of the elliptic curve secp256k1, from which Ethereum key pairs are generated).

In answer to your question, yes, private keys mapping to the same address will both be able to spend the money in that address on a first come first served basis. They will create the same public key, which the ECDSA verification algorithm is performed against, and so signatures generated by either private key will verify against the same address!

In go-ethereum/accounts/key.go, we have a private key generated from S256 which is secp256k1's curve, meaning they will be less than N be default.

func newKeyFromECDSA(privateKeyECDSA *ecdsa.PrivateKey) *Key {
    id := uuid.NewRandom()
    key := &Key{
        Id:         id,
        Address:    crypto.PubkeyToAddress(privateKeyECDSA.PublicKey),
        PrivateKey: privateKeyECDSA,
    }
    return key
}

func newKey(rand io.Reader) (*Key, error) {
    privateKeyECDSA, err := ecdsa.GenerateKey(secp256k1.S256(), rand)
    if err != nil {
        return nil, err
    }
    return newKeyFromECDSA(privateKeyECDSA), nil
}

go-ethereum/crypto/secp256k1/secp256 also generates the key pairs in accordance with secp2656k1 albeit in a slightly different way :)

Cool illustrative explanation for what N really is and why 2 keys will be able to spend money from the same account

Imagine private keys are miles driven in your car, and public keys are number of miles on your car's odometer. If the odometer rolls over from 999,999 to 000,000, a person with miles driven = 1,000,001 will have the same 'public key', and hence the same address, as a person with miles driven = 1.

EC group arithmetic is surprisingly similar to this, but rather than 999,999, we have the seemingly arbitrary number given above! Due to this property, even with your different 'private keys', you will be able to create signatures that verify against the same public key, and hence spend ETH from the same address!!

Boring math explanation

Private keys are 256 bit numbers, and to calculate the public key from a private key you multiply by the generator, g, of the elliptic curve group. The generator in use is defined in the parameters of the secp256k1 libraries being used in ETH. It itself is also an elliptic curve point, and as elliptic curves are cyclic, there exists an n such that n.g = 1 (this is called the generator order).

With this equation we can see that if we had a private key k with k>n, we would have k.g = (k-n).g = k'.g, for a k' that is possibly someone else's private key! So we have keys generated at random modulo n, rather than 2^256.

Related Topic