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

[arma at torproject.org]

commit a7cbf704197e8494bb63d80885f7b99dfadbb0df
Author: Damian Johnson <atagar at torproject.org>
Date:   Tue Feb 23 09:37:14 2016 -0800

    Add 'Implement and Integrate CONIKS for Tor Messenger' project idea
    
    Project idea courtesy of Arlo.
---
 getinvolved/en/volunteer.wml | 72 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)

diff --git a/getinvolved/en/volunteer.wml b/getinvolved/en/volunteer.wml
index 4eda17c..cd4908f 100644
--- a/getinvolved/en/volunteer.wml
+++ b/getinvolved/en/volunteer.wml
@@ -1371,6 +1371,78 @@ tampering.  Third, unit tests should be added for existing and new code
 in order to make the code base more robust.
     </p>
     </li>
+
+    <a id="coniks_in_messenger"></a>
+    <li>
+    <b>Implement and Integrate CONIKS for Tor Messenger</b>
+    <br>
+    Effort Level: <i>Medium</i>
+    <br>
+    Skill Level: <i>Medium</i>
+    <br>
+    Likely Mentors: <i>Marcela, Arlo (arlolra)</i>
+    <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=""></a>
     <li>