status-im
/
specs
mirror of https://github.com/status-im/specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #46 from PombeirP/patch-1 

Add description of integrity in design requirements
This commit is contained in:
Oskar Thorén 2019-09-16 12:01:52 +02:00 committed by GitHub
parent abb8b69581 b0076b6a3b
commit 6943cb509e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
status-secure-transport-spec.md
View File

@ -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. - **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. - **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. - **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 modify the data. - **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.
All of these properties are ensured by the use of [Signal's Double Ratchet](https://signal.org/docs/specifications/doubleratchet/) All of these properties are ensured by the use of [Signal's Double Ratchet](https://signal.org/docs/specifications/doubleratchet/)
@ -282,7 +282,7 @@ TODO: description here
> No honest party will accept a message that has been modified in transit. > No honest party will accept a message that has been modified in transit.
- Yes. - 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) * [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) * [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)
@ -353,7 +353,7 @@ TODO: Verify if this can be done already by looking at Lamport clock difference
#### Message Unlinkability (NO) #### 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 > 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. - 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. - 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.
@ -387,7 +387,7 @@ TODO: Verify if this can be done already by looking at Lamport clock difference
- Accept invitation to group - Accept invitation to group
- Leave group - Leave group
- Non-Members: - 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 - Invited people don't opt-in to being invited
TODO: Group chat dynamics should have a documented state diagram TODO: Group chat dynamics should have a documented state diagram