gandalf- / locknut-encryption Goto Github PK

Running the program on .doc files breaks them. Comparing the contents of original file in plain text and the file after encryption-decryption has been run on it shows that some symbols aren't being put back. Some symbols may be missing entirely.

There used to be a bug similar to this that showed up even in plain text files in which "s and 's weren't being converted back properly. This was fixed by adding the modulo fix to the encryption algorithm.

        ;Check for max modulo case, fix if necessary
        (when (and (= 0 new-shift-amount) 
                   (not (= 0 (char->integer (car remaining-input)))))
          (set! new-shift-amount 200))

I assume that these issues are related but I'm not sure, and if they are, exactly how.

One of the strengths of the old algorithm was the huge possible shift amounts; the shift amounts for Waterfall are significantly smaller and more predicable since they come from the previous plain text.

One approach would be to use the encrypted previous chunk as the key for the current chunk. This could cause issues in files that have more characters than in UTF-8. Racket allows (integer->char x) up to 1,114,111. Supposing the average character is within typical ASCII character range, 0-128, this allows a "safe" maximum of (* 8,700 chunk_size) characters before overflow would occur.

Currently, the chunk size is set to the password length, which is being buffered to 50 characters. So we'd have to get about 435,199 characters into the file before worrying about overflow. That's less than half a megabyte.

Supposing a more generous average character size, say (122 - 65) / 2 = 94. We get 592,612 characters before overflow is imminent. Which is a little bit over half a megabyte, still not very much for something like a big PDF.

Another option would be to boost the chunk size. Doubling the chunk size doubles the safe range of characters. This is going to have a limit though. It'll be difficult to ensure the quality of the initial key if it has to be expanded a huge amount. Chunk size could be determined as some percentage of total file length?

Perhaps a better idea is to have chunk size increase by some percentage as the cipher continues. The additions would start at 0 characters with the initial key, and increase from there. Linear expansion would still eventually run into the overflow problem, but exponential expansion could possibly try to grab more than file before the current chunk than there is file to grab.

Another possible approach is to use more than one previous chunk as the key for the current chunk. (key_n = key_n-1 + key_n-2). This introduces at least one issue in that either we'll need two passwords, a password twice as long as the rest of the chunk lengths, or chunk lengths that are half as long. None of these seem ideal.

One more idea is to implement a modification on the chunk size increasing idea, where it changes in a sinusoidal manner between some reasonable minimum and maximum chunk lengths. Ideally this change would be generally unpredictable and certainly change between different passwords.

Is it still possible to decipher text that uses different chunk sizes? We definitely can't retroactively re-encrypt things, there'd be no way to figure that out coming back through from left->right. What does it even mean to increase chunk size? Decryption seems possible, you'd just need to maintain the original encrypted list as you're working to reference back to. The back referenced chunk needs to be encrypted with the key too, otherwise you're just sprinkling answers throughout the cipher text.

This example isn't perfect, but gets the idea across (key=1111, plain text=1234 1234 ...):

1111
1234 1234 1234 1234 ...

____ 6123 4 => Reach back encrypted 1 chars (5+1)
2345 1234 1234 1234 ...

____ ____ _751 234 => Reach back encrypted 2 chars (7+1,5+2)
2345 7357 5234 1234 ...

____ ____ ____ ___4 7(11)1234 => Reach back encrypted 3 chars (3+1,5+2,8+3)
2345 7345 2985 3584 ...

...

1111
2345 7345 2755 2344 1234

____ 5111 1
1234 6345 2755 2344 1234

____ ____ _521 111
1234 1234 1755 2344 1234

...

The next chunk wouldn't ever reach back further than it's only length if they continued increasing, so you'd only need to keep track of the previous encrypted chunk. If the chunks decrease too, then this would be more complicated. You'd need to define the maximum reach back and keep track of enough encrypted chunks to maintain that if needed.

Would this really add any strength? The example below is misleading because the initial key is so simple. Besides, sure the chunk size is changing, but it's changing predictably, so that might not be very useful. I could image that the chunk "waves" could be semi-reliably determined by looking at the cipher text and watching fluctuations above typical character values, even though this would be obfuscated by the randomness of the plain text "underneathe". It'd need to run a longer example, but I could see this generating odd "spikes" of high values in the cipher texts around the boundaries of the chunks, even as the increase in length.

Waterfall encrypts by working in reverse. This doesn't really complicate things any.

There aren't any standardized tests for any part of the program. This would be easier to do once the CLI functionality is complete.

Locknut.rkt needs to be re-organized to correctly reflect the different frames. Buttons, fields, and panels should be organized by their parent frame.

More testing should be done to ensure the integrity of decrypted text; decrypt( encrypt (text) ) ?= text

Options page has only one option. More should be added or the page should be removed.

Is "Use password as Vigenere Key" still functional? I don't think it's been tested since modularity was added.

Decrypted files default to .txt
It should be simple enough to store the previous file extension in the encrypted .locknut file, then put everything back the way it was.

The current encryption algorithm uses a Vigenere Cipher with a predefined 100 character key. The default key (which is the same every time) is modified using the user's password to make each encryption unique to the given password.

This modification is done by converting each character in the given password to a shift amount and then adding this amount to the corresponding element in the default key. The password is undoubtedly shorter than the default key, so when it runs out of elements it starts over again at the beginning.

(password "Apples")
(default-key '(15 5 3 6 7 8 10 9 25) )

(password-converted '(65 112 112 108 101 115) )
(unique-key '(80 117 115 114 108 123... ) )

Additional security is added through the password verification process, but what can be done to improve the security behind the encryption process itself?