[tor-dev] [GSoC] CONIKS for Tor Messenger - status report #3
Huy Vu Quoc
huyvq.c633 at gmail.com
Fri Jul 1 16:40:40 UTC 2016
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 .
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 )
- 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
- The verification message (Twitter direct message) format is:
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 .
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
More information about the tor-dev