How do Ethereum and Solana generate public and private keys?
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
The public key, and private key, what are they?
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 was 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 is equivalent to 1 byte of data; therefore, the private key entered is a 64-character string.
MetaMask will import the following account.
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
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.
Cryptography for Ethereum
The public address of Ethereum can be derived in 3 steps.
Step 0: generating a private key
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.
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-”.
Cryptography for Solana
Step 0: Generating a private key
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
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:
|On-Chain address||Last 20 bytes of the hashed public key|
Start with 0x
|Public key itself|
|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”|
|Supports BIP32 and BIP39||Yes||Yes|
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.
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.
That is the end of this article. I hope you find it useful.
If you have any questions to clarify, or would like to suggest a blog post that you want to see, feel free to ping me on Twitter/Telegram/Discord.
Thanks for reading.
Happy coding. Cheers.
- Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform.
- Input your workload and see how affordable Chainstack is compared to other RPC providers.
- Connect to the Ethereum, Polygon, BNB Smart Chain, Avalanche, Arbitrum, Optimism, Oasis Sapphire, NEAR, Aurora, Solana, Polygon zkEVM, Aptos, Gnosis Chain, Cronos, Filecoin, Fantom, StarkNet, Harmony, Tezos and Fuse mainnet or testnets through the interface designed to help you get the job done.
- To learn more about Chainstack, visit our Developer Portal or join our Discord server and Telegram group.
Have you already explored what you can achieve with Chainstack? Get started for free today.