revamp key regotiation
you can't do it with discord
This commit is contained in:
parent
c941bee2c6
commit
017024efff
1 changed files with 16 additions and 16 deletions
|
@ -16,14 +16,16 @@ Disclaimer
|
||||||
|
|
||||||
.PP
|
.PP
|
||||||
An OMEMO session can not be fully carried out over Discord due to limitations
|
An OMEMO session can not be fully carried out over Discord due to limitations
|
||||||
of the Discord API.
|
of the Discord API. This paper goes in more detail on overcoming such
|
||||||
|
limitations using a third-party.
|
||||||
|
|
||||||
.NH
|
.NH
|
||||||
Key negotiation / distribution
|
Key negotiation / distribution
|
||||||
|
|
||||||
.PP
|
.PP
|
||||||
Negotiating keys and prekeys in OMEMO use the User's originating XMPP server and
|
Negotiating keys and prekeys in OMEMO use the User's originating XMPP server for
|
||||||
XEP-0163: Personal Eventing Protocol to signal device key changes.
|
key storage and XEP-0163: Personal Eventing Protocol to signal device
|
||||||
|
key fetches and changes.
|
||||||
|
|
||||||
.PP
|
.PP
|
||||||
Discord does not provide any semantics to what XEP-0163 provides, so
|
Discord does not provide any semantics to what XEP-0163 provides, so
|
||||||
|
@ -34,20 +36,18 @@ talking with who, and so, extra care must be given to implementations going down
|
||||||
such paths.
|
such paths.
|
||||||
|
|
||||||
.PP
|
.PP
|
||||||
The second approach is leveraging the existing Discord protocol to provide, at
|
.nr step 1 1
|
||||||
least, key fingerprint material. Such an approach
|
Another approach would be leveraging existing Discord mechanics to provide key
|
||||||
.I "could"
|
fingerprint material to the users via client profiles, however such an approach
|
||||||
involve the existing user profiles, and the fact that you can make a League of
|
would not work because:
|
||||||
Legends entry without verification. USER_UPDATE events would be dispatched
|
|
||||||
when such device keys change.
|
|
||||||
|
|
||||||
.PP
|
.IP \n[step] 2
|
||||||
If implementations go down the second approach, they could embed the key
|
The maximum size for profile entries is too low to fit key material.
|
||||||
material inside the entries as well, but that might prove itself difficult,
|
|
||||||
as there is a limit to how much you can insert on an entry. Same thing applies
|
.IP \n+[step]
|
||||||
to the key fingerprints. Implementations should consider compressing. They
|
Discord does not send USER_UPDATE events when those change. The client would
|
||||||
should also consider a separate key server to give keys based on the key
|
need to send a DM to every user about the key change, so that the other users
|
||||||
fingerprints so conversation can carry on.
|
fetch the new user profile with the new keys.
|
||||||
|
|
||||||
.NH
|
.NH
|
||||||
Key verification
|
Key verification
|
||||||
|
|
Loading…
Reference in a new issue