privly / privly-library Goto Github PK

The big piece of missing functionality in the crypto library is that it has no functions for generating RSA key pairs. I've avoided this issue during development by generating keys with command line tools. There should be a function to generate a key pair, and probably also a function for revoking a key pair.

We need to decide how RSA keys are managed in the Privly system.

The basic problem is to allow users to be confident that all RSA keys used in the Privly system actually belong to the people that they claim. The two basic paradigms are the Certificate Authority (CA) and the Web of Trust (WoT). In the CA scheme, we (Privly) would issue key pairs signed with our "master" key. Essentially, we're asserting that because we issued the User Key, ya'll can trust it. In the other choice (WoT), all keys start out equally "untrusted", and users "sign" each other's keys to show that the signer trusts the signee to (1) actually be who he claims to be and 2) not compromise his key through carelessness.

It seems most natural to use the CA approach here. We'll probably want to get a master key from an established CA (we'll have to pay for this). We will need to develop policies for key revocation, dealing with compromised keys, user authentication, etc.

If we choose CA, we need to decide what to do about users who want to use their PGP keys (PGP uses WoT).

Like the title says, we need an automated test suite for the crypto library.

At some point, we'll want to have an independent security expert review our security code.

Current build system is a one-off Makefile that only works on Windows+Cygwin. We will need a build system that works on all major platforms.

If I was starting tomorrow, I would use CMake, but there are many reasonable choices.

The crypto library depends on Mozilla NSS for the low-level cryptography algorithms (ciphers, keys, etc). We need to document the build process on all platforms that we support, for both developers and users who wish to build from source.

The project I mentioned to you is ZeroBin. (more info, source code (BSD 3-clause I think), made by @sebsauvage)

Short explanation (taken from kcima on Hacker News):
»The genius of this is the realization that browsers do not send the named anchor (technically "fragment identifier"[1]) to the server. Using the named anchor as the cryptographic key enables users to pass around simple URLs to encrypted data. Data is stored on the server, but the server never has access to the complete URL with the key, so it cannot decrypt it.«

So I give you this address http://sebsauvage.net/paste/?44e120bde8118ab1#9iZAutp/KfJA7UbhwBHyL9wdJFyOwHfzLT+l9b8nTOw=
And you open it, see »Hey Privly« without even knowing it is stored encrypted. Super nice!

Since Priv.ly is based on sending around links anyway, I think this fits perfectly.