Ethereum Paper Wallets Explained: A Step-by-Step Guide and Calculator

To embark on our journey, we must convert our selected passphrase, for example, YetAnotherDeFi, into the language of computers: binary.

Fundamentally, computers comprehend only two states (0 and 1), which represent different binary conditions: on/off, +/-, yes/no, true/false. To communicate effectively with our computer, we must convert our text into this binary language. Let’s delve into this conversion process.

We begin by translating our seed text into binary, a numbering system that utilizes only 0 and 1, also known as bits. The binary system (which can also be thought of as the base-2 numbering system) is the fundamental language of computers. For instance, counting decimals in binary starts at 0 (to represent '0'), then 1 (for '1'), followed by 10 ('2'), 11 ('3'), 100 ('4'), 101 ('5'), 110 ('6'), and so forth.

To convert our text into binary, we first translate each character into its corresponding decimal based on the ASCII code. ASCII, short for American Standard Code for Information Interchange, started as a 7-bit coding standard that assigns unique numeric values to each character. However, as the need for a greater range of characters became apparent, ASCII was extended to use 8 bits, thereby increasing the number of possible characters from 128 to 256.

In 8-bit ASCII, each character can be represented by a unique 8-bit binary number. For instance, "Y" is 59, or 01011001; “A” is 41, or 01000001; and “D” is 44, or 01000100.

In binary, you receive the following array: 01011001 01000001 01000100. This binary array is how computers interpret the text "YAD".

Keccak-256 is a cryptographic hash function that generates a 256-bit (32-byte) hash value. Don't worry if some of these terms seem confusing at first; we're going to break them down.

A hash function is a part of the overall process known as hashing. This process transforms input data (like text or a file) into a fixed-size output, known as a hash. You can think of a hash output as a unique fingerprint of the input data; even a tiny change in the input data will create a significantly different hash.

Hashing is a vital component of Bitcoin, where it's used in several ways, such as creating new blocks. In the search for a new block in the blockchain, miners repeatedly alter the nonce value of the candidate block's headers. They take a few transactions from the transaction pool and the potential block's data, transform it all into a block header's hash, and rehash the result until they find a hash that meets the network's difficulty target. Once this is achieved, a new block is unveiled.

Another use case for a hashing algorithm in cryptography is Ethereum’s Merkle Trees. The Merkle Tree is a data structure within each block on Ethereum used to store and organize the transactions included in that block. Transactions are grouped together in pairs and each pair is hashed together to create a new hash value. This process is repeated until there's only one hash value left in the block, known as the "root hash". This root hash is critical because each block on Ethereum is connected to the previous block through its root hash.

There are many more uses for hashing in cryptography, but for now, knowing that the Keccak-256 hash function is used to generate a private key is enough.

------

Now that you understand Keccak-256 as a cryptographic hash function, you might wonder about the part of the definition stating that Keccak-256 produces a 256-bit (32-byte) hash value. What exactly does this mean? What's the difference between bits and bytes? Let's delve into this.

The term Keccak-256 refers to the length of the output of the hash function. Regardless of the input message size, this function produces a fixed-length output of 256 bits, which equals 32 bytes, as there are 8 bits in each byte. Therefore, the generated hash value can be represented as either a 32-byte string or a 256-bit string.

Professionals like computer hardware engineers, software developers, and system administrators often use bytes as a measure for representing larger amounts of data. When we refer to a 256-bit output, we don't mean a string that is literally 256 characters long. The actual string is 64 (hexadecimal) characters long, a shorter version of a 256-bit binary equivalent. Each symbol in the 64-character string represents a group of 4 bits. Here's an example:

f0ca423e9d024b7f69dcdc98a7b6fbf1d5cf968f08c27ebc06a6a98e4bbdf4e4

In this hexadecimal string, "f" equals 1111 (4 bits), "0" equals 0000 (4 bits), and "c" equals 1100 (4 bits).

Each number or letter in this 64-hex string represents a 4-bit group because it's a base-16 string. In case you missed it, hexadecimal is a numbering system that uses 16 distinct symbols (0-9 and A-F) to represent numbers. For example, "a" represents the number 10, "b" represents 11, and so forth, up to "f" which represents 15. Hexadecimal is often used to abbreviate binary numbers. If we represented the above 64-character string in binary, it would be incredibly lengthy. To simplify:

