This is Snake, an platform which aims to make secure one-to-one and many-to-many communications easy for everyone. Snake is composed by a client and a storage server, designed to store as little data about the user and his messages as possible, offering concrete guarantees in terms of anonimity. Take a look at the full design document.
We target any one-to-one communication where the two ends involved in the conversation already know each other (i.e. they share a common secret, even implicitly). We also aim to offer many-to-many communication in the form of groups, providing that a new member is friend at least with an existing member. In particular we don't support: one-to-one communication where one end trusts the other but they don't know each other, which is the typical whistleblowing scenario.
Snake cannot deal with a lot of issues external to the itself, such as browser security flaws, so it's not a complete solution, but it can be part of it.
It depends. Our platform can't guarantee anonymity to the user by itself. It could with the support of other tools such as the Tor Browser Bundle. However the storage server could still trace the user through his behavior (e.g. the user will always make similar requests on login), and very little can be done about this without devastating the system's performance and thus usability. Despite this, we designed Snake to allow an honest storage provider to keep only the strictly minimal information stored on the database to provide the service correctly. For instance, if the storage server behaves following our specifications, by looking at the database it's not possible to say if two users are friend or not, or who is the sender of a message. This is particularly useful to protect users in case of seizures and intrusions.
If the storage provider uses our implementation, it will be no problem. No useful information can be obtained looking at the database, and it is not possible to reconstruct it in any way. The only useful information that can be collected is the number of friendship requests you received (but not who sent them, or if you accepted them) and your public profile, which is something the user knows to be public, and can be empty.
Google Docs is an easy way to let multiple people work at the same time, on the same document. However, currently there is no way to this in private way, i.e. without leaking the contents, the history and the metadata of the document to the service provider, which is particularly bad for businesses and public entities. Snake aims to overcome this antinomy between security and convenience and for this reason it offer collaborative document editing. There will be no passwords, no need to verify public keys or the like: Snake will take care of it all. Just create a new document, invite a friend and start editing. Note that thanks to projects such as WebODF we don't need to implement a document editor from scratch, so it will available pretty soon.
We do believe in Free Software and we'll release the source code of Snake. There is a working prototype but we prefer to improve and clean it up before going public. The source code of Snake, both of the server and client, will be available under the AGPL license. However, in the future we may also release it under another less restrictive license such as MIT.
We will support all the platforms which will provide the WebCrypto API plus a couple of other technologies already widely adopted. The application will always run in a browser context, be it a web page, a browser extension or a mobile application. At the current state we support Google Chrome/Chromium.
All the data is stored on a remote storage server. While at current stage we model it as a single server, in a real scenario it would be composed by a series of interoperating servers, possibly managed by distinct entities. However, the client will always communicate with a single server.
Because it has to run in the browser, because of NAT and serious data availability issues. However, in future, we plan to use WebRTC for file transfer, stream communication (VoIP) and any other kind of communication which doesn't require to be stored on the long-term.
It depends. We plan to offer several distinct ways to obtain the application, for instance the mobile application will be distributed through the appropriate marketplace. We also plan to release it as a web browser plugin for Google Chrome/Chromium and Firefox. However, we also want to allow users to access Snake through a normal web page distributed over HTTPS.
Yes, the application distribution server and the storage server. For what
concerns the former, there's no workaround, you always have to trust
someone who gives you the code, be it the developer itself. "Installing"
the application doesn't really solves the problem, if you update your
system frequently. About the latter server, trust is not required for the
system to work, in fact the storage server could be completely untrusted
and it wouldn't be able to read the contents of your messages. However
this is required for anonymity (e.g. hiding who is the sender of a
message). Since it's not that easy to monetize the little metadata
available, we deem few storage providers will have incentive to store
As a final note, trusting two servers with two different responsabilities is better than trusting a single one, since it gives you trust agility, which means that if one of the two behaves badly, you can move away from it easily.
Not much worse than a web browser plugin. For instance Google Chrome/Chromium plugins are digitally signed, but the public key is embedded in the package itself (the .crx file) and is not signed by any third party authority, therefore in could be faked easily by an attacker. Such a simple attack is not possible because plugins are distributed and updated over HTTPS. The most important advantage over a plain HTTPS connections is the fact that the server belongs to google.com, whose public keys are statically pinned in the browser. However a standard is emerging to allow host operators to pin public keys in user's browsers.
Yes, we will. The plan is to run them in an isolated sandbox and communicate with them through a restricted (and finely tunable) API. Third party plugins won't need to deal with encryption.
Yes, but if the storage provider is malicious and keeps a copy of the old data, which is protected with a weak/compromised password, it will be able to get complete access to your account, or at least to an old version of it.
No, the storage server does not have access to it and cannot change it. However we can implement an account recovery mechanism through a series of questions. These questions would be available to everyone and an attacker would have an infinite amount of attempts to answer them. Therefore to keep it secure, the number of questions should be very high, e.g. more than 80 if the question has a boolean answer. Another option would be to require the collaboration of a number of trusted friends to recover your account, which however could then collude to gain control of it.
Snake shares the aims of PGP and goes further. It could look like the "PGP for web 2.0", since we provide end-to-end encryption and we do use a concept similar to the PGP Web of Trust, however Snake has been designed to overcome the main issues of PGP. In particular it scales well with communication among many users, it doesn't require out-of-band communication to authenticate public keys, it's easy to use and, assuming the service provider is honest, it's also able to protect the communication metadata (e.g. the social graph and the sender of the message are available publicly or to the storage server).
OTR is an overlay protocol for instant messaging systems such as Skype or Facebook Chat. Its peculiarity consists in the fact that it offers perfect forward secrecy and repudiability. While we currently do not support these features in one-to-one communications, it would be farly easy to implement an OTR-like mode for one-to-one private chat, and we plan to do it. As a side note, we took inspiration from the OTR's approach for public key authentication, based on the socialist millionaire protocol.
Diaspora is made of a series of federated servers holding your information in clear. This model would be interesting if every user would have his own server running a Diaspora instance (pod), which is not very realistic. The most plausible scenario for Diaspora is that there will be about a dozen of big Diaspora pods, which is not very different from having a single central entity. It could even be worse due to different policies and difficulties to enforce privacy laws. We use cryptography because we want to put as little trust as possible in the storage provider and offer a technical guarantee of privacy.
Syme is a quite emerging project, as Snake is, and the source code has not been publicly released yet. At first sight it looks similar to our project under various technical aspects, but it misses all the key points of Snake, in particular: separation of data storage and application provider, in-band public key authentication, usage of native cryptographic primitives, anonimity of metadata and scalable group communication.
The cryptography overhead is negligible since we use a native cryptography implementation thanks to the WebCryptoAPI.
We designed Snake to scale up to tens of thousands group members, probably even more users could be handled, but it's hard to keep privacy with that many users. The problem with big groups is that you don't want to send the key encrypted in a different way for each user, so we use a single shared key for the whole group. When a member leaves (or is banned) from a group the group key has to be changed. Snake notifies the group members of this change in an efficient way: it just has to send log(n) messages, where n is the size of the group. For instance if a group has 10'000 members, in the optimal configuration, to notify them of a key update we just need a message containing about 20 keys. Many other solutions require sending 10'000 messages or a single message containing 10'000 keys.
We don't require an out-of-band key verification (e.g. PGP key signing parties), everything can be done from Snake. We offer two ways to authenticate public keys: through a shared secret and through the Web of Trust. The shared secret method (an implementation of the Socialist Millionaire Protocol) consists in asking the other end a question whose answer is known only to the two involved parties (e.g. where did we meet for the first time?). The answer doesn't need to have high entropy, since each answer attempt requires interaction from the other end, and thus offline bruteforce is not possible. The answer to this secret is used to confirm the public key's views match. The question can be recovered by an active attacker, the answer remains completely secret, the only information leaking about the answer is whether the other end agrees on the answer or not. The Web of Trust method consists in checking all the friends list of your friends looking for the public key to authenticate. If more then a threshold of friends have the same public key associated to the target user, that public key is deemed authentic. Ideally the shared secret method should be used only during the bootstrap of the user account, when the user has enough friends the web of trust should usually be enough.
We are currently using:
We currently use secp256r1 (P-256) for all the elliptic curve algorithms, and SHA-256 wherever hashing is required.
Curve25519 isn't standard and thus it's not available in WebCryptoAPI.