USB UUID as an alternative seed methodology for private key generation

11 min readFeb 8, 2018

DISCLOSURE: This paper greatly relies on the ideas of other members of the ethereum community (specifically the shared knowledge and explanations provided by Taylor Monohan, founder of MyEtherWallet) and seeks only to postulate an alternative, perhaps more relatable, method for newbie ethereum users to deterministically generate their own private key.

Background:

For most people, crypto currency remains little understood and therefore, the security standards and best practices for how to securely store crypto assets are concurrently misunderstood. 2017 saw an enormous amount increased attention and investment in the crypto currency space — most people continuing to hold their investments in online exchanges. While this model in coincident with traditional thought processes for investments, which rely on the exchanges to secure and back their investments, most crypto exchanges remain without FDIC insurance standards or ability to recoup stolen funds. Because an exchange typically holds all the users private keys, if the security or accessibility of that exchange is compromised for any reason, the user may loose their assets without any means of recourse.

Ethereum is based on public key cryptography, more specifically, elliptic curve cryptography— which is very widely used in the world even outside ethereum. The ethereum blockchain relies on private/public 256 bit key pairs expressed as 64 digit strings. Unlike the more commonly used methodology of most applications which rely on username/password pairings, as a decentralized application ethereum relies on deterministic mathmatical proofing to relate unique private keys to public account adresses. Unlike using a typical bank account which uses a centralized database to store user’s passwords (or hashes of users passwords) to validate identity, users of ethereum need only provide one private key address. This negates the need for any centralized key:value store.

So does this mean that anyone can randomly type in 64 digit strings and gain access to someone else’s account? Well, yes and no. In theory you could just randomly type in a string of 64 hexadecimal characters until you get one that matched but it is highly unlikely to do so.

To quote from MyEtherWallet’s FAQ page, “in theory you could just type in a string of 64 hexadecimal characters until you got one that matched. In fact, smart people could write a program to very quickly check random private keys. This is known as “brute-forcing” or “mining” private keys. People have thought about this long and hard, especially when Bitcoin exploded. With a few very high end servers, they may be able to check 1M+ keys / second. However, even checking that many per second would not yield access to make the cost of running those servers even close to worth while — it is more likely you, and your great-grandchildren, will die before getting a match”

Taylor Monahan, founder of MyEtherWaller, does a good job of putting this into perspective:

“You know if you want a list of ANY combination 4 numbers, you have to do 10x10x10x10? Because there are 10 choices for each number? So that’s 10,000?

Well for private keys, each character can be 0–9 or a-f. So that is 16 possibilities, not 10. And there are 64 characters, not 4. So it would be: 16x16x16x16x16……….. or 16⁶⁴ (2²⁵⁶ if you want to talk in bytes instead of characters like fancy math people). This comes out to 1.15792089e77 or

115,792,089,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000

It’s just…too big to handle. Too big for computers to handle, as well. You would just be sitting there running a room full of servers for years and years and years and years and they wouldn’t ever come up with anything, but you would be spending all this money running them.”

So then, the question remains, how should I securely store my private key?

While the cold wallet market leaders such as Trezor or Ledger nano provide excellent solutions for cold wallet storage, many people who may only have small amounts invested and choose not to spend the extra $70-$100 remain unprotected. Therefore, I am proposing an cost efficient alternative to purchasing a specialized cold wallet by utilizing a USB drives unique UUID along with cryptographic proofing. By providing an everyday, easily understandable open source alternative to offline wallet storage, I hope to provide the ability for newcomers and microinvestors a low cost, relatively secure solution to storing their crypto assets.

Overview of Cold vs Hot Wallets:

Typically, your ethereum wallets can be stored using a variety of methods (please see link below to myEtherWallet’s FAQ for more detailed information). Ultimately though, your always signing with your private key. The differences therefore represent various methodologies how this private key is encrypted, stored, and generated. One primary difference between these methodologies is hot vs cold; in other words, are you connected to the internet or not when accessing your private key?

The current most popular ‘hot’ wallet solution used to access Dapps on ethereum is Metamask. Metamask offers a very user friendly hot wallet that is also relatively secure since it is tied to your browser. Here’s a quote from a metamask develop posted of the r/metamask reddit channel:

“Today, MetaMask is indeed a “hot” wallet, in that you use it on a computer connected to the internet. This is usually considered less secure, because if a machine is on the internet, it could be accessed remotely, and keys could be stolen.

