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 depth in an epoch. The depth is either zero if the group is formed by two members or equal to the depth of any of its subgroups plus one. That way a tree structure is built from the bottom (leaves) to the top (root). However the root is actually the epoch itself.

Each group will have its own symmetric key that all members of a group will have access to. Members of a group are either the two epoch members which formed the group or all members from both of its subgroups. The reason for all of this additional abstraction is that such a tree structure allows to reduce future key exchange messages quite a bit.

If any member leaves the chat now, it is only necessary to exchange a newly generated key with log(N) of the formed groups in this tree structure instead of N. These log(N) groups are the ones from the previous epoch which did not contain the specific contact that left the chat as member. Other groups get dissolved and the tree structure will require new groups to be formed for completion.

There are currently still issues with the implementation. It’s definitely not trivial to manage the whole group formation process when all clients participate in a decentralized way. But I’m confident to solve remaining issues.

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