views:

557

answers:

4

When looking for encryption related classes/functions in action script / air / flash, I saw the as3crypto project.

This one provides a v. nice set of options, but I am a bit concerned on what the numbers presented means when these are used to decrypt a local media file when its selected about to be played.

I am looking for security vs. performance balance.

For video/music, it needs to decode at a fast enough pace so the player plays it smoothly - which is something that depends on the format used, but is in all cases less than the delay of having to wait to decode the whole file.

The hardest part comes from having to use it for flash apps as well, since afaik it needs to wait for all of it to do anything. Unless this assumption is wrong, this is where the best performance algorithm in the list in the as3crypto page seems too slow i.e. at 1.5 MB x sec, it would take 20 secs to decipher a 30 MB flash app.

The main questions I have on this are:

  • Are there any other libraries with higher performance? Anything in adobe air maybe?
  • For videos/songs, what would be a good number of MB x sec for it to be playable?
  • Does flash waits until loading completely a flash app before running anything of it?
A: 

Use SSL rather than Flash crypto to encrypt the content as it is transported over the Internet.

Justice
@Justice thx, but this is for local media files. Any tip for that case?
eglasius
+1  A: 

Im curious about what kind of encryption you're using. Symmetric or asymmetric crypto? In case of asymmetric, try switching to symmetric.

In case of symmetric, use a stream cipher (RC4, or any other flavour, just google for the names), as the name suggests you can encrypt/decrypt in streams so this fits your needs. As far as i can remember RC4 gives the best performance of the most stream ciphers (still used in WEP and WPA1)

Another option is to use a blockcipher in the ECB (Electronic Code Book) mode. This enables you to encrypt/decrypt content partially since each block of 64/128/192/256 bits is separately encrypted/decrypted. Note that the ECB mode is less secure than the more usual CBC (Chained Block Cipher) mode, but here you can only encrypt/decrypt content as a whole.

Btw, note that i cannot give you any info on the performance of these algorithms, but i guess you can benchmark it.

Henri
eglasius
I know how asymmetric and symmetric crypto is used ;) and i also know how ssl negotiates keys. However, still i dont see why my provided solution wont work since the site promises 1mb/s for a stream cipher. Which is enough to play a flash movie i guess?
Henri
@Henri I didn't say what you mentioned was wrong, is just that I had looked into that + added clarification about that you don't need to pick symmetric vs. asymmetric / weaker vs. stronger. Part of what I was having trouble with is I didn't know what would be enough for videos - but from what I have tested so far it works for that. The issue is its also external flash apps, which at 1 Mb x sec takes 10 secs for a 10 Mb app to load- and in the context I am that's a lot ... from stats I have gathered average is 7 Mb - thus aprox 7 secs which varies per client specs ... +1
eglasius
+1  A: 

Try XTEA - it's reasonably strong if properly implemented; very simple to implement and fairly fast (it can run within a interpreted VM at a reasonable performance level).

The AS3crypto library includes a XTEA implementation which you should be able to directly import.

Adam Frisby
@Adam thx, I will give it a try.
eglasius
+1  A: 

Regarding performance, if you can stream the video & music, i.e. process them one block at a time, then you only need to decrypt one block ahead instead of decrypting the entire file. This will probably be good enough for performance no matter the algorithm.

Security

For the best security try AES-256, preferably in CTR mode (see Colin Percival's article for rationale). Note that CTR mode converts the AES block cipher to the equivalent of a stream cipher without reducing its security - this has some useful properties, like random-access decryption (vs. CBC which forces you to decrypt everything up to the data you want).

If the CPU load is too high, RC4 is weaker but good enough for most uses. Be sure to use a 256-bit key.

Finally, the way you generate the encryption keys is very important:

Nonce / IV

If you use the same base key to encrypt all the files, always use a nonce (a.k.a IV or "Initialization Vector") when encrypting:

  • A nonce / IV is a group of random bytes that are kept in the clear next to your ciphertext (often prepended to the ciphertext)
  • Create and use a different nonce / IV for each encrypted file
  • CTR mode APIs include a way to set the IV / nonce, the library you use supports it
  • If you use RC4:
    • save the nonce / IV yourself
    • generate the final encryption key using HMAC-SHA256 with the base key and the nonce, like mentioned here

Generating a key from a password

If the user enters a password, generate the base encryption key using PBKDF2 (again, see Colin Percival's article for rationale).

Since you have an hmac-sha256 implementation in the library it's easy to implement PBKDF2-HMAC-SHA256 yourself, search the net or SO for sample implementations.

orip