We can easily see the encryption key using a text editor

[ghost]

After saving a file, I can open it with a hex editor: (this was not encrypted, but it is not relevant to the save functionality or this Issue)

After the <?><->, I can easily view my encryption key (in this case it was 1234.)

Ideally this should be hashed, with the salt (possibly?) being based on the encrypted text.

[andrewjcourt]

Yeah, this is true. It wouldn't be a bad idea to encrypt the encryption key. I'll think about it.

[andrewjcourt]

Here's the plan: The numeric key will be converted to a character set based on the first four characters of the text file (whether encrypted or unencrypted).

For example, with a key of 1234 and the text "Hello world", the first four characters of the encrypted text will be "Igop" with the ASCII values of, for each character respectively, 73, 103, 111, and 112. These values are added to the key (i.e. 1+73, 2+103, etc.) to produce new ASCII values (74, 105, 114, 116) which are then converted to a string representing the encrypted encryption key (in this case, "Jirt").

This encrypted representation of the encryption key will be further obscured by meshing it into the text.

So, for the message "Hello world", the encrypted message, saved to a text file, will now appear as "IgJopip rzstsng" - that is, "Igopp zssng" + "Jirt", where the meshing method is to interpolate characters from the encrypted encryption key into the text at the third, sixth, ninth, and twelfth positions.

There would still be an encrypted/unencrypted flag somewhere in the text, although this too could be disguised.

Reverse method to decode.

Note that this approach would require disqualifying messages of fewer than four characters from being saved.

[ghost]

There is another possible way: just use hashlib to hash the text, and then hash the code using the text as a salt. Best practice is to repeat this multiple times, so you could use:

salt = hashlib.sha224(encodedText).hexdigest()
for i in range(0, 100):
    hashedKey = hashlib.sha224(key + salt + hashedKey).hexdigest()

Then store the key just like you do now. After prompting for an unlock key, take it through the same process.

Edit: The unencoded text wouldn't work for decrypting because it would have to be unencoded which would require the key. I changed it in the example.

[andrewjcourt]

Interesting idea. However, I think I'll stick with the solution as outlined above as I'd prefer to code it myself rather than use an inbuilt function. That way, should my student (E*) at any stage ask me to explain how that bit of code works, I'll know what I'm talking about. Full customization.

Also, using a Caesar sometimes results in amusing combinations in the encrypted output.

But hashlib looks good for possible future applications where these factors aren't factors.