On Saturday (2014-07-19) Nadim Kobeissi introduced miniLock, a “file encryption software that does more with less”. A recording of the HOPE X talk introducing the software can be found on Vimeo.
Its big selling point is its ease of use. In order to generate a new key pair all you have to do is enter a passphrase. This gives you a public key consisting of approximately 44 Base58-encoded characters. People can encrypt files to you using this public key, and you can decrypt them from any device, knowing only your passphrase. The brevity of the public key allows it to double as its own fingerprint.
This is great, right? But why does that only happen now? What is the innovation here?
The idea of generating a key pair from a passphrase is not new.
Dan Kaminsky came up with it at least three years ago, and likely there were others before him.
He presented it at the Chaos Communication Camp in 2011 as an “obviously bad idea”.
A recording is available at media.ccc.de (the relevant part starts at 37:04).
The basic idea is seeding a PRNG with a passphrase, and using that PRNG to generate a key pair.
Since the seed remains the same, the PRNG output remains the same,
and ultimately the generated key pair remains the same.
This is precisely what miniLock does, by (ab)using scrypt as a hash-based PRNG.
The reason to call this an obviously bad idea is that (at best) this scheme is as secure as the users passphrase. The way miniLock avoids this is by placing requirements on the passphrase strength. Specifically it requires a passphrase to have at least 100 bit of entropy (as estimated by zxcvbn), which is supposedly sufficient to mitigate attacks. Arguably the innovation here is combining conservative passphrase strength estimation, with clever deterministic key pair creation.
The second innovation is not having to deal with a separate fingerprint. The public key is the fingerprint. That is only possible since the public key is short. What makes it so short, yet secure, is using elliptic curve cryptography (ECC). ECC can provide the same level of security as e.g. RSA, with much smaller key sizes.
There is a third innovation here, and to me this is the big one: the user interface. It is very minimal, easy to understand, and does precisely what is needed for the job. It occurred to me that (ignoring private key distribution across multiple devices) we could make that very same interface work for GPG's file encryption use-case. Once you have a key pair (this can be a first start thing, may take a while, but does not require any arcane knowledge: enter a name, an e-mail address; hit "Create"; done), all you need to get to your private key is a passphrase each time the interface starts. Per recipient all you need to enter is a fingerprint. The fingerprints include the key-ids so the interface can automagically fetch them from a key server, and verify the fingerprint, no further user interaction required. GPG fingerprints are even shorter than miniLock public keys, usually 40 characters, could be even less if Base58 was used instead of plain hex.
The huge problem we have as a community is, no-one writes such interfaces. Granted the GPG interface described above lacks a lot of the benefits miniLock gives you. Still, for this use case it would have been infinitely better than anything we have right now. One of the big things to focus on in order to “win the crypto-wars”, is creating better, easier user interfaces. To me, showing how to do this is the biggest achievement of miniLock and Cryptocat. (I should say that there are a lot of other achievements: working in the open, consistently encouraging peer review, trying to get audits, …)