GNUnet Messenger API: May 2025

Hi again,

to decrease complexity in the account system and key management I decided against separating identity keys from chat accounts and epoch keys for forward secrecy will instead be stored locally using GNS. The keys will be encrypted additionally using a key derived from the private identity key. So only the ownert of this key with storage access will be able to access those epoch and group keys to further access encrypted messages of certain epochs in the message graph.

With those changes I could get rid of bigger API changes in the Messenger service. Key management is completely automatized now, once you provide a private key to the client API. So that makes further implementation a lot easier and it shouldn’t hurt confidentiality.

As next step I want to improve the key exchange in regard to implement perfect forward secrecy. So that in case your long-term identity key gets into hands of an attacker, it’s still impossible to retrieve old epoch keys and access messages exchanged before an attack retrieving the private key.

I’ve also adjusted parts in libgnunetchat to make sure everything is working in the different applications that build on top of it. It will finally store information in the preshared key of Messenger rooms whether this room is public or private, utilizing the new key exchanged to gain forward secrecy. On application level these changes won’t be noticable. But it will fully separate public and private chats long-term.

It will also be possible to mark a chat room via flag as group to check for validity. This should help with consistency and transparency on application level what kinds of chats you have joined or you have received an invitation to. That will allow to mark a direct 1-to-1 private chat as compromised once a third party joins and it will also allow to visualize whether someone invites you to a direct 1-to-1 chat or a group chat. Additionally I’m thinking about adding some meta information to invitations anyway like the title for a group chat. So users can make a very well thought decision before accepting any invitation.

All of this will improve privacy and transparency. However it’s still to consider that every information added to describe a context will allow options for attackers to gain trust via phishing. Which is why I always liked the idea to only separate kinds of chats by technical properties like the amount of members. So I will try to account for such attacks during implementation trying to not misrepresent optional hints for communication contexts as truths but rather opinions.

Kind regards,
Jacki

Read original article

Popular posts from this blog

GNUnet Messenger API: March

Image
Hi again, Last time I had big hopes to make enough progress for a first release. But I think I’m gonna delay that a bit (maybe still this month but we will see) even though I could actually complete the things, I anticipated. However here is finally the long promised video of it running on the Pinephone Pro because there’s still much to show. The back-end of the messenger-gtk application called libgnunetchat now uses the GNUnet Name Store service to manage your chats instead of using a local directory and some configuration files for each chat as before. This means that it is now possible to start the application from any directory and it will properly sync the chats depending on the account/identity selected. Next big feature is that it is possible to generate so called lobbies. Lobbies are empty chat rooms which will be shared in form of a GNS record under a newly generated zone instead of your own identity zone. This has multiple reasons: Technically your own key could ...
Read more

GNUnet Messenger API: July 2025

Image
Hi there, unfortunately I didn’t make it to write a blog post last month. I was quite busy closing open ends of other projects while there were quite some bugs and issues to be solved in the Messenger service of GNUnet . On the bright side this means I have a lot to talk about this month. Most critical issues could be solved already, test cases of libgnunetchat pass again with all latest changes and the end-to-end encrypted chats seem to work as intended. I am still encountering some issues that messages do not get received immediately from chats or the chats can behave somewhat inconsistent. However it’s likely some condition caused by parallel events or a very specific order of events that’s difficult to reproduce. But these issues only seem to appear on reopening old chats from a previous session. The current sessions simply seem to work properly. Invitations do now respond to input feedback all the time and chat types get visualized depending on actual bits in a chat room’s key....
Read more

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 not providing perfect forward secrecy yet. 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 allow...
Read more