Re: [tor-dev] [GSoC] CONIKS implementation for Tor Messenger

[Huy Vu Quoc <huyvq.c633@xxxxxxxxx>]

Hi,

I have included below my draft proposal and would like to hear your advise about it.Â

âââââ
My proposal for this project is presented as follow: firstly, I describe an overview implementation of server, followed by a list of important user interface/overall architectural client components, then data format for protocol and finally a timeline.

a. Server
One challenge of keyserver is efficiency and scalability for large volumes of users, concurrent traffic. According to this requirement, the keyserver will be implemented using libuv library and OpenSSL as cryptography library. libuv is a multi-platform support library with a focus on asynchronous I/O and primarily used by node.js. OpenSSL is used to add TLS/SSL functionality on top of libuv. This ensures that the server can handle a high rate of requests and connections with as low of latency and resource and is able to provide SSL/TLS connection.Â
Generated STR and other user information will be stored in a MySQL database.
I will try to develop the server components as a general API for CONIKS to provide a framework for implementing CONIKS identity providers. It helps other existing communication services easily integrate CONKIS into their system.Â
Some design concerns:
Â- Register username function (VUF): according to the experiment in the paper, the register function will use BLS signature (possibly use PBC library for implementation, no need to reinvent the wheel).
Â- Current implement of libotr only supports DSA public keys, but the CONIKS server component will expand to support any kind of public key (libotr has a key type marker for future extensibility). The server component will have a high-level interface (like EVP interface of OpenSSL).

b. Client
* Client implementation
Most of client code is a part of add-on (OTR addon), and written in Javascript. Interactions with libotr and crypto libraries will be done through ctypes binding.Â
The result of consistency checks will be saved in userâs profile directory using sqlite.Â

* Normal user and Strict user
The user can choose the type of user he/she wants to be. However, both of these types provide policies which is applied for all protocol.

* User interface:Â
There is an option for user to choose which type of user he/she wants to be: normal user or strict user. This setting is shown in OTR addon preference panel. However, the default setting is normal mode and the strict mode is an opt in feature.
If there are any problems with the CONIKS consistency checks, the consistency check result will be noticed to the user by a popup modal. Its design includes a significant signal to alert the user (such as using red sign).

* Workflow:
Key registration: after the user creates a new account, the key registration process will run automatically in background.
Key lookups: Whenever the user starts a new conversation, the key lookups process will be done transparently. Any problems will be noticed using the notification bar (such as no key exists, â). If there are any problems which lead to failure of key lookups process, the verification will be done via current methods (shared secret, manual verification or question & answer).
Monitoring: regularly downloading consistency proofs in the background and notifying to the user by a popup modal if a new key binding is issued.Â

c. Data format & protocol
This definition of data format and protocol is based mostly on current reference implementation of CONIKS. It may be extended in future development (with review of mentors).
Below is some proposal extended data format.
Â- Key Change & Registration protocol
message Registration {
	enum PolicyType {
		STRICT = 0;
		NORMAL = 1;
	}
	string user_name;
	string public_key;
	PolicyType type;
}

message KeyChange {
	string user_name;
	string new_public_key;
	string signed_public_key;		
}

- Update Policy type protocol
message UpdatePolicy {
	enum PolicyType {
		STRICT = 0;
		NORMAL = 1;
	}
	string user_name;
	string siged_public_key;
	PolicyType new_type;
}

Further expansion plans would be
Â- Extending protocol:Â
Ââ Key expiration.
Ââ Supporting multiple devices (mostly like key change protocol).
Â- Making a benchmark for testing the scalability of the server.
Â- Performing code coverage analysis.

* Estimated Timeline
GSoC coding period starts on May 24 and ends on August 15 comprising a total of 12 weeks.

5/23 - Official start of GSoC. However, I am able to start much earlier.
5/23 - 5/29 (1 week) - Setup a public repo on Github with source code of server backend for handling network I/O operation and SSL/TLS connection, deploy to a public server (may be using a cloud service). After that, I can start building both client and server components incrementally by splitting the functionality. First priority is key registration and lookups function, then monitoring. I will also spend this week to study the paper deeper and take a look at references of the paper.
5/30 - 6/5 (1 week) - Study crypto primitives deeper based on resources provided by mentors.
6/6 - 6/19 (2 weeks) - Implement Merkle Prefix Tree and STR.
6/20 - 7/3 (2 weeks) - Implement key registration function.
7/4 - 7/13 (~2 weeks) - Implement key lookup Â& monitoring function.
7/14 - 7/20 (1 week) - catch up week. Review the code and progress with mentors.
7/20 - Midpoint evaluations. Submit a working version of Key registration and Lookups functionality.Â
7/20 - 8/4 (2 weeks) - Extend protocol with some functionalities: key expiration and supporting multiple devices.
8/4 - 8/11 (1 week) - Perform code coverage analysis, do benchmark and unitest.
8/12 - 8/15 (~1 week) - catch up week. Write documentation. Review the code and progress with mentors.
8/15 - Final evaluations. Submit project source code & Documentation.

best,
Vu Huy
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev