lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.02.1411041915430.32105@file01.intranet.prod.int.rdu2.redhat.com>
Date:	Tue, 4 Nov 2014 19:27:54 -0500 (EST)
From:	Mikulas Patocka <mpatocka@...hat.com>
To:	"Theodore Ts'o" <tytso@....edu>
cc:	linux-ext4@...r.kernel.org, dm-devel@...hat.com
Subject: Re: [dm-devel] Some thoughts about providing data block checksumming
 for ext4



On Tue, 4 Nov 2014, Mikulas Patocka wrote:

> 
> 
> > > Recovery after a power fail
> > > ---------------------------
> > > 
> > > If the dm-protected device was not cleanly shut down, then we need to
> > > examine all of the checksum blocks in the Active Area.  For each
> > > checksum block in the AA, the checksums for all of their data blocks
> > > should machine either the checksum found in the AA, or the checksum
> > > found in the checksum block in the checksum group.
> > 
> > ... and if the checksum of the block matches BOTH the checksum in the AA 
> > and the checksum in the checksum group (because of checksum function 
> > collision), you don't know which 4-bit nibble belongs to the data in the 
> > block.
> 
> Though, I realize that you could avoid this problem by selecting the 
> appropriate checksum function - that never results in collision if the 
> 4-bit nibble differs.

Hmm, that is still not sufficient.

Suppose that "a" and "b" is sector content without the 4-bit nibble and 
"x" and "y" are two different nibbles.

Now, we have this situation:

a + x -> checksum1
b + x -> checksum1
a + y -> checksum2
b + y -> checksum2

Suppose that we do crash recovery and we have (x,checksum1) in the 
checksum block and (y,checksum2) in the active area - we can't really tell 
which one is valid.

So you really need cryptographic hashes instead of checksums to avoid the 
collisions.

Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