There is always a mention of securing wallets whenever there is a discussion around blockchain applications, and rightly so. Usually, with the mention of wallets, the discussion digresses towards cold and hot wallets.
While cold storage wallets are significantly more secure, they are also more cumbersome to use, especially if used frequently. Hot wallets provide a significantly better user experience and ease of use.
Regardless of whether it is a cold or a hot wallet, storage of the data (private keys) must be made secure.
![]() |
The article explores basics of securing storage (cryptography practices), and borrows learnings from blockchain. It then applies these learnings to the existing practices to attempt future-proofing storage security against technology advancement.
- The marvel of Proof-Of-Work
- The human factor
- Entropy, password and passphrase
- Brute force attacks
- Brute force resilience
- Salting and Stretching
- Building resilience to technology advancement
- Conclusion
The marvel of Proof-Of-Work
Block interval on the Bitcoin network is 10 mins. That means every subsequent block must be mined in 10 mins. It should not be possible for miners to mine faster than that and create coins at a faster rate.
Over time surely hardware and software would become more efficient, so how would Bitcoin cope with this? Would it not be possible to mine a block in less than 10 mins? The Bitcoin protocol is designed such that improvements in hardware and software would not be able to decrease the time needed to mine a block. This is achieved by increasing the difficulty to mine a block. As mining systems get faster, it gets harder to mine a block. Thus the protocol is resilient to improvements in technology (both hardware as well as software).
Just like the network protocol of Bitcoin it may be possible to make it difficult to “hack” wallets, even if hardware / software technology advances. The wallets must catch-up with technology improvements and increase the difficulty to access securely stored data.
A few key concepts must be understood before delving deeper into the topic.
The human factor
Private keys used for signing transactions on a blockchain are typically stored together using a wallet. The keys are most likely stored on the device used for signing the transactions (disk or SSD or USB drive or phone storage). The stored data (private keys) must be encrypted, if not, any malware can steal it.
A key is needed to encrypt the data and this key cannot be stored on the same device. Otherwise it is as good as locking the door and keeping the key beside it.
The key usually gets generated from a password or passphrase. Hence, ultimately the security of such systems depends upon humans.
Unfortunately, harder the password / passphrase, poorer the overall user experience. The user has to remember such difficult passwords / passphrase, and just in case, record it somewhere else like a piece of paper! If the wallet has something very valuable, then users need to store such papers in a safe or risk losing the secret and the coins forever.
Making systems secure and user friendly manifest as conflicting needs.
Cracking password is getting easier with simple brute force and evolving hardware and software capabilities. Thus it is very important to choose right passwords / passphrase. Humans are not good at that either. To address this, passphrase is generated by computers. This is described later in the article.
Entropy, password and passphrase
In cryptography the term entropy is used often. It is very important to understand this concept, as the security of a system directly depends upon this. The measure of randomness is called entropy. The more the randomness in password, the higher will be the password’s entropy. Higher the entropy harder it is to crack the password.
Understanding what is entropy is much easier with hypothetical systems. Let us consider a system, in which the user’s first name is the username and the password is one of the following:
- birthplace or
- father’s name or
- mother’s name or
- last name
(i.e. only 4 possible values for the password). Note that this is just a hypothetical system. In this case, the probability of an attacker’s guess being right is 25%. The attacker can get these names from spying on user’s letters or looking up some public records etc. Now with only 4 guess, the attacker can get through. As 2 bits can represent 4 possibilities (00, 01, 10, 11) therefore the entropy of the system is 2 bits.
As claimed in this book (regarded as one of the best books on the subject), typical passwords introduce an entropy of 2 bits per character. This means, if someone uses 8 character passwords, we expect an entropy of 16 bits. For secure systems we would need at least 128 bit security. This means we need people to have 64 character passwords. That is impractical.
To overcome the problem of low entropy, secure wallets ask users to have a series of words (12 or 24) or a passphrase. Whether these are generated randomly, or users are asked to create their own passphrase depends upon the wallet. This is done to increase the entropy.
BIP-39 is used by many wallets including metamask, trezzor, ledger etc. The English-language wordlist for the BIP39 standard has 2048 words, so if the phrase contained only 12 random words, the number of possible combinations would be 2048^12 = 2^132 and the phrase would have 132 bits of security. However, some of the data in a BIP39 phrase is not random,[2] so the actual security of a 12-word BIP39 seed phrase is only 128 bits. Wallets can generate a key from this passphrase which is used to encrypt the data stored in the wallet.
How much entropy is good enough depends upon how much technology has evolved!
![]() An interesting talk was presented at DEFCON 23 on wallet security. Here’s the deck for the talk. |
Brute force attacks
If a hacker got hold of an encrypted file, and does not have the key to decrypt it, there are two approaches the hacker could take:
- Get the key by stealing or look for clues elsewhere.
- Guess the key, try it out, if not successful make another guess.
The second approach is called brute force. With modern encryption systems, the number of guesses the hacker has to make is extremely large (2^256 for a 512 bit key). Of course humans are not guessing, computers do the guess work (rather simply try the next key from a set).
![]() |
Modern GPU rigs can be created by engineers to crack passwords by brute force (how to article). To aid this, software is available freely.
Brute force resilience
Even if a user had a decent entropy for the passphrase, a cracker can deploy a number of computers to use brute force and leak the secrets out or in future simply use more powerful hardware. So it is important to make it more and more difficult to reveal secrets from a wallet.
Bitcoin relied upon time needed to “compute” a block as a way measuring how easy or difficult it is. For this it looks at a moving average of 2016 blocks. If the moving average falls below the intended 10 mins, the network decides to increase the difficulty. As hardware improvements are made, or distributed mining farms are created (software improvements), the moving average tends to fall below the 10 min mark. The network then decides to increase the difficulty. This link shows average block time for Bitcoin, from 2010 until now.
![]() |
By increasing the difficulty, the miners need to try out many more “nonce” values to arrive at a valid hash. What is nonce is explained in the article in the note above. The miner needs to run many iterations of hash generation. This in a way is the penalty for increasing the Bitcoin network hash-rate. At the time of writing this article, the bitcoin network is operating roughly around 84 million-trillion hashes per second.
Lesson: To increase the difficulty of cracking passwords, get the computer to perform many more hash computations!
Salting and Stretching
In the current scenario, no password or passphrase is strong enough.
In order to make the wallet secure, wallets must not rely on passwords or passphrases alone. To increase the entropy of the system, the password / passphrase is hashed along with an extremely large random integer (512 bit integer preferably). This large cryptographically secure pseudo random number is called salt.
![]() |
The password concatenated with salt is hashed multiple times to generate a key (see the algorithm below). This key is then used for encrypting the “private keys store” (data stored in the wallet). The private keys for the addresses on the blockchain are now assumed to be secure. This technique is used in cryptography for storing and securing secrets. It relies on the fact that Cryptographic Hashes have the following properties:
- It is impossible to guess the generated hash value for a stream of bytes. To get the hash value, one has to run the algorithm, there is no shortcut.
- For a given input it always generates the same hash value.
- It is infeasible to deduce the input based on the hash value. That means it is an irreversible mathematical function.
![]() |
Key derivation from password / passphrase
K => Generated Key h => Cryptographic hash function r => Stretch factor (number of iterations to generate the key) p => passphrase s => salt (a very large pseudo random number) x0 := 0 xi := h(xi-1 || p || s) for i=1..r K := xr *credit
As the number of iterations increase, more computation is needed by the attacker who is using brute force. By increasing the computation required for each “guess” by a factor of “r”, wallets make it very difficult to run brute force where “r” is reasonably large. However, the user suffers a slightly longer response time each time the user wants to use the wallet. As long as it is only a couple of seconds, it must be acceptable to the user I “guess”.
Lesson: As hardware, software capabilities increase, increasing hashing power needed to generate key can be a deterrent for brute force attacks.
![]() The algorithm described above is only the gist of PBKDF. In industrial strength implementations, expected keyLength etc are taken into account. |
A large number of wallets opt for only double hashes as a way to improve user experience. Double hash is practically computed without any delay for the user. This makes it very tempting for the user to pick up such a wallet. Nobody likes slow wallets after all. Few posts on quora, and reddit claim that: “using such double hash wallets is no big issue, because they are reasonably secure.” This is misconceived. In no time technology will evolve to break such wallets even by brute force techniques or should we say technology has already evolved. See this how to article.
Do not use fast wallets which use double hashing as a way to generate key to secure your crypto-assets, your hard earned money!
It is recommended that an iteration count (“r”) of at least 1000 must be used! This makes trying each guess a 1000 times slower. A big deterrent against brute force.
Building resilience to technology advancement
There is a possibility of future-proofing the salting and stretching. A reasonable value for number of iterations is based on how long it takes the current hardware to compute the hashes. To future proof this, the number of iterations must increase, as the wallet detects bigger hash rates.
One of the possibilities is to store the number of iterations as an integer along with the salt. Whenever the wallet detects that it is increasingly becoming faster to generate the key, the wallet must increase this value and re-write the encrypted data. The network’s hash rate could be one of the indicators. As the hash rate increases by a certain magnitude, the wallet must decide to up the difficulty.
The flip side of this approach is that the user could experience a slower response time. However, it is in user’s benefit to accept the slower response time, or upgrade the hardware.
Remember the generated key is only encrypting the data stored on the storage. The private keys for addresses of bitcoins / ether will not be altered. In time, this data must be re-encrypted with a newer more resilient key.
Data written on disks is stored in blocks. This is not the same as the blocks in blockchain, it happens to be that disks are segregated in sectors and blocks.
While the newly encrypted data is being rewritten, care must be taken to overwrite the same blocks on the storage or at least destroy the old blocks by overwriting garbage on it.
![]() This leaves the space on the storage available for the OS to write a new file. However, if the space is not consumed, your secrets are still there for hackers to read! |
Conclusion
Beware of using wallets without understanding how the wallets are securing secrets. If you have a good understanding of how secrets can be stored securely, then you have a better chance of choosing the right wallets. Finally, as they say in Cryptography, do not trust anybody especially yourself (more so, if you are an application developer) on designing secure systems, hence, do not design your own wallet!
4 Comments