[tor-commits] [webwml/master] Drop 'Implement and Integrate CONIKS for Tor Messenger' project idea

[atagar at torproject.org]

commit 5b6d2c232ac9648466f7a62a00aae8222f0cf27e
Author: Damian Johnson <atagar at torproject.org>
Date:   Sun Jan 29 13:06:09 2017 -0800

    Drop 'Implement and Integrate CONIKS for Tor Messenger' project idea
    
    We had a student (Huy Vu) that did this last year.
---
 getinvolved/en/volunteer.wml | 71 --------------------------------------------
 1 file changed, 71 deletions(-)

diff --git a/getinvolved/en/volunteer.wml b/getinvolved/en/volunteer.wml
index 84fadf9..035dcbe 100644
--- a/getinvolved/en/volunteer.wml
+++ b/getinvolved/en/volunteer.wml
@@ -896,77 +896,6 @@ the codebase that you want to work on.
     </p>
     </li>
 
-    <a id="coniks_in_messenger"></a>
-    <li>
-    <b>Implement and Integrate CONIKS for Tor Messenger</b>
-    <br>
-    Language: <i>C, JavaScript</i>
-    <br>
-    Likely Mentors: <i>Marcela (masomel), Arlo (arlolra)</i>
-    <br><br>
-    <p>
-CONIKS is an end-user key management and verification system for end-to-end
-secure communication services, which improves upon existing key management
-systems by providing both strong security and better usability using a model
-called key transparency. CONIKS does this by requiring providers to manage
-tamper-evident, publicly-auditable key directories, which contain mappings from
-usernames to public keys, on behalf of their users. This design makes it easier
-for users (both "default" users and power users) to establish trust since they
-don't have to worry about or even see keys, but users also don't have to
-trust the provider to be well-behaved because the CONIKS client can run as
-part of the secure messaging app and automatically check that the service
-provider doesn’t map spurious keys to their users' usernames, and it can
-verify that observed name-to-key mappings are consistent with what other
-clients in the system are seeing. Unlike existing key transparency solutions,
-CONIKS also provides strong privacy guarantees by employing cryptographic
-primitives for robust data obfuscation.
-    </p>
-
-    <p>
-The CONIKS system design, protocols, and proof-of-concept are described in
-great detail in the <a
-href="https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-melara.pdf">CONIKS
-research paper</a>, and basic reference implementations of a CONIKS key server
-and a CONIKS client are avialable on <a
-href="https://github.com/coniks-sys/coniks-ref-implementation">Github</a>.
-    </p>
-
-    <p>
-This project has two main components: (1) designing and implementing a CONIKS
-key server tailored to Tor Messenger users, and (2) building a CONIKS client
-which integrates with the Tor Messenger client. One challenge the applicant
-will face is ensuring that the key server design is efficient and scalable for
-large volumes of users, concurrent traffic and guarantees this scalability even
-as Tor Messenger's user base grows. On the client side, the main challenges
-will be to focus on space efficiency as well as minimizing computational
-overhead when implementing the CONIKS consistency checks, and determining how
-to best communicate CONIKS consistency check results to users in the UI. Since
-Tor Messenger does not hand out online identities per se, as most online
-communication services do (like, say, Twitter, in which each user has a unique
-handle), the CONIKS key server for Tor Messenger will have to map usernames
-from third-party communication services to the encryption keys used in Tor
-Messenger. One additional important challenge that the applicant will have to
-help address is ensuring that each such third-party username remains unique in
-the Tor Messenger space and that such external, third-party identities are
-indeed controlled by the expected user of that third-party communication
-service.
-    </p>
-
-    <p>
-Some design and implementation questions have been discussed in <a
-href="https://trac.torproject.org/projects/tor/ticket/17961">Ticket #17961</a>.
-    </p>
-
-    <p>
-The applicant should have some familiarity with well-known crypto primitives
-and algorithms, as well as have a basic understanding of the key transparency
-model. Client side integration will require some basic use of JavaScript.
-Consider submitting a patch for <a
-href="https://github.com/arlolra/ctypes-otr/issues">one of the open key
-verification issues</a> as part of the application process.
-    </p>
-    </li>
-
     <a id="panopticlick"></a>
     <li>
     <b>Panopticlick</b>