How do Ethereum and Solana generate public and private keys?

Wuzhong Zhu

November 22, 2022

This is an article about the secret behind accounts, seed phrases, and key pairs.

In the Web3 world, the private and public key is, and always will be a user’s sole identity on-chain. But not many people know how it works. Do you think you are a Blockchain expert? Here are some questions to test your understanding:

Can Ethereum private keys be imported on Solana?
Can hackers brute force crack a private key base on public information?
How likely are two users are assigned to the same public address?
Are different blockchains using the same cryptography system?
What is a seed phrase and how does it work?

This blog explains how public keys and private keys are generated on Ethereum and Solana. You can find the answer to the above questions along the way:

The public key, and private key, what are they?
Ethereum vs Solana
How does Ethereum generate a public address from a private key?
How does Solana generate a public address from a private key?
How secure is this system?
Technical terminologies
- BIP-32 and BIP-39
- ED25519 and ECDSA
- SHA512 and Keccak-256
Conclusion

What are the public key and the private key?

Let’s start with the private key.

Ethereum and Solana’s private keys both are 32 bytes/256 bits. So technically you can use the same key for both chains. But you should never do that, we will get into this later.

In the cryptography world, private key and public key are mainly used in two areas– encryption and authentication. In both cases, the public key is known by everyone (just as the name suggested), and the private key is known only to the owner self.

Let’s say Derp wants to send a message to Derpina asking her out for dinner.

In the case of Encryption, Derp can encrypt his message with Derpina’s public key. When the message is sent, no one can interpret it.

When Derpina receives her message, she can decrypt it with her private key. Hence message is transferred securely.

However, encryption is NOT relevant to our topic today.

For blockchain protocols, authenticity is the primary use case of cryptography. When a message, or transaction from a blockchain’s perspective, is sent, the main question is whether the message is indeed from its said sender.

When a message/transaction was created, it was attached with a signature from the sender.

The signature is generated from the sender’s private key and anyone can verify its authenticity with the sender’s public key. Theoretically, no one can forge a signature without knowing the private key behind it.

Here comes the first takeaway– the public key is generated from the private key and authenticity is the main use case for blockchain.

The second takeaway for you is: a private key is not a password.

Open MetaMask or any other Ethereum wallet; go to “Import account” and paste the following private key into the text box: “1111111111111111111111111111111111111111111111111111111111111111”.

There are sixty-four 1s in this key string. As mentioned, Ethereum’s private key is 32 bytes/256 bits. In most cases, it is represented as hexadecimal characters. Two hexadecimal are equivalent to 1 byte of data; therefore, the private key entered is a 64-character string.

MetaMask will import the following account.

The account for private key “1111111111111111111111111111111111111111111111111111111111111111”

Hacker in the house! 🥷

Anyone can easily access any account, as long as the private key is valid. The user does not need to provide the public key or go through any other authentication steps. This applies to both Ethereum and Solana, or any other blockchain.

Ethereum vs Solana private key generation

So, can a user replicate the same steps to import a random private key into a Solana wallet? The simple answer is no, at least not directly. Use two popular Solana wallets – Phantom and Solflare – as an example.

This is the “Private key” from Phantom:

This is the “Private key” from Solflare:

Notice how these two “private keys” are in a different format?

Yes, unlike Ethereum, which represents data in hexadecimal; Solana represents data in two systems(mostly): Base58 and Uint8. Both of them are valid formats and under the hood, they represent the same set of binary data.

Dig a little deeper, you will realize that the “private key” data is not 32 bytes, it is 64 bytes.

This is because both wallets misuse the term “private key”. According to Solana’s official documentation, this shall be called a “secret key”.

The secret key is created by combining the public key and private key of the account. The first 32 bytes are the private key, the last 32 bytes are the public key.

There are many terms misused/misunderstood widely in the blockchain space. It is probably best to clarify them before going further.

Even though many people call the Ethereum account address a public key, it is NOT. The public key of an Ethereum account is never revealed explicitly.
Solana’s account address IS its public key in Base58 format.
A 64 bytes “private key” on Solana is actually its “secret key”.
Base58 or Base64 is not an encoding system, they are number systems, just like decimal and hexadecimal.

Generating account address from private key for Ethereum

The public address of Ethereum can be derived in 3 steps.

How an account address is generated from a private key on Ethereum

Step 0: generating a private key on Ethereum

Ethereum private key is a 32 bytes/256 bits data often represented as a 64 hexadecimal character string. Theoretically, any string can be used as a private key. Most wallets and blockchains support generating private keys from seed/mnemonic phrases, which are first defined in BIP-32, BIP-39, and BIP-44.

Step 1. Using ECDSA to generate a public key

Once a private key is obtained, Ethereum uses ECDSA (Elliptic Curve Digital Signature Algorithm) to produce a public key. ECDSA leveraging on Epileptic curve for validation.

