2 ms·
> Not to mention that if you're pushing for hard crypto merkle tree stuff, you'd be a fool to do it without things like ecc ram too. Since cosmic rays will blow
by petertodd 3y ago
> Not to mention that if you're pushing for hard crypto merkle tree stuff, you'd be a fool to do it without things like ecc ram too. Since cosmic rays will blow up your data structures. So you're not just making embedded go slow. You're making it less reliable too. Just to wield ironclad remote control of people's personal possessions.
Can you give me an example of how a bit-flip would blow up a cryptographic merkle tree, but not blow up a non-cryptographic file system?
- deleted 3y ago[deleted]
- pravus 3y ago> Can you give me an example of how a bit-flip would blow up a cryptographic merkle tree, but not blow up a non-cryptographic file system? Any bit changes anywhere in the merkle tree immediately destroy its ability to self-verify because the integrity is ruined. Basically the entire tree is dead because you can't add new nodes. Non-cryptographic file systems? A bit-flip changes 1-bit in an isolated place. That one place is ruined but can be easily recovered with checksums or strategies like RAID parity. Detection is harder, though. Either can be recovered at the block level, though. I use merkel trees as a solution for a project at work and it has brittleness issues related to data integrity and we have to solution specifically around it.
- londons_explore 3y agoTurns out most bit flips in non-crypto systems simply have no effect. A bitflip in an error handling path of a binary, where that error never happens - no user impact. A bitflip in a bitmap image buffer - user doesn't notice one miscoloured pixel for 1 frame in an animation. A bitflip in a config datastructure changing 0x00000001 to 0x00400001 - no impact because the whole number is treated as boolean anyway.