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 ground up to be utilized in a decentralized way without such a central entity. Which is why the first problem to address when generating and exchanging a new key needs to be done: “Who will generate the key?” And the answer is of course: “Everyone but hopefully not everyone at the same time because we don’t want to end up with a ton of keys but ideally one.”
So the protocol needs to address who generates the key and when, reducing conflicts and concurrency without putting more trust on one entity than any other. Additionally it is important to setup a way to retrieve or exchange the key but only with the parties that should get access to it, nobody else. Last problem is to reduce traffic as much as possible, so every time a bot, spammer or attacker joins a chat, we don’t start a whole new excessive round of key exchange operations that might never end. Because obviously this can also be an attack vector to starve or at least slow down operations.
So far I’m having fun implementing my ideas and concepts. But I want to be sure they are not completely awful and have bare minimum of testing before I present them here. This will actually be part of my studies. So results are intended to be more scientific than my typical projects which start as idea, go into experimental phase and potentially end up working to some degree. Ideally it may be comparable in many properties to the MLS protocol.
I’ve definitely figured that it makes sense for the service to finally differentiate between public and private chats. Because all those key exchanges to have forward secrecy might not scale well enough for public chats. Also I doubt it would have real benefits in public chats where anyone can join at any time. But at least the private chats will heavily benefit from the added security. I also try to take post compromise secrecy into account which is a concept intended to not leak all future information once there has been a temporary breach. It does require clients to notice or suspect a leak though for functioning from what I understand. So that’s kind of difficult to implement if you take into account that not all users will understand the implications of a data leak, its effects and such.
But the goal is to think of all users, I assume. On the bright side: If the whole thing works for groups of any size, it will work in private chats with only one other contact too.
Kind regards,
Jacki