1 hexadecimal = 4 bits = 0.5 bytes.

Wow, this is starting to sound quite technical, isn't it? No worries, though; we've got your back. You'll understand this in no time.

Firstly, welcome to the world of asymmetric cryptography. From here on out, we'll need two distinct keys — a private one and a public one — to encrypt and decrypt data, or in other words, send and receive transactions. This approach contrasts with symmetric cryptography, where the same key is used for both tasks. But that's less secure. But why do we need to encrypt and decrypt information when transacting in crypto? Why, specifically, do we need Elliptic Curve Cryptography (ECC) today?

Let's break down the term "cryptocurrencies". They're named that way because they rely on public-key cryptography to secure transactions and ensure the authenticity of the participants involved. Here's an analogy: How did monks from a secretive medieval monastic order exchange information? They needed trustworthy couriers. Similarly, the two keys in cryptography are like two experienced couriers ensuring that your crypto funds (analogous to valuable ancient manuscripts) are safely transacted.

Consider this example: When you want to send ETH to another user, the wallet software creates a unique transaction message. This message includes the recipient's public address, the amount of ETH to be sent, and other transaction details. The transaction message is then hashed and signed using the ECDSA algorithm, which is based on ECC and involves some math operations on the sender's private key and the hash of the message.

On the recipient's side, they perform a series of operations, including hashing the message (similarly to the sender) and using their public key to verify the signature. If, after a series of mathematical operations, the result matches a certain condition, the signature is considered valid.

This may be a lot to take in if you're new to cryptography. However, you don't need to unravel all the mathematical intricacies to understand that the private and public keys need to correspond with each other in order to send and receive crypto transactions. That's where public-key cryptography algorithms, such as ECC, come into play.

While there are other cryptography algorithms like RSA (i.e., Rivest-Shamir-Adleman), blockchains such as Bitcoin and Ethereum use ECC (specifically the secp256k1 curve) to calculate public key coordinates because it's generally more efficient and secure. It has smaller key sizes, faster performance, and is resistant to quantum computing.

Why calculate public key coordinates, you may ask? This is necessary to find the corresponding keys, and an elliptic curve serves this purpose excellently.

So, how do we determine the public and private keys in ECC?

For encryption or digital signatures using ECC, two parties must agree on an elliptic curve and a base point of that curve — Bitcoin and Ethereum use secp256k1. This base point is a fixed point that generates a cyclic subgroup of the elliptic curve's points. Each party chooses a private key — which ought to be a random seed number, though in this guide we are creating nonrandom (i.e., not secure) seed — and calculates their public key by multiplying the base point by their private key. This is exactly what you've done at this stage... minus the randomness part.

The result of multiplying the private key by the predetermined generation point is a location on the elliptic curve comprising two coordinates (x,y) that can be used to generate a public key... which is what we are going to do next!

In the world of blockchain and cryptocurrencies, public keys play a crucial role in ensuring the security and authenticity of transactions. Public keys, as part of the public-key cryptography system, are derived from private keys and are used to verify digital signatures, providing a level of trust and validation for transactions occurring on the blockchain. When it comes to public keys, there are two formats that can be used: uncompressed and compressed. Understanding the differences between these formats is essential for grasping how blockchain networks handle transactions and maintain security.

Uncompressed public keys are the original format used in many cryptographic applications. In this format, the public key is represented as a pair of coordinates (X, Y) on an elliptic curve, resulting in a larger data size. While the uncompressed format offers compatibility with a wide range of systems, its larger size can lead to increased transaction fees, slower transaction processing times, and higher storage requirements. These factors may not be ideal for resource-constrained devices or environments where efficiency is critical.

Compressed public keys, on the other hand, offer a more compact representation by only including the X-coordinate and a single bit indicating the Y-coordinate's parity (whether it is odd or even). This significantly reduces the size of the public key without compromising its functionality. The primary advantage of using compressed public keys in blockchain applications is the reduced data size, which translates to lower transaction fees, faster processing times, and more efficient use of storage resources.

