Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] SSD drives vs. Mechanical drives



> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
> bounces+blu=nedharvey.com at blu.org] On Behalf Of Bill Bogstad
> 
> And checksums can be incorrectly generated/verified by any hardware at any
> time.
> I claim that 100% data integrity is impossible. 

You have some control over the type of cksum used.  On zfs, by default they use fletcher4, which is very strong against accidental (random) bitflips, but easily fooled by a deliberate attacker.  If you completely overwrite data with random garbage, then you have a probability of approx 1 in 4 billion producing a fletcher collision.  But the fewer bitflips exist between the actual data and the corrupted data, the lower the probability of cksum collision.  For example, I think fletcher will 100% reliably detect a single bitflip (I may be wrong, but I think so) but when you layer in more and more randomly corrupted bits, then the probability of the fletcher failing is increased and approaches as I said, a very low maximum probability of 2^-32.  (Non-intelligent attacker assumed.  Random corruption.)

You may if you wish, choose SHA-256.  In which case, even an intelligent attacker cannot, with all the cpu's presently on earth, ever find a collision in 3.8*10^52 years.  Considerably longer than the life of our solar system.   (Estimated 9.6 billion cpu cores each capable of 10m SHA256 calculations per second). 

So as you claimed, not 100%.  But there are 78 nines.  99.9999999....%



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org