[GSoC] CONIKS implementation for Tor Messenger
Dear devs, My name is Huy, and I am a computer science student at Hanoi University of Science and Technology, Vietnam. GSoC is a great opportunity for me to contribute to Tor. I have been watching the development of Tor Messenger since its release. As my major is cryptography, I find the idea “implement and integrate CONIKS for Tor Messenger” very interesting. I am studying the CONIKS paper and my confusions were mostly answered in Elias's thread. I'm thinking about how to integrate CONIKS module to current implementation of Tor Messenger. I have some questions to ask: - A standard for data formats & protocol: I know the standard is essential for the project, so can I define a standard when developing (with your review) or I have to wait for your work in future? Another question about GSoC: - What should be deliverable by mid-term of GSoC? Btw, I also created a pull-request for ctypes-otr project on Github. Best, Huy Vu
Hi Huy, Great to meet you and thank you very much for your interest in this project!
- A standard for data formats & protocol: I know the standard is essential for the project, so can I define a standard when developing (with your review) or I have to wait for your work in future?
It's reasonable to assume that the client may one day talk to other CONIKS servers and clients. So clearly specifying the data format that the Tor Messenger client (and also the server) uses is an important part of the project. Ultimately, the data format specification should follow the data formats given in the paper. So you should provide a clear specification for Tor Messenger but you shouldn't worry too much about making it compatible with other services. The main reason being that we don’t know of other communication services that have already implemented and deployed CONIKS. I'm not currently working on a standard specification. That's something that I think communication/identity providers should come together to do once there are a few tested deployments of CONIKS. This is what I've heard from other communication service providers I've talked to, and I think it makes sense. To get a rough sense of what a data format might look like, you may look at the CONIKS reference implementation (github.com/coniks-sys/ref-implementation). It uses Protobufs to specify the data exchange format, so you could use a similar format.
Another question about GSoC: - What should be deliverable by mid-term of GSoC?
As part of your application, we’d like for you to provide us with your planned timeline according to the functionality we’d like to have. Here’s the functionality that would be great to have by the end of the summer: key registrations, lookups and monitoring. The nice thing about splitting up the functionality like this is that it allows for the key server and the client to be built incrementally. So given how you want to tackle these tasks, you should set up your plan accordingly.
Btw, I also created a pull-request for ctypes-otr project on Github.
Thank you for your pull request. I understand you’ve already been in touch with Arlo about this, that’s great. Please let Arlo or myself know if you have any other questions. Best, Marcela
Hi Marcela, Thanks for your quickly reply.
It's reasonable to assume that the client may one day talk to other CONIKS servers and clients. So clearly specifying the data format that the Tor Messenger client (and also the server) uses is an important part of the project. Ultimately, the data format specification should follow the data formats given in the paper. So you should provide a clear specification for Tor Messenger but you shouldn't worry too much about making it compatible with other services. The main reason being that we don’t know of other communication services that have already implemented and deployed CONIKS. I'm not currently working on a standard specification. That's something that I think communication/identity providers should come together to do once there are a few tested deployments of CONIKS. This is what I've heard from other communication service providers I've talked to, and I think it makes sense. To get a rough sense of what a data format might look like, you may look at the CONIKS reference implementation (github.com/coniks-sys/ref-implementation). It uses Protobufs to specify the data exchange format, so you could use a similar format.
Thanks for your suggestion. I will have a look at this carefully.
As part of your application, we’d like for you to provide us with your planned timeline according to the functionality we’d like to have. Here’s the functionality that would be great to have by the end of the summer: key registrations, lookups and monitoring. The nice thing about splitting up the functionality like this is that it allows for the key server and the client to be built incrementally. So given how you want to tackle these tasks, you should set up your plan accordingly.
I get it. It would help me a lot when writing my proposal. best, Vu Quoc Huy
Hi Huy, You’re very welcome, we look forward to your application! Best, Marcela
On Mar 13, 2016, at 3:40 AM, Huy Vu Quoc <huyvq.c633@gmail.com> wrote:
Hi Marcela,
Thanks for your quickly reply.
It's reasonable to assume that the client may one day talk to other CONIKS servers and clients. So clearly specifying the data format that the Tor Messenger client (and also the server) uses is an important part of the project. Ultimately, the data format specification should follow the data formats given in the paper. So you should provide a clear specification for Tor Messenger but you shouldn't worry too much about making it compatible with other services. The main reason being that we don’t know of other communication services that have already implemented and deployed CONIKS.
I'm not currently working on a standard specification. That's something that I think communication/identity providers should come together to do once there are a few tested deployments of CONIKS. This is what I've heard from other communication service providers I've talked to, and I think it makes sense.
To get a rough sense of what a data format might look like, you may look at the CONIKS reference implementation (github.com/coniks-sys/ref-implementation). It uses Protobufs to specify the data exchange format, so you could use a similar format.
Thanks for your suggestion. I will have a look at this carefully.
As part of your application, we’d like for you to provide us with your planned timeline according to the functionality we’d like to have. Here’s the functionality that would be great to have by the end of the summer: key registrations, lookups and monitoring. The nice thing about splitting up the functionality like this is that it allows for the key server and the client to be built incrementally. So given how you want to tackle these tasks, you should set up your plan accordingly.
I get it. It would help me a lot when writing my proposal.
best, Vu Quoc Huy
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
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
Thanks Vu, looking good.
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.
There's been some confusion around the languages listed in the project description. C/JavaScript are there as prerequisites for working with the ctypes-otr add-on. It may be prudent to consider a memory-managed language (I'll suggest golang here as popular choice) for the server component.
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).
...
Monitoring: regularly downloading consistency proofs in the background and notifying to the user by a popup modal if a new key binding is issued.
Wherever possible, we'd like to avoid modals and use the notification bar. There's also a suggestion to grey out the conversation window and use a throbber here, https://github.com/arlolra/ctypes-otr/issues/20
Hi Arlo,
It may be prudent to consider a memory-managed language (I'll suggest golang here as popular choice) for the server component.
It is good to know that I can use golang to develop the server component. I am going to rewrite this part.
Wherever possible, we'd like to avoid modals and use the notification bar. There's also a suggestion to grey out the conversation window and use a throbber here,https://github.com/arlolra/ctypes-otr/issues/20
Since the monitoring protocol is done periodically so there certainly exist a case of an unexpected key change whereas there are not any conversation windows. In such a case, how do we show the message using the notification bar? I think that a popup modal is a good choice for this situation. Btw, I also added a timeout enforcement for responding to events in my proposal. Timeout for requests is 100ms and this can be changed based on some surveys and tests during development phase (may the registration request take a longer time than other requests?). Best Regards, Vu Huy
On Mar 23, 2016, at 9:05 PM, Huy Vu Quoc <huyvq.c633@gmail.com> wrote:
Wherever possible, we'd like to avoid modals and use the notification bar. There's also a suggestion to grey out the conversation window and use a throbber here,https://github.com/arlolra/ctypes-otr/issues/20
Since the monitoring protocol is done periodically so there certainly exist a case of an unexpected key change whereas there are not any conversation windows. In such a case, how do we show the message using the notification bar? I think that a popup modal is a good choice for this situation.
Sorry, you're right, I was misreading that. For what it's worth, a notification bar exists on each window, not just the conversation. It may make sense to display this on the accounts window. The point I was failing to make is that since modals stop the world, we should use them sparingly. But maybe this is a case where it's warranted.
Btw, I also added a timeout enforcement for responding to events in my proposal. Timeout for requests is 100ms and this can be changed based on some surveys and tests during development phase (may the registration request take a longer time than other requests?).
Ok.
participants (3)
-
Arlo Breault -
Huy Vu Quoc -
Marcela Melara