Unlike Jaxx, MetaMask always stores your seed phrase encrypted with your password, so we have a slight advantage in that an attacker with full access to your computer would also need you to have MetaMask unlocked to have a chance of using your accounts. This could also be done by recording your MetaMask password and having total control of your computer.

I absolutely recommend storing value off-line as much as possible. When I use MetaMask to exchange some value, I try to transfer that value back to a “colder” wallet soon. If I don’t, I accept that there’s a risk involved.”

So, what then are the most common ‘cold’ wallet solutions today?

For starters, you have a ‘paper wallet’. This means literally just writing your private key down on a piece of paper. Pretty simple… just don’t loose that piece of paper.

Step up a notch and you have some other fairly basic strategies using USB drives, preferably encrypted. With an encrypted USB, you can save a JSON keystore file which is generated by wallet provider and used as a seed, along with a password, to deterministically generate your private key. You can also just save a plain text version of your private key on the USB and use that (not recommended). The idea of a USB keystore has been further perfected by companies such as Ledger or Trezor; uses a mnemonic seed (24 word seed) to generate private key further protected by user password which is only accessible while this external device is plugged in to your local machine. (I use a Ledger nano and would definitely recommend it — the added features and extra security are definitely worth the $70 you’ll spend, not to mention, it looks cool)

Therefore, for the people who may not yet be interested in investing in a more specialized hardware wallet, I am simply proposing an alternative low cost methodology for offline wallet storage to holding a keystore or private key string by leveraging the unique UUID already inherent to all ordinary USB drives.

Deterministically Generate Unique Private Key using USB’s UUID:

Most USB drives are produced with a unique UUID tag. UUID stands for universally unique identifier — a 128 bit number used to identify information in computer systems. According to the wikipedia UUID page:

“When generated according to the standard methods, UUIDs are for practical purposes unique, without depending for their uniqueness on a central registration authority or coordination between the parties generating them, unlike most other numbering schemes. While the probability that a UUID will be duplicated is not zero, it is close enough to zero to be negligible.

Thus, anyone can create a UUID and use it to identify something with near certainty that the identifier does not duplicate one that has already been, or will be, created to identify something else. Information labeled with UUIDs by independent parties can therefore be later combined into a single database, or transmitted on the same channel, without needing to resolve conflicts between identifiers.”

The general idea is that these UUIDs can only be called by a local machine, so we can use them as an additional security protocol for private key generation. By using a local command line tool to call this UUID and hashing it together with a unique passphrase using a SHA-256 to generate a private key, we can create a highly simplistic yet secure methodology for accessing an online wallet. This is because, rather than needing to write down our public key, or storing in browser, we can divide the security risk into two factors 1) an offline 128 bit key tagged to our USB drive and 2) an user generated password, which are never stored online.

Lets compare this to a very similar solution of holding a keystore file on an encrypted flashdrive:

With a keystore file on an encrypted flash, you have 2 levels of security if someone was to steal this flashdrive. First, they would actaully need to decrypt the flashdrive to access keystore file. Since this keystore file is basically an excrypted version of your private key, the hacker would also need to then brute force this password. (tip: dont use the same password to encrypt your flashdrive as you do to access your keystore file!)

Using the USB’s UUID is not much different than using a keystore file. There are still two levels of security. The difference lies at the second level. If a hacker was to snatch up your USB drive and decrypt it, once they found a keystore file, it would be like finding a locked safe— they would know that what they have probably contains value and will do their best to break in. On the other hand, by leveraging a USB’s inherent UUID as a sudo for keystore, that “locked safe” would be hiding in plain sight. The hacker may open the USB drive and get past first level encryption but see nothing to suggest that it contains valuable information. Even if they were to figure it out, they would still need the user generated password (or hash of) to append to UUID in order to crack your private key.

A Closer Look at Security:

Lets talk about entropy using brainwallet as a case study. Reading from bitcoin wiki,

“A brainwallet refers to the concept of storing Bitcoins in one’s own mind by memorizing a mnemonic recovery phrase. If the mnemonic is not recorded anywhere, the Bitcoins can be thought of as being held only in the mind of the owner”

So, early on, brain wallets allowed users to generate their own mnemonic seed. Sounds secure right? Not so much. Turns out humans are not so good at generating random keys.

Lets refer again to Taylor Monohan to explain how this process worked:

“… In Bitcoin land, brain wallets are/were much more popular. Most of the most popular Ethereum Wallets work like this:

