[ANN - MofNfs: store files in the SuperNET cloud using fully encrypted M of N shared secret fragments]
Since there was no large network for me to test with today, I decided to make two new API calls that allow for cloud storage of files. They are massively encrypted and also M of N is supported to deal with hash collisions, sybil attacks, offline nodes, etc. With the proper M and N settings, I think this will be quite a resilient file storage appropriate for the files you just cant lose. The comms with the cloud are via the DHT API from this weekend and the L parameter is for the max number of onion layers to use and all the packets are the same size, so there is no leakage based on packet size.
Now I am not sure what all the other decentralized storage projects are doing and I am sure what I did today is just a small portion of a full system. Still, after I debug it tomorrow, it will be an easy way to safely put things in the cloud.
char *savefile[] = { "filename", "L", "M", "N", "usbdir", "password", 0 };
char *restorefile[] = { "filename", "L", "M", "N", "usbdir", "password", "destfile", "sharenrs", "txids", 0 };
./BitcoinDarkd SuperNET '{"requestType":"savefile","filename":"","L":0,"M":1,"N":1,"usbdir":"","password":""}'
The savefile will print (and save in usbdir) the required sharenrs and txids JSON fields to use for the restorefile.
The "destfile" field is where the file will be reconstructed.
If the "usbdir" parameter is set, then local backups are made (highly recommended!) and it is used to check the data coming back from the cloud. After you verify that the cloud has a proper copy, then you can partition the various parts from the usbdir directory to various places to have two full backups, one under your local control and one in the cloud.
The max value for N is 254 and M has to be less than or equal to N. The M of N parameters are independent of the "password" field. If you are using M of N, then unless the attacker gets a hold of M pieces, they wont be able to reconstruct the file. Without the txid list, the attacker wont know how to reconstruct the file.
But why take any chances. so I made the password field use an iterative method to create what I think is a pretty practical encryption method, which is based on the name of the file, your pubNXT acct passphrase and the password itself. The length of the password determines the number of ciphers that are applied
namehash = calc_txid(name,strlen(name));
len = strlen(password);
passwordhash = (namehash ^ calc_txid(keygen,strlen(keygen)) ^ calc_txid(password,len));
for (i=0; i {
expand_nxt64bits(key,passwordhash);
cipherids = (password % NUM_CIPHERS); // choose one of 18 ciphers
privkeys = clonestr(key);
if ( i < len-1 )
passwordhash ^= (namehash ^ calc_txid(key,strlen(key)));
}
Since the keygen is the pubNXT password, which in turn is a dumpprivkey for a BTCD address, this assures high entropy and the filename being encrypted is added to the passwordhash so that different files will have different encryption keys. By using the password to modify the initial password hash and to determine the number of ciphers and their sequence creates a lot of impact from even a short password, like a PIN
When M of N is combined with password, the attacker would need to get a hold of the name of the file, M fragments, the list of txids, the randomly generated sharenrs array and the password you used. Unless your computer is totally compromised and you divulge your short password, this seems like a pretty good level of security.
Now with the DHT there is the chance of collision, sybil attacks, inaccessible nodes, etc. I think using M of N side steps all of these issues. Also, the txid (calculated like NXT does) is based on the contents being stored, so it would take a lot of computation to be able to even get control of the nodes needed to block access to any specific content and near impossible to spoof anything. Maybe someone can come up with a sybil attack that can be done? However, without knowing the hash values of all the fragments, where will the sybils setup their attack? And will they be able to invalidate M copies that they dont know the txid for?
The following are the ciphers:
"aes","blowfish","xtea","rc5","rc6","saferp","twofish","safer_k64","safer_sk64","safer_k128",
"safer_sk128","rc2","des3","cast5","noekeon","skipjack","khazad","anubis","rijndael"
Having a place to store things reliably will help with managing telepods, especially since with the privateblockchains, any loss of data on your computer would not be good. So I think I will default to cloud backup for the telepods. Unless your computer is compromised and your divulge your passwords, it wont do anybody any good to get some telepod fragments. In any case, if they have compromised your computer, they would have access to the same data.
James
