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 | <ke...@isnotajoke.com> _______________________________________________ tahoe-dev mailing list tahoe-dev@allmydata.org http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev