[tor-dev] GSoC: Tor Messenger CONIKS integration

Tue Mar 8 15:28:56 UTC 2016

Hello!

On 7 Mar 2016, at 23:06, Arlo Breault wrote:

>> On Mar 5, 2016, at 8:25 AM, Elias Rohrer <ml at tnull.de> wrote:
>>
>> Hello nice people of the Tor project!
>>
>> I'm very interested in using the Google Summer of Code stipend to 
>> integrate the CONIKS key verification protocol into Tor Messenger.
>>
>> So I wanted to say 'Hi!' and introduce myself: I'm a computer science 
>> student at Humboldt Universität zu Berlin in Berlin, Germany. The 
>> main focus of my studies lies on security, computer networks (such as 
>> the peer-to-peer ones) and privacy enhancing technologies.
>> In the last years I mostly worked with C/C++, but these days I'm 
>> learning erlang – mostly for its benefits in concurrent & network 
>> scalable programming, but also to learn 'something different'.
>
> Hello Elias. Nice to meet you and thanks for your interest.
>
>
>>
>> This brings me to some questions regarding the project:
>> If I understand correctly (after reading [1], there are three parts 
>> which should get implemented in course of the project:
>>
>> - A server component which stores the tamper-resistant database and 
>> would be run by the identity providers.
>> - An auditor module which tracks the states of the server and 
>> publishes its view, so users can check that theirs is consistent with 
>> it.
>> - And a client side plugin for Tor Messenger written in JavaScript.
>
> That's correct, though perhaps the project description
> should emphasize that the priority is on the server and
> client components.
>
Ok. The CONIKS paper proposes that an identity provider A publishes its 
commitments to others and then the user can then query  multiple 
identity providers if they all have the same picture of A's commitment.
So, the functionality of auditing commitments would be a subset of the 
server anyhow, I guess then the auditors could also just use the server 
component which was configured to act only as an auditor?!

>
>> Concerning the two first parts: What would be the requirements 
>> concerning the language of the server? The Projects page list 
>> JavaScript and C as required languages, but would you also consider a 
>> server component written in erlang?
>
> Unfortunately, I don't think there's a lot of erlang expertise
> in the Tor community. In order to maintain the server going forward
> (despite any intention you'd have of staying on the project), I
> think it'd be best if we went with a language more developers here
> are accustomed to, such as golang.
>
Ok, then I would probably fall back to implementing the server in C/C++. 
However, there is still some time until GSoC actually starts, maybe I 
can have a look at golang until then. (Which from what I heard could 
also spare one some of the pitfalls of C/C++).

>
>> I could do that in C/C++, but since I'm experimenting with erlang I 
>> thought I'd ask, especially, because I could imagine that the auditor 
>> functionality could be implemented into a XMPP server such as 
>> ejabberd or prosody.
>
> Prosody is in lua, no?
>
Yup

>
>> So, while the CONIKS provider would be more or less centralised for 
>> Tor Messenger, third parties like the XMPP server hosters could act 
>> as auditors by just loading up a plugin for their XMPP server. This 
>> Idea is based on the Q&A found in the ticket [1]. Do you think this 
>> would be a viable idea to roll out the auditor software?
>
>
> While I agree that would probably ease deployment
> for those running ejabberd, it's not very helpful
> in the general case. We'd like anyone to be able to
> run an auditor. And, again, I should stress that the
> other components are the priority and should make up the
> bulk of the work.
>
I see your point. As stated above: I'd try to design the server so it 
can be configured to only act as an auditor.

>
>> This should be it for my first questions. I'll study the CONIKS paper 
>> more in depth in the next days and will come back at you if more 
>> questions come up concerning the project idea – if that's okay with 
>> you.
>
> Sounds great. Again, thanks for your interest
> in the project. Feel free to ping Marcela (masomel)
> and I (arlolra) on irc in tor-dev
>
Ok, thanks a lot, I will!
Two questions came up in the last days:

1. How would the CONIKS client code integrate with the ctypes-otr 
add-on? It would probably be part of it? So should I also have a look to 
implement client functionality in a C library and then use the calls via 
ctypes?

2. While reading the paper I had some confusion about a minor point, 
namely about the way CONIKS calculates the index of a user identity in 
the merkle prefix tree. I know you neither wrote the paper nor the 
reference implementation, but maybe you can shed some light onto this 
issue, even if it is probably a very small one.

On Page 4 the authors state:
"We can implement a VUF using any deterministic, existentially 
unforgeable signature scheme [42]. The signature scheme must be 
deterministic or else (in our application) the identity provider could 
insert multiple bindings for a user at different locations each with a 
valid authentication path. In practice, this could be a classic RSA 
signature [51] (using a deterministic padding scheme such as PKCS v. 1.5 
[26]) or BLS “short signatures” [9], which provide the best space 
efficiency. Many common discrete-log based signature schemes such as DSA 
[30] are not immediately applicable as they require a random nonce.
In CONIKS, we generate the index for a user u as: i = h (sign_K (u))
where h() is a one-way hash function and sign() is a deterministic, 
existentially unforgeable signature scheme. The extra hash function is 
added because some bits of sign_K (u) might otherwise leak through 
binding validity proofs, and signature schemes are generally not 
unforgeable given some bits of the valid signature. The hash function 
prevents this by ensuring the final lookup index leaks no information 
about the value of sign_K (u)."

I understand that using the signature of the user identity ensures that 
no information indicating its existence on the server is leaked. But why 
are they hashing the signature again? RSA-signatures normally already 
consist of a signed hash-value. Why would it bad to leak bits of the 
signature?
Also, if I see this correctly, they don't do it in their reference 
implementation 
(https://github.com/coniks-sys/coniks-ref-implementation/blob/master/coniks_server/src/org/coniks/coniks_server/SignatureOps.java), 
instead they just use SHA256withRSA...
So, am I misreading the paper? Or do they actually mean sign_K(h(u)), 
which would be the normal 'hash and sign' operation of RSA? Or does it 
make sense to rehash the signature and their own implementation is not 
consistent with it?
This is probably no important point, however I want to make sure I'm not 
missing a piece concerning the security of the user identities.

Thank you & Best Wishes

Elias

>> Best Wishes!
>>
>> Elias Rohrer / _tnull @ irc
>>
>>
>>
>> [1]:	https://trac.torproject.org/projects/tor/ticket/17961