From 6d80d934cd3727f2fec320e722124562ffb7dd21 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Wed, 28 Sep 2016 18:49:56 +0100 Subject: typo --- docs/megolm.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/megolm.rst') diff --git a/docs/megolm.rst b/docs/megolm.rst index 7853963..2ea0b94 100644 --- a/docs/megolm.rst +++ b/docs/megolm.rst @@ -27,7 +27,7 @@ The Megolm ratchet is intended for encrypted messaging applications where there may be a large number of recipients of each message, thus precluding the use of peer-to-peer encryption systems such as `Olm`_. -It also allows a receipient to decrypt received messages multiple times. For +It also allows a recipient to decrypt received messages multiple times. For instance, in client/server applications, a copy of the ciphertext can be stored on the (untrusted) server, while the client need only store the session keys. -- cgit v1.2.3 From 63800ad8e61ebdfa756d8bde8466b70337b85d67 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Sun, 2 Oct 2016 00:47:29 +0100 Subject: s/PCKS/PKCS/ --- docs/megolm.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/megolm.rst') diff --git a/docs/megolm.rst b/docs/megolm.rst index 2ea0b94..1f04840 100644 --- a/docs/megolm.rst +++ b/docs/megolm.rst @@ -143,7 +143,7 @@ copy of the counter, ratchet, and public key. Message encryption ~~~~~~~~~~~~~~~~~~ -This version of Megolm uses AES-256_ in CBC_ mode with `PCKS#7`_ padding and +This version of Megolm uses AES-256_ in CBC_ mode with `PKCS#7`_ padding and HMAC-SHA-256_ (truncated to 64 bits). The 256 bit AES key, 256 bit HMAC key, and 128 bit AES IV are derived from the megolm ratchet :math:`R_i`: @@ -285,6 +285,6 @@ Version 2.0 `_. .. _`SHA-256`: https://tools.ietf.org/html/rfc6234 .. _`AES-256`: http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf .. _`CBC`: http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf -.. _`PCKS#7`: https://tools.ietf.org/html/rfc2315 +.. _`PKCS#7`: https://tools.ietf.org/html/rfc2315 .. _`Olm`: ./olm.html .. _`Protocol Buffers encoding`: https://developers.google.com/protocol-buffers/docs/encoding -- cgit v1.2.3 From df04cd509a13fb1a3c8b953de4f987b15fcde9b1 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Wed, 19 Oct 2016 19:16:23 +0100 Subject: Add notes on limitations to megolm spec --- docs/megolm.rst | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 65 insertions(+), 4 deletions(-) (limited to 'docs/megolm.rst') diff --git a/docs/megolm.rst b/docs/megolm.rst index 1f04840..4929349 100644 --- a/docs/megolm.rst +++ b/docs/megolm.rst @@ -199,9 +199,9 @@ session. In order to maintain the ability to decrypt conversation history, inbound sessions should store a copy of their earliest known ratchet value (unless they -explicitly want to drop the ability to decrypt that history). They may also -choose to cache calculated ratchet values, but the decision of which ratchet -states to cache is left to the application. +explicitly want to drop the ability to decrypt that history - see `Partial +Forward Secrecy`_\ ). They may also choose to cache calculated ratchet values, +but the decision of which ratchet states to cache is left to the application. Data exchange formats --------------------- @@ -269,7 +269,68 @@ protocol). The MAC protects all of the bytes preceding the MAC. The length of the signature is determined by the signing algorithm being used (64 bytes in this version of the protocol). The signature covers all of the -bytes preceding the signaure. +bytes preceding the signature. + +Limitations +----------- + +Lack of Transcript Consistency +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In a group conversation, there is no guarantee that all recipients have +received the same messages. For example, if Alice is in a conversation with Bob +and Charlie, she could send different messages to Bob and Charlie, or could +send some messages to Bob but not Charlie, or vice versa. + +Solving this is, in general, a hard problem, particularly in a protocol which +does not guarantee in-order message delivery. For now it remains the subject of +future research. + +Lack of Backward Secrecy +~~~~~~~~~~~~~~~~~~~~~~~~ + +Once the key to a Megolm session is compromised, the attacker can decrypt any +future messages sent via that session. + +In order to mitigate this, the application should ensure that Megolm sessions +are not used indefinitely. Instead it should periodically start a new session, +with new keys shared over a secure channel. + +.. TODO: Can we recommend sensible lifetimes for Megolm sessions? Probably + depends how paranoid we're feeling, but some guidelines might be useful. + +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. + +To mitigate this issue, the application should offer the user the option to +discard historical conversations, by winding forward any stored ratchet values, +or discarding sessions altogether. + +Dependency on secure channel for key exchange +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The design of the Megolm ratchet relies on the availability of a secure +peer-to-peer channel for the exchange of session keys. Any vulnerabilities in +the underlying channel are likely to be amplified when applied to Megolm +session setup. + +For example, if the peer-to-peer channel is vulnerable to an unknown key-share +attack, the entire Megolm session become similarly vulnerable. For example: +Alice starts a group chat with Eve, and shares the session keys with Eve. Eve +uses the unknown key-share attack to forward the session keys to Bob, who +believes Alice is starting the session with him. Eve then forwards messages +from the Megolm session to Bob, who again believes they are coming from +Alice. Provided the peer-to-peer channel is not vulnerable to this attack, Bob +will realise that the key-sharing message was forwarded by Eve, and can treat +the Megolm session as a forgery. + +A second example: if the peer-to-peer channel is vulnerable to a replay +attack, this can be extended to entire Megolm sessions. License ------- -- cgit v1.2.3 From 8c4a11a92d2eac501e06659dff062d84d5c855ec Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Fri, 21 Oct 2016 15:13:20 +0100 Subject: Document the potential for message replays and possible mitigations --- docs/megolm.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'docs/megolm.rst') diff --git a/docs/megolm.rst b/docs/megolm.rst index 4929349..56e5f1d 100644 --- a/docs/megolm.rst +++ b/docs/megolm.rst @@ -274,6 +274,16 @@ bytes preceding the signature. Limitations ----------- +Message Replays +--------------- + +A message can be decrypted successfully multiple times. This means that a MITM +server can send multiple copies of a message and they will successfully decrypt. + +To mitigate this it is recomendend that applications track the message indicies +they have recieved and that they reject messages with indicies that they've +already decrypted. + Lack of Transcript Consistency ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.2.3 From 0a7d4e35ccee89c34adeb03b112d243a27326fda Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Fri, 21 Oct 2016 15:44:53 +0100 Subject: Reword and s/message index/ratchet index/ --- docs/megolm.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'docs/megolm.rst') diff --git a/docs/megolm.rst b/docs/megolm.rst index 56e5f1d..0994100 100644 --- a/docs/megolm.rst +++ b/docs/megolm.rst @@ -277,12 +277,13 @@ Limitations Message Replays --------------- -A message can be decrypted successfully multiple times. This means that a MITM -server can send multiple copies of a message and they will successfully decrypt. +A message can be decrypted successfully multiple times. This means that an +attacker can re-send a copy of an old message, and the recipient will treat it +as a new message. -To mitigate this it is recomendend that applications track the message indicies -they have recieved and that they reject messages with indicies that they've -already decrypted. +To mitigate this it is recomendend that applications track the ratchet indicies +they have recieved and that they reject messages with a ratchet index that +they've already decrypted. Lack of Transcript Consistency ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.2.3 From 092bf880f5adaf9897b1c869b67f6d9c5284eda5 Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Fri, 21 Oct 2016 15:45:33 +0100 Subject: s/they've/they have/ --- docs/megolm.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/megolm.rst') diff --git a/docs/megolm.rst b/docs/megolm.rst index 0994100..dce64d7 100644 --- a/docs/megolm.rst +++ b/docs/megolm.rst @@ -283,7 +283,7 @@ as a new message. To mitigate this it is recomendend that applications track the ratchet indicies they have recieved and that they reject messages with a ratchet index that -they've already decrypted. +they have already decrypted. Lack of Transcript Consistency ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.2.3 From 884ad02413e334473a338986c2291a717defb662 Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Fri, 21 Oct 2016 17:07:26 +0100 Subject: Spelling --- docs/megolm.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/megolm.rst') diff --git a/docs/megolm.rst b/docs/megolm.rst index dce64d7..03ee426 100644 --- a/docs/megolm.rst +++ b/docs/megolm.rst @@ -281,8 +281,8 @@ A message can be decrypted successfully multiple times. This means that an attacker can re-send a copy of an old message, and the recipient will treat it as a new message. -To mitigate this it is recomendend that applications track the ratchet indicies -they have recieved and that they reject messages with a ratchet index that +To mitigate this it is recommended that applications track the ratchet indices +they have received and that they reject messages with a ratchet index that they have already decrypted. Lack of Transcript Consistency -- cgit v1.2.3