defense against split view attacks about trillian HOT 3 CLOSED

Take a look at https://github.com/google/trillian-examples/tree/master/witness/ for our generic witness. The nested directories up to and including https://github.com/google/trillian-examples/tree/master/witness/golang/omniwitness/monolith are worth visiting too, as these contain the generic implementation, a Dockerized version that monitors all known public logs that use the generic checkpoint format, and finally a single binary that does this all as a single process.

Each individual witness deployment checks that it sees an append-only view of the log. In order to get a central view of what multiple witnesses see, we have experimental distributors running (https://github.com/mhutchinson/mhutchinson-distributor, https://github.com/WolseyBankWitness/rediffusion). Witnesses push any checkpoints they have co-signed to these distributors in the form of PRs. Github actions merge these PRs after validation, and also merge any equivalent checkpoints seen by multiple witnesses. The code backing these is from https://github.com/google/trillian-examples/tree/master/serverless/deploy/github/distributor. This approach seems to work well, and we are considering what a non-experimental version of this would look like.

from trillian.

Hi Jan,

Yes, this is something we're looking at currently.
We're experimenting with what we're calling "witnessing", there's some working code and notes here: https://github.com/google/trillian-examples/tree/master/witness
Some of the thinking behind it is in the Think Global, Act Local: Gossip and Client Audits in Verifiable Data Structures paper.

We have an experimental deployment up which is witnessing a number of active logs (both Trillian and non-Trillian-based [e.g. serverless logs). At a high level, we have a few witness nodes running which watch known logs for updated checkpoints, verify consistency with prior checkpoints they've seen for the same log, and cosign [only] checkpoints which are consistent. These "witnessed" checkpoints are then made available through some sort of "distributor" for Believers to consume (they would have their own policy about what constitutes a "good" checkpoint - e.g. "the newest checkpoint signed by the log, and at least 3 known witnesses one of which should be either EFF or my friend Dave" or whatever).

We have some very experimental/placeholder distributors running on GitHub (e.g. https://github.com/WolseyBankWitness/rediffusion), these use GitHub Actions to update themselves based on automated PRs from the witnesses. We'll likely be looking at other mechanisms for distributing checkpoints in the future though.

There's a [hopefully] very easy to deploy all-in-one binary we're using for this at the moment if you'd like to have a play with it too: https://github.com/google/trillian-examples/tree/master/witness/golang/omniwitness/monolith

Hope that's helpful, would love to hear more about your particular use case of transparency logs too.

from trillian.

I'll close this for now since there's been no further follow up, feel free to reopen though.

from trillian.