Published: 2013-12-04 13:56:22 by Daniele Ricci

Many weeks have passed since I said I will be releasing a first beta of Kontalk 3.0. Since it obviously hasn't happened yet, I thought it was time for me to write a few lines about the project status.

At the time of writing this post, 13 previews of 3.0 have been released, mostly debug versions. Another preview will be released very soon (probably this evening) with a few fixes.

After that, pre-alpha cycle will end and a first alpha will be released: it will have a first testing version of message encryption using PGP keys, but without OTR.

XMPP version is still missing a few things that need to be addressed before ending the alpha cycle — higher priority tasks are in bold:

  • PGP message encryption
  • user invitation confirmation
  • proper key roll-over
    • compromised key protection
  • legacy protocol (2.x) bridge
  • XMPP stream compression (server-side)
  • XMPP federation (s2s)

I'm currently working on PGP message encryption (androidclient repository, encryptedMsg branch). I hope I can release a first alpha in a few days.
PGP encryption will replace the old symmetric encryption method, meaning that encrypted messages will not be compatible between versions 2 and 3 of Kontalk client.

I'm still not really sure about the legacy protocol bridge. Of course it would allow users from both versions to communicate, but eventually everyone will have to upgrade. What I know for sure is that the old service will be online for a few months after 3.0 release on Play Store. More information about this will come during the beta phase.

Published: 2013-10-26 18:11:16 by Daniele Ricci

Introducing asymmetric encryption has a cost. Because of the decentralized nature of asymmetric keys (i.e. no passwords database), people have to manage their own keys and take responsability for their actions with those keys. This includes losing your device, for example.

If you lose your device and the key pair is inside, the key pair is said to be compromised: anyone using your device will be able to literally impersonate you and encrypt/sign with your former keys. There are a few actions you could take (or have taken):

  • encrypt your keys and ask for a password every time you use Kontalk
  • revoke your keys

The first options is brute-force breakable, so it's not so useful really: it just delays the inevitable.
The second option requires you having a backup copy of your key pair (actually a revocation certificate) and some server to be aware of you wanting to revoke your key pair. Since Kontalk has no concept of permanent key pair storage (it's actually just a cache erasable at any time), even if the rightful owner of the compromised key pair sends a revocation certificate to the server, the server would lose it at the first cache purge, and the "other guy" — the one who found your lost device — can restore it.

To overcome this problem, Kontalk will use this implementation logic: clients can't update their own key pair to the server unless it's the same key (e.g. just a signatures update) or the client has a valid revocation certificate for the key they are about to overwrite. This way, even if there is a cache purge on the server, your new device will be able to overwrite the impostor's key pair.

Of course there is a chance that the impostor succeeds to send a few messages in the meantime: to protect against such cases, the client software will warn users about the inconsistency of the signature on the message.

Published: 2013-07-19 13:36:00 by Daniele Ricci

This extension has been deprecated.

Recently I implemented a first version of public-key driven presence subscription on both server and XMPP client1. The idea is simple: if Alice wants to see Bob's presence and write to him, Bob must sign Alice's public key first — and vice-versa. Server can verify each other's public key signatures and either allow or deny presence subscription and message delivery. This can bring some benefits:

  • server won't need to store roster list — since Kontalk is a roster-less system, this is a very good way to achieve it and store it in a user-controlled way.
  • Many will start to use Web of Trust — PGP web of trust is still confusing to some users; using a system like this can broaden adoption of a decentralized web of trust using open and standard tools.

Here is how the protocol looks like. It's an extension to the normal presence subscription flow.

Alice wants to subscribe to Bob.

<presence id='xk3h1v69'
    to='bob@example.com'
    type='subscribe'/>

Server checks if Alice's public key has been signed by Bob. If that's the case, subscription is accepted immediately: server will reply with presence subscribed.

If Alice's key is not signed by Bob, server forwards the presence subscription request to Bob, injecting Alice's public key:

<presence id='xk3h1v69'
    from='alice@example.com/balcony'
    to='bob@example.com'
    type='subscribe'>
    [Alice's public key]
</presence>

Public key might be included using XEP-0189 with the pubkey element inside the presence stanza.

At this point, Bob can decide to either sign Alice's public key or reject the subscription.

<presence id='xk3h1v69'
    from='bob@example.com'
    to='alice@example.com/balcony'
    type='subscribed'>
    [include Alice's signed public key]
</presence>

Refusal is achieved in the usual way — presence unsubscribed stanza.

Obviously to make this work, both users have to sign each other's key. Eventually servers will use those signatures to check if message delivery and presence subscription are allowed.

I recently proposed this idea to the XMPP standards list but I guess they didn't feel so happy about it — actually they didn't even reply. If anyone has opinions or comments please post them to the mailing list.


  1. androidclient genkeypair branch 

Published: 2013-06-15 16:15:46 by Daniele Ricci

I've just started to contribute to Bouncy Castle to implement RFC 6637. I'm having a few... "difficulties" I hope to solve thanks to the help of BC developers, but I really want to go through it because having elliptic curve keys is very important to Kontalk.

Because of the very small key and signature sizes compared to the actual PGP standards (RSA, DSA, ElGamal) and being much stronger, ECC will be a major part of Kontalk development. The primary benefit of using ECC in Kontalk is key size: having smaller keys means smaller signatures, less bandwidth, less storage capacity for servers (and clients too).

Asymmetric-encryption-driven privacy lists and invitation system will probably require clients to sign or encrypt the list of allowed buddies, probably signing it with each buddy's public key. This could mean a lot, thus a big bunch of data to be exchanged between servers and clients and between servers.

This part is addressed by issues 48, 54 and 55. If you have any ideas please head there and post them, we really need help :-)

Published: 2013-05-30 10:12:37 by Daniele Ricci

Blog is back online! :-) Power supply unit was damaged and I had to order a new one.

A good news for everyone: there will be a new server on the XMPP network soon, but I will introduce it later on another post — when everything will be ready.

Just yesterday, by merging branch gnutlsnet, I introduced OpenPGP-over-TLS serverlink connection and authentication. For now it's just a simple fingerprint-host match, but it's a start for safe Kontalk server-to-server connections. Changes are live on both prime and beta so anybody can just switch server by setting it manually on Kontalk Android client settings (use this notation: kontalk.net|beta.kontalk.net). Remember that fileserver is disabled on beta so you won't be able to send attachments if you are connected to beta (although you can still receive them from other users). It will however be activated soon.

I will release a new Kontalk XMPP Android preview soon, including changes on internal serverlist to include prime, beta and the new server — which doesn't have a name yet :-)