# Approximately how much entropy/security is lost by typing passphrase words using a number pad?

For context, the coldcard hardware wallet has a number pad as input. In order to maintain my sanity, I'd like to input an alphanumeric passphrase using a single keypress for each letter or number.

So for example, the password "boyhowdy123" would be typed "26946939123".

I know that doing this loses some security (becomes easier to brute force crack) based on the number of words (or word sequences) that have the same numeric representation using this method as other words (or sequences).

My question is: approximately how much security is lost here? Am I missing anything that also affects the security of doing this? Is there anything published that analyses this kind of thing?

• Aren't you essentially asking how much combinations one has with letters+digits (62^N) vs only with digits (10^N) and then divide these numbers? It does not matter for the calculation that you "mean" to type a letter - you still enter only digits. Or do you mean that your passphrase consists of real words and is not just an arbitrary alphanumeric string. – Steffen Ullrich Jan 11 '20 at 22:23
• I'm not asking about the simple combinations. I'm asking for a somewhat more nuanced analysis that understands how humans choose passwords they can remember. Its not simply about the combinations of alphanumeric characters, its about combinations of words. Similar to analysis don here: coldbit.com/can-bip-39-passphrase-be-cracked . I do mean that the passphrase consists of real words, but are expressed using numbers as described above. – B T Jan 11 '20 at 22:28

tl/dr: This method hurts your password strength quite a lot due to the loss of characters (mainly since 0 and 1 are often left out when entering letters through a numeric pinpad). However, trying to brute force a password here is slow, so with a long enough password you'll be fine anyway.

## Analysis

You already seem to know the answer, but I'll spell it out with a bit more detail in hopes that this is helpful.

Unfortunately, your selected method of password generation will, quite possibly, generate the lowest possible amount of entropy. Obviously you would get less entropy by picking a clearly bad password, but this method still gives pretty poor results.

The best way to see this is by comparing against it's entropy ceiling - a pure digit password. That's a simple one. If all you have is numbers then you have `10^n` possibile passwords, where `n` is the number of digits in your password. A 4 digit password has 10,000 possible combinations, etc...

In your case though your numbers are determined by conversion from letters. As you know, the English language doesn't use letters evenly, resulting in a loss of entropy. It would be difficult to determine exactly how much entropy is lost, so a good paper would be required. I don't have one of those though, but I can still guestimate!

1. You lose at least 1 number because in most letter mapping systems the 0 is unused
2. Many telephone keypads leave the 1 unused as well
3. And of course the variation in frequency hurts. Harder to estimate so I'll just knock off another digit and call it a day

You'll effectively lose 2-3 possible characters out of the 10 you have. This actually takes a big hit out of your entropy, because the number of possible passwords is determined by `[Number of characters]^[Password Length]`. The presence of that exponent makes this very non-linear, as we'll see below.

## Brute-forcing

Is this a deal breaker though? That depends!

Deciding how difficult a password is to crack depends on two things: the number of possible passwords, and the rate at which an attacker can guess passwords. Both can be determined accurately enough in this case. First, how many possible passwords are there? Let's assume you end up with a 12 character password, and let's compare against three passwords: randomly chosen numbers and characters, randomly chosen numbers, and random numbers without 0 and 1.

We also need to know how fast an attacker can run through passwords. Just for kicks, I'm going to compare two speeds: the rate at which a high-end GPU hashing rig can crack MD5 hashes (200GH/s), and the rate at which a very experienced person can enter numbers into a pinpad. Obviously the former (the MD5 hashing rig) is not in the least bit applicable here, but I want to include it because I think it will give a helpful reference. For pinpad entry, it's hard to guess exactly how fast an attacker can enter passwords, but we'll be generous and give them 10 guesses per second. Here are our numbers:

