Open n4n0GH opened 5 years ago
Got some testing done, these are the results: Converting a binary file to base64 encoding roughly adds 30-40% bytes. Turning that string to hex doubles that size due to each bit being turned into two new bits. This method might be fine for text content as users will rarely type essays worth a million characters into a dum text box on some shitty website, but for images it's a catastrophe and crazy increase of space needed to store data. Issue is closed for the time being.
With reconsideration for how we'll run the own backend (i.e. our own IPFS node): 0xchan's official frontend which will write to our own node will have a maximum filesize limit, so the added weight of encrypted files is not that terribly large. Furthermore a dynamic key instead of a static one is to be used. Images are XOR'd against a key consisting of the thread ID and board ticker that the image is located in. That makes the key random enough to increase plausible deniability should glow-in-the-darks try to van node operators.
Text content is properly encrypted, user supplied files need some work still.
Linebreaks break at least the rendering:
Encoded: 74686973a74686973
Decoded: this§F
Expected: this\nthis
Fixed issue with 280425a
Encoder detected LF
like it should, but encoded it as a
instead of 0a
, leading to breaking decoding, as the decoder takes byte pairs to decode back into characters.
Regular text should be converted to hex, then bitwise XOR against a repeating salt to keep the length -> then store on IPFS
Media files should be converted to base64, then hex, then bitwise XOR against a repeating salt to keep the length -> then store on IPFS https://codepen.io/AshV/pen/pjodjV