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