AnonyMint understood Teleport after James explained it to him.
This isn't satisfactory. This whole word of mouth explanation to individuals is not cryptography. There needs to be vetted math, science, crypto and code for all to see.
Did BBR get sucked into SuperNET due to jl777 being the biggest BBR holder and XMR showing him the door? Some of what XMR bullies did I definitely frown upon (mainly Poloniex not able to milk money from ICO after giving XMR all the life it has), but can you blame them for not supporting convolution?
That's fine if it's not sufficient. I didn't mean to say that it was. I was mainly replying to the assertions that no one understood it.
There's no rush here. It's being developed and no one is telling anyone to buy anything.
The only thing I'm advising people to do here is wait and see and let results speak for themselves.
If someone is able to use BBR via SuperNET then why do we need to get BBR individually? Pure Anonymous transactions are what we have all been after since this space was discovered, but don't forget that it is also mostly about an agreed upon, unanimously chosen store of wealth.
I respect your posts EN. At this point I would ideally like CZ, James and or someone who speaks on behalf of them to come forward and
start making a lot of sense.
"There needs to be vetted math, science, crypto and code for all to see."
Well the code is here:
https://github.com/jl777/libjl777I use standard crypto: nacl and libtom
Right now I am debugging on a test scale network. Cassius will be documenting the API. I have a technical roadmap, but I do not have the skills to explain it to nontechnical people, so I will just push forward and implement it. I dont have time to deal with baseless accusations that I am some snake oil guy.
###
https://forum.thesupernet.org/index.php?topic=154.msg1111#msg1111I finished debugging all the DHT calls. Ended up adding data compression to the loop, along with out of band binary data beyond the JSON in the onion packets. Also, a lot more difficult that I thought it would be, but finally got all packets to be the same size, thus removing a leak of info about the type of commands you are sending.
./BitcoinDarkd SuperNET '{"requestType":"getpeers"}'
./BitcoinDarkd SuperNET '{"requestType":"getPservers"}'
./BitcoinDarkd SuperNET '{"requestType":"ping","destip":"209.126.70.156"}'
./BitcoinDarkd SuperNET '{"requestType":"findnode","key":"<nxtaddress>"}'
./BitcoinDarkd SuperNET '{"requestType":"store","name":"<name of data>","data":"<hexstr>"}'
./BitcoinDarkd SuperNET '{"requestType":"findvalue","name":"<name of data>"}'
This weekend I implemented a variant of
http://www.cs.rice.edu/Conferences/IPTPS02/109.pdf, using 64bit NXT addresses for the hash, eg. least significant 64bits of sha256. collision resolution is something for a layer above this level to do. I plan to add some simple file API on top of this so we can get a nice decentralized storage along with sending of files.
of course all this is under heavy encryption, but still the IP addresses are not shielded yet. The sendmessage API appears to be working in simple topologies, should work with more layers, but need a larger network to test this.
./BitcoinDarkd SuperNET '{"requestType":"sendmessage","dest":"<nxtaddress>,"msg":"<text of message>","L":<maxonionlayers>}'
Using the sendmessage api, it should be pretty easy to make an encrypted chat application.
####
yesterday I did this:
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.
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":"<file to save>","L":0,"M":1,"N":1,"usbdir":"<dir for backups>","password":"<can be 4char PIN>"}'
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<len; 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"
####
I apologize for only working 16 hours per day and not having the proper skills to explain everything perfectly clearly.
I am just a simple C programmer
James
P.S. The fundraising idea did not work out, but this has nothing to do with the tech. SuperNET is not a one dimensional thing.
