@@ -1531,8 +1531,19 @@ For example, Megolm sessions that were sent using the old session would
1531
1531
have been lost. The client can attempt to retrieve the lost sessions
1532
1532
through ` m.room_key_request ` messages.
1533
1533
1534
+ {{% boxes/note %}}
1535
+ Clients should send key requests for unknown sessions to all devices for
1536
+ the user which used the session rather than just the ` device_id ` or
1537
+ ` sender_key ` denoted on the event.
1538
+
1539
+ This is due to a deprecation of the fields. See
1540
+ [ ` m.megolm.v1.aes-sha2 ` ] ( #mmegolmv1aes-sha2 ) for more information.
1541
+ {{% /boxes/note %}}
1542
+
1534
1543
##### ` m.megolm.v1.aes-sha2 `
1535
1544
1545
+ {{% changed-in v="1.3" %}}
1546
+
1536
1547
The name ` m.megolm.v1.aes-sha2 ` corresponds to version 1 of the Megolm
1537
1548
ratchet, as defined by the [ Megolm
1538
1549
specification] ( http://matrix.org/docs/spec/megolm.html ) . This uses:
@@ -1580,10 +1591,36 @@ ratchet index that they have already decrypted. Care should be taken in
1580
1591
order to avoid false positives, as a client may decrypt the same event
1581
1592
twice as part of its normal processing.
1582
1593
1583
- As with Olm events, clients must confirm that the ` sender_key ` belongs
1584
- to the user who sent the message. The same reasoning applies, but the
1585
- sender ed25519 key has to be inferred from the ` keys.ed25519 ` property
1586
- of the event which established the Megolm session.
1594
+ Similar to Olm events, clients should confirm that the user who sent the
1595
+ message corresponds to the user the message was expected to come from.
1596
+ For room events, this means ensuring the event's ` sender ` , ` room_id ` , and
1597
+ the recorded ` session_id ` match a trusted session (eg: the ` session_id `
1598
+ is already known and validated to the client).
1599
+
1600
+ {{% boxes/note %}}
1601
+ As of ` v1.3 ` , the ` sender_key ` and ` device_id ` keys are ** deprecated** . They
1602
+ SHOULD continue to be sent, however they MUST NOT be used to verify the
1603
+ message's source.
1604
+
1605
+ Clients MUST NOT store or lookup sessions using the ` sender_key ` or ` device_id ` .
1606
+
1607
+ In a future version of the specification the keys can be removed completely,
1608
+ including for sending new messages.
1609
+ {{% /boxes/note %}}
1610
+
1611
+ {{% boxes/rationale %}}
1612
+ Removing the fields (eventually) improves privacy and security by masking the
1613
+ device which sent the encrypted message as well as reducing the client's
1614
+ dependence on untrusted data: a malicious server (or similar attacker) could
1615
+ change these values, and other devices/users can simply lie about them too.
1616
+
1617
+ We can remove the fields, particularly the ` sender_key ` , because the ` session_id `
1618
+ is already globally unique, therefore making storage and lookup possible without
1619
+ the need for added context from the ` sender_key ` or ` device_id ` .
1620
+
1621
+ Removing the dependence on the fields gives a privacy gain while also increasing
1622
+ the security of messages transmitted over Matrix.
1623
+ {{% /boxes/rationale %}}
1587
1624
1588
1625
In order to enable end-to-end encryption in a room, clients can send an
1589
1626
` m.room.encryption ` state event specifying ` m.megolm.v1.aes-sha2 ` as its
@@ -1596,6 +1633,11 @@ that they can decrypt future messages encrypted using this session. An
1596
1633
` m.room_key ` events sent by other devices in order to decrypt their
1597
1634
messages.
1598
1635
1636
+ When a client is updating a Megolm session (room key) in its store, the client MUST ensure:
1637
+
1638
+ * that the updated session data comes from a trusted source.
1639
+ * that the new session key has a lower message index than the existing session key.
1640
+
1599
1641
#### Protocol definitions
1600
1642
1601
1643
##### Events
0 commit comments