Open HulaHoopWhonix opened 8 years ago
From the description, there's a server component (this would be the toxme bit) and a client component, and each client checks in with the server to make sure the server isn't lying about their identity mapping, as well as checking that other clients are seeing the same mapping. It also appears that multiple CONIKS providers are intended to verify each other.
https://www.torproject.org/getinvolved/volunteer.html.en#coniks_in_messenger
http://www.coniks.org/our-solution/
I'm intrigued. Any devs want to give this a preliminary evaluation of feasibility? Any immediately-apparent problems?
EDIT:
From the research paper:
Clients need to download about 17.6kB per day from the CONIKS server
: /
It does talk about mixing later on though
anything in the Kb range is meaningless at this point, tox can reach 1GB a day.
I've gotten about 1/2 through the white paper, and it's based on the trust of the system to do it's job... that is you can cheat, but you'll get caught... Maybe.
It also seems that if you can know who's going to contact whom, you can poison a tree for a long time before you'll get caught. Especially if you can target the two people you're trying to get in between. It's better than what we have now... kinda.
EDIT: any time you suggest that you can win by whistleblowing, and that you can do so by sneakernet... you've already lost.
My concern is with connecting to nameservers every day and revealing identity/location metadata, not necessarily the amount of data used. But they do talk about mixing later on in the paper.
Sounds interesting. It relies on each user regularly checking its own record and peersn(or servers, but I'd definitely include peers in this) exchange their info about str's. If a manipulation is detected it can be proven which server was malicious or compromised. You cannot tell apart, however, if it was hacked or the server Adkins themselves were malicious. Once fraud is detected, coniks does warn the user
Location can be hidden by using for. But the servers would learn which identities are being actively used
The developers for Tor Messenger plan to add support for CONIKS - an end-user key management and verification system for end-to-end secure communication that has tamper-evident, publicly-auditable key directories.
A user security will not have to verify long key strings to be sure they were not MITM'd. CONIKS guarantees that usernames are mapped to the correct public key and any foul play is flagged.
More details: https://www.torproject.org/getinvolved/volunteer.html.en#Coding Section: Implement and Integrate CONIKS for Tor Messenger
CONIKS research paper: https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-melara.pdf
basic reference implementations of a CONIKS key server and a CONIKS client: https://github.com/coniks-sys/coniks-ref-implementation