GNUnet Messenger API: November 2025
Hey again,
this month a few changes in GNUnet rolled out that would rename keys from its identity service to make clear they are blindable asymmetric keys. So I updated libgnunetchat to keep building against it. Additionally it was suggested that services like the messenger service in GNUnet should stop using those keys for HPKE (hybrid public key encryption) directly by deriving a keypair from the identity key. Instead it should use a separate key pair only for HPKE but signed by this blindable identity key.
The advantage is pretty obvious. The least a keypair is reused for encryption purposes, the lower is the chance to reverse engineer the private key using samples of such encryption. The disadvantage is that such separate keys need to be stored additionally, exchanged between multiple devices by the receiver to decrypt private messages. So in simple terms: It makes everything a bit less efficient and more complex.
But since I’d already implemented storing symmetric keys for the forward secrecy in the messenger service, it seemed reasonable to approach this change. So I implemented the necessary changes which break protocol but since the service is still in heavy development, that’s nothing unexpected at the moment.
Everything works like this now: Once a user enters a chat or replaces their identity key, they will publish two public keys. The first one is from their identity key pair. The second one is from the new HPKE key pair, only intended for private encrypted messages (like invitations to other chat rooms for example). The second key might change more frequently than the first one.
The implementation does not enforce a specific encryption algorithm, similar as with the identity keys but currently only X25519 keys are supported for HPKE in GNUnet. The changes are not fully merged upstream yet because I’m still thinking about how to encrypt those key pairs locally in storage. Technically it should be fine to encrypt them using a derived secret from the identity key. But having an independent secret would increase security further in case of an attacker optaining the private identity key. So such an attack would only risk temporal identity theft but not providing the attacker access to private messages.
The reason why I’m still hesistant adding an independent secret (for example a user selected password) for securing against such attacks is that it should be really unlikely if the attacker has no direct access to the victims device (physically or remotely) in which case the attacker would likely be able to log keys or socially engineer gaining access to the required secret anyway. At the same time entering passwords every time you launch an application is quite annoying and I would consider annoyance to be a big risk as well. Since how does an application protect your messages if people won’t use it?
Which is exactly why I’m considering the usage of libsecret to store the secret for the messenger applications later on. But that would require more changes in libgnunetchat and the client side of the messenger service. However I don’t have a ton of free time until January. So I assume you will read about it first next year. Until then I wish you happy hollidays!
Kind regards,
Jacki
