Do you have to build an encryptor on your own? No, obviously. Even people with very good knowledge in security will make a flawed encryptor.

Here is a link to a guide for encryption in python. It doesn't explain how it works, just how to do it. pycrypto is in there, but they show various libs other than that: https://docs.python-guide.org/scenarios/crypto/

Now I'll give you some explanation. Pickle is just a serializer, it doesn't encrypt, its only job is to save an object and its state. You throw an object at pickle, pickle burps back serialized data and you can do whatever you want with it. You can store it to a file or send it over the wire to a server or another client or a remote database or what not. Now anyone can take serialized data and deserialize it, meaning it will convert back to its original object state, usable in your code. It's not safe, it's a convenient way to persist data.

Encryption is the process of blurring data so that it's impossible to make sense of it. You can very well encrypt serialized data, you can encrypt any data whatsoever. However, here's what you need to know. You encrypt data with a key. In symetric encryption, the key used to encrypt is the exact same key you need to decrypt. In asymetric encryption, you use a different key to encrypt and decrypt. The key to encrypt is public, meaning anyone can see it and the key to decrypt is private, meaning it must be safely stored somewhere. This means that anyone can encrypt data with that key, but only the holder of the private key will be able to read that data.

Now, if you make a local game, meaning that the game will run on the player's computer and that there is no server, you don't care about asymetric encryption, because there is no purpose of it. You will want to use symetric encryption, but there is something super important you must know. You cannot safely store that key. This means that no matter what you do, someone clever will be able to read that local file by decrypting it. What they have to do is find the key you used to encrypt it and if your game running locally on the PC can decrypt the file, it means it must have the key and if the local program has the key, then it is possible for someone to intercept it.

That being said, it can make someone's life harder, because retreiving that key can be difficult depending on how you do it. And you get to the difficult part of cryptography, which is key management. The problem is not the encryption algorithm, we have really good and safe algorithms, the problem is to securely manage, use, store, transfer that key.

As soon as the key touches something you don't control, consider that key compromised, it's not safe to use it. Again, I wanna stress this, if you make a local game running on a local PC and the program can decrypt the files, your key will always be considered compromised, there is nothing you can do about it.

A good symetric algorithm for encryption is AES-256, though you can also use AES-128. Block cyphers like AES have multiple modes of encryption, I suggest CBC with IV or CTR. An IV is an initialization vector, it must be random every time you encrypt data, but it's not a secret. I can tell the whole world I encrypted this message using this IV, it's totally safe as long as they don't have the key. You can use the same key to encrypt multiple times, but just take for granted that the more you use a key, the less safe it is. Changing a key is called key rotation and is probably not necessary in your case.

Yeah I wanted to talk about good practices in cryptography and how it works. I'm curious, what do you want to achieve with cryptography or what do you want to prevent with it in your particular case, OP?

@Ethan, doing encryption / decryption remotely would indeed secure the key, but it would serve no purpose. The question is against who are we trying to secure the information? If that person is the user / player, then decrypting remotely would probably make it even easier to see the decrypted information, if it's sent over HTTPS, then just open Fiddler or any web proxy and intercept it. It would require one additional layer of encryption in the application layer which is not required.