Re: file encryption

@Origine, very good post on cryptography. 'd recommend GCM mode for AES encryption, IMO. (You could also use ChaCha20+Poly1305, which is AES in GCM mode without all the hardware acceleration and CPU-specific instructions and possible fallbacks to slower software implementations). It doesn't add any (outward/programmer-facing) complexity, but it is majorly different from CBC or CTR mode. CBC mode works by taking the current block of data (called the "plaintext") and XORing that block of data either with the previous block of data, or with the initialization vector (IV), then sending the result of that operation through the cipher, which outputs a new block of encrypted data (called the "ciphertext"). GCM works on a hole different level though. When GCM mode is used, it maintains an internal counter value. When you go to encrypt data, the value of that counter is passed through the cipher, and the result of encrypting the value of that counter is XORed with the plaintext, creating the ciphertext. So, the major differences are that CBC encrypts the plaintext with data that is already known before the operation even occurs(the initialization vector or prior block of data); GCM mode XORs the plaintext with output created by the block cipher, making it very difficult (if not impossible) for anyone to guess the output unless that person knows both the ciphertext and plaintext beforehand.
There are other things that make GCM and CBC different, as GCM provides both privacy and integrity and CBC doesn't, but that's not relevant to this discussion.
I digress, however. origine is right; if your performing encryption and decryption locally (which is most likely the wisest thing to do, as doing it remotely can cause massive delays depending on the speed of the connection) your key is compromised. Not immediately, but it will be eventually. There are ways to mitigate the discovery of the key via simple or even complex methods, such as well-written, secure memory management and storage routines, but eventually someone will obtain your key, even if you do everything correctly. It may not even be something you did; it could be a bug in the operating system, a processor bug (i.e. meltdown/spectre), a bug in the implementation of the algorithm you choose to use, and so on. So you can't prevent someone from getting your key, but you can make it pretty damn hard to do. Hope I didn't confuse anyone! smile
Just saw your question. One way you could encrypt a dictionary (or any type) is to serialize it, as Origine recommended, then encrypt that serialized data and do with it what you will.

-- 
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
  • ... AudioGames . net Forum — Developers room : amerikranian via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : amerikranian via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Origine via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Ethin via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Ethin via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Ethin via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Origine via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Ethin via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : amerikranian via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : amerikranian via Audiogames-reflector

Reply via email to