From 8f81663f3ebbaa9201d605a1bfffe1853f729179 Mon Sep 17 00:00:00 2001 From: Pedro Pombeiro Date: Mon, 2 Sep 2019 14:34:48 +0200 Subject: [PATCH 1/2] Add description of integrity in design requirements --- status-secure-transport-spec.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/status-secure-transport-spec.md b/status-secure-transport-spec.md index 0cde88d..4ff1e8b 100644 --- a/status-secure-transport-spec.md +++ b/status-secure-transport-spec.md @@ -46,8 +46,8 @@ In this document we describe how a secure channel is established, and how variou - **Confidentiality**: The adversary should not be able to learn what data is being exchanged between two Status clients. - **Authenticity**: The adversary should not be able to cause either endpoint of a Status 1:1 chat to accept data from any third party as though it came from the other endpoint. - **Forward Secrecy**: The adversary should not be able to learn what data was exchanged between two Status clients if, at some later time, the adversary compromises one or both of the endpoint devices. +- **Integrity**: The adversary should not be able to cause either endpoint of a Status 1:1 chat to accept data to accept data that has been tampered with. - ### Conventions @@ -285,7 +285,7 @@ TODO: description here > No honest party will accept a message that has been modified in transit. - Yes. -- Assuming a user validates (TODO: Check this assumption) every message they are able to decrypt and validates its signature from the sender, then it is not able to be altered in transit. +- Assuming a user validates (TODO: Check this assumption) every message they are able to decrypt and validate its signature from the sender, then it is not able to be altered in transit. * [igorm] i'm really not sure about it, Whisper provides a signature, but I'm not sure we check it anywhere (simple grepping didn't give anything) * [andrea] Whisper checks the signature and a public key is derived from it, we check the public key is a meaningful public key. The pk itself is not in the content of the message for public chats/1-to-1 so potentially you could send a message from a random account without having access to the private key, but that would not be much of a deal, as you might just as easily create a random account) @@ -356,7 +356,7 @@ TODO: Verify if this can be done already by looking at Lamport clock difference #### Message Unlinkability (NO) > If a judge is convinced that a participant authored one message in the conversation, this does not provide evidence that they authored other messages -- Currently, the Status software signs every messages sent with the user's public key, thus making it no able to give unlinkability. +- Currently, the Status software signs every messages sent with the user's public key, thus making it unable to provide unlinkability. - This is not necessary though, and could be built in to have an option to not sign. - Side note: moot account allows for this but is a function of the anonymity set that uses it. The more people that use this account the stronger the unlinkability. @@ -390,7 +390,7 @@ TODO: Verify if this can be done already by looking at Lamport clock difference - Accept invitation to group - Leave group - Non-Members: - - Invited by admins show up as "invited" in group; this leaks contacat information + - Invited by admins show up as "invited" in group; this leaks contact information - Invited people don't opt-in to being invited TODO: Group chat dynamics should have a documented state diagram From 25114e3bc00236feb6f0cf3a5d7b51a0770893b0 Mon Sep 17 00:00:00 2001 From: Pedro Pombeiro Date: Thu, 12 Sep 2019 15:36:50 +0200 Subject: [PATCH 2/2] Update status-secure-transport-spec.md --- status-secure-transport-spec.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/status-secure-transport-spec.md b/status-secure-transport-spec.md index 4ff1e8b..06f8eac 100644 --- a/status-secure-transport-spec.md +++ b/status-secure-transport-spec.md @@ -46,7 +46,7 @@ In this document we describe how a secure channel is established, and how variou - **Confidentiality**: The adversary should not be able to learn what data is being exchanged between two Status clients. - **Authenticity**: The adversary should not be able to cause either endpoint of a Status 1:1 chat to accept data from any third party as though it came from the other endpoint. - **Forward Secrecy**: The adversary should not be able to learn what data was exchanged between two Status clients if, at some later time, the adversary compromises one or both of the endpoint devices. -- **Integrity**: The adversary should not be able to cause either endpoint of a Status 1:1 chat to accept data to accept data that has been tampered with. +- **Integrity**: The adversary should not be able to cause either endpoint of a Status 1:1 chat to accept data that has been tampered with.