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 accounts in libgnunetchat to use the shared anonymous key as long-term key. For this there need to be implemented some exceptional management of key exchange messages. So users with this anonymous key try to avoid making requests with their compromisable signature and instead rely on pre-exchanged symmetric keys from older key exchanges if possible. Additionally since epoch keys need further key management on account basis anyway, the messenger service could start using unique asymmetric keys for signatures per room basis signed by their long-term key. That way less signatures would be made using the same key, replacing keys would cause less friction internally and the private key from the identity service would not need to be shared with the client-side of the messenger service.

All of this could be merged with planned changes in the account management in libgnunetchat. Because I want to separate identity keypairs from the actual accounts. So you can have more private keys in the identity service than accounts and you can have more accounts than unique private keys. Accounts will just refer to a private key if desired. Which will ultimatively allow using attributes via reclaimID and GNS entries. However a lot of the internal details which require all of this currently, could be simplified.

So far about all of my future ideas. There has also been a new release of GNUnet 0.24.0 and libgnunetchat 0.5.3 to stay compatible. Meson is getting the default build system for GNUnet. There’s still ongoing work in the new core layer of GNUnet and NLnet announced to fund efforts bringing GNUnet on Android which includes the goal to port the GNUnet messenger application to this platform. Which features will be supported exactly across all different applications and front-ends is still an open question. But it would be neat to see these efforts speed up bringing GNUnet in the palm of your hands.

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