From this step, a public key of 128 hexadecimal characters/64 bytes/512 bits is obtained.

Step 2: Hash the public key with Keccak256

Ethereum uses Keccak-256 for hashing. A hashing function basically converts a data input in any size to a fixed size output.

From this step, 32 bytes/256-bit hashed data was produced.

Step 3: Obtain the on-chain address

The last step is to get rid of the first 12 bytes/96 bits from the hashed data. The remaining 40 hexadecimal characters/20 bytes/160 bits of data were used as addresses.

Usually, the address is prefixed with “0x-”.

Generating account address from private key for Solana

How an account address is generated from a private key on Solana

Step 0: Generating a private key on Solana

Same as Ethereum, Solana’s private key is 32 bytes, but it is usually represented as an array of 32 8-bit unsigned integers(Uint8). Solana supports seed/mnemonic phrases too.

Step 1: Hashing the private key with SHA512

Solana’s private key is first hashed with the SHA-512 function, converting the private key into 64 bytes of hashed data.

Step 2: Pruning

From the result, the second half of the hash output is discarded. Only the first 32 bytes is used to generate its public key.

Step 3: Calculating the public key

Solana uses Ed25519 for cryptography. Same as ECDSA, Ed25519 is an Elliptical signature algorithm.

From this step, 32 bytes of data are generated. It is both the public key and the account address. Solana’s account address is usually converted to base58.

Below is a table that summarizes the key differences between Ethereum and Solana cryptography:

	Ethereum	Solana
On-Chain address	Last 20 bytes of the hashed public key Start with 0x 20 bytes	Public key itself 32 bytes
Data format	Hexadecimal	Base-58 or Uint8
Private key	32 bytes random number	32 bytes random number
Wallet import/export	The private key	Solana’s “secret key pair”
Cryptography system	ECDSA	Ed25519
Hashing system	Keccak-256	SHA512
Supports BIP32 and BIP39	Yes	Yes

Cryptography, Ethereum VS Solana

How secure is the system?

As you may know, both Ethereum and Solana are proven to be very secure, but why?

Let us start with a question:

“I have 100 Ethers in my account, and my private key is randomly generated. What is the chance that someone ‘accidentally’ accesses my account by entering the correct private key?”

This is a yellow rectangle. In the middle of this rectangle, there is a black dot.

The yellow area represents all possible combinations of private keys and the black dot is all the addresses that have been claimed on Ethereum.

Hacking Ethereum can be simplified as randomly dropping points onto this rectangle. When you hit the black dot, it means a collision occurs, an account is hacked – not a specific account though, just any random active Ethereum account.

What is the probability of this happening?

What about the same dot, but the yellow rectangle is the size of the whole EARTH?

The actual probability of private key collision on Ethereum is roughly equal to hitting a small black dot on the earth, 3 consecutive times.

Technically it is possible, but extremely unlikely. If a hacker wants to hack into a specific account, with current computation capability, it is going to take more than the age of the universe to do it. So yes blockchain is secured.

But, all of this does NOT hold true if the private key is NOT randomly generated.

So always generate your private key randomly.

Technical terminologies

There are a few important technical terms that came up in this article. It is impossible to explain them all but if you are interested to learn further, here is a high-level explanation of what they are.

BIP-32 and BIP-39

Both of them are related to “seed phrase”, AKA “mnemonic phrase”.

As mentioned previously, randomness is a very important aspect of private key generation. To enforce this, most wallets and blockchain supports using seed phrase to generate a private key.

BIP(Bitcoin improvement proposal)-32 is a proposal submitted in 2013, it is about generating random private keys from a set of Binary data known as “seed“.

BIP-39 is about using a fixed set of words to represent the “seed” data, which is called “seed phrase”. It is mainly for ease of reference and human readability. The list of words can be found here.

One thing to take note of is neither the “seed phrase” nor the data derived from the seed phrase are private keys. In fact, a seed phrase can even generate multiple private keys with a Password-Based Key Derivation Function(PBKDF).

ECDSA and ED25519

Both ED25519 and ECDSA are elliptic curve-based cryptography systems. They are the fundamentals of Ethereum and Solana.

Both ECDSA(Elliptic Curve Digital Signature Algorithm) and EdDSA(Edwards-curve Digital Signature Algorithm ) are variants of DSA(the Digital Signature Algorithm ). Ed25519 is the EdDSA signature scheme using  a special curve named curve 25519.

SHA512 vs Keccak-256

Both SHA and Keccak are hash functions. A hash function basically converts its input data(of any length) to a fix-size output.

There are many variants of hashing algorithms, among them SHA(secure hash algorithm) is the most widely used. One of its important characteristics is it is non-reversible; once data is processed, it is nearly impossible to recover the source data.

Both SHA512 and Keccak-256 belong to the SHA family. Their number represents the length of the output. SHA-512 returns a 512-bit/64 bytes string as result, Keccak-256’s output is 256 bits/32 bytes.