[dmdsoftware]

I've added some encryption routines to the 0.4.0 code base, but have disabled it while I test it.

It uses Python Crypto libraries with a user supplied salt and password to decrypt files stored in application-octet-stream filetype. For photos, it is no different then the current code where it caches the files to a local directory and it decrypts it as it writes the file to disk. For video and music, it is similar to the disk cache mode, the plugin downloads the file and decrypts as it writes it to disk, and it playsback the file as it downloads. I'm doing some serious digging around in the XBMC player classes to see if this can be improved on, to actually decrypt the content using XBMC's player. The disk cache method causes issues with subtitles.

The user can use any encryption script that uses the same encryption parameters. I have a simple python script that will create take a user's desired password, create a salt and use the combination to encrypt a local folder's content. User can use another script (I have both a perl and python script) to upload the files to their Google Drive. They can also use Google Drive client software or web app to uploaded the encrypted files. It just matters that the file type is application-octet-stream.

I typically use encfs to store my files I want secured in Google Drive. The idea is very similar here. As a matter of fact, with a few adjustments, the current disk cache method in the plugin could accommodate encrypted encfs files. After I've had more time to test both methods, I was going to post some videos demonstrating it. I don't see there really being much of a need or a practical implementation that would make this a default for a typical user.

This sounds very promising. I agree that this is something that most users probably wouldn't need or know what to do with. I might fork your code and add the encryption routines myself. If you could point me in the right direction, or keep me updated on your progress I would very much appreciate this.

By the way, I wouldn't depend too much on encfs as this has a few significant security problems, as a recent audit has shown. Better simply implement a reliable encryption algorithm like AES-128-CBC or -XTS in my opinion.

I tend to maintain 3 branches of this code for some reason. Rock solid 0.2.x that you know does the trick and won't fail you, 0.3.x that has nice features but some things fall in the waste-basket, and 0.4.x which is what I'm running on my gear. The first few 0.4.x releases I forgot to comment out the import statements so it wouldn't even run on folks who don't have the crypto modules installed.

Now that I'm feel the stuff that fell in the waste basket are back in 0.4.4, I can retire 0.2.x and 0.3.x. So I'm expecting to keep 0.4.x going as it-is today, and add some new features, but will fork it off to a 0.5.x and re-enable encryption so that I can continue on that. I'm keeping mindful that there is at least 1 other person who'd like the encryption, so I'll be sure to make sure you know when I've pushed out the branch. So far I've been running the encryption version off a raspberry pi machine to test out the theory of it actually working

I haven't checked out the new audit results. I like encfs but I realized years ago that it has some issues -- issues I witnessed myself, that I was also able to later find documented concerns brought up. Issues I witnessed pertains to the fact that identical content will have the same encrypted result, which could assist someone intent on decrypting your stuff a way to at least figure out what your data resembles. I'm not relying on encfs for anything secret or ultra-private, nor would I, especially when storing in the cloud.