encrypted resources
by Adrian W · in General Discussion · 09/06/2009 (8:48 pm) · 15 replies
I just had one of those "lightbulb" moments about something thats been bugging me - how to post resources that include GG code. For example, you mod the engine in some way that you want to share with fellow GGers, but you can't just zip up the modded files and upload them for public download because then you'd be making large amounts of GG's proprietry code available for public download as well. What a lot of people do is post the code changes with comments about where to paste each snippet into the GG source. Another way is to create patch files that can be automatically merged into the GG source, but both approaches can mean a lot of extra work for the person creating the resource. Ideally there would be an upload area on the GG website that only registered users can download from depending on their licensed products, but thats unlikely to happen.
So what's the solution. Well, say that you've modded TGEA 1.8.1 and you zip up the modded files, including GGs proprietry code. Then you run the zip file through a simple xor encryption program that encrypts your zip file *using the TGEA 1.8.1 installation program as the key*. Now you can post the encrypted zip for public download and only people who already own TGEA 1.8.1 can decrypt it and use it! If you modded TGE 1.5.2, then you would use the TGE 1.5.2 install program as the key, and so on. This would work equally well with rars, tars, and any other kind of archive format you can think of.
Normally xor encryption is considered to be weak, but thats because the key is usually a lot shorter than the message. In this case the key would be 100 MBytes or so, much longer than any zip file you are likely to want to distribute, so it would be effectively unbreakable. Also xor encryption is very easy to implement so a program to do this ought to be a pretty trivial task.
So what's the solution. Well, say that you've modded TGEA 1.8.1 and you zip up the modded files, including GGs proprietry code. Then you run the zip file through a simple xor encryption program that encrypts your zip file *using the TGEA 1.8.1 installation program as the key*. Now you can post the encrypted zip for public download and only people who already own TGEA 1.8.1 can decrypt it and use it! If you modded TGE 1.5.2, then you would use the TGE 1.5.2 install program as the key, and so on. This would work equally well with rars, tars, and any other kind of archive format you can think of.
Normally xor encryption is considered to be weak, but thats because the key is usually a lot shorter than the message. In this case the key would be 100 MBytes or so, much longer than any zip file you are likely to want to distribute, so it would be effectively unbreakable. Also xor encryption is very easy to implement so a program to do this ought to be a pretty trivial task.
About the author
#3
Or else we wouldn't need RSA/AES :) But yeah, it depends on your definition of "safe enough". RSA/AES isn't SAFE either, but it's safe enough for most. ;)
09/08/2009 (11:48 am)
It's still trivial to bruteforce, no matter the key. If you do it in different passes it's slightly better (like TEA does, which is nice) but it's still not "safe".Or else we wouldn't need RSA/AES :) But yeah, it depends on your definition of "safe enough". RSA/AES isn't SAFE either, but it's safe enough for most. ;)
#4
09/08/2009 (1:03 pm)
I think the basic idea isn't bad but what happens if a resource would replace files that were modified already (maybe by a previous resource or changes you made yourself)? 
#5
Coming from a cryptographic background I can tell you that practically all commercial and publicly available encryption schemes are decidedly "weak".
But is a pretty good idea.
09/08/2009 (1:50 pm)
Considering the wealth of information that GarageGames has made available to the public by making the private forums open to all, it really doesn't matter does it?Coming from a cryptographic background I can tell you that practically all commercial and publicly available encryption schemes are decidedly "weak".
But is a pretty good idea.
#6
Not convinced about that Michael, or are you dropping a subtle hint that GG won't mind about this :-).
For example I did some experiments with adding a second UV channel to TSMesh's in TGEA, for light mapping DTS shapes. The zip with all my modified files in contains a lot of the GG code that generates procedural shaders so I'm not really sure that they'd be happy for that to be posted somewhere where anyone can download it.
What I do at the moment is, when anyone finds my old blogs and wants a copy of the source I check their account here and if they're licensed I email them the code. It just seeemed like this might be an easier solution that would allow me to put my zips back up on my website.
I'll take your word for that Stefan, I know very little about cryptography so I'm in the position where a little knowledge can be more dangerous than no knowledge at all! But it still might be strong enough for the example I've given above???
09/08/2009 (2:50 pm)
Quote:Considering the wealth of information that GarageGames has made available to the public by making the private forums open to all, it really doesn't matter does it?
Not convinced about that Michael, or are you dropping a subtle hint that GG won't mind about this :-).
For example I did some experiments with adding a second UV channel to TSMesh's in TGEA, for light mapping DTS shapes. The zip with all my modified files in contains a lot of the GG code that generates procedural shaders so I'm not really sure that they'd be happy for that to be posted somewhere where anyone can download it.
What I do at the moment is, when anyone finds my old blogs and wants a copy of the source I check their account here and if they're licensed I email them the code. It just seeemed like this might be an easier solution that would allow me to put my zips back up on my website.
Quote:It's still trivial to bruteforce, no matter the key.
I'll take your word for that Stefan, I know very little about cryptography so I'm in the position where a little knowledge can be more dangerous than no knowledge at all! But it still might be strong enough for the example I've given above???
#7
I'm far from an expert in cryptography, but as far as I understand that's why RSA is the standard because as you increase the key size you increase the complexity and time to crack it.
Edit: Oh I don't know. That would be up to the owner (GG in this case) and I doubt they'd change their resource system when the current one works. IMO, obviously.
09/08/2009 (7:25 pm)
What I've read is that the complexity to crack TEA is linear, unlike RSA. That's why it's trivial. And TEA does more than a single XOR pass.I'm far from an expert in cryptography, but as far as I understand that's why RSA is the standard because as you increase the key size you increase the complexity and time to crack it.
Edit: Oh I don't know. That would be up to the owner (GG in this case) and I doubt they'd change their resource system when the current one works. IMO, obviously.
#8
09/08/2009 (8:35 pm)
Google is mocking me! Trying to follow your argument I googled for "cracking TEA" and got pages about Wallace & Gromit ... cracking tea Gromit! I think the light bulb has gone out now.
#9
it could look like a good idea but it's not a good idea, really. :-)
This is because, regardless all discussion about algorithm type or key size (and a 100Mb key is not a manageable neither useful key size) it's useless to use a persistent symmetric key that anyone can easily obtain: in few minutes "protected" resources would be unencrypted and reinserted in the WWW again.
Anyway, nice try: continue "googling" (better "wikipeding" ^_^) because security is a nice argument to reading about.
09/10/2009 (1:01 am)
Hi Adrian,it could look like a good idea but it's not a good idea, really. :-)
This is because, regardless all discussion about algorithm type or key size (and a 100Mb key is not a manageable neither useful key size) it's useless to use a persistent symmetric key that anyone can easily obtain: in few minutes "protected" resources would be unencrypted and reinserted in the WWW again.
Anyway, nice try: continue "googling" (better "wikipeding" ^_^) because security is a nice argument to reading about.
#10
It's really only ever used when you want to encrypt the network stream. And I assume that's because it's not cryptographically strong. It's fast, though.
09/10/2009 (5:24 am)
Here's TEA on Wikipedia.It's really only ever used when you want to encrypt the network stream. And I assume that's because it's not cryptographically strong. It's fast, though.
#12
You use some noise, say random mouse movement, to pick a small number of bytes from random positions within the TGEA install program. You then use these bytes as the key to a pseudo random number generator to generate a stream cipher ( en.wikipedia.org/wiki/Stream_cipher ) to encrypt the resource. You then publish the positions of the key bytes within the TGEA installer (not the bytes themselves obviously!), together with the encrypted resource. The decryption program would use the same pseudo random number generator to reconstruct the stream cipher and decode the resource, but only people who already have the TGEA installer would be able to construct the key from the given set of positions.
Remember, this is purely for the sake of interesting discussion, I’m not suggesting the problem is important enough to actually merit implementing this!
09/10/2009 (2:54 pm)
OK, here's my second attempt. This isn't as trivial to implement as the original so this is purely for the sake of an interesting discussion.You use some noise, say random mouse movement, to pick a small number of bytes from random positions within the TGEA install program. You then use these bytes as the key to a pseudo random number generator to generate a stream cipher ( en.wikipedia.org/wiki/Stream_cipher ) to encrypt the resource. You then publish the positions of the key bytes within the TGEA installer (not the bytes themselves obviously!), together with the encrypted resource. The decryption program would use the same pseudo random number generator to reconstruct the stream cipher and decode the resource, but only people who already have the TGEA installer would be able to construct the key from the given set of positions.
Remember, this is purely for the sake of interesting discussion, I’m not suggesting the problem is important enough to actually merit implementing this!
#13
no problem with "the sake of interesting discussion", we are here for that and you don't need to justify yourself :)
Anyway, I think you start from a weak security assumption: only who regularly purchased TGEA could have it installed on his computer. Unfortunately, this is not true, so every mechanism you try to implement using that assumption will just not work.
09/18/2009 (6:57 pm)
Hi Adrian,no problem with "the sake of interesting discussion", we are here for that and you don't need to justify yourself :)
Anyway, I think you start from a weak security assumption: only who regularly purchased TGEA could have it installed on his computer. Unfortunately, this is not true, so every mechanism you try to implement using that assumption will just not work.
#14
As Giuseppe mentions it's really easy to get hold of a copy of the full engine anyway in much the same way you can get hold of practically every piece of software, music and movie made so any encryption scheme based on that is no more than a deterrent anyway.
I can't see GG being too concerned about resources containing code from the engine being posted as Michael mentions all the resource section and forums are open to the public now anyway so whether it's posted here or elsewhere isn't any more secure. Not like they can re-construct an entire engine from a few snippets of code probably less than (0.5% of the engine size is included in any one resource).
Obviously I'm not condoning people just stealing code but really it's futile to fight it, all of the big companies - Microsoft, Adobe, etc, etc with their army of developers have been trying for years and haven't succeeded and at the end of the day it just costs them money and the product activation issues cause hassle for their legimate customers. Oracle are one of the few exceptions as they just just post all of their products on their site for free download and a license to use it personally for development, testing, prototyping purposes.
09/19/2009 (5:41 am)
@Adrian - there's one problem with your approach, if you haven't already got the engine then a resource is practically useless regardless of what engine code it contains.As Giuseppe mentions it's really easy to get hold of a copy of the full engine anyway in much the same way you can get hold of practically every piece of software, music and movie made so any encryption scheme based on that is no more than a deterrent anyway.
I can't see GG being too concerned about resources containing code from the engine being posted as Michael mentions all the resource section and forums are open to the public now anyway so whether it's posted here or elsewhere isn't any more secure. Not like they can re-construct an entire engine from a few snippets of code probably less than (0.5% of the engine size is included in any one resource).
Obviously I'm not condoning people just stealing code but really it's futile to fight it, all of the big companies - Microsoft, Adobe, etc, etc with their army of developers have been trying for years and haven't succeeded and at the end of the day it just costs them money and the product activation issues cause hassle for their legimate customers. Oracle are one of the few exceptions as they just just post all of their products on their site for free download and a license to use it personally for development, testing, prototyping purposes.
#15
It seemed to me that the encryption idea was a way of avoiding making the patch files and avoiding breaking the EULA at the same time. If someone already has an illegal copy of the TGEA source obtained through some other route then giving them access to my modified files doesn't distribute any GG code to them that they haven't already got.
09/20/2009 (1:59 pm)
The point of this is not to protect the resource, its to avoid distributing GG's code. The background is that a while ago I put up a TGEA resource with all the GG code still in the modified files. I always put my changes inside #ifdef ADE_name_of_change ... #endif blocks so its easy to see where they are in the code. It was pretty quickly pointed out to me that the way I'd released the resource violated the TGEA EULA, so I redid the resource as patch files, which was OK.It seemed to me that the encryption idea was a way of avoiding making the patch files and avoiding breaking the EULA at the same time. If someone already has an illegal copy of the TGEA source obtained through some other route then giving them access to my modified files doesn't distribute any GG code to them that they haven't already got.
Torque 3D Owner Daniel Buckmaster
At least for longer resources with a large number of modified files, I'm going to consider this... thanks for sharing the lightbulb moment!