Yabasta 1.0 Pre-Alpha 2 Released
I have started to look into the Yabasta communication protocol during this week.
I started out with a set of protocol requirements:
- End-to-end security: The protocol must not allow an intermediate entity to read or manipulate communication between end-users. Any communication shall be secure in terms of confidentiality (not understandable to external entities), integrity (any alterations must be detected by the system), and replay protection (copies of previous communications must be identified by the system).
- Usability: The protocol must allow (or even encourage) implementing systems to be intuitive and easy to use. The necessary configuration for end-users should be minimal. Any password credentials needs to be easy to remember. Connections needs to be firewall-friendly.
- Trust: The protocol must allow end-users to establish trust in each others credentials, such as (self-signed) certificates, a shared secrets, or pre-shared keys. Note that the protocol must not require a trust model that is external to the users, such as a Certificate Authority or a web-of-trust.
- Uncentralization: The protocol must allow end-users to be spread out over a federation of servers. Malicious servers must not be able to cause harm to the rest of the network.
- Perfect forward secrecy: The protocol must prohibit any previous communications be revealed if any of the long-lived (private) keys are compromised. It must also be possible to periodically change the decryption (public) keys.
- Forgeability: The protocol must not allow any recipient of communication to prove who produced or sent the message, or that the message has not been faked or altered.
- Upgradeability: The protocol must signal its current version so that new versions of the protocol can be developed. Also, the protocol must be flexible in terms of what algorithms it supports.
- Identity protection: The protocol authentication credentials should not be related to a name, address, or any other information that can be used to link a credential a specific person.
- Extendability: The protocol must allow the data payloads to be arbitrarily extendable in order to allow Yabasta (and compatible software) to expand into other areas later.
- Efficiency: The protocol must perform well in constrained environments (such as smartphones and web browsers).
I have published a first draft of the protocol, which is basically the beginning of a “Jabberization” of the Off-the-Record protocol. I hope that this can be a starting point for discussions about the future protocol of Yabasta. The draft protocol is indeed “quick and dirty”. While it adds somewhat of a possibility to negotiate the Diffie-Hellman primes, it does assume SHA hashing, AES-128-CTR, etc., and is thus not really as extendable or flexible as I would have liked it to be. My current priority, however, is to get Yabasta up and running quickly.
I will now start to focus on making Yabasta.com an actual XMPP client.
David Ammouial - 10/21/2012 ←
Great news!
One thing makes me a bit sad, though: many people have great ideas for a decentralized social network, but can’t seem to merge their ideas together. If you don’t know them already, please check out the following projects: Tent.io, Diaspora, Movim (using the Moxl library for Jabber), Jappix. Do you think it would be possible to bring your ideas to these projects?
Don’t get me wrong: I think it’s great that different projects exist. I only think that we should aim at having only one *protocol* for a given task. What do you think?
David Ammouial - 10/21/2012 ←
Also, about the encryption, a few more ideas: XMPP already uses something called E2E (end-to-end encryption). It’s also possible to use OTR. Several clients already implement one or both of them. There’s also GPG.
Check out Retroshare, too. It’s bot based and XMPP, and is serverless, but uses strong encryption methods. It’s based on SSH and GPG. It has a notion of “identity”, just like Yabasta, and identities are key pairs too, but GPG ones.
Jon Kristensen - 10/22/2012 ←
Hello, David, and thank you for your feedback!
The social networks that you are mentioning in your first post are all great projects. However, I think that Yabasta different enough to warrant to stand on its own. The key difference is that Yabasta is a solution without a smart server; the Yabasta application basically just a static HTML5 application. The logic, the encryption, and the data – it all resides in the client (such as the web browser). The XMPP server just routes the messages; the contents of the messages are not even understandable by the administrators of the XMPP server. Of course, there might be other ways in which we can co-operate, and I would certainly be be open to that.
I did consider the proposed E2E protocols (and GPG) before deciding to go with an approach similar to that of Off-the-Record. The main reason for doing this was to allow for deniability (see the blog post). The key difference between the Yabasta protocol and Off-the-Record is that its negotiated with XML stanzas instead of binary objects, and can be used to protect stanzas of any types (and not just message bodies). I hope that the Yabasta protocol can grow to a general-purpose protocol (perhaps even an XEP, in the future), but at the moment I’m mostly focusing on developing a proof-of-concept application.
I have never heard of Retroshare before. Thank you for bringing it up. I will take a look at it.
Thanks again!
tong - 11/15/2012 ←
for the protocol:
5 failed e2e encryption attempts:
http://mail.jabber.org/pipermail/jdev/2012-November/089240.html
Jon Kristensen - 11/18/2012 ←
Thank you, tong!