View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011535 | GNUnet | messenger service | public | 2026-06-18 00:20 | 2026-06-18 00:20 |
| Reporter | thejackimonster | Assigned To | thejackimonster | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Product Version | Git master | ||||
| Target Version | 1.0.0 | ||||
| Summary | 0011535: Perfect forward secrecy in E2E group chat encryption | ||||
| Description | In current state the messenger service is using group exchanged epoch keys to encrypt messages during every epoch with a different key. Every time a user joins a messaging room or leaves it, a new epoch starts and the previous epoch ends. So new users can't access the encrypted older messages even if they get exchanged across all peers sharing the messaging room in the service since the keys to decrypt them are missing. This provides a form of forward secrecy since users can't easily gain older epoch keys from newer ones. However there currently is still some attack vector based on authentication. Since older messages get exchanged asynchronously and might be delayed for some users, there is a wide time window for specific requests to epoch keys from all users being part of the given epoch. So in case an attacker would gain access to their private identity key used for signing their request messages, they had the option to gain access to an older epoch key from other peers breaking encryption for all messages down the line in worst case. That is why these requests should be prevented. | ||||
| Additional Information | To achieve perfect forward secrecy, a further adjustment would be necessary, as this would also ensure the confidentiality of messages even if the long-term private key were compromised. Clients of the service would have to ignore key requests as soon as they concern older epochs and their epoch keys. Otherwise, after obtaining the long-term asymmetric private key used for signing, an attacker could generate a temporary key pair, sign it, and use it to send a valid request regarding an older epoch key. Such a request would have to be recognized as invalid because the epoch has already ended. A possible exception would be requests from an application belonging to the same user after explicit confirmation, in order to facilitate the use of multiple devices by the same user within the service. If necessary, a different rule might be more precise and appropriate in this case. | ||||
| Tags | No tags attached. | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-06-18 00:20 | thejackimonster | New Issue | |
| 2026-06-18 00:20 | thejackimonster | Status | new => assigned |
| 2026-06-18 00:20 | thejackimonster | Assigned To | => thejackimonster |
