View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010716 | GNUnet | messenger service | public | 2025-12-04 09:26 | 2026-01-17 04:12 |
| Reporter | thejackimonster | Assigned To | thejackimonster | ||
| Priority | normal | Severity | tweak | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Product Version | 0.27.0 | ||||
| Target Version | 1.0.0 | ||||
| Summary | 0010716: Key separation for encryption of messages in messenger service | ||||
| Description | Since there is already a thread on mattermost, I wanted to open this issue for tracking it. Currently the messenger service is using the private identity keys (or blindable keys) to derive a key pair used for encrypting/decrypting private messages. In practice these should only contain invitations (which don't contain sensitive information) to other chat rooms but technically this isn't limited to those kinds of messages. To change this the idea is to use a fully separate key pair for encryption than for signatures. So in case an attacker gains access to the identity key, they will not gain access to any encrypted messages. Question is how to store such a key pair, how often should it rotate and depending on storage of it, how would it be encrypted to protect access against an attacker. Since if an attacker would be able to gain access to an identity key (which is only stored locally on device), additional encryption seems necessary. | ||||
| Steps To Reproduce | - | ||||
| Additional Information | Most changes are already implemented on my development branch. It generates a separate key pair every time a user joins a chat room via client and publishes the public key inside join- and key-messages. Those key pairs might rotate too often that way but I think that needs further practical testing. They current keys as well as previous ones are stored via the namestore only locally using the identity key but all keys are stored in an encrypted form. For the encryption of those records I derive a secret from the private identity key currently. That's not ideal but I wanted to avoid user selected passwords for now. However I'm thinking about using libsecret to either select or generate a secret on application level that can be passed towards the service automatically. So users don't need to enter a password every single time they open and close the application. I'm just not sure yet whether libsecret should be integrated into libgnunetchat or gnunet itself. I would also adjust the current code for storing the group and epoch keys in the messenger service to use such a secret as well for encrypted storage. Because those keys actually protect more sensitive information in practice. They are currently encrypted using a secret derived from the private identity key as well. | ||||
| Tags | No tags attached. | ||||
|
|
The current implementation expects applications to provide a char-array of dynamic length to libgnunetchat for connection with an account. The client-side library will only hash that and provide the result to the messenger service which uses that hash as partial secret for key derivation, decrypting group, epoch and private keys. That way applications can either choose to have a manual password input for users per account or using libraries like libsecret storing such a secret. I've implemented examples for this in messenger-gtk and messenger-cli using libsecret. Other tools in the terminal expect manual input as argument by the user. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-12-04 09:26 | thejackimonster | New Issue | |
| 2025-12-04 09:26 | thejackimonster | Status | new => assigned |
| 2025-12-04 09:26 | thejackimonster | Assigned To | => thejackimonster |
| 2026-01-17 04:12 | thejackimonster | Note Added: 0027266 |
