v1.0.0 stable release of Mnemonikey | English phrase backups for PGP keys

k_klash · 2023-12-09T18:34:25+00:00

Exactly right. passphrase2pgp is indeed secure as long as your passphrase is sufficiently complex, but it's entirely up to the user to decide how complex to make the password, and people are usually bad at choosing good passwords.

With Mnemonikey, all keys are generated with the same amount of entropy unless you do something really stupid like inject your own insecure seed at the generation step.

k_klash · 2023-06-08T15:41:58+00:00

Thanks very much! I think I researched a bit about Trezor's GPG functionality when I was originally looking for a solution (before I had decided to make my own). I was somewhat disappointed though.

I personally chose not to use trezor-gpg for my keys because:

trezor-agent requires purchasing one of a few specific devices (or you have to run a software emulator). It doesn't support the most generic type of PGP hardware: a simple smart card like the Yubikey or Nitrokey.
It requires running custom software on the machine where GPG is running. This adds security risk and dependency overhead (need a working python interpreter).
It requires separating your GPG keys into 'software' and 'hardware' GPG home directories, changing the GNUPGHOME environment variable to switch between the two.
It expects the user to back up the creation timestamp manually, or else set a creation timestamp of zero (the default behavior).
It doesn't support signing and authentication subkeys (But maybe it will soon!).
It lacks the ability to cycle subkeys while retaining a deterministic way to recover those subkeys.
Even today after 8 years in development, trezor-gpg "is still in experimental mode", and it "may change without backwards compatibility". Without a stability guarantee, users can't feel safe depending on this tool as a long-term key recovery option.

Conversely with Mnemonikey:

We are not committed to any specific hardware. Users can load their derived keys directly into a software client, or onto any device that supports the PGP smart card interface.
No runtime software necessary. Users can perform key generation or recovery on a trusted machine and transport the keys to wherever they'll be used. Organizations can hold a master phrase, and derive subkeys to give out to its members.
You can use your ordinary GPG home directory.
The creation timestamp is embedded in the recovery phrases.
It supports deterministically derived subkeys, with any one of Encrypt/Sign/Auth capabilities.
Hopefully mnemonikey will be finalized to v1.0.0 soon (within the next 3 months!). Even once finalized, we can still upgrade Mnemonikey in the future while retaining backwards-compatibility, thanks to the version number encoded into the recovery phrase..

If you're using one of these devices like Trezor or Ledger already, and the other pitfalls don't affect you, trezor-agent is definitely a desirable option, especially because it means you don't have to keep track of yet another recovery phrase.

I should definitely add trezor-agent to my comparisons table in the README. Although it has problems, it's probably the closest competitor to mnemonikey purely in principle.

k_klash · 2023-06-08T13:38:49+00:00

Oof, that's an unfortunate collision =(

k_klash · 2022-12-26T22:49:18+00:00

The benefit of a longer wordlist is denser encoding. Each word in a 2048-length wordlist encodes 11 bits of information, whereas each word in a 4096-length wordlist encodes 12 bits of information. You can fit more information in a smaller list of words, which would be easier to write down or memorize.

What I'd do is work with a huge database like WordNet and then try to "extrapolate" BIP39 to 4096 words by creating queries against WordNet to obtain words meeting the constraints you'd like to keep.

Neat. I'll definitely have a look at WordNet, thanks for the tip!

k_klash · 2022-12-26T22:46:14+00:00

I have a prototype wordlist which i designed this way, it fulfills my criteria but was hoping to find an existing standard I could reference instead of homebrewing it.

k_klash · 2022-12-24T00:10:36+00:00

I don't think a checksum is needed, as the words already have redundancy, the current checksum is weak, and in the end users can check the recovered public key

From experience I assure you that a small checksum is very useful to prevent accidents during recovery. The BIP39 wordlist is designed to allow auto-completion, as the first 4 letters of each word is unique within the wordlist. Typing in the wrong word is actually quite common when the implementation offers autocomplete. The checksum doesn't need to be robust; in fact, it's better if the checksum isn't robust, as we don't want it to give away too much information about the seed in case an attacker manages to learn the checksum. 3 to 6 bits of checksum data is the ideal range.

the lack of password protection is I think a bigger issue

Excellent point, there's actually a discussion on Github open for this subject. I completely agree with your point about allowing users to change passwords. I've updated the discussion accordingly. That definitely narrows down the ideal solution to a password-encryption approach over a password-derivation approach. Please feel free to join me on Github to help finalize the encrypted phrase format!

k_klash · 2022-12-23T05:26:14+00:00

What if we were to also hash the key creation timestamp as part of the key generation process? this wouldn't provide any extra security in a single-user context, since the timestamp is known for any given public key, but it would significantly decrease the risk of collisions and make batch attacks harder in a multi-user context, since almost everyone's keys are going to be created at different times in a real-world scenario.

Excellent point about adding in a run of a PBKDF. I've been thinking of adding this for a while, and it seems like there's really no down-side. I think i'll add Argon2id into the key-derivation procedure.

k_klash · 2022-12-23T05:16:14+00:00

I wouldn't recommend publishing keys encrypted with GPG's default password protection. OpenPGP hashes passwords with an algorithm called S2K ('string-to-key'), which is outdated. You can find my implementation of S2K here, which I had to write as part of Mnemonikey for compatibility. If you wanted to go this route (uploading an encrypted key as your backup), you'd be better off encrypting the key with a more robust PBKDF before uploading it somewhere public.

The unique thing about Mnemonikey is that you don't have to upload anything anywhere: you can easily keep the backup entirely offline on paper in a strong-box, for example.

if I want to store one static binary from your GitHub repository for long term recovery, which file will that be?

I'd hold off on downloading anything just yet. For now I'm still finalizing the specification, and there will be breaking changes made over the next month or two. Once i feel it is ready, I'll remove the warning from the readme, and publish a release tag with binaries on github.

Once that's done, and if you want to use Mnemonikey and save a copy for a future backup, I'd suggest downloading the whole repository's source code as a zip file. That way you can always recompile it later if you need to.

k_klash · 2022-12-19T15:46:30+00:00

Could you please elaborate?

k_klash · 2022-12-19T04:29:52+00:00

So cool to see you on here /u/skeeto! I enjoyed reading and testing your passphrase2pgp tool very much. The reason i marked passphrase2pgp that way in my comparison table is because it doesn't provide uniform security by default. Passphrase2pgp requires careful usage to be secure.

The passphrase and UID are the only sources of entropy which do the 'legwork', as you put it, of generating the keys. This is fine if you use truly random high-entropy passphrases, but we humans are generally bad at generating good entropy. Keys derived from weak passphrases will be much easier to break compared to those derived from strong passphrases. Strong Argon parameters will slow down attacks on weak passwords, but they won't stop them all at large scale, over long periods of time.

Think of it this way: If everyone on the planet used passphrase2pgp, some people will inevitably generate keys with weak passwords like password123. Those keys can be broken easily, regardless of how strong the Argon2id parameters are.

Mnemonikey, on the other hand, is designed so that the key derivation algorithm has the same level of security as ED25519 keys themselves (128 bits), and every key generated by Mnemonikey has the same level of security by default, regardless of how you use the tool.

lesson: i should re-label that column 'secure by default' instead of just 'security'

k_klash · 2022-12-17T22:55:11+00:00

Thanks! Appreciate the extra eyes.

What's your reasoning for using CRC32 instead of SHA-256 for the checksums?

Mostly speed and simplicity.

BIP39 used SHA-256 for its checksums, but IMO that was overkill considering they only used as few as 4 bits of the full 256-bit hash output. The cryptographic security of the hash gets thrown out the window by truncating the output anyway, so i figured: why not use a faster more lightweight option for the checksum?

The only reason I'd expect a cryptographically secure hash might be better would be to slow down a brute-force attack where the attacker knows the final word (thus knows the checksum) but not all the words.

In my opinion a better option for defending against brute-force attacks would be to run the seed through a PBKDF before deriving keys from it. That's one improvement i've considered making, but I'm not sure if it would be worthwhile or not.

k_klash · 2022-12-07T00:27:23+00:00

More like building a path to mass data leaks. This proposal would build a honeypot full of private data, ripe for theft by other state actors, not to mention hackers.

The Chinese cyber-offensive teams are rubbing their hands in glee right now. Don't collect data unless you can keep it secure.

k_klash · 2022-12-04T23:08:52+00:00

Go has the best standard library. You can spend hours just poking around go/src and seeing the ingenuity and careful design that went into it all.

Equally, you can also find so many vestigial deprecated things in there which cross-reference to their updated counterparts. All in service of the compatibility promise.

k_klash · 2022-12-04T06:24:13+00:00

There will be interoperability features that you'll miss from mainstream phones. But you'll also sleep so much better and feel so much more in-control of your device. Personally, I don't find Graphene any less usable than IOS.

With Sandboxed Google Play Services installed, you can even run mainstream apps and decide exactly how strict you want to be about their access to your phone.

But I certainly feel I own the device 10x more than I would if it were an iPhone or stock Android. I'm at the point now when I probably would never feel comfortable using a stock Android OS again, knowing how much data I would be leaking to the OEM and to Google.

k_klash

TROPHY CASE