Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

We can easily see the encryption key using a text editor #3

Open
ghost opened this issue Nov 25, 2017 · 4 comments
Open

We can easily see the encryption key using a text editor #3

ghost opened this issue Nov 25, 2017 · 4 comments
Assignees

Comments

@ghost
Copy link

ghost commented Nov 25, 2017

After saving a file, I can open it with a hex editor:
screen shot
(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
Copy link
Owner

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

@andrewjcourt
Copy link
Owner

andrewjcourt commented Nov 29, 2017

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
Copy link
Author

ghost commented Nov 29, 2017

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
Copy link
Owner

andrewjcourt commented Nov 30, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant