Posts

GNUnet Messenger API: March 2025

Hello again, since last month I tried to optimize the mechanism of forward secrecy further and indeed I was able to reduce the amount of messages required for a whole key exchange in a new epoch. So rather than scaling N scare if N is the amount of epoch members, it seems to scale linear now. That is quite an improvement but there’s still room for more adjustments. For example I realized recently that the current implementation is now providing perfect forward secrecy. That means if your long-term private key (the identity key to sign messages) gets compromised, an attacker might still be able to access messages from older epochs by request its keys from others. So to mitigate this, it will require changes that restrict requests of older epoch keys much more. Additionally deriving epoch keys via KDF could be adjusted to make it much more difficult to brute-force any epoch key from messages with HMAC using keys from the KDF. Once that’s done, there’s still work to do for allowing ...

GNUnet Messenger API: February 2025

Image
Hi again, My progress on the forward secrecy in the Messenger service of GNUnet is coming to a state where I have proper testing and results. You can find the current state of tests and benchmarks in a development branch of libgnunetchat which utilize a new ping tool for the Messenger service. The tool sends a TEXT message into a selected chat room and waits for other clients using the same tool but acting as receiver to send a TAG message back choosing the TEXT message as target. As a result the sender will measure and print out the delay between sending and receiving the response. Like that it’s possible to measure latency added via the implemented forward secrecy as well as its key exchange mechanism. The results so far are a mixed bag to be honest. Good news is that latency and general cost by symmetric encryption is negligible once the key for an epoch is exchanged. However bad news is that the amount of messages required for a proper key exchange as well as group formation...

GNUnet Messenger API: January 2025

Hello there, so I got some news for you again regarding my progress on the GNUnet Messenger service as well as the applications. Because there has been a GNUnet release last month which made libgnunetchat and the messenger applications using it incompatible, I needed to implement some changes, fixes and announced a new release . The forward secrecy I’m implementing in the Messenger service of GNUnet is still on development branch though. It will take some time until those changes are ready for release. But I got quite a bit of progress. The members of a chat actually start building groups, exchanging keys to form a tree structure as suggested in my last post from December . If any member of such a group is missing an epoch key, they will delay depending on their position inside their group the appeal for the missing key to then authorize the whole group after gaining access. This way ideally just one member will send an appeal, receive access, send an authorization and the rest of ...

Development in 2024

Hey everyone, welcome to my yearly recap of the year 2024. What happened? What did I work on? Well, quite a lot actually. So let’s start with the biggest project and continue from there. The GNUnet Messenger got funding from NLnet again as I mentioned in the end of last year. The new goal was to improve usability and add new features. What features are we talking about exactly? My concept was to achieve feature parity with most popular messaging apps but sticking to a decentralized context. For example I wanted to add profile pictures. But we can’t simply upload image files to a profile picture server/provider and poll from there for any new contact we get. So the solution required a bit of hacking around in the back-end. I used reclaimID from GNUnet to allow users sharing personal information with selected contacts of their choice and profile pictures may be such personal information for example. That means we can upload encrypted image files to a decentralized file sharing ser...

GNUnet Messenger API: December 2024

Hello, last month I’ve started to mention that I began to implement forward secrecy into the Messenger service of GNUnet . The fallback for key exchange in an epoch of messages is already working. Senders of messages will generate a new key just in time and announce it. Other members of that chat epoch will appeal the new key if missing and potentially gain access if allowed. As a way to improve key exchange further I’ve utilized a key derivation function to generate new epoch keys from ones of the previous epoch if and only if all members of the previous epoch are members of the new epoch (for example in case a new member has joined the chat). Otherwise a full exchange of a new and independent key is required to avoid access leakage to previous members that already left the chat. The last remaining step to improve efficiency further requires the setup of groups (or subgroups) inside an epoch. Those groups will either be formed by two members of an epoch or two groups of the same...

GNUnet Messenger API: November 2024

Hey again, It has been a few months since I last posted here since I finished my major project of the video and audio chat in the GNUnet Messenger application . I took a short break and now I’m working on a completely different part in the service again. So not a lot of visual progress but technical details to brag about. The plan is to finally implement proper forward secrecy into the Messenger service in GNUnet . So a theoretical attacker can not access or read messages posted prior to their event joining a group chat. This is ensured by encrypting the content of messages with a key that changes every time, a client joins or leaves a chat. Additionally because chains of events can diverge in the Messenger service a merge event of two message chains that use different keys will also cause a new key generation and exchange. The big problem I’m trying to solve is how to make this most efficient without relying or trusting a central entity. Because the whole service is designed from ...

GNUnet Messenger API: August 2024

Image
Hi again, as mentioned last time when talking about the user interface for discourses, I was looking into the implementation of video streaming this time. For this task I wasn’t really able to workaround using RTP or something comparable. So I tried looking into it again with success. The problem I had with it previously was actually related to me overlooking the structure GstRTPBuffer in the documentation of GStreamer . With that I was able to calculate the actual durations of each buffer. I could simplify the code handling video and audio streams into one with only some variables like datarate which differ. But overall it worked for RTP via both rtpL16pay and rtph264pay nodes. So I could transfer H.264 encoded video via GStreamer now without major issues. However one thing I needed to solve was getting encoding done on many different platforms and form factors. Because not every SoC or device offers hardware encoding and decoding which is preferable though reducing power cost ...