Malicious server admins (aka compromised servers)

Need to ensure unencrypted msgs in encrypted rooms are flagged clearly (given encrypted msgs no longer have badges) --M

Private SSK required to sign new devices

Look at the member list; in future, clients will sign membership events to control room membership

Private SSK required for device to appear 'verified'. Own devices shown in client settings protects against send your own messages to malicious device. Your devices shown to others in your profile to prevent others sending messages to it (?)
(Matthew: we should also track which devices the client is aware of at the client, rather than relying on /devices)

No mitigation? (uhoreg: The homeserver could tell other people about the phony device, but hide it from you. Which means that the attacker wouldn't be able to read messages that you sent, but they would still be able to read messages sent from others.)
(Matthew: we could sign the metadata. If we also track device presence clientside to avoid the server withholding devices, this might help a lot)

Backup signed by master key, devices only write to it if backup sig verified.

Clients won't be able to generate same shared secret (DH) -> untrusted

Two-way verification: users prompted to ensure success on partner's side

other client won't trust my devices then
(invalid signature chain). On login my new session will detect it after verification/passphrase and ask to replace keys

Guarded by authorisation / accept terms?

Guarded by authorisation to open

Guarded by OTKs being signed

Message content protected by e2e

Data from interception by a Global Passive Adversary (GPA)

HTTPS, message content encryption

DNS hijack / reuse attacks

HTTPS X.509 for HS DNS hijack, user key verification prevents DNS resuse being same user (for e2e rooms only)

Only single message at each session index permitted

Unknown keyshare attacks

OTKs signed? User is prompted

Attacks on forward secrecy (i.e. being able to decrypt old messages based on a snapshot of current encryption state)

Ratcheting, although note Element stores all historic keys (but could choose not to store older keys, and instead 'restore' them in on demand)

Interception/interference from cloned devices (e.g. restored from backups)

Attacks on deniability. (e.g. cryptographically speaking, whilst the sender should be authenticated time of sending, there should not be proof in retrospect of their identity. For instance, it could have been a malicious server admin.).

I think we sacrifice this by signing our OTKs?

Timing side-channel attacks.

Passive Attacks on out-of-band verification (e.g. shouldersurfing a QR code or bugging an OOB SAS code)

Two-way verification: users prompted to ensure success on partner's side

I left an opened session on a computer

Can't take control of account (re-auth needed to change pwd, add mail, upload new signing keys)
Can logout session from another session (with re-auth)

Stuff we don’t try to protect against:

Metadata interception by a malicious server admin

Metadata interception by a GPA

Malicious servers withholding messages from being sent to clients or servers

Transcript consistency attacks in general

Attacks on post compromise secrecy within a given megolm session (i.e. being able to decrypt new messages based on a snapshot of current encryption state)

Compromise of megolm keys (via interception on client, or intercepting recovery key/passphrase for an online/offline key backup)

Evil maid or rubber hose attacks on megolm key backup keys/passphrases

Brute force attacks on megolm key backups (offline & online)

Active Attacks on out-of-band verification (e.g. using a speech synthesizer to fake text auth comparison, or an attacker tricking you to showing a screenshot of a compromised QR code on your phone to fake a QR verification)

File size exposure of encrypted attachments to a malicious media repository owner or server admin

Global Passive Adversary

Short Authentication Strings