Skip to content

CONIKS Java Library v0.2.0

Pre-release
Pre-release
Compare
Choose a tag to compare
@masomel masomel released this 05 Sep 17:26
· 72 commits to master since this release
v0.2.0
This tag was signed with the committer’s verified signature. The key has expired.
masomel Marcela Melara
GPG key ID: 8E556CF999AAFE63
Expired
Learn about vigilant mode.
467fe68

The main goals of this release were to add support for key changes and improve the client's maintainability and facilitate debugging.

Addressed issues: #2, #10, #11, #13, #17

In this Release

Key changes

At a high level, the server and test client now support unsigned key changes, signed key changes, and changes to the key change policy (i.e. allow or disallow unsigned key changes). The default key change policy is to allow unsigned key changes, which means that the server doesn't require a signed key change statement for key changes. However, by default the test client signs all changes including changes to the policy, unless it explicitly initiates an unsigned key change.

For future extensibility, we've introduced the notion of generic key data that is mapped to a name, instead of expecting a specific key type, and added a DSA key pair changeKey used to sign and verify any user mapping changes. This change key is updated with every signed mapping change and is authenticated as part of the mapping change message.

CONIKS Users

We've introduced special classes in the test client representing CONIKS users and client users. CONIKS users are used to represent generic CONIKS users who have a name, public key data, a public change key used for verifying signed mapping changes, and a key change policy. ClientUsers represent users of a specific client, and extend the functionality of CONIKS users to include private key data as well as a private change key used to sign mapping changes. These classes allow the test client to save and keep track of CONIKS users across epochs and perform various operations on existing users.

New test client interface

The test client used to only be able to perform a single operation for a given number of users. We have enhanced the test client interface to prompt the user repeatedly to perform operations on a set of ClientUsers; we believe this interface more closely resembles what the operation of a deployed CONIKS client would be.

Easier server and client configuration, and new operating modes

The server and test client are now configurable via config files. They also now support two different operating modes: testing mode and full operation mode. We hope that this new configuration mechanism and operating modes will help new users get started with working with the reference implementation, and facilitate debugging. Please see the READMEs for details on how to configure the server and test client.

More modular code organization

Most of the server and client functionality was concentrated in only a small number of files. To improve maintainability and facilitate debugging we've reorganized our code as follows:
Server:

  • org.coniks.coniks_server.ServerOps and org.coniks.coniks_server.ConiksServer were refactored into org.coniks.coniks_server.DirectoryOps, org.coniks.coniks_server.TransparencyOps, org.coniks.coniks_server.ServerMessaging, org.coniks.coniks_server.RequestHandler and org.coniks.coniks_server.ServerHistory (see below for details).
  • org.coniks.coniks_server.ConiksServer now only contains a high-level test CONIKS server that initializes the key directory, initiates server history updates and listens for client requests.
  • org.coniks.coniks_server.DirectoryOps implements all high-level directory operations (e.g. registrations, updates)
  • org.coniks.coniks_server.RequestHandler contains the request handler server thread that was in the ConiksServer before
  • org.coniks.coniks_server.ServerHistory implements all STR directory history operations (e.g. taking new epoch summaries)
  • org.coniks.coniks_server.ServerMessaging contains the lower-level messaging functions that were in the ConiksServer before
  • org.coniks.coniks_server.SignedTreeRoot implements the signed tree root as described in the CONIKS paper
  • org.coniks.coniks_server.TransparencyOps implements all transparency-related operations (e.g. generating new signed tree roots, authentication paths)

Test client:

  • org.coniks.coniks_test_client.ConiksClient was refactored into org.coniks.coniks_test_client.ClientMessaging and org.coniks.coniks_test_client.TestClient
  • org.coniks.coniks_test_client.TestClient now only handles the high-level CONIKS operations such as registrations, key changes and lookups.
  • org.coniks.coniks_test_client.ClientMessaging contains the lower-level messaging functions that handle the message exchange between the client and server
Assets 2
Loading