Removed access-group members can still decrypt all future group messages

[sungkhum]

Repos affected: deso-protocol/core, deso-protocol/backend, deso-protocol/identity
Severity: Medium — silent privacy expectation gap. No funds at risk; no protocol invariant violated. Affects every app built on access-group messaging (deso-chat, ChatOn, any third-party messenger).
Reporter context: Surfaced while documenting group-chat behavior in a third-party DeSo messenger. Filing here because the root cause sits below the application layer — no app-side patch can fix it.

Summary

When the owner of an access group calls removeAccessGroupMembers, the removed member loses their on-chain AccessGroupMember entry and disappears from the members list. However, they retain the cryptographic ability to decrypt every future message posted to that group. This is the combined effect of three independent design choices, each reasonable in isolation:

1. Access-group keypairs are deterministically derived from the group's AccessGroupKeyName, so the key cannot be rotated without changing the group's identity.
2. removeAccessGroupMembers deletes the member's encrypted-key entry but does not regenerate the underlying access-group keypair or re-key the remaining members.
3. GetPaginatedMessagesForGroupChatThread (and the equivalent UtxoView lookup for self-hosted nodes) does not check whether the caller is a current group member — it returns ciphertext for any access group ID the caller can name.

Most users — and most apps building on this — assume "remove member" implies "remove access." It does not. It only revokes UI-level discoverability.

Steps to reproduce

1. User A creates an access group myGroup and adds users B, C as members.

2. B opens any DeSo messenger that exposes the access-group key (or simply re-derives it via identity.accessGroupStandardDerivation('myGroup') — the derivation is deterministic).

3. A removes B from the group via removeAccessGroupMembers.

4. A and C continue posting NewMessage transactions to the group.

5. B (now removed) calls GetPaginatedMessagesForGroupChatThread against any DeSo node:

   await getPaginatedGroupChatThread({
     UserPublicKeyBase58Check: A_OWNER_PUBKEY,   // public
     AccessGroupKeyName: 'myGroup',              // public
     MaxMessagesToFetch: 1000,
   });

6. B decrypts the returned ciphertext using the same shared key they had as a member. All messages sent after the removal are readable.

No special tools needed. No custom node. Standard deso-protocol SDK calls against a public node.

Root cause: code references

1. Deterministic key derivation — deso-protocol/identity

accessGroupStandardDerivation(groupKeyName) returns the same keypair for the same name across all calls. There is no nonce, no epoch, no per-instantiation salt. Two consequences:

• A removed member who knows the group name can re-derive the access-group private key without ever having exfiltrated it.
• An owner who wanted to "rotate" the key has no way to do so within the same group identity.

2. No re-keying on member removal — deso-protocol/backend (and on-chain in core)

removeAccessGroupMembers accepts the list of AccessGroupMember entries to delete. It removes those entries from state. It does not:

• Generate a new access-group keypair
• Re-encrypt and re-publish the new key for remaining members
• Mark the old key as superseded for downstream consumers

This is consistent with how the transaction is documented (it's billed as a member-management operation, not a key-rotation operation), so I'm flagging it as a design gap rather than a bug in the handler.

3. Public read access to group ciphertext — deso-protocol/backend/routes/new_message.go:689

func (fes *APIServer) GetPaginatedMessagesForGroupChatThread(ww, req) {
    // Decode JSON body
    // Validate UserPublicKeyBase58Check + AccessGroupKeyName parse
    // Build accessGroupId
    // Return utxoView.GetPaginatedMessageEntriesForGroupChatThread(...)
}

No signature verification. No membership check against the current AccessGroupMember set for the requested AccessGroupId. The UserPublicKeyBase58Check parameter is the group owner's key, not a credential identifying the caller. Self-hosted nodes inherit the same property at the UtxoView level.

This is reasonable as a default — it matches the rest of DeSo's "everything is public, encryption is the gate" philosophy — but it leaves no defense-in-depth when the encryption gate is itself stuck open.

Why this matters

End-user expectation, drawn from every centralized messenger: "kicking" someone from a group prevents them from reading future messages. Apps built on access groups inherit DeSo's behavior whether they realize it or not. The mismatch shows up in the worst possible way: the user trusts the kick, the app shows the kick succeeded, and the removed party silently keeps reading.

A few specific impact paths:

• Personal: ex-partner / former friend removed from a family or friend group continues reading
• Workplace: terminated employee removed from a project group continues reading post-termination discussions
• Community/moderation: banned user continues reading mod-only or appeals discussions
• Compliance: any "right to remove access" guarantee an app makes is unenforceable at the protocol level

Possible mitigations (sketch — happy to discuss)

These are not equally good; listing in increasing protocol-invasiveness:

1. Documentation-only. Add a clear note to the access-group section of the docs and the deso-js SDK: "Removing a member does not prevent them from decrypting future messages. To revoke decryption ability, create a new access group with a different AccessGroupKeyName and migrate remaining members." Apps can surface this in their UI.

2. Convention for app-level rotation. Establish a convention where AccessGroupKeyName includes a versioned suffix (e.g., myGroup-v2), and removal triggers app-side migration to the next version. Painful UX but possible without protocol changes. Would benefit from a helper in deso-js.

3. Optional access control on GetPaginatedMessagesForGroupChatThread. Allow an opt-in mode where the endpoint requires a signed request from a current AccessGroupMember. Doesn't help against self-hosted nodes (the data is still on-chain) but materially raises the bar for casual abuse. Would need careful thought about how it interacts with backup/restore and cross-app reads.

4. Protocol-level rekey transaction. A new transaction type that updates the access-group's underlying keypair (decoupling group identity from key derivation), with re-encrypted key copies for current members. This is the only option that delivers the user expectation faithfully, but it's a significant protocol surface change.

I'd love to know which (if any) of these the team thinks is on the table, and whether there's existing thinking I missed.

Environment

• DeSo backend: main as of 2026-04-16
• deso-js: latest
• Reproduced against node.deso.org (public node)
• Originally surfaced via deso-chat and getchaton.com source review