Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-01-09 09:23:43 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Move section to under Olm stuff

Browse source
This commit is contained in:
Travis Ralston 2019-05-31 11:37:09 -06:00
parent 754b19bb92
commit 57e3b152b0
1 changed files with 25 additions and 25 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

50
specification/modules/end_to_end_encryption.rst
View file

@ -550,31 +550,6 @@ Example:
]
}
Recovering from undecryptable messages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Occasionally messages may be undecryptable by clients due to a variety of reasons.
When this happens to an Olm-encrypted message, the client should assume that the Olm
session has become corrupted and create a new one to replace it.
.. Note::
Megolm-encrypted messages generally do not have the same problem. Usually the key
for an undecryptable Megolm-encrypted message will come later, allowing the client
to decrypt it successfully. Olm does not have a way to recover from the failure,
making this session replacement process required.
To establish a new session, the client sends a `m.dummy <#m-dummy>`_ to-device event
to the other party to notify them of the new session details.
Clients should rate-limit the number of sessions it creates per device that it receives
a message from. Clients should not create a new session with another device if it has
already created one for that given device in the past 1 hour.
Clients should attempt to mitigate loss of the undecryptable messages. For example,
Megolm sessions that were sent using the old session would have been lost. The client
can attempt to retrieve the lost sessions through ``m.room_key_request`` messages.
Messaging Algorithms
--------------------
@ -692,6 +667,31 @@ that it will maintain for each device, and expiring sessions on a Least Recently
Used basis. The maximum number of olm sessions maintained per device should
be at least 4.
Recovering from undecryptable messages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Occasionally messages may be undecryptable by clients due to a variety of reasons.
When this happens to an Olm-encrypted message, the client should assume that the Olm
session has become corrupted and create a new one to replace it.
.. Note::
Megolm-encrypted messages generally do not have the same problem. Usually the key
for an undecryptable Megolm-encrypted message will come later, allowing the client
to decrypt it successfully. Olm does not have a way to recover from the failure,
making this session replacement process required.
To establish a new session, the client sends a `m.dummy <#m-dummy>`_ to-device event
to the other party to notify them of the new session details.
Clients should rate-limit the number of sessions it creates per device that it receives
a message from. Clients should not create a new session with another device if it has
already created one for that given device in the past 1 hour.
Clients should attempt to mitigate loss of the undecryptable messages. For example,
Megolm sessions that were sent using the old session would have been lost. The client
can attempt to retrieve the lost sessions through ``m.room_key_request`` messages.
``m.megolm.v1.aes-sha2``
~~~~~~~~~~~~~~~~~~~~~~~~