Client send salt along with the registration

[vqhuy]

During our last meeting, we discussed how should the server/the client compute the commitment:

• Main concern: server is using a static salt which would allow an attacker to test whether keys exist in the tree
  => client sends salt along with the registration
  => need secure PRNG

• How to ensure the server is using the right commitment scheme? Client should verify with the scheme specified in the STR policy.

[chesnokovilya]

Is crypto/Rand library [https://golang.org/pkg/crypto/rand/] secure enough for salt implementation?

[masomel]

We currently use Go's crypto/rand package for salt generation (see https://github.com/coniks-sys/coniks-go/blob/master/crypto/util.go#L61), so it should be fine to continue using crypto/rand to generate a salt on the client side.

[chesnokovilya]

Where should client store salt?

[vqhuy]

Sorry for the late response. As you mentioned in your email, we could store the salt (and other things) in a json-encoded file. OTOH, as we discussed in #193 (comment), we'll eventually do some sort of abstract API for persistent storage.

[chesnokovilya]

Fine, so It will goes like this (in simple terms):
When client register he creates salt and save it on hard drive and send it to server. Server take salt and calculate commitment with it and key:value. When client audit the system he reads salt from the disk and check server commitment and STR of merkle tree.

It means there are required changes to client, protocol, server, pam, merkletree, and util folders.