Re: Let's share some useful Python code
@2, if your not going through an intermediary like this library, pretty much every crypto library offers a way to decrypt encrypted data streams into RAM without dumping stuff on the disk. It won't stop someone from freezing the execution of the python interpreter and extracting the key but it will stop the casual FS snooper who just wants your decrypted sounds and knows where the game puts them. That is, of course, depending on if the person has the know-how to figure out where the game extracts its sounds to.
Looking through this code, I've noticed several issues with the code already:
* You use a hardcoded nonce! Don't do this! Ever! Pull from os.urandom()!
* Not really sure why you use a hardcoded zlib compression level... definitely not major, but it takes control away from the user. (Don't let the user give you a nonce; assume that all your users are stupid idiots, even if they aren't.)
* You call print() in get_closest_offset(). What exactly are you trying to accomplish with that? You do know that the value of num and valueffaf will be printed side-by-side to sys.stdout, right?
* You have an add() method. Why? This is entirely unnecessary here, since add_file() does what your intending, so your imposing an unnecessary amount of overhead. Furthermore, you check file.__class__.__name__. Keep in mind that when doing type checks, you have type(), which I'd say is (probably) far more reliable than checking file.__class__.__name__.
* Once again, you use a hardcoded key and attempt to mask it in awhile loop. This is not going to work and is inherently dangerous. (As some might say, this is suicidal.) Given the fact that the key and nonce are constant, you are completely and utterly nullifying the security that AES would normally give you. You are not giving any form of security whatsoever doing this because your giving the attacker the keys to the kingdom.
* Why do you hash the key? What is that going to do? It does not provide any form of advantage, see my earlier point.
* You, once again, hardcode the nonce in the AES.new() call directly. So now you have 2 (or more) copies of the nonce floating around. That's a treasure trove for an attacker.
* You use EAX mode. Why not GCM or ChaCha20, both of which are TLS cipher suites? I hesitate to throw an accusation out at the developers of cryptodome, but is the EAX algorithm they use EAX or EAXprime? EAXprime has been broken (quite nastily, too).
* You use pickle more than once, and I'm confused on exactly what your attempting to do. Mind explaining that?
Overall, most of the decisions that you made during the development of this library were *very bad* ones. Some suggestions:
1. Stop using hardcoded data in cryptography. Avoid that at all costs. Never hardcode a nonce or cryptographic key, and never try hiding it -- an attacker (even a novice) will figure you out very quickly. The way you've used these algorithms is worse than even ECB (and that's saying something)!
2. (Perhaps) offer the user control over the compression level.
3. Remove all of these debug print statements. Perhaps, even, offer an interface that compresses the files into an archive and then encrypt the archive itself, rather than the files within it, and let the user extract the files into RAM instead of dumping them to disk?
4. Remove add(). Its entirely useless.
5. Remove the key hashing. This offers no form of security whatsoever (and given that you've hardcoded the key, the hash will *always* be the same, which would make it easy for an attacker to fool the system while giving it malicious data).
6. Switch to CBC, GCM, or ChaCha20/XChaCha20.
7. You don't have to do this, but try and avoid storing the key in unencrypted form. One way (if you ever use AWS SDKs) is to generate a data key per each encrypt, store the encrypted key alongside the nonce and encrypted data, and retrieve the key from AWS KMS when you need it. This will stop an attacker from retrieving the key from disassembly or hex dumps since it won't be hardcoded into your app.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
