2017-03-21 20:15:04

Why can't you just implement OpenSSL AES-256-cBC encryption? That can be brute forced, but it's top-of-the-line government-standard cryptography and it's probably the best and strongest encryption algorithm available at the moment. You could even triple encrypt the data you want to encrypt, giving you a possible AES-3-256-CBC. Don't ever use AES-256-EBC though!

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github

2017-03-24 02:40:13

This isn't about keeping the chosen encryption algo a secret. and by no means do I intend to attempt my own crypto scheme.
My previous post probably wasn't very clear as I wrote it late at night when I really should have been sleeping. but I was referring more to such things as the master keys used to encrypt/decrypt the compiled byte code from the script compiler.
Though it's encrypted, the key has to be stored within the executable and hidden via what boils down to security through obscurity.
Though this is by no means immune to cracking (you could potentially find the obfuscated key in a memory dump and put the pieces together), having the method -- whatever it may be -- opened to the public would make people think twice about compiling commercial games. and even with a scheme which involved changing the internal key with each game compilation, the relevant section of code will still reveal where and how the sensitive data is stored.
This might all be academic if I never get around to finishing, but this was the initial concern.

Official server host for vgstorm.com and developer of the Manamon 2 netplay server.
PSA: sending unsolicited PMs or emails to people you don't know asking them to buy you stuff is disrespectful. You'll just be ignored, so don't waste your time.

2017-03-29 18:28:36

I think we should move this discussion somewhere else, but I will add one more post on this subject:
@Trajectory:
No matter what you do someone is always going to find the secret master key. Attempting to hide it via security via obscurity is only going to make people try harder. I think that the only real way you could fully master this is if you somehow used the 64-bit processors AESDEC, AESDECLAST, AESENC, AESENCLAST, AESIMC, and AESKEYGENASSIST instructions to create your own algorithm (something that, as you've said before, you do not wish to do). Attempting to protect it by making two different versions will only piss people off because they have to implement their own encryption algorithm. This would, in turn, depopularize your product.
Your only choice then would be to:

  1. Generate a random master seed using a combination of arandomly-generated seed value at compilation time stored as an internal variable compiled into the executable and referenceable by a constant such as master_dec_enc_key;

  2. Use this key to then encrypt the data that the user wishes to encrypt; and

  3. Use the decryption master key that, again, is stored in the executable, to decrypt the data.

Alternatively:

  1. Use an already-provided OpenSSL AES-256-CBC encryption algorithm to manage all your encryption and decryption needs (I highly recommend this one); or

  2. Do not include encryption whatsoever (highly not recommended).

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github

2017-03-29 19:05:36

Yeah sorry for taking this on a tangent. and amen to the previous post.

I don’t believe in fighting unnecessarily.  But if something is worth fighting for, then its always a fight worth winning.
check me out on Twitter and on GitHub