CONIKS Java Library v0.4.0

The main goals of this release are to set the basis for transitioning the Java reference implementation to a more developer-friendly, usable Java library. This requires substantial code reorganization into individually reusable packages, adding unit tests, and stricter adherence to the CONIKS specification given in the original paper.

As first steps, we renamed this repo to coniks-java, and switched to Maven builds. We also refactored the cryptographic operations and utility functions into individual packages, and added unit tests to these packages. Additionally, we implemented cryptographic commitments, which are used by the Merkle tree to protect the privacy of user data during lookups.

Addressed issues: #33, #34, #35, and #40

In this Release

Renaming coniks-ref-implementation to coniks-java

We decided to rename this repo to coniks-java to signal the transition to a more developer-friendly and usable library. As we begin developing CONIKS libraries for other languages, we seek to make our implementations more cohesive and compatible, so we believe this new name is more suitable for a Java library and helps establish a clear naming scheme for the different CONIKS implementations.

Maven builds

To improve the maintainability and usability of the library, we move to Maven builds. Using Maven facilitates dependency management, testing, and packaging, and we hope this will improve developers' ability to import and use any (or all) coniks-java packages.

Restructuring the code base

We designed our Golang implementation (coniks-go) to be more modular and usable from the start; to make the Golang and Java CONIKS APIs compatible, we plan to follow the same code base structure in both implementations (see #32). Transitioning to coniks-go's code structure in coniks-java will take some time as existing features are migrated to their respective individual packages, so we have decided to reorganize the coniks-java code base incrementally.

Important: As we restructure the code base, we will deprecate the parts of the API we have migrated, so please make sure to update any code that may be using the deprecated APIs.

Unit Tests

To improve the maintainability and developer-friendliness of coniks-java, we have started adding unit tests. These unit tests do not cover any existing code that will be deprecated and replaced by the new individual packages, they only cover new packages. We measure our test coverage using coveralls.

crypto and util packages

Since the crypto and util packages are the most fundamental packages of a CONIKS implementation, these are the first two packages we refactored and covered by unit tests.

Cryptographic commitments

As part of our effort to adhere to the CONIKS specification more closely, we implemented a basic cryptographic commitment scheme that is designed to protect the privacy of users' data during key lookups. This scheme will be used in the upcoming Merkle tree package.

CONIKS Java Library v0.3.0

The main goal of this release was to use Google Protobuf's bytes type for protobuf message fields that hold byte arrays, instead of repeated int32. We also patched a buffer overflow bug that was causing the Merkle prefix tree hashing to hang.

Addressed issues: #1 and #30

In this Release

API changes in generated Protobuf classes

org.coniks.coniks_common.C2SProtos and org.coniks.coniks_common.UtilProtos API which reflect the transition to ByteStrings.

API changes in ServerUtils

intListToByteArray() and byteArrayToIntList() have been removed from org.coniks.coniks_server.ServerUtils.

Bug fix in Merkle tree hashing

Fixed a BufferOverflowException in getUserLeafNodeBytes() in org.coniks.coniks_server.ServerUtils that was causing the tree hashing operation in the org.coniks.coniks_server.TreeBuilder to hang.

CONIKS Java Library v0.2.0

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

Initial Release

In this Release

This release serves as the first version of the reference implementation of the CONIKS system.

The CONIKS server implements the basic functionality of an identity provider: it maintains the key bindings in a Merkle prefix tree, and it supports new key registrations and key lookups, and the generation of authentication paths (proofs of inclusion) and directory summaries (currently called commitments in the code).

The simple test client supports new key registrations, key lookups and authentication path verification, both in individual mode and in batch mode (see the instructions for running the test client).

The protobufs define message formats for key registrations and registration responses, key lookups, authentication paths, summary requests, and summaries.