The Business and Technology of Zero-Knowledge Software

In the past year and a half I’ve written a few times about an encrypted email app we built at Black Chair called Parley. Parley, at this point, is essentially dead: the service has been in “pre-beta” for about 7 months, and we haven’t made any significant changes to it in at least 5. As it stands, I consider it an impressive accomplishment for our company, but it needs quite a bit more work before being ready for prime-time and it is unlikely to see those changes without a significant cash injection. (Basically, we chose a horrible intersection of the consumer space for a bootstrapped project: email software is very difficult to get right, encryption is very difficult to get right, they are both even more difficult to get right on mobile platforms, and—even worse—general consumers are not feeling any pain due to unencrypted email. We need to target businesses, and that’s an entirely different kettle of fish.) I’m not crazy about taking on investment for this sort of project (or rather, I’m incredibly picky about who we might take on as an investor) so Parley is basically on the shelf for now.

However, we’re still extremely passionate about software built around end-to-end encryption, and we learned a lot of valuable lessons—both in business and in technology—which we’ve been eager to put to good use. Business-wise, we’ve learned that “minimum viable products” mean something entirely different when it comes to encryption software, and we’ve learned that “ship early, ship often” doesn’t work the same way in the world of installed apps (as opposed to web apps). We’ve also learned that keeping things incredibly small and simple, with the tightest possible set of features, is even more important for bootstrapped encryption projects than any other bootstrapped project (essentially, because encryption itself is such a large and complicated feature that you can’t reliably tack on much more without inappropriately increasing the scope). Tech-wise, we learned:

  1. Encryption is already hard. For a small bootstrapped project trying to reach all platforms, it’s almost impossible. In Parley, we chose to target desktops first, and we used TideSDK (formerly Titanium) to let us run Python modules under the hood which took care of encryption (and all the PGP stuff ran through a Python binding to a locally installed version of GPG). That worked well (we could never have expected to beat GPG in terms of security and reliability) but when we started contemplating mobile platforms we got a bit stuck. To achieve feature parity, we would have had to either use a non-GNU C implementation of OpenPGP and write separate bindings for Objective-C and Java OR do that for iOS and use GPG with Java bindings on Android OR do that for iOS and use a pure-Java implementation of PGP on Android. All of that seemed awful, because suddenly the most critical part of our codebase would need to live in triplicate. The only other thing we could think of was to use OpenPGP.js inside the WebViews on every platform, but (a) Javascript implementations of PGP have never been audited as far as we know, and (b) OpenPGP.js isn’t compatible with all of the same formats as GPG, so we would have lost inter-operability with other PGP users in certain edge cases.
  2. Working with an untrusted server is hard. The whole point of projects like Parley is that even server administrators (either maliciously or under court order) wouldn’t be able to access your data even if they wanted to, but for that to really be true it needs to be considered at every step of the process. For example, account creation can’t happen in a browser anymore—at least not entirely—because then the server could serve malicious Javascript that sniffed the user’s passphrase. However, it’s nice to at least offer an email signup form online (to increase conversions/provide the ability of recovering botched setups) and it’s necessary (especially in Parley’s case) to verify ownership of a user’s email address, but the typical method of sending a link becomes quite convoluted when the rest of the account creation process needs to happen in-app.
  3. Kinda like #1, but different: building apps for multiple devices is harder when encryption is involved. Ideally an email client should sync with the server, but things like marking a message as read on one device should also mark it as read on any other devices where the user is logged in, in real-time. None of the current solutions for real-time data or offline sync specifically consider the encrypted use-case, and some of them are difficult or inefficient to use that way.
  4. Searching and filtering data is a lot harder when the server can’t read it—you need to do everything client-side, or arrange a division of labour between server and client which leaves you with the appropriate trade between what the server is allowed to see and what the user is able to do.
  5. All of the cross-platform code problems related to encryption (see #1) also apply to email protocols, aka IMAP sucks. We used to help us get Parley out the door, but that was (understandably) an unpopular choice among privacy conscious folks, because we were giving a third party access to their (obviously heavily encrypted, but still) data.

#5 is email-specific, but #1-4 apply to any projects requiring a “blind/untrusted/zero-knowledge” server. There are several great projects of that variety coming out lately (Turtl was on the front page of HN this week) and at least one excellent framework for them in Crypton, but we’ve been working on our own version of both (a zero-knowledge app and a framework for zero-knowledge apps) that we think nails each of those problems (with the exception of #5) in a better way. We think the app addresses some of the business problems we ran into with Parley, too. I don’t want to say too much more until they’re ready, but that should be happening within the next month or two :)


Software developer, book writer, beer brewer :)

No Comments

Leave a Comment

Please be polite. We appreciate that.
Your email address will not be published and required fields are marked