Finally (slowly) making progress on my cooperative storage cluster project
The idea is to have a distributed storage system that lets you set up a cooperative storage cluster between multiple semi-trusted parties; with RAID-like striping across participants (so more efficient than duplication) but with all data being encrypted and independently verifiable, so it's resistant to stuff like hacked systems. It's strongly inspired by Tahoe-LAFS (but makes some different design choices for practical reasons).
I got stuck on a seemingly trivial problem; how to make the hashes of different storage objects verifiable while also allowing retrieval of a file when the only thing you have is its decryption key
@joepie91 Why does your starting point have to be just the key, and not, say, also hash of the encrypted blob? Is deniability an important design goal?
@riley Practicality; you need the key to access the file's contents either way, *and* an address to locate the data to retrieve and decrypt in the first place, so if you were to use the hash of the ciphertext as the address, you would effectively double the size of the address; the actual address plus the decryption key.
By using a hash of the decryption key as the address, having the decryption key alone is enough to locate *and* decrypt the file, and it still lets you share that hash with others to give them access to the ciphertext only (which is necessary for some low-trust maintenance tasks).
