[tor-dev] [GSoC] CONIKS for Tor Messenger - Status report #6

[Huy Vu Quoc]

Hi everyone,

This is my sixth status report for my GSOC project.

There are not much for this recent weeks since we (my mentors and I)
are concentrating on reviewing/refactoring code.

1- Development of the CONIKS protocol library:
The pull for this issue is at
https://github.com/coniks-sys/coniks-go/pull/64. It’s almost done.
However, we opened new ticket for discussion over key lookup & key
monitoring function (issue #70).

2- Starting integrating CONIKS into Tor Messenger
There’re currently 2 pulls for the integration
(https://github.com/arlolra/ctypes-otr/pulls). We also probably would
do some refactoring on the cgo client library, the idea is to wrap all
client tasks into this library, and then the server’s responses would
be passed in the library instead of unmarshalling the response and
passing them into separate functions as now.

3- Fixing bugs and making improvements based on our discussions/feedbacks

Basically, there’re many things need to be done before the end of GSoC.
We probably cannot merge all the implemented features into master
branch before the end of GSoC,
so I’m working on a separate branch that merged all pulls so far, the
main purpose is
to have a working prototype for my GSoC.

Best,
Huy
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] [GSoC] CONIKS for Tor Messenger - status report #5

[Huy Vu Quoc]

Hi everyone,

These are things that I have been doing in the last two weeks:

- I and my mentors have had a discussions for next steps for the
project. We decided to reorganize our project’s repo [1]. All repos
has been merged into one [1]. This helps us maintain and keep tracking
the development easier.

- A lot of issues and PRs have been resolved/merged. The merkletree
library is almost done for now.

- Thanks for Ismail and Arlo’s suggestions, the client library for
crypto verifications (including the VRF verification, Ed25519
signature verification, auth path verification and so on) is
implemented in Go and compiled with `c-shared` build mode [2]. This
library then will be wrapped with js-ctypes to use in the add-on. I
have successfully loaded the library into the add-on in Linux
machines. There’s still some problem since Tor Messenger for OS X is
compiled from a Linux machine, while the library is compiled from
macOS, then when loading the library into Tor Messenger for OS X, Tor
Messenger may crash. We will probably dig deeper on this issue.
Windows’ DLL version of the library also should be taken care.

Next steps are mostly to focus on the client-side, along with
finishing the server reference implementation. Here’s thing I expect
in the next weeks:
- Merge the server-registration and registration-bots PR.
- Merge the coniks-preference PR.
- Merge the PR of client library.
- Submit PR for client registration and lookup.

I also expect to have a working version of project before August 15,
including the functions which I described in my proposal.

Best,
Huy

—
[1] https://github.com/coniks-sys/coniks-go
[2] https://github.com/coniks-sys/coniks-go/tree/client-cgo
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] [GSoC] CONIKS for Tor Messenger - status report #4

[Huy Vu Quoc]

Hi guys,

These are things that I have been doing in the last two weeks:

1. Continue implementing the libmerkletree library.
The next module of the lib is a storage backend. The implementation is
at [1]. Below is a brief description of my implementation:
- In each update, both tree version and STR are entirely stored to the
db. (this idea is mostly from Coname authors)
- The developers now can construct the tree from db or do lookup in
the STR which is stored in the persistent storage. The idea is when
the server has been restarted, the developers can initialize the
in-memory PAD (the history hash chain) with an existing tree; or
whenever the developers needs to do a lookup from the db instead of
the in-memory STR (the length of the history hash chain is limited by
server’s configuration).

2. Implement the key lookup protocol.
This function is not finished yet, since I’m still working on the
client. The source code for the server is at [2].
For the client, since we are signing the STR using Ed25519 signature
scheme, the client also needs a library for verifying the signature
efficiently. I’m working on a C library that makes use of libgcrypt
library (which also be used currently by libotr library). It takes me
time to learn how to use libgrcrypt library.
When this C library is finished, I can start working on key lookup and
monitoring functions on the client part.

In the next two weeks, I will try to have a working prototype (both
key registration and key lookup) for Tor Messenger. Then I and my
mentors can focus on refactoring and optimizing source code, as well
as writing tests.

