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
[email protected]
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
