47
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 01 Apr 2024
47 points (98.0% liked)
Game Development
3412 readers
4 users here now
Welcome to the game development community! This is a place to talk about and post anything related to the field of game development.
founded 1 year ago
MODERATORS
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 1
in the example CLI), and one full execution of bcrypt to last 47.5 seconds (rounds=20
and thebcrypt
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.