Best,
Huy

—
[1] https://github.com/coniks-sys/libmerkleprefixtree-go/tree/db
[2] https://github.com/coniks-sys/libconiks-server-go/tree/lookup
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [GSoC] CONIKS for Tor Messenger - status report #3

[Huy Vu Quoc]

Hi everyone,

I have made some mistakes in my status report #3, about the
registration & verification protocol:

Wrong version:
> The verification protocol could be simplified by letting
> the client send the fingerprint to both registration bot and the twitter 
> handle. Then
> we can do a comparison these two messages for the verification.

Correct version:
The client sends its registration request (by DM) directly to the
registration bot and the bot forwards it to the server. There is no
comparisons during registration, and the client doesn’t be contacting
the key server at all.

Thanks Arlo for correcting me.

We are also discussing on how the client receives the response from
the key server. 2 solutions are:
- Sending the response (i.e., the temporary binding of registering
user) to the client by DM through the registration bot.
- The client could just do a normal lookup for its own value after a
timeout. This way, it could obtain its temporary binding.
It will be updated in my next status report.

Best,
Huy

On July 1, 2016 at 23:40:40, Huy Vu Quoc (huyvq.c...@gmail.com) wrote:
> Hi everyone,
>
> This is my third status report on the CONIKS for Tor Messenger project.
>
> These are things that I have been doing in the last two weeks:
>
> 1. Continue implementing the Merkle prefix tree module. Currently, the STR 
> source code
> are under review.
> This module takes a lot of time since it is probably the biggest components. 
> There are
> a lot of discussions over the development to make sure everything is on right 
> track (e.g.
> the proof of absence …)
>
> 2. Continue working on libconiks library. This library currently consists of 
> several
> modules:
> - CONIKS server construction from config file
> - TLS socker listener
> - Request handler
> I submitted a pull request for the registration implementation [1].
>
> 3. Registration implementation (Tor Messenger-specific module).
> This work includes both server & client modules:
>
> - Server modules: the registration bot acts as a proxy between the client and 
> the CONIKS
> server. Account verification is performed by comparing the fingerprint 
> (base64 encoded)
> included in registration request and the DM sent to CONIKS twitter account.
>
> - Client modules: the client module consists of a preferences UI and coniks 
> module which
> sends the request. Currently, the policies setting of each user is stored in 
> a sqlite
> database. (source code of client module is pushed to [2])
>
> - The server will return base64 encoded string of the temporary binding (TB). 
> This would
> be changed when we start working on monitoring & key lookup modules. (i.e. 
> returning
> more data along with TB)
>
> - The verification message (Twitter direct message) format is: 
> ?CONIKS?b64Encode(fingerprint)
>
> The registration protocol can be illustrated as follows:
>
> Client - Registration bot (listening on port 3000) - CONIKS server (listening 
> on port
> 3001)
> 1. Client sends a DM to CONIKS Twitter handle
> 2. Client sends a registration request to registration bot
> 3. Registration bot verifies the request
> 4. If it is valid, the bot forwards the request to the CONIKS server
> 5. The server returns a TB for the requested user
> 6. The bot forwards the TB to the client.
>
> The source code is available for review [3].
>
> After some discussions with my mentors (Arlo and Marcela), we also came up 
> with an improved
> account verification scheme.
> In the original proposal, the client would send the public key to the 
> registration bot
> and the signed public key to the twitter handle.
> However, that doesn't always make much sense, since the Merkle tree really 
> stores an
> opaque blob, not just a key. The verification protocol could be simplified by 
> letting
> the client send the fingerprint to both registration bot and the twitter 
> handle. Then
> we can do a comparison these two messages for the verification. The new 
> verification
> scheme seems more effective in case of Tor Messenger and OTR protocol.
>
> Best,
> Huy
>
> —
> [1] https://github.com/coniks-sys/libconiks-server-go/pull/3
> [2] https://github.com/c633/ctypes-otr/tree/coniks-registration
> [3] https://github.com/c633/tor-messenger-coniks/pull/1
>
>
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [GSoC] CONIKS for Tor Messenger - status report #3

