Rockbox Development > Feature Ideas

Encrypt and decrypt files

(1/2) > >>

gbl08ma:
Recently, in the sequence of wanting to store some sensitive information on my iPod which I would want to access on the go (without a computer near me), and I not wanting anyone who could eventually browse the files on the iPod to see that private files, I ran into a problem: there was no way to encrypt files in a way that they could be decrypted and the accessed through Rockbox.

I thought on using keybox, but even although (in that case) the "private data" was only text-based, it was way too long to fit on the limited keybox fields - to not talk about the work of manually copying everything into the virtual keyboard.

Something that would fit perfectly on my situation was a viewer (or two) which encrypted and decrypted files when opened through it, after asking for a password. I remembered that keybox uses the Tiny Encryption Algorithm and that the encryption it provides was, at least for me, more than enough for any kind of purpose.

So I started to work on a encryption plugin, which would encrypt the file contents and save the encrypted content as a new file with the same name as the original one and .rbc extension (rbc of RockBox Crypted). To be honest, what I did was copying the keybox plugin - I thought it would be easy to replace/delete the keybox part for something that reads a file and saves it after encrypted -, and renaming the copy to encrypt.c :) This was enough to figure out that it'll be more difficult than what I thought at first. :)

To avoid having work for ending up with nothing, I have a few questions:
1. Is it actually feasible to use TEA to encrypt files? I'm not thinking on large files, these might represent a problem because there's not enough memory to load the buffer in memory. But, I'd like to have something working that would encrypt, at least, small text files.
2. Should I take the keybox plugin and scale it down to what's needed, or should I start from the scratch with only the main and basic TEA functions (those available on the Wikipedia article of TEA)?
3. If using TEA, should I use TEA, or its successor, XXTEA?
4. (but should be the first) Should I put effort in implementing encrypting functions in Rockbox at all?

By the way, does this belong on the Feature Ideas or on the Start Developing and Compiling section? This is both a help request and a feature idea...

Thanks in advance
Gabriel

nls:
Hi i wrote the keybox plugin but is in no way an expert on cryptography.

1) It's a fairly simple block cipher so it will work well no matter what you encrypt. You don't need to keep the entire file in memory at once but can load a part of it, encrypt and write out and the n load the next part. However i did not try to optimize the TEA code at all so if you use it on large files it will probably be quite slow.

2) Most of keybox is UI and a simple linked list so i don't think copying most of that will help you, i think it'd be better to start from scratch if you just want to encrypt/decrypt files and copy in what you need, or if you want to display your encrypted text maybe add that to the text viewer plugin.

3) no idea

4) if you want them :)

gbl08ma:
Thanks for your reply.

I came back to work on the plugin, this time I started from a blank template and added the two main encrypt and decrypt functions (those available on the Wikipedia article for TEA). It seems it'll be a lot of work and time until I get something that works.

All I did was coding something that would encrypt a fixed array of int32_t and save the encrypted result to a file. This part seemed to work well, at least the output on the file was not the array but some gibberish (like the one that appears when you open the keybox.dat file with a text editor). I then tried to add the decryption part, to see if I was able to code something that would decode the encrypted file into another file with the original array. This last part didn't work: all I get on the resulting file is more gibberish.

Although I'll try to not forget about this plugin idea, I'll try to learn a bit more of C and then get back to the plugin...

If, in the meantime, anyone wants to develop this idea, don't wait for me and go ahead.

If anyone wants my "code" (with quotes), I can provide it as-is by some way (pastebin, email, PM). I don't think it's developed enough to create a patch in the tracker, so I won't create an entry there.

torne:
If you are encrypting files that already exist on the filesystem, remember that the original file may still be left, in whole or in part, on the drive, even if you delete or overwrite it. You would probably want to take special care to avoid this.

gbl08ma:
Yeah, I know the bytes of the unencrypted file will still be left in memory even after the file is deleted or overwritten, and can be read by specialized software. However, it's not my intention to provide a so secure encryption; it is mostly meant to avoid the normal reading of the file by standard programs, after it is copied or moved (e.g. a virus that copies files and sends them to some server, this is very common on public computers where, very rarely, I need to connect my iPod).

I paused work on this plugin to focus on the tag editor of another thread; I'll go back to this plugin once I have a barely working tag editor.

Navigation

[0] Message Index

[#] Next page