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 their group don’t have to start an own exchange by themselves. So it reduces a lot of potential traffic.

When a new member joins a chat room, all others announce at least their biggest group that is still valid to the new epoch. This mechanism is to reduce the chance of new group formation proposals that would not benefit overall efficiency and therefore should not get accepted.

Also I had to restructure a lot of code because previously the groups depended on the epoch announcements which increased complexity without actual benefits. So now groups and epoch announcements just use separate identifiers while utilizing similar messages for key exchange. But they don’t strictly depend on each other.

Potentially it might even make sense to further make groups independent of epochs. Because that could reduce the overall amount of group keys that need to be stored. While theoretically a group key will invalidate itself anyway as soon as any member of a group leaves the chat room. But I need to investigate whether this might open an attack which I currently don’t see.

Currently a group key will be only used inside its epoch of the group formation and the next epoch might derive a new group key from the old one in case all members are carried on to the next epoch (so in other words, none of them leaves the chat room). As soon as anyone outside a complete group announces to have their key and verifies that via a valid HMAC using the key, a key will be revoked starting new group formation and key exchange. This is already partially implemented but more testing is necessary.

But despite there are still open issues in the implementation and testing, the fundamental key exchange works. There are two working optimizations implemented, either deriving an epoch key from last epoch if allowed or utilizing groups to reduce requests. So it’s really looking good.

Obviously for the chat applications it’s still open how to store and manage all those keys easily without weakening the gained security of the forward secrecy. Likely all group and epoch keys will be stored to a file or database that gets encrypted using the private key from the client applications account or a chosen password. The password would be required if the selected account does not use any own private key to sign and decrypt messages.

This isn’t possible yet in libgnunetchat (having an account without such a unique private key) but technically the Messenger service supports it and I was already looking for a solution to add this feature. Therefore it’s likely I’m gonna implement a solution to both of my open issues in the future. The goal would still be to not introduce any unnecessary friction that hurts usability. But I’m confident that’s possible.

So that’s where I’m at for now.

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: February

Image
Hi there, At the beginning of the month I didn’t think to make that much progress. But now I get the feeling that the GUI client could come to an end next month. Why do I have this feeling? It’s looking really good already, not gonna lie. So as stated in my last update in January, loading older messages needs to be implemented as well as switching accounts during runtime. Now it is. Getting older messages still needs some tweaking to not load all older messages but it’s good enough for now. image of messenger-gtk account selection Switching accounts was more difficult to implement because I had to go back looking into the Messenger service of GNUnet itself, fixing that the service will run as user to make use of the same EGOs as the client side library in multi-user setups. The client side library ( libgnunetchat ) now exposes each of your EGOs as account with name and own directory to store the files and configurations used by the applications. Another benefit of this is tha...
Read more

GNUnet Messenger API: September

Image
Hey, this is the last post under the topic “GNUnet Messenger API”. As mentioned last time I only had a few remaining things to implement in the messenger-cli application. So that is pretty much what I did with some small caveats. The only thing not working as planned is file sharing. Let me explain this: You can already write a file path to your text input and it will send the file. When a file gets received, you can select the message, hit ENTER and download the file. However depending on your GNUnet setup uploading a file might not work. This seems to depend on user access permissions of your selected files. The best work-around I know is to use a single-user installation for GNUnet. But I hope that this can be solved properly, so users don’t have to mess with configurations. More information about this issue can be found here . The second missing part is that you can technically download the file and progress of that will be visualized. However there’s still no opt...
Read more