#keyoxide 0.4 has just launched! Small update but a huge increase in benefit for users 🎉
You can now add #omemo fingerprints to your #xmpp identity proofs and if the proof is verified, you'll get a QR code which automagically trusts your OMEMO keys upon scanning with the #conversations app!
Blog post with details and an example: https://yarmo.eu/post/keyoxide-xmpp-omemo
Smart Picture Frame - "Unexpected"-Edition!
Built using a #raspberrypi and an IKEA picture frame :)
A keen self-hoster writes about the new voice/ video calling features in Conversations:
Looking for a job where you can work with #XMPP?
Or perhaps you're looking to employ someone with XMPP skills?
Looking for XMPP service providers?
We've got you covered at http://xmpp.work!
Check out https://xmpp.work
XMPP@home - 9 June 2020
The XMPP Newsletter covering the month of May 2020.
During our next (virtual) XMPP meetup on Wednesday, 18:00 CEST, Daniel Gultsch and me will give an introduction to the technologies used for A/V calls with XMPP. Topics discussed will include Jingle, ICE/STUN/TURN, (S)RTP, and WebRTC. The meetup will take place on Jitsi Meet, see:
We'll also be streaming this meetup live to YouTube, so if you participate, you will be recorded. If you'd prefer to just listen, please use the YouTube stream:
What's up with K-9 Mail?
The release of the latest stable version of K-9 Mail was in September 2018, nearly two years ago. So, of course, many of you have been wondering if K-9 Mail is dead. I’m happy to inform you that [it’s] not the case. Work on K-9 Mail was slow at times, but has never really stopped.
On parle de l’avancement du projet, des problèmes avec les conditions requises par G.Play, refonte de l’interface… et une version bêta !
E2EE scheme that's under consideration for Mastodon
(First, I'm talking from my perspective and not on behalf of Eugen or the Mastodon project)
There's still a long way to go, but we're working on providing end-to-end encryption of chat-like messages in Mastodon.
The cryptographic protocol we're considering is basically that used in XMPP's OMEMO, Signal, and part of Matrix (part of Matrix, because Matrix also features another protocol, that provides weaker security but is much more efficient in group chats).
Like Matrix and OMEMO, your server will still know who you're talking with and when (Signal does manage to avoid that to a great extent).
There's one feature we are discussing that I want to talk about a bit: message franking. It's a scheme designed by Facebook to enable the receiver of a message to report it to their server without revealing other messages in the process.
Basically, it works by having the sender hash (using HMAC) the message with a key they generate just for signing that single message. They then encrypt that key together with the message. So, the hash is visible to the server, but not the message nor the key. So it cannot, at that point, be verified by the server or infer anything about the message or key.
The server then takes note of the hash, and who sent the message to whom. It then signs that note with its own key (that key can be private, it's not important). It could also encrypt it. Nobody but the server needs to be able to read and verify it, but it's also not super important if anyone else can.
Then the server gives that signed note, along with the message, to the receiver, and forgets about it.
Upon receiving the message, the receiver performs the usual checks, but now, it has the message and the HMAC key, so it is able to verify the HMAC hash. If the HMAC hash is invalid, that means the sender lied, and he won't be able to report it. So the receiver just discards it (it could display an error message to the user, but that's not important). Otherwise, the receiver can report it. How? By sending the message, along with the HMAC key and the signed note back to the server.
The server first decode/decrypts the note, verifies its signature so that it can be sure that it indeed made that note, and then, since it has the HMAC key, can finally check the HMAC hash and verify that the reported message is indeed the message that was sent.
To lie about the reported message, you'd have to find another message and another key that match the hash, which is exactly what the HMAC algorithm tries to make impossible, and for which there are no known attack to this day.
Since you need the key and the message, on its own, the key does not let you learn anything about the message. If you were almost sure you knew the message, you'd still need the key to verify it.
According to a paper (https://eprint.iacr.org/2017/664.pdf)—which I'm going to trust here, I intuitively understand the reasoning, but I don't have enough knowledge to be completely sure about it, the message franking construction isn't even needed because the underlying protocol already has the same properties, if you reveal just the right key. This means adding message franking doesn't make the deniability of the protocol actually weaker. Adding it just makes it easier to implement and also makes sure that you disclose exactly the message you were reporting and not a few more (the alternative would be to reveal the input to the key derivation function for one message, but it could be used for more than one message, although it would usually be a short amount of messages)
Sind diese Vier (neben einigen wenigen Anderen) diejenigen, die unsere Demokratie am ehrlichsten vertreten? #Herzchensmiley https://twitter.com/MartinSonneborn/status/1265691583518818311
During this year's Google Summer of Code, Anmol will implement optional real-time texting in Dino. Real-time text means that text is transmitted and displayed to the receiver while it is being typed. Anmol will write about his progress here: https://wolfieanmol.github.io/gsoc-blog/ #Dino #XMPP #GSoC
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.