1. 12 character alpha numeric password. Number of possible passwords: `62^12 = 3e21` (entropy = `log2(3e21)` = 71 bits of entropy)
2. 12 character numeric password. Number of possible passwords: `10^12 = 1e12` (entropy = `log2(1e12)` = 39 bits of entropy
3. 12 character numeric password (but without 1 and 0). Number of possible passwords: `8^12 = 6.9e10` (entropy = `log2(6.9e10)` = 36 bits of entropy.

### Against a cracking rig

Our cracking rig can check 200,000,000,000 (aka `2e11`) passwords per second. Simply divide the number of passwords by the hashing rate to get how long it will take to crack it:

1. Alpha numeric: `3e21/2e11 = 1e10 seconds = 511 years`
2. All numbers: `1e12/2e11 = 5 seconds`
3. Numbers without 1 & 0: `6.9e10/2e11 = 0.3 seconds`

As you can see, there is a huge difference in their cracking times. For reference, some websites still use plain MD5 for storing passwords, so the above math is why using a long, random password is required. Of course an attacker can't just hook your wallet up to a GPU cracking rig and run through guesses that quickly.

### Hand entry

Instead the passwords have to be entered by hand, so we'll try again with our 10 passwords per second rate (which is probably very generous):

1. Alpha-numeric: `3e21/10 = 3e20 seconds = ~700 times the age of the universe`
2. All digits: `1e12/10 = 1e11 seconds = ~30 centuries`
3. Numbers without 1 & 0: `6.9e10/10 = 6.9e9 seconds = 2 centuries`

Your password is still quite uncrackable under these circumstances, but it is worth noting that losing just 2 out of 10 possible characters reduced the cracking time by a factor of 15!

The above analysis assumes a full brute-force search of the entire password space. For a long diceware-style password that is actually quite unrealistic, and an attacker would be better off working off of the actual word list. In that case, a more detailed analysis from the OP shows that the loss of entropy is much smaller. Either way though the overall summary remains the same:

## Summary

So your chosen method definitely weakens the password. However, given that these passwords have to be manually entered (and therefore password cracking is quite slow), you can still get sufficiently secure passwords even with this method, as long as it is long enough.

Personally though, since we're talking about a potentially high-value target that someone has to physically steal, I'd be more worried about rubber-hose cryptanalysis.

• Yes exactly on the right tack here. – skrap3e Jan 12 '20 at 4:54
• So, a 4 word passphrase can be reasonably secure, even if you're using a relatively small word list (eg 1000 words). If each word is 4 letters on average, that's 16 characters, which would be a 16 number password with this method. I always get confused about the conversion between entropy and relative cracking time, so I'm not sure how bad a 20-30% loss of entropy is. Would you mind elaborating on the consequences of a 20-30% entropy loss? – B T Jan 12 '20 at 22:29
• That's a great point about 1 and 0 being often unused. They certainly are on my phone's number pad. I might write a little program to test the combinations with different word lists and get to the bottom of this. – B T Jan 12 '20 at 22:41
• @BT nice! You obviously took that math and ran with it! That's a great analysis. To explain, the difference between your findings and mine is because of how the attacker approaches the problem. The entropy of the password is determined by how it is generated, but if an attacker doesn't know that they can guess the wrong way to approach the problem and end up making more work for themselves. As an example let's pick a 3 word diceware password, and the attacker knows that the final password is 12 characters long and composed only of lower-case letters. – Conor Mancone Jan 13 '20 at 13:25
• BTW, you have a small typo in your Readme. In your very first example you "translate" `boyhowdy` to `16946939`, but it should be `26946939` – Conor Mancone Jan 13 '20 at 13:33

this is going to be answered by measuring the potential for entropy which is determined by your character library. Taking words and making them numbers is only going to be good when it ends up making for a longer password. You would be better off going in reverse and substituting every numeric and special character used in a password for an alpha character or finding a library with more possibilities like Unicode.

If you want to know the measures difference use an online password generator and you can see the different resulting measure of entropy between two example passwords.

• You can't "upconvert" and add entropy unless you randomly choose the new letter, but then you are no longer substituting characters. This means that if you had a numbers-only password selected from 1 of 10,000 possible passwords, then a process that somehow turned that into an alpha-numeric string would still leave only 10,000 possible passwords. As a result it would be just as easy to guess for someone who knew how the process worked – Conor Mancone Jan 12 '20 at 11:27
• @ConorMancone thats correct! Good comment. The exact kind of process weakness that got the enigma cracked. – skrap3e Jan 12 '20 at 15:17