I suggested using a better compression module primarily to reduce the size of the overall pack file. With Zstandard, for example, you can pass in it about a hundred MB (or, even, just a few hundred KB) of data to "train" it, then you fuck with the compression level (which could be done automatically to find the smallest one by testing the size of the data per each round) so that we aren't distributing (possibly gigabytes) of game data around, and that size mostly consists of the pack file. All of my suggestions were just that, suggestions. No one has to actually use them. As for the AES/SHA thing, tha was a summary of the Crypto101 book, available at https://www.crypto101.io. The reason he stated that statement as one of his opening statements was that some people (especially those who aren't well trained in cryptography) tend to use raw APIs (that is, APIs that are low-level and offer high control over the cryptography process, like Cryptography's Hazmat layer) when the library offers a better (and probably safer) version, or they tend to write their own crypto scheme.
Clearly, pauliyobo was not doing that, but inserting that was more of a cautionary note than anything else. Plus, that brought me nicely into the IV/key issue.
And as for encrypting the entire file, that was, again, a suggestion; you don't need to do it. @8, hate to say it, man, but you certainly have the same attitude of "Any other comp science person would just laugh at you and ask if you're from mars"; and yes, while you do back up your posts with links, and stats, your general attitude has that kind of feel. So, really, its something both of us need to work on, though I don't usually exhibit that attitude off-forum (how odd!).
Now, to answer the final question, why should you use pyka/cryptography over cryptodome/pycryptodome/pycryptodomex. ? That was partially my personal opinion/bias, though Cryptography does offer its Fernet module, which abstracts away all the IV complexities, encryption scheme and such, so all you have to do is:
from cryptography.fernet import Fernet
# either allow Fernet to create you a key:
key =Fernet.generate_key()
# or pass in your own:
key="'SM{-Jb;5<Fy2C6(cuZ;ep87fjj5^7V&7*nSb<TG2"
# initialize Fernet
f = Fernet(key)
# encrypt data
data = f.encrypt("data".encode())
As for securely wiping memory, I've been doing my own research on that particular problem myself; Python isn't exactly an OK security instrument (of sorts) if you can't do that. So far as I know, I've found This issue on bugs.python.org, this (https://softwareengineering.stackexchan … -in-memory), and, of course, this known security limitations document (https://cryptography.io/en/latest/limitations). That document does state:
Memory wiping is used to protect secret data or key material from attackers with access to uninitialized memory. This can be either because the attacker has some kind of local user access or because of how other software uses uninitialized memory.
Python exposes no API for us to implement this reliably and as such almost all software in Python is potentially vulnerable to this attack. The CERT secure coding guidelines assesses this issue as “Severity: medium, Likelihood: unlikely, Remediation Cost: expensive to repair” and we do not consider this a high risk for most users.
How ever, I did prepend that suggestion with "if you can," so I was really hoping to find one, but my hopes aren't very high. The issue I linked to is probably the only true lifeline for security wiping we have, if they even choose to implement that, though I'd think they might just bring in something like Monocypher and its memory wiping functionality to do that instead.
As for the stack overflow answers, yeah, I've found some pretty dumb ones on there, though about 80-90 percent of the time I've found stack overflow to be very useful.
"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