[Huy Vu Quoc]

Hi everyone,

This is my third status report on the CONIKS for Tor Messenger project.

These are things that I have been doing in the last two weeks:

1. Continue implementing the Merkle prefix tree module. Currently, the
STR source code are under review.
This module takes a lot of time since it is probably the biggest
components. There are a lot of discussions over the development to
make sure everything is on right track (e.g. the proof of absence …)

2. Continue working on libconiks library. This library currently
consists of several modules:
- CONIKS server construction from config file
- TLS socker listener
- Request handler
I submitted a pull request for the registration implementation [1].

3. Registration implementation (Tor Messenger-specific module).
This work includes both server & client modules:

- Server modules: the registration bot acts as a proxy between the
client and the CONIKS server. Account verification is performed by
comparing the fingerprint (base64 encoded) included in registration
request and the DM sent to CONIKS twitter account.

- Client modules: the client module consists of a preferences UI and
coniks module which sends the request. Currently, the policies setting
of each user is stored in a sqlite database. (source code of client
module is pushed to [2])

- The server will return base64 encoded string of the temporary
binding (TB). This would be changed when we start working on
monitoring & key lookup modules. (i.e. returning more data along with
TB)

- The verification message (Twitter direct message) format is:
?CONIKS?b64Encode(fingerprint)

The registration protocol can be illustrated as follows:

Client  - Registration bot (listening on port 3000) - CONIKS server
(listening on port 3001)
1. Client sends a DM to CONIKS Twitter handle
2. Client sends a registration request to registration bot
3. Registration bot verifies the request
4. If it is valid, the bot forwards the request to the CONIKS server
5. The server returns a TB for the requested user
6. The bot forwards the TB to the client.

The source code is available for review [3].

After some discussions with my mentors (Arlo and Marcela), we also
came up with an improved account verification scheme.
In the original proposal, the client would send the public key to the
registration bot and the signed public key to the twitter handle.
However, that doesn't always make much sense, since the Merkle tree
really stores an opaque blob, not just a key. The verification
protocol could be simplified by letting the client send the
fingerprint to both registration bot and the twitter handle. Then we
can do a comparison these two messages for the verification. The new
verification scheme seems more effective in case of Tor Messenger and
OTR protocol.

Best,
Huy

—
[1] https://github.com/coniks-sys/libconiks-server-go/pull/3
[2] https://github.com/c633/ctypes-otr/tree/coniks-registration
[3] https://github.com/c633/tor-messenger-coniks/pull/1
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [GSoC] CONIKS for Tor Messenger - 2nd status report

[Huy Vu Quoc]

On June 18, 2016 at 01:08:34, Marcela S. Melara (mel...@cs.princeton.edu) wrote:
> Another related issue that arises if you wait to push all of your new code at 
> once is that
> your PRs become very large and more complex to review. So in addition to 
> publishing your
> code early and often, I would also encourage you to divide your tasks into 
> smaller units
> that can be easily debugged, tested and reviewed. Creating separate specific 
> issues
> on Github for each small task might be a good way of keeping track of what 
> work is in progress,
> what you still need to do, and what you've finished.

On June 18, 2016 at 00:46:01, Arlo Breault (a...@torproject.org) wrote:
> As much as possible, I would encourage to work in the open, and publish
> early and often. Even though the code may not be ready for review, it's
> helpful to see progress from our end.

Yes. I will do it.

Best,
Huy
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] [GSoC] CONIKS for Tor Messenger - 2nd status report

[Huy Vu Quoc]

Hi everyone,

This is my second status report on the CONIKS for Tor Messenger project.

During the last two weeks I’ve been working on several things:

1. Continue implementing the Merkle prefix tree module and fix issues
based on comments from Marcela, Arlo and Ismail.
These are still some works need to be done including:
- Using an abstract cryptography library [1] instead of specific primitives
- Add hooks for storage backend [2]. Currently, I’m discussing with my
mentors (Marcela and Arlo) about how to do it.

2. Spend time to studying current implementation of coname/dename [3,
4]. It would help me so much when I go to implement the CONIKS library
(e.g., the server struct, server config and http front)

