191–200 of 258 posts
[1] https://forum.restic.net/t/troubleshooting-unreproducible-co...
The push for crypto without ecc ram is a nonstop horror show. Software under normal circumstances is remarkably resilient to having its memory corrupted. However crypto algorithms are designed so that a single bit flip effectively changes all the bits in a block. If you chain blocks then a single bit flip in one block destroys all the blocks. I've seen companies like msps go out of business because they were doing cr…
Not really? What you are saying applies to anything that uses hashing of some sort, where the goal by design is to have completely different outputs even with a single bit flip.
And "resilience" is not a precise enough term? Is just recovering after errors due to flips? Or is it guaranteeing that the operation will yield correct output (which implies not crashing)? The latter is far harder.
This leaves with a bit of concern about how reliable is storage encryption on consumer hardware at all. As far as I know, recent Android devices and iPhones have full disk encryption by default, but they do protect the keys against random bit-flipping? Also, I guess that authentication devices (like YubiKey) are not safe and easy to use at the same time, because the private key inside can be damaged/modified by a cos…
ECC RAM would help somewhat, but independent verification is orders of magnitude better because it's a cryptographic protocol and a reliable way of generating broken log entries that validated on another system would constitute a reliable way to generate SHA2 collisions.
What log operators should be doing, and I am surprised they are not, is verifying new additions to their log on a separate system or systems before publishing them. In the worst case scenario they might hit a hardware bug that always returns the wrong answer for a particular combination of arguments to an instruction in all processors within an architecture, so verification should happen on multiple architectures to…
I wonder if the CT log should have been more like that...?
What log operators should be doing, and I am surprised they are not, is verifying new additions to their log on a separate system or systems before publishing them. In the worst case scenario they might hit a hardware bug that always returns the wrong answer for a particular combination of arguments to an instruction in all processors within an architecture, so verification should happen on multiple architectures to…
This is a rare example of a problem that a (closed-membership, permissioned) blockchain is a good fit for. CT logs are already merkle trees. If a consensus component were added, entries would only be valid if the proposed new entry made sense to all parties involved.
Earlier quoted context omitted.
I haven't thought about whether an actual blockchain is really the best solution, but the redundancy argument is legitimate. We've been doing it for decades in other systems where an unnoticed bit flip results in complete mission failure, such as an Apollo mission crash. I'm not really sure what Yeti 2022 is exactly, so take this with heaps of salt, but it seems like this is a "mission failure" event -- it can no lon…
> I'm not really sure what Yeti 2022 is exactly Sometimes there are problems with certificates in the Web PKI (approximately the certificates your web browser trusts to determine that this is really news.ycombinator.com, for example). It's a lot easier to discover such problems early, and detect if they've really stopped happening after someone says "We fixed it" if you have a complete list of every certificate. The…
Obviously that's a huge pain but in theory it would work?
Earlier quoted context omitted.
Not sure what you mean with "safety critical". I made no such assumption. Also since the topic is about a (write-only) log it probably doesn't need such low latency. What it more likely needed is final states so once a entry is made and accepted it must be final and ofc correct. DLTs can do this distributed and self-fixing i.e. a node that tries to add fault data is overruled and can never get a confirmation for a fi…
You said If a system is critical I thought you were making a more general statement about all critical systems, that's all. And since many critical systems have a safety factor in play, I wanted to distinguish them as not always being a good target for a Blockchain solution to the problems of consensus. Blockchain is a very interesting solution to the problem of obtaining consensus in the face of imperfect inputs, th…
>...blockchain is going to be overkill for dealing with some types of fault tolerance
But it this case likely it isn't. The current systen already works with a chain of blocks its just lacks the distributed checking and all that stuff. But "blckchains" aren't some secret sauce in this case it just an way to implement a distributed write-only database with filed proven tech. It can be as lightweight as it any other solution. The consensus part is completely irrelevant anyway because all nodes are operated by one entity. But due to the use case (money/value) of modern DLT ("blockchains") they are incredible reliable by design. The oldest DLTs that uses FBA (instead of PoW/PoS) are running since 9+ years without any error or downtime. Recreating a similar reliable system would be month and month of work followed by month of testing.
Earlier quoted context omitted.
This is a rare example of a problem that a (closed-membership, permissioned) blockchain is a good fit for. CT logs are already merkle trees. If a consensus component were added, entries would only be valid if the proposed new entry made sense to all parties involved.
Blockchains are fork-tolerant whereas append-only SCT logs are not, intentionally so.
There is no requirement that the consensus mechanism used permit forking in a blockchain.