[tahoe-dev] [tahoe-lafs] #750: deterministic IV for writecaps for dir entries

[tahoe-lafs]

#750: deterministic IV for writecaps for dir entries
-------------------------------+--------------------------------------------
     Reporter:  zooko          |       Owner:                 
         Type:  enhancement    |      Status:  closed         
     Priority:  major          |   Milestone:  1.5.0          
    Component:  code-dirnodes  |     Version:  1.4.1          
   Resolution:  fixed          |    Keywords:  confidentiality
Launchpad_bug:                 |  
-------------------------------+--------------------------------------------

Comment(by warner):

 I think this is ok.. we're always using the same data with the same key,
 so no worries there.. we'd be enabling readers to mount a dictionary
 attack if we weren't already doing so by putting the readcap in the
 dirnode contents, so there's no increase in exposure there either.

 I think it would be more accurate to call this a "salt" instead of an "IV"
 though, since 1) we're using CTR mode, and 2) we're hashing this value to
 generate and AES key, not an IV. I don't know what I was thinking when I
 named that value "IV" in the original code.

 Also, looking at the code, we're using two hashes and not using the
 intermediate value anywhere. So how about using just one hash? Instead of:

 {{{
 IV = hashutil.mutable_rwcap_iv_hash(self._node.get_writekey())
 key = hashutil.mutable_rwcap_key_hash(IV, self._node.get_writekey())
 cryptor = AES(key)
 }}}

 we could use something like:

 {{{
 wk = self._node.get_writekey()
 key = hashutil.mutable_rwcap_key_hash2(wk)
 cryptor = AES(key)
 }}}

 where {{{mutable_rwcap_key_hash2}}} is a one-argument function that hashes
 a fixed prefix with the writekey.

 I too am surprised by the apparent speedup. Maybe the kernel context-
 switching time needed to read from /dev/urandom (or the
 refill-/dev/urandom code that gets invoked when you drain few kb from the
 entropy pool) is larger than the SHA256 code that gets invoked by the
 extra hash. In any case, using just one hash ought to be faster than
 either the original code or the attached patch.

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