Key and Transaction Management in Ethereum

Security keys are used almost everywhere within Ethereum during user interactions, and the Ethereum address is derived from the private key. In other words, the Ethereum address is the last 20 bytes of hash of the public key controlling the account with 0x appended in front.

How are Ethereum addresses generated?

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

  • Create a random private key (64 (hex) characters / 256 bits / 32 bytes)
  • Derive the public key from this private key (128 (hex) characters / 512 bits / 64 bytes)
  • 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.

Generating private key

The procedure for generating private keys relies on pseudo-random number generators (PRNG) with enough entropy. The most important thing to remember about a private key is that it needs to be selected randomly from the integer space 2^256-1. Any number can be a private key as long as it’s within the value of 1 and 2^256 - 1.

Note, if you plan on generating a new account, you should be sure these are seeded with a proper RNG.

A Private Key is a randomly selected positive integer (represented as a byte array of length 32 in big-endian form) in the range [1, secp256k1n − 1]. Every single string of 64 hex are, hypothetically, an Ethereum private key, that will access an account.

Private Key -> Public Key

To generate an Public Key from this Private Key, we need to do Elliptic Curve point multiplication, where we multiply the generator point and concatenate the coordinates into a single value. This can be complicated, so to simplify, using Elliptic Curve Digital Signature Algorithm (ECDSA), you end up with a public key that is 64 bytes.

Public key -> Address

An Ethereum address represents an account. For Externally Owned Accounts (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.

To get one, start with the public key (128 characters / 64 bytes). 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). 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. Since each byte of the address is represented by 2 hex characters, a 0x prefixed address is 42 characters long.

For a given private key, the Ethereum address A is defined as the rightmost 160-bits of the Keccak hash of the corresponding ECDSA public key.

Transactions and keys

R, S and V

It is also possible to retrieve the public key from the signed transaction. However, you can do so if and only if a transaction has been sent from the account. When you send a tx, you sign the transaction and it includes the r, s and v values, where r and s are the 2 values used in standard ECDSA signatures; and v is the recovery value.

Specifically, the (r, s) is the normal output of an ECDSA signature, and with great probability, 𝑥 represents 𝑟 and 𝑦 represents 𝑠. The r is computed as the X coordinate of a point R, modulo the curve order n. The fact is that if you have the full R point (not just its X coordinate) and s, and a message, you can compute for which public key this would be a valid signature. What this allows is to 'verify' a message with an address, without needing to know the full key (we just do public key recovery on the signature, and then hash the recovered key and compare it with the address).

There can be up to 4 different points with a given "X coordinate modulo n". (2 because each X coordinate has two possible Y coordinates, and 2 because r+n may still be a valid X coordinate). That number between 0 and 3 we call the recovery id, or recid. Therefore, we return an extra byte, which also functions as a header byte, by using 27+recid (for uncompressed recovered pubkeys) or 31+recid (for compressed recovered pubkeys) - which is our v with the following options:

  • 27/31 = lower X even Y
  • 28/32 = lower X odd Y
  • 29/33 = higher X even Y
  • 30/34 = higher X odd Y

Strictly speaking the recid is not necessary, as we can just cycle through all the possible coordinate pairs and check if any of them match the signature. The recid just speeds up this verification. Note that 29 and 30 (or their compressed versions 33 and 34) are exceedingly rarely, and will in practice only ever be seen in specifically generated examples. There are only two possible X values if r is between 1 and (p mod n), which has a chance of about 0.000000000000000000000000000000000000373 % to happen randomly. For any v >= 35 you might be dealing with Ethereum signatures as per EIP-155: v = recovery_id + CHAIN_ID * 2 + 35

Moving on...

One can parse the r, s and v parameters from the signed tx and then pass these values and the hash of the transaction back into a special recovery function and it'll spit out the public key (Solidity provides a built-in function ecrecover that accepts a message along with the r, s, and v parameters and returns the address that was used to sign the message).

Note, that r, s, v, are specific to a transaction (and nonce), so using r, s, v on another transaction will almost always have an invalid effect.

Also, it is not possible to uniquely recover the public key only from an ECDSA signature (r, s). This remains true even if we also assume you know the curve, the hash function used, and you also have the message that was signed. With the signature and the message that was signed, and the knowledge of the curve, it is possible to generate two public keys; only one of which will be the public key corresponding to the private key used.

Comments

Post a Comment

Popular posts from this blog

CAP Theorem and blockchain

Image
In theoretical computer science, the CAP theorem states that it is impossible for a distributed data store (such as a blockchain network) to simultaneously provide more than two out of the three guarantees: Consistency, Availability & Partition tolerance. CAP Theorem – the parts C: Consistency – At any given time, all nodes in the network have exactly the same (most recent) value. A: Availability – Every request to the network receives a response, though without any guarantee that returned data is the most recent. P: Partition tolerance – The network continues to operate, even if an arbitrary number of nodes are failing. Due to the nature of distributed data stores (such as blockchain), Partition tolerance is a given fact; there will always be failing/unreachable nodes in the network (not least because of the unstable nature of the internet). CAP Theorem states that one has to choose between C (Consistency) or A (Availability) when in the presence of P (Partition): Av...
Read more

Length extension attack

Image
What is length extension? When a Merkle–Damgård based hash is misused as a message authentication code with construction H(secret ‖ message), and message and the length of secret is known, a length extension attack allows anyone to include extra information at the end of the message and produce a valid hash without knowing the secret. Quick sidebar, before you freak out: Since HMAC does not use this construction, HMAC hashes are not prone to length extension attacks. So, a length extension attack is a type of attack where an attacker can use Hash(message1) and the length of message1 to calculate Hash(message1 ‖ message2) for an attacker-controlled message2, without needing to know the content of message1. Algorithms like MD5, SHA-1 and most of SHA-2 that are based on the Merkle–Damgård construction are susceptible to this kind of attack. Truncated versions of SHA-2, including SHA-384 and SHA-512/256 are not susceptible, nor is the SHA-3 algorithm. A bit more details ...
Read more

Contract upgrade anti-patterns

Image
A popular trend in smart contract design is to promote the development of upgradable contracts . To be fair, existing techniques to upgrade contracts have flaws, increase the complexity of the contract significantly, and ultimately introduce bugs - even in the Zeppelin contract upgrade strategy. In this article, we are going to detail our analysis of existing smart contract upgrade strategies, describe the weaknesses we have observed in practice, and provide recommendations for contracts that require upgrades. In a follow-up blog post, we will detail a method, contract migration, that achieves the same benefits with few of the downsides. An overview of upgradable contracts Two ‘families’ of patterns have emerged for upgradable smart contracts: Data separation, where logic and data are kept in separate contracts. The logic contract owns and calls the data contract. Delegatecall-based proxies, where logic and data are kept in separate contracts, also, but the data contr...
Read more