Client: Paper keys

[Radagan]

This isn't exactly a bug, but I think it is a trust issue. When I generate a paper key, I'm given a passphrase without any idea where that passphrase was generated and possibly stored. This is a very powerful passphrase and could be greatly abused. Passphrases normally come from the user to the system--such as in ssh--not the other way around.

Since such XKCD style phrases are dependent on randomness for strength, I realize that you are probably wanting to generate the phrase in the client and are reluctant to rely on the user to provide a good one. But I feel strongly that I should at least have the option to provide one.

[junderw]

I should at least have the option to provide one.

You are misunderstanding.

A paper key is an encryption key.

Encryption keys are extremely large.

Even a password like:

_bCFq*);L2T!U4N!

is too small entropy wise.

Telling a human to generate a fully random encryption key is impossible. They will most likely chose "123456" or "password" and their account will be completely hacked.

The reason why the long key is shown as words is so that people can write it down on a piece of paper and store it somewhere safe.

When the device generates the key, it uses the exact same method it used to generate the device key that is saved on your computer... the only difference is instead of saving it on your disk encrypted, they show it to you as 12 words. After they show it to you, they completely delete that key from memory, it is never saved on disk in any form. If you didn't write it down or copy paste it somewhere, it is gone.

Paper key is a great feature... but it's hard to understand, and a lot of people accidentally think that it is a password or something... it's not. It's a device key just like your computer holds.

[Radagan]

Okay, this is fascinating. I follow you to a point. If you generate the encryption key as you normally would for a device, how do you map that to a dictionary style passphrase to get the key back at some future point? Mustn't there be some hash of strings to encryption keys somewhere? Or an algorithm that deterministic generates keys for given word strings? I'm not criticizing, just trying to get my head around it. It's easy to serialize a key to a string, but a string of English words? Now that's very cool, so long as having such a mapping didn't compromise the key.

[junderw]

the word list is 2048 words. which means that you can encode the index of a word in 11 bits of data (2^11 = 2048) just like you could encode 1 byte of data in a wordlist of 256 words. (since you have one word for each possible byte, since 1 byte has 256 possibilities)

12 words x 11 bits = 132 bits... but actually keybase uses 4 bits as a checksum (so if you mess up a word order, there's a 15/16 chance you will catch the mistake.) so that leaves with 128 bits (16 bytes)

So the paper key is 16 bytes of random data, a checksum of 4 bits is taken and stuck on the end. 132 bits.

132 1s and 0s are then split into groups of 11 bits, and each group of eleven bits is converted into a word in a 2048 wordlist (2^11 = 2048)...

So you can encode and decode data into words and words into data without any loss of information.

[Radagan]

That's... a really cool trick. Thank you for taking the time to share it. I think I need to learn Go, so that I can look at this inspiring project more closely.

[ryukinix]

Just a question here because @junderw cites paper key with 12-words length.

I saved earlier a paper key with 12 words... for my surprise didn't work and the app says that there is no enough words in my paper key.

Every elsewhere I look they said that paper key has 13-words, but I found this. So... After all, paper keys have 12-words or 13-words length?

[junderw]

Keybase is 13. Sorry for the confusion.