[tahoe-dev] [tahoe-lafs] #453: safely add plaintext_hash to immutable UEB

tahoe-lafs trac at allmydata.org
Mon Feb 22 20:42:09 PST 2010


#453: safely add plaintext_hash to immutable UEB
-------------------------------------------+--------------------------------
 Reporter:  warner                         |           Owner:           
     Type:  enhancement                    |          Status:  new      
 Priority:  major                          |       Milestone:  undecided
Component:  code-encoding                  |         Version:  1.0.0    
 Keywords:  integrity newcaps performance  |   Launchpad_bug:           
-------------------------------------------+--------------------------------

Comment(by zooko):

 If we require a "flat hash" of anything (i.e. a Merkle–Damgård
 construction such as SHA-256 or one of the Merkle–Damgård, HAIFA, or other
 "chain-like" or "sponge-like" constructions that are SHA-3 candidates)
 then compatible implementations will be unable to parallelize the
 computation of the secure hash.

 Most of our data structures are parallelizable. It would be kind of a
 shame if some future implementation of Tahoe-LAFS on a
 [http://greenarraychips.com/home/documents/greg/GA144.htm 144-core
 ColorForth chip] had to stop processing a Tahoe-LAFS data structure in 144
 parallel streams and wait for one of its cores to process the whole input
 by itself. :-)

 In contrast, if we require a Merkle Tree hash of the thing, then future
 implementations will have the option of parallelizing the computation of
 it.
 A properly specified Merkle Tree has the same security properties as a
 flat hash has, although it doesn't have the property that it will detect
 bugs in the Merkle Tree implementation.

 Another property that it doesn't have is that it computes a widely
 understood, standardized hash value of the input. (Unless, of course, we
 can convince the SHA-3 standards body to standardize on a tree hash
 instead of a linear hash.)
 So anyway, in the short term I think we should either not have a plaintext
 hash at all (which is the current situation) or have one which is optional
 so future implementations can skip it or define a Merkle Tree hash of the
 plaintext instead of a linear hash.

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/453#comment:3>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid


More information about the tahoe-dev mailing list