README

Chronicle is a self-hostable microservice, built with Slim Framework, which enables authorized users to commit arbitrary data to an immutable, append-only public ledger.

Chronicle is superior to "blockchain" solutions for most real-world technical problems that don't involve proofs-of-work or Byzantine fault tolerance.

More precisely, Chronicle is a self-hostable microservice exposing an append-only, cryptographically-secure hash chain data structure that accepts arbitrary data from authorized clients through an HTTP API, secured by Sapient, that can be used as a building block for building a cryptographic audit trail similar to Certificate Transparency.

Chronicle will make you question the need for blockchain technology.

Chronicle was developed by Paragon Initiative Enterprises as part of our continued efforts to make the Internet more secure.

Fork overview

This fork is made to speed up Chronicle development with tons of features while considere using "Semantic Versioning". So, this fork will maintain the compatibility with legacy Chronicle as much as the development process go. ChronicleX is just the flag and the name of the brance. But, the project will use Chronicle as usaual in the legacy.

These are the following features that will be exists in the ChronicleX:

• chronicle/export Pagination.
• chronicle/since Pagination.
• chronicle/replica/export Pagination.
• chronicle/replica/{replica}/since Pagination.
• Fetch "Public Key" by URL in replica command line.
• Fetch "Public Key" by URL in cross-sign command line.
• Make replication command to fetch data while its resources is paginated.
• chronicle/replica Pagination.
• Make tests to covers (SQLite, MySQL & PostgreSQL) Databases at once.
• Create chronicle/instances API to list all instances.
• Extend chronicle/lookup API to search at currhash, summaryhash, publickey, signature and data.
• Create Web Application at chronicle/explorer endpoint to explore chronicle instances.
• Revise cross-sign functionality.
• Revise tests to cover all functionalities.
• Create chronicle/instances API with option to hide some instances.
• Make cross-sign command to fetch data while its resources is paginated.

Getting Started with Chronicle (Documentation)

• Instructions for Installing Chronicle
• How to write (publish) to your Chronicle
• How to setup cross-signing to other Chronicles
• How to replicate other Chronicles
• Concurrent Instances
• Internal Developer Documentation
  • Design Philosophy
  • SQL Tables

Client-Side Software that Interacts with Chronicle

PHP

• Herd - PIE
• Quill - PIE
  • Monolog-Quill - PIE
• Chronicle-API - Lukáš Unger (@lookyman)

What does Chronicle do?

Chronicle allows trusted clients to send data to be included in an immutable, auditable, cryptographic permanent record.

Furthermore, Chronicle has cross-signing and many-to-one replication built-in, which, when used, greatly enhances the auditability and availability of the data written to your local Chronicle instance.

What problems do Chronicle solve?

Chain of Custody

If you have sensitive information, you can write metadata about client access times to a private Chronicle in order to have verifiable, tamper-resistant proof that specific records were accessed by specific user accounts at a specific time.

Proof of Knowledge

By inserting an encrypted message and then revealing the key at a later date, you can provide strong evidence of prior knowledge.

Userbase Consistency Verification

For building a secure code delivery system, committing some metadata and a SHA256 or BLAKE2 hash of each update file to a publicly verifiable Chronicle allows users to compile a whitelist of known update files to help block trojan horse malware (in the event of a compromised update server).

For best results, combine with cryptographic signatures (which may also be registered in the Chronicle) and reproducible builds.

Auditable Security Event Logging

Because of Chronicle's cryptographically assured append-only properties, and its use of modern elliptic curve digital signatures, Chronicle is a good fit for integrating with SIEM solutions and internal SOCs.

How does it work?

All communications are secured with Sapient. Sapient ensures that all published messages are signed with Ed25519. All messages are committed to a hash chain data structure backed by BLAKE2b, which we call Blakechain for short.

There are two hashes for each message:

1. The hash of the current message, whose BLAKE2b key is the previous message's block. This is just called currhash internally.
2. The summary hash, which is a BLAKE2b hash of all message hashes to date, concatenated together in order. This is called summaryhash internally.

The rationale for using the previous message's hash was to add a degree of domain separation in the event that a BLAKE2b collision attack is ever discovered. The keying should reduce the likelihood of any practical attacks, especially if the chain is updated rapidly.

License