How to verify contents response?

[catahax313]

This project seems interesting and potentially something I'd like to use for a project, however not entirely sure how the design works on the verification side.

I installed the Chronicle and a replica. How can the clients be sure that the contents returned from a Chronicle are intact? Do you have an pseudo code example of that?

My understanding is that you'd query multiple replicas and compare the contents response? But I feel like I'm missing something.

For example, is it required to compare the contents field against the currhash; if so how may the client compute that hash? Or is this only done as part of the Chronicle replication process?

[paragonie-scott]

What you're verifying depends on your threat model. Any or all of the following may be appropriate.

Verifying API Responses

If you're trying to ensure the HTTP response hasn't been tampered with (e.g. MitM from an attacer with a CA cert), Chronicle uses Sapient.

You can verify the Body-Signature-Ed25519 header (which is base64url encoded, as per RFC 4648, and authenticates the HTTP response body against the static application-layer public key). Or you can use Sapient (we provide PHP and JS implementations) to verify the signature and return an associative array of the decoded JSON response body in one fell swoop.

Verifying Hashes

If you're interested in the integrity of a specific record, the simplest way to verify that is to set up your own Chronicle replica. The replication process is designed to automatically verify updates it receives from the source Chronicle.

If you're like to build your own verification logic, look at the Blakechain source code.

The currhash is the BLAKE2b hash of the message body, with the BLAKE2b key set to the previous entry's currhash.

The summaryhash is a hash of all of the currhash values concatenated together. (This is accomplished with a streaming API process in the implementation, but if you concatenate every raw binary currhash from the start of a chain, you will get the summaryhash for the latest node.)

In this way, we manage to facilitate writes at the cost of two BLAKE2 hashes rather than rehashing half of an entire tree.

Verifying Userbase Consistency

You simply want several independently operated Chronicle replica instances in the world that replicate the same source. To establish quorum, perform a lookup of the summaryhash you are most interested in, and ensure that the response is valid. Furthermore, make sure that all records have identical bodies. (They will have different signatures since they're provided by different Chronicle instances, and thus different Ed25519 keypairs.)

Your quorum theshold (at least 2 of 3, at least 3 of 10, etc.) will likely depend on the availability of replica servers in the world. You should in general place the minimum somewhere between 2 and sqrt(N) (where N is the number of available replicas).

A lazy approach that will likely scale well is 1 + floor(log2(N)), which with 1024 servers will require 11 agreements. You probably want to use a secure random number generator e.g. for selecting these candidate nodes.