[tahoe-dev] Storing a small file leads to a weird read capability

Kevan Carstensen kevan at isnotajoke.com
Wed Apr 7 11:40:35 PDT 2010


At 2010-04-07 14:09 (+0200), Francois Deppierraz wrote:

> Hi folks,
> 
> Storing a 32 bytes file which contains '17' followed by 30 zeros leads 
> to the following read capability:
> 
> URI:LIT:ge3qaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> 
> Here's the file content in hex.
> 
> 0000000 3731 0000 0000 0000 0000 0000 0000 0000
> 0000010 0000 0000 0000 0000 0000 0000 0000 0000
> 0000020
> 
> It looks weird to me to see a cryptographically-secure identifier which 
> doesn't look random enough. Wouldn't such feature lead to potential attacks?

The URI:LIT prefix means that that's a literal cap. Nothing is stored on
the grid as a result of its creation; the cap contains an encoded
representation of your file, as in:

  >>> from allmydata.util import base32
  >>> base32.a2b("ge3qaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa")
  '17\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
  >>> 

and anyone who has that cap need only decode it to get the file. 

In other cap formats, the cryptographic security of the things you see
in the cap is necessary to ensure that attackers cannot violate the
confidentiality or integrity of your files as they sit on the storage
servers (or convince you to accept their violations of those things).
Since nothing is placed on a storage server as the result of an upload
that produces a literal cap, literal caps can be much simpler. Both
literal readcaps and other, more complicated caps are consistent with
the idea of a readcap -- both are a delegation from you to whoever holds
them of the authority to read the resource that they correspond to.

(The NewCaps/WhatCouldGoWrong [1] page on the Tahoe-LAFS wiki is
interesting reading if you want a general idea of what sorts of things
attackers can do to your data as it sits on a storage server, and how
caps can be designed to make those attacks infeasible)

[1] http://allmydata.org/trac/tahoe-lafs/wiki/NewCaps/WhatCouldGoWrong
-- 
Kevan Carstensen | <kevan at isnotajoke.com>


More information about the tahoe-dev mailing list