3. Work on some other modules of libconiks library (HTTP server and
server config)

4. Implement the Twitter bot for registration protocol. I used a 3rd
client library for Twitter APIs [5]. This bot uses the Twitter
streaming APIs to listen for new coming registration message, as
described in the account verification protocol.

The source code of (3) and (4) is not pushed to the github repo yet
since I’m still doing on these modules and they are not ready for
integrating into the library.

My focus on two next weeks is mainly to implement the registration
protocol and continue refining the Merkle tree library.

Best,
Huy

—
[1] github.com/dedis/crypto/
[2] https://github.com/coniks-sys/libmerkleprefixtree-go/issues/4
[3] https://github.com/yahoo/coname
[4] https://github.com/andres-erbsen/dename
[5] https://github.com/dghubble/go-twitter
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] [GSoC] CONIKS for Tor Messenger - 1st status report

[Huy Vu Quoc]

Hi everyone,

This is the first status report on the CONIKS for Tor Messenger project.

This is what I have done so far:

* Discussing with Arlo and Marcela about the account verification module.
The proposal is described below.

* Implementing the Merkle prefix tree module. The source code is under review
and is available on github repo [1]

* Submitting 2 patches for ctype-otr addon (pull #74 and #75 [2])

For now, I'm working on implementing the STR module as a part of Merkle tree
module. This module would be moved into its own repo as a library, separated
from the key server module, after others commented on the code.

Next I plan to continue implementing the key server module
(including the registration and key change operation). It also requires a
prototype implementation of the account verification module.

Besides, we also established the collaboration with engineers and PhD students
from EPFL on developing the CONIKS server module. The source code of the CONIKS
server module would be committed to its own repo [3], while other Tor Messenger
specific modules would be committed to the repo of the project [4].

---
The account verification protocol is proposed as follows (credit to Arlo)
- the user connects to an account
- the client sends the registration request to a registration bot on the server
- the client also signs the registered public key and sends it
to the registration bot
- the bot verifies the signature and registers the sending account with
the public key

The client sends the signed public key to the registration bot by using one of
following methods:
- send a direct message to the Twitter account of the bot (in case the account
is a Twitter account)
- send a private chat to the Jabber account of the bot (in case the account is
a Jabber account)

Best,
Huy

[1] https://github.com/coniks-sys/libconiks-server-go/pull/1
[2] https://github.com/arlolra/ctypes-otr/pulls
[3] https://github.com/coniks-sys/libconiks-server-go/
[4] https://github.com/c633/tor-messenger-coniks
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] [GSoC] CONIKS for Tor Messenger - gsoc.hello()

[Huy Vu Quoc]

Hi everyone!

I'm Huy, a senior year undergraduate from HUST-Vietnam, who is starting to work 
with CONIKS for Tor Messenger as a part of Google Summer of Code. This project 
aims at implementing a CONIKS server for key verification and a CONIKS client 
which integrates with the Tor Messenger client. The details of CONIKS system is 
described in [0].

My mentors are Marcela and Arlo.

I will start with this project soon, may be on the first day of May and finish 
at the end of July. Currently, I am studying deeper about crypto primitives. 
After that, I think I will speed up with code base in the GitHub :)

I will be on IRC as c633, in GitHub as c633.

I will send bi-weekly status reports to this list, and also share it on my blog 
[1].

Cheers!
Vu Huy

—
[0]: 
https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-melara.pdf
[1]: http://c633.net
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Huy Vu Quoc]

Hi Arlo,

> > 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.

Thanks for good lesson in UX :). Marcela’s and your comments have helped me 
very much. 

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

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

[Huy Vu Quoc]

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
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] (no subject)

[Huy Vu Quoc]

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
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Huy Vu Quoc]

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 registrati

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

[Huy Vu Quoc]

Dear Marcela, Arlo 

> You’re very welcome, we look forward to your application! 
I have submitted my draft proposal via GSoC website. I am looking forward to 
your feedback.  

Thank you so much!  

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

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

[Huy Vu Quoc]

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

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

[Huy Vu Quoc]

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
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev