17 August 2018
Recap: Ian and I are building Fluidkeys, software that helps teams protect themselves with strong encryption. Fluidkeys builds on the OpenPGP standard and is compatible with other OpenPGP software.
This week we’ve:
We’ve got lots of ideas for cool things Fluidkeys could do to help teams protect themselves.
Early in the week we confused ourselves about what we’re trying to do… are we improving PGP or making end-user features?
For example, we’re interested in integrating with Slack to allow sending end-to-end encrypted messages. What’s that got to do with wrapping GnuPG or making a PGP key?
Here’s what we realised:
With that realisation, we can separate features into two classes:
With that in mind, we started working towards our first mini-release of Fluidkeys. The aim of version 0.1.0 is simple:
“Make a best-practice PGP key that I can use with GnuPG”
This release is aimed at developers and sysadmins, and we wanted to tackle these specific usability issues in other software:
It’s just silly to expect non-cryptographers to tell you what key size they want, so we don’t ask them. We deferred to Mozilla’s Infosec team’s key management guidance and went with a 4096-bit RSA key.
As a usability principle, we plan to ask as few questions as possible, and be opinionated with (strong) defaults instead. (Hypothesis: teams will defer to our expertise over their own — we’ll have to earn this credibility.)
It’s a heavy mental burden to be asked to come up with a new password, and decide what’s meant by “secure”.
We’ve tried to side-step both issues by just making a password for them. We’ve used the 6-word Diceware technique with EFF’s wordlist which provides a number of usability improvements. It generates relatively memorable passwords like this:
We’ve also dropped the word “passphrase” because… WTF.
We took some inspiration from Bitcoin wallets here which use an intriguing design pattern.
After presenting the password, we ask them to put it in their password manager or write it on a piece of paper and keep it on them. We ask them to hit enter once they’ve recorded it.
Then we clear the screen, and ask for one of the words from the password. If they type in the word correctly, we assume they did write it down.
If they get it wrong, we give them another chance to write it down before bailing out.
This isn’t infallible — I suspect people might just paste the password into a text editor and subsequently lose it. But at least they can’t copy-paste the whole password, since they need to give a single word.
Hopefully with time and testing we’ll figure out how to make this bit as reliable as possible.
Having chosen to generate 4096-bit keys, we made the user experience worse by introducing a potentially long delay. (It takes a lot of entropy to securely generate a 4096-bit key, and computers generate entropy quite slowly from sources like mouse movements and hard disk timings).
The solution’s obvious: do it in the background!
Fluidkeys asks the person to write down their password and come back when they’re done, so we use that dead-time to generate the key behind the scenes.
Understandably, because it’s complicated and boring. Most of us never quite get round to making a backup until it’s too late.
Again, we just do it automatically. Fluidkeys makes a ZIP file with a sensible name and saves it to your
Inside the ZIP file, it looks like this:
fluidkeys-2018-08-17-paul-paulfurley-com.zip ├── 2018-08-17-paul-paulfurley-com.private-encrypted.txt ├── 2018-08-17-paul-paulfurley-com.public.txt ├── 2018-08-17-paul-paulfurley-com.revoke.txt └── README.txt
We wanted v0.1.0 to be properly releasable, and that meant packaging it properly from the start. We took some upfront effort to properly package Fluidkeys for macOS and Debian/Ubuntu:
To set an example, we’re signing (almost) all our commits on Github, and we’re strictly signing releases as version tags
When Jenkins prepares to build a new DEB package and Homebrew formula, it gets the most recent tag and check that it’s properly signed by me or Ian, and blows up if not.
Finally, Jenkins has its own automatic signing key which it uses to sign the apt repo.
It’s not infallible, but it protects against attacks on Github accounts like the one recently suffered by Gentoo.
Fluidkeys v0.1.0 is furiously minimal, but we’d really appreciate your thoughts on what we’ve built so far.
If you’d like to test drive it, head over to Github and follow the install instructions there.