Need to restore zeroed file
dstainton415 at gmail.com
Thu Jul 9 21:35:41 UTC 2015
I'm sorry to hear about your data loss. It is my understanding that if
you do not possess a cryptographic capability for either ReadOnly or
ReadWrite access to a file, you will NOT be able to recover it. That
is... not with some sort of cryptographic attack.
You might check if any of your Tahoe-LAFS aliases link to the file or
directory that you are trying to recover. In other words, you can
either choose to "remember" a capability inside or outside of tahoe.
On Thu, Jul 9, 2015 at 2:22 PM, Ed Kapitein <ed at kapitein.org> wrote:
> On 07/09/15 21:00, Roland Haeder wrote:
>> Hello all,
>> bad news: One of my files in my storage got zeroed and I don't have the
>> old (working) URI or up-to-date backup (only from 2013).
>> I have currently written a brute-forcer which currently *should* test
>> all possibilities. Sure this needs massive improvement.
>> So I need to know something:
>> 1) Is this URL pattern valid:
>> <key1> = 26 Byte long character consisting of a BASE32 checksum
>> <key2> = 52 Byte long character consisting of a BASE32 checksum
>> <num> = Random number from 0 to 99999
>> <filename> = The file's name without path
>> 2) Is z_base_32_alphabet or rfc3548_alphabet taken as an alphabet?
>> 3) Do I calculate this correctly?
>> 26 length, each can have 32 different characters (key1)
>> This means 1*32^26 =
>> possibilities for key2?
>> 3) Do I *really* have to brute-force them all to find the correct URI?
>> Or can someone (I don't like to paste brute-forcer publicly) improve the
>> search algorithm?
> Well, without doing the actual math, i think our sun has died before you can
> bruteforce key1*key2*99999.
> Do you have the storage index for the lost file? that might give you a
> fighting change to get the content back.
> Kind regards,
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
More information about the tahoe-dev