Asset Encryption Resource

#1 Very cool, i'm sure people will find good use for this :)

#2 Super nice. I am glad you found my resource useful. It was basically there to provide a stepping stone for exactly this.

#3 Neat! Next step is getting it to work with the packaging utility ;D

Edit: from TDN

Quote:(One could think of integrating it in T2D's new Packaging Tool to automagically encrypt all with with a certain extension).

That would be very cool.

#4 I wrote the code that the packaging tool is written on, and this is totally possible.

There is one small problem. We can't integrate this into the Torque engine itself, because encryption export is regulated by the government. This was another reason why my resource only included a loose framework and took more of a, "This is how you would do it," feel instead of a complete solution.

#5 @Jason: I hope so! :)

@Joe: Yeah, it would not be to hard, I think. I suspect the doFinalBuild() function in the packaging code is the point to jump in.

@Pat: Hm, that doesn't sound good. Could you explain that a bit more? Edit: Is this a problem I even if all encryption algorithms used are public domain?

#6 No, Michael, you are fine, don't worry about it.

I honestly do not know the specifics of exactly what is covered, but I do know that things with encryption have export restrictions on them. I didn't find a good link searching Wikipedia quickly, and maybe I am wrong about us not being able to include this. I just wanted to err on the side of caution. I know that programs which have over a certain key length of encryption they support are restricted.

#7 128 bit and above IIRC (and I probably don't!) cannot be exported without going through restrictions. Basically, the restriction is that you ask the purchaser/receiver to confirm they can legally receive the software, but there are legal hoops to jump through.

#8 Last thing we need is Al-Qaeda buying T2D and hiding terrorist messages in Match-3 games....

#9 Yeah the laws on encryption are pretty stupid. It may even be above 64 bits. I think RC4 encryption is one of the few(only?) that is allowed to be exported under current law. But that's pretty weak, and it may require licensing from the RSA group... So given the state of things maybe XOR is the way to go? Just to prevent casual users from editing your assets.

Edit: DES56 may be an option too, but it still may need some type of "review" by the government. Bah...

#10 Well, what about Skype and 7zip? They both use AES (says the german wikipedia).

Maybe the law could be circumvented by just providing the framework but now cipher implementations. The library is designed in a way that you just have to drop in new ciphers (which could be made available in a package on TDN). Default encryption would be xor or no encryption at all.
This would give the whole thing a usability boost. Yesterday I have looked into the code what it would take for dso-encryption. It would not be too hard but it would again need core code modification. And that's always a nono.

EDIT:

I mean, if you wanted to include this in the engine, it would suffice to provide the BlockCipherStream class, the BlockCipher base class, CipherBitmap class, and Cipher tool class. None of these contain any specific cryptographic facilities, just the interfaces and the means to read a stream in blocks.

A new BlockCipher derrivate can then be included very easily be the user themselv, provided it can be found ready to use on TDN or on the resource page (by just adding the source files to the project).

-Michael

#11 I think this is a much needed resource, and a welcome one. However, I honestly don't believe 65,536 bit inverse gravity flux holographic encryption is required here. Anything that prevents the average end user from sniffing around resources is fine in my book, even if it's only some glorified ROT13 algorithm.

Really, all I'd like to see prevented is casual access to the raw art and sound resources distributed with T2D games. Perhaps combined with a with a wad file type system to package them all in one handy file.

#12

Quote:
However, I honestly don't believe 65,536 bit inverse gravity flux holographic encryption is required here.

I think that too. But if you've got a library it is not harder to use AES than to some ROT13 derivate. And I was quite surprised how fast AES, Twofish and so on were. I thought those are really elaborate algorithms, they must be as slow as they are elaborate but they are not.
In fact, formerly I used another Blowfish implementation (from codeproject.com) because it had an easier interface. I exchanged it later because it was broken. And it was 3 or 4 times slower than AES. I thought it would have to be much faster because it was invented more then 10 years ago and is known to be fast because of its simplicity. However, the new algorithms are not only more safe but faster (or as fast) too. There really is no reason for not using them. ( except the US law :P )

For the wad file: Torque supports zip-files which are handled transperently through the Resource Manager. I have not tried this yet, but as the create-function for encrypted images gets it read stream from the resource manager, it may well be possible that you can read encrypted images from zip files with no modification to the resource. Someone should try this! :)

-Michael

#13 I can't wait to try this resource out, I'm still (gleefully) using a modified version of your original encryption stuff in my current project. :)

One of the additions I had made is the ability to encrypt/decrypt strings (e.g. encryptString(string, key); ) for use during client/server communication for more secure auth and data exchange. I'd love to see that as part of this resource, and I think it'd be universally handy.

Regarding zip files, I don't know if the resource differs significantly in implementation from the original Cryptostream stuff, but the original AES-over-cryptostream resource does not work with the resourcemgr's ZIP support. I didn't get a chance to find out why.

#14 Have you tried encrypt the zip? Cause I don't think that would work. But encrypting a file and then putting it in the zip afterwards may work...

#15 No I was just zipping up the directory full of encrypted images.

I zipped my (unencrypted) images subdir into images.zip, rand the game and it worked. I then encrypted the PNGs and JPGs and re-ran the game against the encrypted (but-not-zipped) images and that also works. Then I re-zipped them into images.zip and it dies.

Once, I was noodling around in nearby code for something completely different and I came across the zip handler code. I vaguely remember saying to myself, "Oh that's probably why encrypted files in a zip doesn't work" but right now I have no recollection of what that was... I should go dig around in there again and see if inspiration strikes me again. :)

#16 I have just looked into this a bit. One problem is that the files in the zip file don't start at stream position zero. This will mess up everything while decrypting. But it should not be too hard to solve that by incorporating an offset when the cipher stream is created. I'll try this some time this week. Maybe then it will work :)

#17 Hey, good news!

I tried using zip files and it worked perfectly. I used 7-Zip to build the archive tried with options "store" and "deflate" and both worked without error with the newest version of this resource (which is the one that is online). I have to admit, I only test with 1 file though. But I don't see any problem with this.
The issue I talked about in the last post doesn't actually exist. The stream the resource manager delivers always starts at position zero.

I am glad about that. Now that last thing to try is using encrypted sound files.

(Btw, I was doing everything like it is described under "Adding Support for encrypted PNG files" in the TDN article)

-Michael