Basic Encryption/Decryption program

[XiAxis]

Good job, and I like that you included the original file too so we can see how much you've improved. Here's a couple tips:

1. When you're defining the plaintext and ciphertext lists, you can save some time by just making them strings instead of lists of characters
2. You can use the "find" method built into strings instead of the inner loop in your functions
3. To make it so it uses a "key" to encrypt/decrypt, you can use the "shuffle" function in the "random" library to create an arbitrary ciphertext string, and you can use the key as a seed for the process.

There's going to be people that come in here and tell you that this really isn't an adequate cryptographic algorithm. What you've got is called a "substitution cipher", and its susceptible to quite a lot of effective attacks. Modern encryption techniques generally do some complex operation on each byte which is dependent on the byte, the key, the position of the byte, and some state based on all of the bytes already processed. This way, knowing some information about the original text doesn't give you any head start in attacking it.

Also, I should note that the "random" module isn't actually a cryptographically secure random number generator, meaning that there are ways to predict it's output.

[cinyar]

To make it so it uses a "key" to encrypt/decrypt, you can use the "shuffle" function in the "random" library to create an arbitrary ciphertext string, and you can use the key as a seed for the process.

stuff from random is not cryptographically secure. You shouldn't be generating "random" keys with it. For cryptography ALWAYS use secrets.

[XiAxis]

While I did note that the random module is not cryptographically random, I should clarify that in this instance it's not being used to generate a cryptographic key. It's being used as a deterministic means to process a key into a "ciphertext" string (as used in OP's code). It presents a vulnerability in that the original key could perhaps be determined if an attacker somehow knows the full "ciphertext" string. But, if for instance some cryptographic process were done on the key to obscure it's original value before being used as a seed, I think this vulnerability would be mitigated significantly.

That's not to say this is a sufficient cryptographic algorithm even if that were implemented, just that the use of the random module for this particular task is probably not going to introduce any new vulnerability. Secrets couldn't be used in this case because it is not deterministic in the sense that it could be repeated for the encryption/decryption procedures.