1:38 am    10/21/17

    October 2017      
Su Mo Tu We Th Fr Sa  
 1  2  3  4  5  6  7  
 8  9 10 11 12 13 14  
15 16 17 18 19 20 _2_1  
22 23 24 25 26 27 28  
29 30 31              
The fileserv is a bit of “web software” that I wrote so that someone could send me a file using their browser. It gradually evolved into a featureful web file repository, much like what's offered at xdrive, except that it's running on my desktop, so I can devote free space on my 120GB hard drive to it, and it doesn't cost me anything to run.

My plan is to rewrite it in the next few months and maybe make it open source. One of my highest priorities is to throw on some security features.

In the comments to this article on slashdot, Doodhwala writes:

If you were in the US, all the RIAA needs to do to sue you is download a single chunk of data from you. They don't need to break your door down and cart the computer away. So, the encryption is moot anyway.

This is definitely an invasion of privacy; fortunately, it's pretty easy to protect ourselves from this. Fairly elementary cryptography can show you how to encrypt two distinct, arbitrary 1024-bit messages into a single 2048-bit message using two distinct encryption/decryption key pairs. Using this scheme, Alice and Bob can exchange pairs of secret messages at a time, one of which they don't mind anyone else finding out about, and one that they would like to keep secret (i.e., fake data and real data, respectively), so that if Eve (the cop) subpoenas them for their private key, they can return the key that will reveal their innocuous messages and Eve is none the wiser.

This kind of scheme could be used in something like the fileserv: when a user wishes to upload a “sensitive” file, he could select an extra local file to upload and type in two keys for the transfer. When he wishes to upload non-sensitive material, the double-encryption scheme will be used anyway, but the second message will be random data. When he wishes to download sensitive data, he will be required to enter a password locally to decrypt the sensitive message. This way, a wire-tapping third-party can't tell when sensitive data is being transferred, can't decrypt either message without a key (in reasonable time, anyway), and can't get the sensitive data (if it's there) even if they can force a secret key out of either user.