Computer generate truly super ultra random seed.
Use this as seed for private key

Even Jaxx does this: the mnemonic that you save is a super ultra randomly generated seed which you then use to access your account. On the backend, they are going seed -> private key rather than just private key.

Brain Wallets allow you to generate a seed. You could use the seed “asdfasdf” or “Say hello to my little gun” or “I love you” or whatever you wanted. live.ether.camp has a brain wallet feature on their site (press “Get Address”)

If you create new wallet with seed 123456789. You will get an address 62f689837da39b1b50ad39d79e924989e340e0bb. Surprise! This address DOES have a balance (albeit very small). And that is how you get access to people’s wallets without having to guess thru 2^256 private keys. You narrow the possible scope so that the master list is far, far less than 2^256. Because humans are humans. This is known as “entropy.” True random number generators have “sufficient entropy”. Your brain does not have sufficient entropy.

So, back to Bitcoin-land. Brain wallets were very popular and so hackers did indeed crack human readable passwords. These included computing thru the top password lists. Computing through top movie quotes, song titles, band names. Computing through popular historical (or not that historical) figure’s names.

When the main lists had been checked, they started doing exactly what you said: they had a list of brainwallet seed phrases and would watch them. This resulted in users depositing 1BTC into a brand new account, only to watch it stolen <1 minute later by this program. The list of phrases that crackers have cracked is one of the most interesting studies in ‘humans trying to create strong passwords’ ever…

The other way to get private keys without trying all the private keys is to find other ways that a key may have been generated with weak entropy. We’ve covered that humans are terrible at entropy. But, humans can also write programs with weak entropy. In the case of brainwallet.org they doubled up on the shitstorm of weak entropy. Not only did they let users generate entropy, but they then gave more risk-adversed users an option to “generate a random seed” button. Problem? They were using Math.random() which is not a sufficient source of entropy and therefore white-hat and black-hats bruteforced many “randomly” generated keys created and took the BTC. Some were returned, many were not”

Alright, if your still reading here, congratulations and thank you. Now how does this all fit back into my suggested alternative to storing private keys via USB. It does, unfortunately, create a small problem of reducing entropy.

As discussed earlier, instead of a potential hacker needing to brute force through the roughly ~115,792,089,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 possible private keys to find one with a balance, they could instead, cleverly, mimic how that private key might be getting generated.

Since in our case, we will be taking 1) the SHA-256 hash of a USB’s 128-bit integer Unique Universal ID (represented by 32 hexadecimal (base-16) digit string, separated by hyphens; a total of 36 characters) along with 2) a user generated password— this task would be very very difficult.

Here’s why:

Most likely, we’ll be using specifically a ‘version 4 variant 1 UUID’, the version most commonly used today. This specific UUID has a total of 122 bits of entropy; of the 64 character (128 bit) number, they will have 6 predetermined variant and version bits, leaving 122 bits for the randomly-generated part, for a total of 2^122, or 5.3 undecillion (did you know that was a number?) possible different variants. The important part, and highest security flaw here, is the use of pseudo number generators, which are shown to produce UUID’s which follow predictable pattern. If you want to dig more into the challenge of generating “truly random” numbers, please see link for an interesting mathematics discussion on stack exchange in references below.

Getting back to the point, the smallest number of version 4 UUIDs which must be generated for the probability of finding a collision to be p is approximated by the formula:

Therefore, in a nutshell, to have just one in a billion chance of duplication, 103 trillion version 4 UUIDs must be generated. So then, even with less than optimal entropy, this still poses an enormous challenge for any potential hacker to brute force and, still further, a completely negligible chance for collision.

Furthermore, even if someone gets control of your USB, they still don’t necessarily even know they have access to your seed or have the additional passphrase needed to generate the true seed for deterministically generating your wallet private key. More importantly, you can do all on your local machine, not connected to the internet and not relying on a wallet provider to decrypt a UTC JSON keystore file!

If you’ve made it this far, thanks for reading! Would love to hear your thoughts on this or other alternative cold wallet storage strategies in the comments below. For the more technical, please see link to my original whitepaper on github below — any guidance/comments/contributions would be much appreciated!

Finally, if you’d like to experiment from a would-be hacker’s perspective, I’ve also attached a link to ‘pyethrecover’. This program is meant for helping people recover lost passwords in combination with JSON keystore file but acts in much the same way a hacker might try to brute force entry using hints.

Cheers!