Does it checksum metadata only? Is there checksum support for file's data?
Also, CRC32 seems a little bit weak.
As far as i know, CRC32 is used by many hardware internally for error correction.
When data corrupted and undetected in hardware level (which means the hardware CRC32 test probably passed without error), i doubt how reliable that ext4's CRC32 can detect corruption.
At least an alternative implementation of MD5 should be provided, the overhead should be acceptable if those crypto library are written in SIMD instruction (MMX, SSE)
Announcement
Collapse
No announcement yet.
EXT4 In Linux 3.5 Gets CRC32 Meta-Data
Collapse
X
-
Via's cpus have supported hardware SHA-1/SHA-256 for years. Many ARM cpus also support it in hw.
Leave a comment:
-
Modern x86 (and IIRC SPARC) processors have hw accelerated CRC32C. "Luckily", the exact same polynomial is used in the btrfs and ext4 crc checksum, among others, allowing those to benefit from the hw acceleration.
Leave a comment:
-
Originally posted by smitty3268 View PostYou could replace it with SHA-1, but what would that give you? A much more complicated and CPU-taxing algorithm, and nothing else. Crypto hashes have to be a lot more complicated so that small changes to the data provide pseudo-random changes to the hash that can't be reverse-engineered. There's isn't a single good reason to want that overhead in an integrity check.
Leave a comment:
-
Originally posted by smitty3268 View PostThere's a reason every FS and DB I've ever heard of that added checksums uses simple CRC hashing.
It's a simple algorithm that is well suited to the task.
You could replace it with SHA-1, but what would that give you? A much more complicated and CPU-taxing algorithm, and nothing else. Crypto hashes have to be a lot more complicated so that small changes to the data provide pseudo-random changes to the hash that can't be reverse-engineered. There's isn't a single good reason to want that overhead in an integrity check.
If you want to verify that the data hasn't been tampered with, you should just encrypt the whole FS.
Leave a comment:
-
Hopefully by the time F18/F19 will be released e2fschk will support on-disk upgrade giving an option, via anaconda, to switch existing ext4 to CRC-check-summed.
As it stands, I doubt that I'll be using btrfs before 2014 and better error detection in existing stable FS is always welcome.
- Gilboa
Leave a comment:
-
Originally posted by uid313 View PostNo, SHA-1 is not a cipher, it is a hash algorithm. It does not encrypt anything.
SHA-1 is very suitable to verify the integrity of data. Not only does it verify that the data is not corrupted, it also verifies the integrity of the data, that it has not been tampered with.
It's a simple algorithm that is well suited to the task.
You could replace it with SHA-1, but what would that give you? A much more complicated and CPU-taxing algorithm, and nothing else. Crypto hashes have to be a lot more complicated so that small changes to the data provide pseudo-random changes to the hash that can't be reverse-engineered. There's isn't a single good reason to want that overhead in an integrity check.
If you want to verify that the data hasn't been tampered with, you should just encrypt the whole FS.
Leave a comment:
-
Originally posted by oliver View PostDon't feed the troll, I'll bite anyhow.
CRC is used to verify that the data inside the block is not corrupted. it's a redundancy check. Is my super-block valid, or not.
CRC-64 is not that useful in this specific scenario.
SHA-1 is completely useless as that is a cipher. The point was not to encrypt the metadata, just to verify it.
SHA-1 is very suitable to verify the integrity of data. Not only does it verify that the data is not corrupted, it also verifies the integrity of the data, that it has not been tampered with.Last edited by uid313; 01 June 2012, 06:34 PM.
Leave a comment:
-
Originally posted by uid313 View PostWhat about CRC-64?
What about using a secure hashing algorithm such as SHA-1 or Skein?
CRC is used to verify that the data inside the block is not corrupted. it's a redundancy check. Is my super-block valid, or not.
CRC-64 is not that useful in this specific scenario.
SHA-1 is completely useless as that is a cipher. The point was not to encrypt the metadata, just to verify it.
Leave a comment:
-
Checksum
What about CRC-64?
What about using a secure hashing algorithm such as SHA-1 or Skein?
Leave a comment:
Leave a comment: