-
Notifications
You must be signed in to change notification settings - Fork 283
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DRAFT] Toxcore Threat Model #210
Comments
@GrayHatter could you elaborate on the main objectives that this threat model should defines, and why ? Would be easier if someone wish to write something like that :) |
@SkyzohKey this is a good start for a threat model https://conversations.im/omemo/audit.pdf |
I think we first needs to define why an attacker would attack the network (profit, data leaks, etc) and then define the potential target of that attack. Next to that we have to list if every potential target has any kind of protection from the toxcore point and if not, push some code to fix. This is a tentative list and I'm probably missing points, but that's a start. Nb: I'll use the same conventions as OMEMO's pdf here to gain time, as we share some points with it.
|
I've added the threat model @SkyzohKey generated with some fixes to the first post, and that version here as well.
|
Deniability of the conversation is not given. Both deniability of the conversation and future secrecy are provided by axolotl protocol, or as it is called now, signal protocol. It also offers all the other features we currently have. Additionally, it allows for securing asynchronous messages, so if we ever want to have real offline messages, this protocol is really worth looking into. |
I'm not sure what this means. Toxcore already has both, as noted above.
It's okay, it's not bad. But I don't see a reason to use this protocol instead of something else. All it add is async keys, but they have to be stored somewhere, like a server. I'm sure we can come up with something better. |
Has both? No. As noted above? No, above it says "Unknown", and toxcore does NOT have it. Deniability of conversation means that if your contact wants to prove the fact that you had a communication, they cannot. Toxcore does NOT have this. So it would add to what we currently have: deniability of conversation and, if we don't have it yet, also future secrecy , and thirdly secure offline messages. |
Ah, I misunderstood you the first time. I thought we were talking about deniability of content.
I wonder how Axolotl provides this. According to the audit (here: https://conversations.im/omemo/audit.pdf ) for OMEMO derived from the Signal Protocol. It's theoretical at best. The audit says...
So the audit it self suggests, that Deniability of conversation should remain out of scope.
No, it wouldn't because from the the quotation from the OMEMO audit says that protection of the conversation, would have to go through a server. An adversary sitting on the wire between you and the person you're talking to would be able to prove you exchanged traffic. And with Tox, without deep packet inspection, it could just as easily be DHT traffic.
What part makes you think a server is optional? |
No. They say if leaks can occur on other layers, other layers should take those into account too, or such a claim cannot be made.
"such", meaning server logs.
Your contact, not a server or ISP or wirehog.
I do not think so.
I don't think that this DHT traffic is a feature of libsodium, so it's orthogonal to the key exchange discussion. That means, you'd still have the same DHT traffic as before, and it would be equally hard for the adversary sitting on the wire to prove it.
Because there are p2p solutions that use DH key exchanges which need no server (cf. toxcore) and direct p2p communication. From OMEMO website:
Sounds pretty much like what tox wants to accomplish
Sorry for the long reply, but I hope it makes the axolotl threat model clearer and shows how it could fit into the big picture. |
It is a provenly secure protocol. For a quick overview, cf. wikipedia: https://en.wikipedia.org/wiki/Signal_Protocol Otherwise, I recommend reading this: https://eprint.iacr.org/2016/1013.pdf And I think, widespread adoption of that protocol will lead to constant improvement. |
Can someone move this issue to the https://github.com/TokTok/spec repo? I wonder if there is some way to do that with the github api. Either way, this issue is high priority but doesn't belong in toxcore. It is a documentation issue. |
I will if someone promises to leave the formatting static for > 24h for the
pull to merge?
…On Jan 12, 2017 04:19, "iphydf" ***@***.***> wrote:
Can someone move this issue to the https://github.com/TokTok/spec repo? I
wonder if there is some way to do that with the github api. Either way,
this issue is high priority but doesn't belong in toxcore. It is a
documentation issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#210 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAO20GLgBeCBBNVhFy4KckDb2UODZqMIks5rRhobgaJpZM4KgcZk>
.
|
This issue has moved and is now accessible here: TokTok/spec#50. Thus closing. |
The text was updated successfully, but these errors were encountered: