Waiting for Codexx to show up now that I;'m home. Also pondering some stuff from my post up there
>>129785
Really the most important part is the file deniability. Such a site could work even if it was sniffed out by whoever because the files would all be meaningless dreck that you couldn't get in trouble for. I'm trying to imagine how to implement the flow of what is almost "reverse symmetric key encryption."
>Suppose such a system is running and the network is intact.
>A user goes to upload a file
>Their software takes that image, generates a key, and encrypts it. How?
To me it would make sense to first establish the image's SHA512 hash like a normal imageboard upload. Then use a cryptographic function
on that hash to produce a text keyfile.
>The software then completes your "upload" by seeding both the encrypted file and the key.
We don't care if this user is a faggot uploading CP, because right now he'd be the only one to blame for it. The encrypted image and key are on his computer only.
Meanwhile another user is browsing 00008chan and sees the first user's post. As the page loads its contents over the bittorrent network, this user's client downloads the encrypted file first, just like 08chan, but it appears as a temporary graphic. Once that is loaded, the viewer's client then searches for the decryption key from the first available seed.
>Problem
How do we identify what key is needed to decrypt the file? We need an asymmetric split - where every file should tell you exactly what key to go fetch to open it, but where looking at a given key should give you no clue as to what file it opens. So when the image is encrypted and the key made,
something needs to tag the image file in such a way that the key can be searched for.
>Assuming we solve this issue
Now the key comes over bittorrent and the image decrypts, switching from a placeholder thumbnail to the actual image thumbnail. For simplicity's sake we're going to say that this thumbnail isn't a separate file, but the entire image shrunk into a mini-preview like ye olden Internet did it. Click on it and it instantly opens to full size. It's bunny musclegirl hentai and you fap. Meanwhile a process in your client decides whether or not it wants to retain and seed the image file, or the key file. It should never, ever allow both and the data should go back to being useless as soon as you close your client and lose the decrypted file from your cache. If you want to save it, you can just Save As from your browser like normal while the file is still decrypted. Any time you upload a file your client also needs to check and see if you already retain the key or file from a previous upload, and if you do to merely default to it so there's no risk if ever winding up with a complete pair locally.
>Oh no! It was CP!
Your client should have a "file blacklist" option. Upon seeing something like this, you click that button and both the encrypted image's SHA512 hash and whatever identifier was put on the decryption key are added to your blacklist. Both files are deleted from your machine, and your client will never try to download or decrypt those files again.
Now lets say you really like Mirko pussy, and you want to share that image in another thread. You re-upload it, and the same process happens. Your keyfile should be identical to the original keyfile that the first poster seeded when he uploaded it. Now you reupload it, and your keyfile becomes seed 2/2. Now everyone else has 2 places they can pull the key and/or file from.
In a way its very meritocratic. The more popular a file is, the more times it will be shared and the more active seeds will go up for it and the key to it. Meanwhile a very unpopular file would not get re-upped much, and might be blacklisted a lot, which would eventually choke it off until nobody was seeding either it, or its key.