Encrypted Archives

[G_G]

First of all, the "or" in the description of this board is meant to be "of" if I'm not mistaken. Second, how are we going to be creating our encrypted archives. I sure as hell don't want it to be as easily decrypted as RM games are right now. Though I'm sure someone (vgvgf) will figure it out eventually.

[Blizzard]

I really make that mistake often. ._.

Everything can be figured out, nothing is unhackable.

As for the encryption, somebody should first research what file encryption methods and concrete algorithms there are. Then we will figure out a way to implement an asymmetric algorithm and this should do the trick. Don't even bother with anything less powerful than asymmetric algorithms. Any volunteers for the research?

[G_G]

I'll look into it but I can't guarantee I'll be of much help. First of all, file encryption, randomizing, etc... is probably one of my weaker points as I never really studied it. And I'm not that great of a researcher either.

[ForeverZer0]

How about the RSA Algorithm? At first look, it seems it could be a possible candidate for our encryption method.

I know you want to stick with an asymmetric algorithm, but as far I know the Triple DES Encryption has proven to be quite secure. In fact, it is the standard for ATM's and other forms of money transfer in the world. As far as practical implementation goes, that I am still uncertain of.

[Ryex]

I thought DES was asymmetric.

in any case I have no problem with RSA it's secure and as long as we build the Zer0Division.dll with the private key obfuscated then it is unlikely that people will be able to crack it.
the bigest mistake Enterbrain made was using symmetric encryption and having the key blatantly defined in the dll.  if we say had the private key generated through several function calls people wouldn't be able to find it any where near as easily.  we just need to keep in mind that asymmetric encryption is much slower than symmetric.

[Blizzard]

As far as I know AES is better than DES and I know how we always make fun of AES being the weakest encryption. O_o
Take a look at this: http://en.wikipedia.org/wiki/Block_cipher_security_summary

http://en.wikipedia.org/wiki/List_of_algorithms#Cryptography
http://en.wikipedia.org/wiki/Topics_in_cryptography#Modern

RSA is public domain now so it might be a good choice. But let's first check out what else is out there before we make a final decision.

[G_G]

Alright, I think I'm stuck with having individual encrypted files. Why? Easily make patches and updates. Easily see if a file exists or not. I mean it seems right doesn't it?

[Blizzard]

Yeah, that was my first thought as well. If we make archives, then we also have to use program the access to those archives and we have to mess around with path changes, etc. It's way too much work for something that is actually a worse solution. I also think we should stick to individual files.

[Ryex]

I agree this way we can have the encrypter run on directories encrypting every file it finds. and we could do what RGSS did and have the load_data method automatically unencrypted encrypted files

[Blizzard]

Yup, that's the idea.

[Ryex]

http://en.wikipedia.org/wiki/Elliptic_curve_cryptography

http://en.wikipedia.org/wiki/Crypto%2B%2B

an alternative to RSA?

[ForeverZer0]

It would appear that the library from the second link has a lot to choose from, both elliptic curve and RSA. I think this is a great to add to the project.

As for the actual method to use, I like them both. I admit that I am not super-versed when it comes to encryption methods, but both seem like they could fit our needs. It's a flip of a coin for me.

[Blizzard]

What about the license? If the license is fine, I think we can go about using another external library rather than coding it ourselves.

[Ryex]

http://www.cryptopp.com/License.txt

the whole compilation is open source and the individual files are public domain. I see nothing is the license that prevents us from using it.

[Blizzard]

This is great. It will allow us to offer an encryption option for the end user before compiling the project into a game distribution. xD

[Ryex]

if we offer that service..

[G_G]

Just trying to clear things up before I look stupid again.

We're basically going to have 2 formats right? One for the Engine and Editor to load. Basically the .rxdata. Then we'll have our encrypted format that only the game engine can load.

I just wanted to throw a suggestion out, have a hidden method that saves data in our encrypted form. Obviously we'll have "load_data" to load the encrypted data, but a save_data method would be nice as well.

Also, do we plan on encrypting Audio files this time?

[Blizzard]

Yes, yes and yes.
.rxdata is actually just serialized Marshal, we will have our own format for that.
We will have a save_data method which will be also visible to scripters in case they want to take advantage of the format. It will be basically the msgpack format.
And yeah, we will implement audio encryption. In fact, upon "compilation", you will be able to choose what stuff you want to encrypt.

[Blizzard]

Alright, guys, we're getting close to an actual release here. I wanted to bump this topic again so we can resume this discussion and find an appropriate solution.

We will support ARC::Data.load and ARC::Data.dump for our own format and load_data will do the same thing that RMXP does. This is for script compatibility.

As for the encrypted format, we will use the .arc format for the data which is used by the editor and we will call the encrypted version .arc as well. Files names will not be changed, only the extension will be changed.

If we can pull it off anyhow, we should try to generate a huge encryption key based on something the userdeveloper gives us. e.g. he could give us his name and we use a hashing function to generate some badass key that will be used to encrypt his game individually. The question is only how we can pull this off since we have to add that key somehow into the game so the engine knows what to use to decrypt the data. Or should we use one key? Because if we allow a different key, updates for any games would require the user to enter the same string for the key generation which might not be such a good idea. Except, of course, if the encryption key generation string becomes a project setting that is saved so the user can compile his game with the same encryption key as much as he wants.

[G_G]

The encryption should definitely be saved in the project settings if we go this route. As far as how we're going to save the key into the engine is beyond me. If we just use one key for everyones game, chances are that someones going to find out that key eventually.