Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Even though we can't e2e encrypt state events, should we sign them? #227

Open
ara4n opened this issue Jan 28, 2017 · 1 comment
Open

Even though we can't e2e encrypt state events, should we sign them? #227

ara4n opened this issue Jan 28, 2017 · 1 comment
Labels
A-Client-Server Issues affecting the CS API feature Suggestion for a significant extension which needs considerable consideration

Comments

@ara4n
Copy link
Member

ara4n commented Jan 28, 2017

To prevent server admins spoofing them in e2e rooms

@Lapin0t
Copy link

Lapin0t commented Mar 1, 2017

The idea could be extended so that the e2e spec has a "sign-only" mode in which a every event just has a signature field which is simply a detached signature of the event using plain ed25519. Note that to keep forward-secrecy and other olm features, one could use the same double-ratchet as olm/megolm but it would be a bit more complicated. Also notice that this is something that the first solution is something that application can easily do on top of matrix on their own but the second (olm-based) solution would more likely be at the right place if it's included in the e2e spec.

@turt2live turt2live added the feature Suggestion for a significant extension which needs considerable consideration label Jul 19, 2018
@turt2live turt2live added the A-Client-Server Issues affecting the CS API label Feb 6, 2019
@richvdh richvdh transferred this issue from matrix-org/matrix-spec-proposals Mar 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Client-Server Issues affecting the CS API feature Suggestion for a significant extension which needs considerable consideration
Projects
None yet
Development

No branches or pull requests

3 participants