From: Gregory Maxwell <gmaxwell@gmail.com>
To: reiserfs-list@namesys.com
Subject: Plugin for corruption resistance?
Date: Fri, 11 Feb 2005 13:58:59 -0500 [thread overview]
Message-ID: <e692861c05021110583585f84e@mail.gmail.com> (raw)
Anyone ever given a though to adding support to reiserfs to store a
cryptographic checksum along with a file?
The idea is that files get a hidden attribute that contains their SHA1 hash.
If the file is modified, the hash is marked as 'unclean'. A trusted
cleaner comes by eventually and hashes the file, OR the file is hashed
right away if someone tried to read the attribute while the file is
unclean.
Fsck could be optionally told to go check the hash on every file.
Files could also be tested via a background process that randomly
tests some files every night.
Why would this be useful?
1. Lots of applications today (such a P2P sharing systems) need the
hashes of files.. it's inefficient to keep recomputing them. The file
system always knows when a file changes, so it can be setup to always
return the correct hash.
2. Random disk corruption can go undetected (even if the drives ECC is
sufficient to prevent corruption there could be memory, bus, or kernel
issues the corrupt data, a hash will help it be detected).
3. Although there are encrypted block devices available in Linux, none
of them can provide authentication.. So it's possible for an attacker
(with access to your disk) to replace hunks of files with random (and
potentially chosen depending on the chaining mode) crud without
detection.
4. It could greatly speed up casual verification of files for changes
(if you don't trust the kernel to report the true hash, then you
couldn't trust it to return the real file to some userspace file
verifier either).... it could also be used to help locate duplicates
in a very efficient manner..
next reply other threads:[~2005-02-11 18:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-11 18:58 Gregory Maxwell [this message]
2005-02-11 20:39 ` Plugin for corruption resistance? Jake Maciejewski
2005-02-11 20:53 ` Tom Vier
2005-02-12 5:19 ` David Masover
2005-02-13 3:48 ` Esben Stien
2005-02-14 2:01 ` Reiser 4 Apple Michael James
2005-02-14 18:49 ` Hans Reiser
2005-02-14 17:45 ` Plugin for corruption resistance? Hans Reiser
2005-02-15 20:42 ` Adam
2005-02-17 4:10 ` David Masover
2005-02-17 10:53 ` Christian Iversen
2005-02-18 3:43 ` David Masover
2005-02-18 4:28 ` Valdis.Kletnieks
2005-02-18 13:36 ` Gregory Maxwell
2005-02-18 22:09 ` Valdis.Kletnieks
2005-02-19 3:28 ` Gregory Maxwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e692861c05021110583585f84e@mail.gmail.com \
--to=gmaxwell@gmail.com \
--cc=reiserfs-list@namesys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.