The New Peerio: A Technical Deep Dive
Last week we released a complete rewrite of Peerio — our end-to-end encrypted messaging, email, file management and team collaboration platform. Our team has been working extremely hard over the past months to bring you a better, faster, more secure application.
After touting the exciting benefits of our new architecture, we have now also published a detailed whitepaper. This document contains a deep dive into the keys and permission schemes of our KegDB system. As mentioned in our launch blog post, this new design has huge performance benefits and allows us to tailor level and mode of access to data in a variety of ways. You will find more details about this in the whitepaper.
I’d also like to highlight a few security improvements we have made to our core.
Users now have multiple keys that are used for different purposes. This removes some potential weaknesses from our legacy architecture. Under our legacy system users only had one key. They had to use this key for both sending messages to contacts and decrypting authentication tokens from our servers. Our new scheme uses an entirely different set of keys solely for communicating with the server, reducing the risk of future bugs.
We also increased our passphrase entropy and added a salt to the initial key derivation, to make sure it isn’t deterministic.
We added some extra steps to our server authentication scheme to mitigate impersonation. The server must now prove to the client that it is aware of the user’s public key before the client will agree to prove itself to the server. We believe in reciprocal relationships! 😃
Trust on first use (TOFU)
We’ve also improved our TOFU scheme for contacts’ keys. In Peerio 1.0 this was limited to checking identities against a device-specific local cache. The key history ledger is now shared between devices through a user’s (encrypted) personal KegDB.
Public key fingerprints
While we were fiddling with keys and authentication schemes, we also took some advice from our friends at Universität Bonn and created much shorter numeric public key fingerprints — known as Peerio ID #s — for out-of-band comparison.
The source code for our clients (which are licensed under the GNU GPLv3) is available on Github. We have three main repositories:
- peerio-icebear is the core where all the crypto and KegDB details live
- peerio-desktop contains the desktop applications (built with Electron)
- peerio-mobile contains the mobile applications (built with React Native)
- peerio is our central repository for issues from the community
As always, we encourage users to visit our help centre and contact our support staff for assistance. We also welcome questions about the whitepaper and our documentation in general. Subscribe to this blog to get more dispatches from development and hear about new security features as we add them!