Howdy! Here we are, back with some news for you, and also an explanation about how we approach security in Caliopen. Ready? Let’s go!
- Unfortunately in March other projects than Caliopen left our lead developers little time left : little progress were thus made on this regard. In order to allow new persons to easily join the project and contribute, we plan to completely reorganize our code: this is being taken care of, and it will soon be done.
- Our work on the gamification process of security setup continues: we met with the Manzalab crew in order to discuss our ideas. A public pad, where everyone can bring his contribution, has been open.
- We also met with project PEPS: our project have quite different goals, but we’d both like for our project to converge on some points. We have thus started considering the integration of the Privacy Index into other messaging services.
- Caliopen crossed the border! The BGLUG hosted the first conference about Caliopen outside France: we thank them for their invitation!
- Next on our list is a conference on April 24th in Brest. Do you want us to give a talk about Caliopen? Becasue we’d surely love to! Please get in touch with us!
The Keys Caos
Since the beginning of Caliopen, we’ve been asked over and over what encryption we will use in order to guarantee users’ privacy.
If we don’t have a straight forward reply, that’s because we have to lay down the premises first:
– We can’t talk about the encryption system of Caliopen, by design, the user will be able to choose not to encrypt anything, to encrypt the messages he sends, or to encrypt the messages saved in Caliopen… These choices might prove to be more or less constraining for the users on a daily basis: their adoption will of course influence the Privacy Index score, but users won’t be forced into them. Caliopen will surely offer encryption systems, it’s in its DNA, but the user won’t be forced to adopt them.
– Also, we don’t think that anybody can guarantee privacy. Even in the most protected environment one can always be trapped by a microphone, a USB key plugged while away, a targeted attack, or just a plain dumb mistake. Caliopen’s goal is to make mass surveillance harder, making it too expensive to be used. The goal is not to protect the privacy of some individuals (even though, of course, that’s what we will strive to do), rather, we aim to improve the privacy protection of all of the users.
These are key points in order to understand Caliopen. We might be used to think in a binary mode: my communications are encrypted, and thus I am protected VS my communications are not encrypted, thus the NSA knows everything about me. But with Caliopen we are building a multi-step system: me and my contacts have now a better protection, but we still can do more.
Nonetheless, this explanation wouldn’t suffice without presenting our technical choices about encryption. And especially about encryption keys.
Since the beginning we decided that Caliopen won’t lock users into its own ecosystem: our choices are conservatives and compatibles with the whole of the messaging systems existing today, according to the good old Postel principle ( “Be liberal in what you accept, and conservative in what you send”). The same is true about encryption: in order to remain compatible with existing solutions, PGP will be available to those willing to sign or encrypt their messages.
PGP has a huge advantage: it is completely decentralized. Contrary to S/MIME, it doesn’t use any central authority to distribute public keys.
On the other hand, PGP has a huge disadvantage: being completely decentralized, it might be hard to find the public key that will allow you to encrypt the message you are writing to a new contact, and it is also hard to make your own public key available to those willing to write you encrypted messages. A key server? The SKS protocol has been a great advance, no doubt about that, but it remains rather unstable to be reliable on a daily basis. And, by centralizing key management, it represents a vulnerability that weakens PGP. This is why we thought it was necessary to offer another solution to Caliopen users willing to use their own encryption keys.
This kind of problems have been recently discussed by Werner Koch (we’ve translated his article answering a critic against PGP) and we chose to use DNS, and this for several reasons.
– Every Caliopen user has (at least) an ID (user@domain) that can be used as an e-mail address, DNS allows to easily find his public key. It will suffice to query the domain name server (for example ‘dig @ns.brainstorm.fr -t cert laurent.brainstorm.fr’ will provide the PGP key for “firstname.lastname@example.org”). No need for a working SKS server, no need to rely on a third party to act as an intermediary.
– On this regard, DNS is a decentralized system: apart from the zone admins, especially if DNSSEC is used, it is extremely hard for a third party to edit it in order to insert fake keys.
– Managed like this, keys are easy to revoke (which is one of the main problems with PGP).
There are still more reasons, but while translating Werner Koch‘s post, we discovered that those are described in detail in a document of the STEED project (a project featuring, once again, Werner Koch): http://g10code.com/docs/steed-usable-e2ee.pdf .
Once again, Caliopen users won’t be forced: those preferring to manage public keys in a different way will be most certainly allowed to do so. Caliopen’s algorithms will calculate the Privacy Index according to the management technique chosen: more points will be earned with a safer management choice, but all of them will be handled, of course.
We look forward to keep on explaining our encryption choices (key generation, private key management, multiple devices use) in our future posts, and are eager to have your feedback!
While waiting for our next blog post, you may want to reach us: good idea! And, even better, it’s so easy!
- Through IRC, on irc.freenode.org, channel #caliopen or, to take part in the development, on #caliopdev. And please, don’t be intimidated if, when you come in, we are talkin in French: let us know that you’d rather converse in English and we’ll immediately switch language!
- On Twitter, we are @caliopen_org
- Drop us a good old-fashioned e-mail! email@example.com
- Github: everything’s clear, no need to ask questions? Great! We are waiting for your PR! Caliopen is on Github