Rockbox

  • Status Closed
  • Percent Complete
    0%
  • Task Type Feature Requests
  • Category User Interface
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by MasterShin - 2006-06-12

FS#5534 - Encryption on folders of your choice

I’ve seen the suggestion of pin numbers before, but this is different.

The idea is to be able to encrypt a folder of your choice, and without entering the right access code to the folder, rockbox doesn’t even recognise the folder to be of any type (since its content will be jibberish).

This is a good feature in my opinion, and clearly not just for music files. If you want to store a folder of certain encrypted text files that have valuable information, but at the same you want to be able to access them from your player - this is the solution.
Of course for the newer players, one could also encrypt folders of images and video, which might be a desirable option.
Also, you might want to encrypt the contacts, notes and calendar appointments you have.

Closed by  zagor

Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Closing all feature requests.

Well, you’d essentially have to just encrypt all the individual files within the folder, rather than the “folder” itself I believe, unless you wanted to do something like .tar it, and then encrypt that.

Again though, I don’t think you could expect any reasonably strong encryption. I don’t know much about encryption, but it seems that because the decryption algorithm is available, and the key would have to be something you could memorize and input on the device, you’d end up with a fairly weak level of protection.

You wouldn’t have to type the key into the device, you could do it the same way its usually done with a symmetric encryption, where the key is stored locally, and is itself encrypted against a password, so you’d just have to type in a cryptographically strong password (which would be a pain) or maybe use a password & keyfile system (ala truecrypt) where you’d have to enter a passphrase as well as select a file.

I think the real main problem would be that the encryption & decryption would be really, really slow. To play media, it would have to decrypt to the harddrive and then play it, as opposed to decrypting on the fly, and really you never want plaintext on disk since if someone could get their hands on the disk that information would be recoverable. You’d have to come up with a way to generate very, very random numbers (I donno if Rockbox has this capability) and even if you can do that, then generating a key would take a pretty long time as well.

We use big keys now (256 & 512) bit keys now becuase we have so much computational power on a desktop that its trivial to do, but even encrypting with a 128 bit key for one of these devices would be a pretty enormous computational problem, and 128 bit keys aren’t even really regarded as secure any more.

I’ve only just discovered Rockbox and am just learning how it works, once I’m more familiar with the source maybe I’ll give implementing DES or something a shot, but I don’t think its gonna be practical.

I don’t agree with both of you.

If we encrypt txt files with something like RC4 using a 256 bit key, it will be very hard to decrypt and on the fly decryption is definitely possible and fast.
As for the password, the user just needs to select a 8 character pass and that’s quite secure.
We store the RC4 of the word “yahoo!” using his pass.
When he wants to access the encrypted file, he types the pass, and Rockbox tries to decrypt the “yahoo!”.
If it doesn’t come out as “yahoo!”, then “Wrong Pass!”, if it does, print the file.

RC4 (and a few others) is a very fast encryption/decryption algorithm, that a player can definitely use on the fly for files less than 1mb.
For bigger files, I’d say the player should decrypt the file to the ram, then use it from there, and later just garbage collect it. Decrypting wouldn’t take too long.

For txt files it will work without a problem.
For photos, it might take a while - but it might be worth it to be able to have passes on some photos.
As for mp3 and video, sure, that might be farfetched.

I believe that a simple application to encrypt/decrypt text files would be extremely useful. I’m thinking off a simple Cryptopad clone that is available for Palm Pilots. I use this maintain some personal passwords - a single passcode opens the “safe” to display the rest of the information.

I just ran across Rockbox today - I have an iRiver H10 20GB - but a Cryptopad/Password Safe clone would put the final nail in the coffin of my Sony Clie… The source license for Cryptopad is GPL - http://cryptopad.sourceforge.net. There are other open source projects similar to these 2.

 .../Ed
phr commented on 2007-12-29 10:24

The encryption could be pretty fast but if the encryption key (passphrase) is long, it would be quite difficult to enter through the UI of a typical mp3 player (no keyboard and just a few buttons). But if the key is short, it will be vulnerable to cracking if someone gets hold of the device.

A “password vault” application (you store a bunch of passwords in an encrypted file, accessed through a short code that self-scrambles if you enter it incorrectly several times) could be useful though not very high security. You might as well use some more conventional file protection instead of encryption in that case.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing