Merge branch 'matthew/define-secrecy' into 'master'

### Lack of Backward Secrecy

Once the key to a Megolm session is compromised, the attacker can decrypt any

future messages sent via that session.

[Backward secrecy](https://intensecrypto.org/public/lec_08_hash_functions_part2.html#sec-forward-and-backward-secrecy)

(also called 'future secrecy' or 'post-compromise security') is the property

that if current private keys are compromised, an attacker cannot decrypt

future messages in a given session.  In other words, when looking

**backwards** in time at a compromise which has already happened, **current**

messages are still secret.

By itself, Megolm does not possess this property: once the key to a Megolm

session is compromised, the attacker can decrypt any message that was

encrypted using a key derived from the compromised or subsequent ratchet

values.

In order to mitigate this, the application should ensure that Megolm sessions

are not used indefinitely. Instead it should periodically start a new session,

### Partial Forward Secrecy

Each recipient maintains a record of the ratchet value which allows them to

decrypt any messages sent in the session after the corresponding point in the

conversation. If this value is compromised, an attacker can similarly decrypt

those past messages.

[Forward secrecy](https://intensecrypto.org/public/lec_08_hash_functions_part2.html#sec-forward-and-backward-secrecy)

(also called 'perfect forward secrecy') is the property that if the current

private keys are compromised, an attacker cannot decrypt *past* messages in

a given session. In other words, when looking **forwards** in time towards a

potential future compromise, **current** messages will be secret.

In Megolm, each recipient maintains a record of the ratchet value which allows

them to decrypt any messages sent in the session after the corresponding point

in the conversation. If this value is compromised, an attacker can similarly

decrypt past messages which were encrypted by a key derived from the

compromised or subsequent ratchet values. This gives 'partial' forward

secrecy.

To mitigate this issue, the application should offer the user the option to

discard historical conversations, by winding forward any stored ratchet values,