I can’t really imagine how would this work in practice. While “I’m using industry standart AES encryption” may mean the cypher and the key itself will not be breakable, the bigger issue is how to get the 256b key from the player. Does he expect them to actually figure out and manually input 265b of data? That would be a pretty hefty game design challenge to make something like that possible.
I’m betting there’s probably something that generates the key from a vastly smaller player input, i.e what gameobjects you interacted with, in what order, or what did you press/place somwhere. But that also means that the entropy is probably in the bruteforcable range, and once you find the function that decrypts the secrets, it should be pretty easy to find the function that generates the key, and the inputs it takes.
The only A solution to keeping data from data-miners I can imagine would require just storing the key on the server - which could generally also be bypassed, since then you probably need a way to request the key, which could be data-mined and faked, so you’re back at step one - how to validate requests for the key.
Or just make the secret puzzles so difficult, that they can’t be brute-forced and the result really is 256b or more of data. Thinking about it, having specified 256 inputs you either have to make or are red-herrings that shouldn’t be interacted with isn’t really that much, but then the data-miner can just check the location of each one and filter out the inaccessible, and bruteforce the rest. And if all are accessible, it would make for a really difficult secret to discover properly.
I’m betting there’s probably something that generates the key from a vastly smaller player input, i.e what gameobjects you interacted with, in what order, or what did you press/place somwhere. But that also means that the entropy is probably in the bruteforcable range, and once you find the function that decrypts the secrets, it should be pretty easy to find the function that generates the key, and the inputs it takes.
When handling passwords, it is standard practice to use an intentionally costly (in CPU, memory, or both) algorithm to derive the encryption key from the password. Maybe the dev can reuse this? The resulting delay could easily be masked with some animation.
Most of the costly algortihms I know of are still reasonably fast, i.e you can try thousands of checks per second, so it would definitely help, but you would then still have to design a puzzle that has a large number od possible answers or combinations - which I still think really limits what you can create with it.
He could design a check/hash that would take a lot longer than common algs like bcrypt, but then theres a risk of someone reverse engineering it and simplyfiing it, or even finding a vulnerabilty that makes guessing the key easier. Because its suprisingly really difficult to make a hash that is matematically ok and doesnt have side-effects. Especially since crypto is dealling with some obscure advanced math, and some of the vulnerabilities in existing algorithms are pretty mind-blowing - especially since the more math you stack up, the more chances are there of you unknowingly using some kind of obscure math laws that can be used to simlplyfi or predict the results of your algorithm.
For a really bad and simple example (that kind of illustrates the point) from the top of my head, if i was just multipliing the input by 2 to get the key, and i did it 1000 times, it would mean that 1) the attacker could make it faster by multiplying it just once by 2^1000, and 2) the result would always be even, so now he knows he only has to bruteforce half of the keys, since it cannot be any odd key.
Ultimately you can configure these however you want. On my 5600X, I easily got one full execution of scrypt to last 34.6 seconds (--logN27 -r 1 -p1 in the example CLI), and one full execution of bcrypt to last 47.5 seconds (rounds=20 and the bcrypt Python library).
This kind of configuration (ok, not this long, but definitely around 1 second per execution) is very common in things like password managers or full disk encryption.
I am guessing it will just be sharded and hidden throughout the code in areas that get triggered as you play though the game.
The only real question is if it is quicker to find it in the code or to play though the game. IMO that is all a bit pointless as once it is cracked it will be cracked. All this does is maybe buy a few hours after launch (assuming the game files are not predownloaded before then) at best before all the info is available online. And now they have announced this quite a few will take it as a challenge and I doubt it will really slow anyone down.
I can’t really imagine how would this work in practice. While “I’m using industry standart AES encryption” may mean the cypher and the key itself will not be breakable, the bigger issue is how to get the 256b key from the player. Does he expect them to actually figure out and manually input 265b of data? That would be a pretty hefty game design challenge to make something like that possible.
I’m betting there’s probably something that generates the key from a vastly smaller player input, i.e what gameobjects you interacted with, in what order, or what did you press/place somwhere. But that also means that the entropy is probably in the bruteforcable range, and once you find the function that decrypts the secrets, it should be pretty easy to find the function that generates the key, and the inputs it takes.
The onlyA solution to keeping data from data-miners I can imagine would require just storing the key on the server - which could generally also be bypassed, since then you probably need a way to request the key, which could be data-mined and faked, so you’re back at step one - how to validate requests for the key.Or just make the secret puzzles so difficult, that they can’t be brute-forced and the result really is 256b or more of data. Thinking about it, having specified 256 inputs you either have to make or are red-herrings that shouldn’t be interacted with isn’t really that much, but then the data-miner can just check the location of each one and filter out the inaccessible, and bruteforce the rest. And if all are accessible, it would make for a really difficult secret to discover properly.
When handling passwords, it is standard practice to use an intentionally costly (in CPU, memory, or both) algorithm to derive the encryption key from the password. Maybe the dev can reuse this? The resulting delay could easily be masked with some animation.
Most of the costly algortihms I know of are still reasonably fast, i.e you can try thousands of checks per second, so it would definitely help, but you would then still have to design a puzzle that has a large number od possible answers or combinations - which I still think really limits what you can create with it.
He could design a check/hash that would take a lot longer than common algs like bcrypt, but then theres a risk of someone reverse engineering it and simplyfiing it, or even finding a vulnerabilty that makes guessing the key easier. Because its suprisingly really difficult to make a hash that is matematically ok and doesnt have side-effects. Especially since crypto is dealling with some obscure advanced math, and some of the vulnerabilities in existing algorithms are pretty mind-blowing - especially since the more math you stack up, the more chances are there of you unknowingly using some kind of obscure math laws that can be used to simlplyfi or predict the results of your algorithm.
For a really bad and simple example (that kind of illustrates the point) from the top of my head, if i was just multipliing the input by 2 to get the key, and i did it 1000 times, it would mean that 1) the attacker could make it faster by multiplying it just once by 2^1000, and 2) the result would always be even, so now he knows he only has to bruteforce half of the keys, since it cannot be any odd key.
Ultimately you can configure these however you want. On my 5600X, I easily got one full execution of scrypt to last 34.6 seconds (
--logN 27 -r 1 -p 1in the example CLI), and one full execution of bcrypt to last 47.5 seconds (rounds=20and thebcryptPython library).This kind of configuration (ok, not this long, but definitely around 1 second per execution) is very common in things like password managers or full disk encryption.
I am guessing it will just be sharded and hidden throughout the code in areas that get triggered as you play though the game.
The only real question is if it is quicker to find it in the code or to play though the game. IMO that is all a bit pointless as once it is cracked it will be cracked. All this does is maybe buy a few hours after launch (assuming the game files are not predownloaded before then) at best before all the info is available online. And now they have announced this quite a few will take it as a challenge and I doubt it will really slow anyone down.