Many modern blockchain platforms, including Bitcoin and Ethereum, support both uncompressed and compressed public key formats. Users can choose the format that best suits their needs, considering factors such as compatibility, efficiency, and resource usage. As blockchain technology continues to evolve, it is essential to strike a balance between maintaining robust security and optimizing performance.

In conclusion, public keys in blockchain networks can be represented in both uncompressed and compressed formats, with each offering distinct advantages and disadvantages. Uncompressed public keys provide wider compatibility, while compressed public keys offer a more compact and efficient representation. Choosing the appropriate public key format depends on individual use cases and priorities, such as transaction speed, storage, and compatibility with existing systems. Ultimately, understanding the differences between these formats helps users make informed decisions about how best to secure their digital assets and interact with blockchain networks.

Input the X and Y coordinates from Step 4. Click "Concatenate" to combine them and generate your uncompressed public key. By the way, "concatenate" is just a fancy word for sticking things together end-to-end — kind of like a digital high-five!

Keccak-256 is a widely-recognized cryptographic hash function that plays a crucial role in securing the Ethereum blockchain. As part of the SHA-3 family, Keccak-256 is based on a sponge construction that provides strong security and excellent performance. It replaced the older SHA-1 and SHA-2 families due to their perceived vulnerabilities and susceptibility to attacks.

Ethereum employs Keccak-256 in its Ethereum Virtual Machine (EVM) cryptography to ensure the security and integrity of its transactions and smart contracts. Keccak-256 produces a fixed-length (256-bit) output regardless of the input size, making it an ideal candidate for creating unique hashes of data on the blockchain. This fixed-length output is essential to prevent potential attackers from deriving the original data or finding a different input that generates the same hash, which would be known as a hash collision.

The Keccak-256 algorithm is also used in generating Ethereum addresses. The process involves hashing the public key of a user to produce a 256-bit hash, which is then truncated to the last 160 bits to create a unique Ethereum address. The resulting address provides a level of abstraction between a user's public key and their on-chain identity, ensuring security and privacy in the Ethereum ecosystem.

Understanding the base number systems used in Keccak helps illustrate its robustness as a cryptographic hash function. Keccak-256, in particular, offers high levels of security and ensures the overall integrity and security of the Ethereum network. Its role in Ethereum's cryptography includes generating unique hashes for transactions and creating Ethereum addresses, further enhancing the privacy and safety of users within the ecosystem.

In considering the likelihood of collisions, it's essential to acknowledge that the data moves through base 25, base 50, and up to 1600 before reversing the process. This complex progression contributes to Keccak's impressive resistance to collisions, likely a significant design goal of the algorithm.

EIP-55, or Ethereum Improvement Proposal 55, introduced a mechanism that enhances Ethereum address verification by adding a checksum encoding to the standard hexadecimal address representation. This improvement makes it significantly more difficult to accidentally send ETH or tokens to an incorrect address due to a mistyped or mistaken input. EIP-55 is widely used across Ethereum-based services and applications, such as wallets and decentralized platforms.

The EIP-55 address encoding process involves two primary steps. First, a Keccak-256 hash of the lowercase hexadecimal address (without the preceding 0x) is calculated. This hash is then used as a checksum. Next, each alphabet character in the original address is capitalized if its corresponding hexadecimal digit in the hash is greater than or equal to 0x8. The final encoded address consists of a mix of uppercase and lowercase letters, making it easier to verify and reducing the risk of errors.

EIP-55 provides an additional layer of safety in the Ethereum ecosystem. While the checksum encoding does not guarantee total protection against human errors, it does offer a significant improvement over the simple, non-checksummed addresses that were used prior to its implementation. Most Ethereum wallets and tools now support EIP-55 encoded addresses, checking and validating them before initiating transactions.

Overall, EIP-55 has improved the user experience within the Ethereum network, helping to minimize the risk of lost funds due to human error. By incorporating EIP-55 encoding into wallets and services, developers can better ensure the secure transfer of assets within the Ethereum ecosystem, thus strengthening trust and confidence in the platform.