Yabasta 1.0 Pre-Alpha 2 Released

10/14/2012 Uncategorized

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.

, , ,

5 Comments

Join the conversation → Add yours

Leave a Reply Please be polite!