Comment by JanisErdmanis | Hacker News Reader

Comment by JanisErdmanis | Hacker News Reader

Parent Full thread

I generally agree with what you have said. However regarding this part

> Yes, Clients are "thin", to use blockchain terminology, but they don't monitor the Log in order to detect attacks

The clients can monitor the ledger via consistency proots and it is highly beneficial as that prevents any chances of split being undetected view without requiring to trust other parties in the process. Clients submiting the record to the chain they can get inclusion proofs, but they can also at random times can query that the previous chain root commitment is consistent with existing one in the process keeping consistency proof chain. If it isn't judiciary actions in the presence of evidence can be taken against the authorithy. This is particulary interesting when ledger hosts votes which allows for a fully centralized deployment which is the basis of an voting system I am developing [1].

> it is important that Clients trust multiple logs for redundancy

Replication solves the issue that the records would would always be available which can be done by anyone who has stakes in the integrity of the ledger. Wheras the censorship reistance is an emergent phenomena where multiple people organize and collect unincluded records and overthrows the authorithy. Thus there is no actually need for Clients to trust multiple logs. Clients only need to trust that they would be able to do incident response in the case of misbehaving authorithy.

[1]: https://janiserdmanis.org/artefacts/EVOTEID-2023-poster.pdf

> The clients can monitor the ledger via consistency proots and it is highly beneficial as that prevents any chances of split being undetected view without requiring to trust other parties in the process. Clients submiting the record to the chain they can get inclusion proofs, but they can also at random times can query that the previous chain root commitment is consistent with existing one in the process keeping consistency proof chain.

The design you're describing doesn't have those security properties.

A malicious or compromised Log conducts a split-view attack by showing different views of the Log to different parties. This is done by providing different parties with different inclusion proofs and consistency proofs. Thus the Log remains consistent from the respective network vantage points of the target(s). They all see an append-only log.

A Client or Monitor shouldn't merely be concerned with whether the Log is consistent from their vantage point. It should be concerned with whether the Log is globally consistent, i.e. whether all views of the Log are consistent with each other. Historically this has led to designs where the Clients gossip consistency information to each other, the introduction of Log Auditors and witness cosigning. I prefer witness cosigning, although to be fair Clients gossiping can work in some designs. Apple's transparency log design is one example, if I remember correctly. It's been a while since I thought about transparency logs.

> A malicious or compromised Log conducts a split-view attack by showing different views of the Log to different parties. This is done by providing different parties with different inclusion proofs and consistency proofs. Thus the Log remains consistent from the respective network vantage points of the target(s). They all see an append-only log.

You are spot on the vantage points. It is therefore at utmost necessity that the server does not know who has made a request, is not able to track clients. This is why requests need to be routed through anonymization service like TOR to preserve a single consitent view. The client only gives away the current root commit index they have stored locally which gives a little wiggle room there to be malicious. The latter can also be improved by first asking for the current tree root commitment and then aksing consitency proof with respect to locally stored commitment.

The global consistency in this design is achieved by the server not knowing who makes requests and thus gosiping is not needed.

We considered this design and rejected it because it requires an ultimately unwinnable cat-and-mouse game of fingerprint resistance.

Things the log can use to partition the users include their Tor version, HTTP library behavior, contact periodicity... the list goes on and on, and keeps restricting the use cases where it can be deployed securely even just in theory.

Witness cosigning is secure even if the way you fetch the proofs is completely attacker-controlled, which is closer to user expectations of regular digital signatures.

For my application of the history trees (tansparency log) there are additional measures that help to ensure a global consistency view eventually. The authorithy would need to publish the final tally at the end of the vote which also would contain a tree root. The tree root would be distributed in print, in official anouncements thus any user can check that the tree root shown on the client coresponds to that with anounced tally and thus the authorithy would not know who does the check. Thus it would be unreasonably hard for adversary to deploy a deception attack at such scale.

Additional measure is that the TOR integration with the help of Arti project is deployed with the client. That ensures that every client does make the requests in the same way. It is surelly important to not disclose the server any local data or make identity revealing requests within the same session like giving away clients local commitment index before the server has shown their current commitment. Using anonymous channel for ensuring global consitency for sure is not universal but for some applications it is doable if the problem is approached holistically particularly in situations where anonymous channel is already needed within the protocol.

> Witness cosigning is secure even if the way you fetch the proofs is completely attacker-controlled

Opting for this approach makes sense if the protocol doesn't initially require an anonymous communication channel. However, if the protocol already uses it, introducing an additional assumption for trusted witnesses adds complexity.

Reply on news.ycombinator.com