# Thoughts on This Encryption Method, Please? [closed]

I'm very much an amateur programmer, and 90+% of the math of true encryption is way over my head. That said, I did write an encryption program once upon a time and I'd appreciate your thoughts on it. It was written in C++ as a command line executable that accepted a filename and a password as input. To encrypt, you would enter 'N-Crypt filename password'. What it did was almost ludicrously simple. It opened the file it was to encrypt, looked at each byte in order and converted it to a value from 0 to 256 value based on the password you specified, using each successive ASCII character value of the password in order and cycling back to the first character when it reached the end. It also alternated between adding and subtracting the character value So, for example, if the password was 'God' and the first byte of the file had a value of 30, it would add the ASCII value of 'G' which is 71 to the 30 and return 101. If the resulting value was greater than 255, it would cycle around, so 256 would become 0. If the second byte of the file was 220, it would subtract the ASCII value of 'o', which is 111, and the result would be 109, and so on until the entire file was encrypted, then it would overwrite the original file with the encrypted version.

Ludicrously simple, yes? But here's where I think it got interesting - you could cycle the file encryption through as many different passwords as you wanted, and there was no limit on how long the password could be (except whatever limits the command line structure had). So, say you started with a jpeg file, and cycled it through three encryptions using three different passwords. To decrypt the file, you had to reverse the process with the D-Crypt command line program, using the original passwords in reverse order. If you didn't get any part of the passwords correct, the decryption process would fail, producing a file of gibberish. The only way anyone could know they'd successfully decrypted the file is it come out as whatever the file originally was.

So, my question is this. If your a highly paid NSA cryptologist and you are handed a mystery file encrypted in this manner, what are your chances of successfully decrypting it? What methods would be useful given the encryption scheme? Some of the first issues you face include 1. Not knowing the encryption scheme. 2. Not knowing the passwords. 3. Not knowing how many passwords were used. How would your chance of decryption improve if you also had copies of the encryption and decryption programs (you still would be facing issues 2 and 3)? To my non-cryptologist's brain, my scheme seems pretty secure, but you hear about decryption methods that border on the miraculous, so I really have no clue how secure it really is.

Thank you for any reply you care to give.

## closed as off-topic by yyyyyyy, Henrick Hellström, otus, Ilmari Karonen, tyloAug 22 '16 at 12:57

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

• Hint: Search Vigenere cipher, One Time Pad and Least Common Modulus. Using a triple Vigenere Cipher derivate that alternates between addition and subtraction with keys of length $k,m,n$ will never be more secure than using a Vigenere Cipher with a single key of length $LCM(2,k,m,n)$. – Henrick Hellström Aug 21 '16 at 1:10
• "Schneier's Law": Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break. – zaph Aug 22 '16 at 17:50

That looks like a (polyalphabetic) substitution cipher, with a less-straightforward method of entering the key. As already mentioned in the comments, close to the Vigenère cipher, which is rather well known. IIRC ciphers like that were used (and broken) in times before WWI (or WWII?), The Code Book by Simon Singh has material about historical ciphers, among other books, if you are interested.

As for not knowing the algorithm, it's usually taken as granted as the algorithm will be known (Kerckhoffs's principle), as it's hard to keep it hidden if the system is used widely enough and there is sufficient interest in it. Either the algorithm is widely available and can be bought, or it will be found out by old-fashioned spying, or in case of a single criminal using it, law-enforcement will be happy to read the software off your computer... (Since you need to have an unencrypted copy of the encryption program anyway.)

As for the system, consider that using words as keys isn't that unpredictable, passwords are attacked with dictionaries daily, and the range of 26 letters out of 256 values is also quite small (if mostly lower-case letters.) Also, this isn't strictly true:

To decrypt the file, you had to reverse the process [...], using the original passwords in reverse order.

The algorithm has a property that makes the order of the keys irrelevant. Perhaps you can find it?

So, my question is this. If your a highly paid NSA cryptologist and you are handed a mystery file encrypted in this manner, what are your chances of successfully decrypting it? What methods would be useful given the encryption scheme? Some of the first issues you face include 1. Not knowing the encryption scheme. 2. Not knowing the passwords. 3. Not knowing how many passwords were used. How would your chance of decryption improve if you also had copies of the encryption and decryption programs (you still would be facing issues 2 and 3)? To my non-cryptologist's brain, my scheme seems pretty secure, but you hear about decryption methods that border on the miraculous, so I really have no clue how secure it really is.

No need to be a cryptanalyst at all, your encryption is a totally broken classial encryption scheme. Even with a single file (of certain length depening on keyword lengths), this is broken on a modern computer almost instantly. But now to your actual questions:

1. This is an invalid assumption. According to Kerckhoff's principle security must still hold, even if the attacker knows everything except the key. It is naive to think, the attacker hasn't done some research, or that your algorithm isn't showing what it is doing. For example, chances are quite high, a serious attacker is able to decompile your program code from a binary.
2. "Passwords" can be considered as low-entropy versions of actual keys. Using them without any transformation in an encryption scheme is really, really bad. Common practice today is to use a so called "password-based key derivation function", such as PBKDF2, bcrypt or scrypt. Without those, you can not make the necessary assumptions about the key for any proof of security. For example, basic encryption schemes require the key to be uniformly distributed over some range. Passwords simply are not.
3. This is irrelevant, because the attacker can find that out, but let's get back to that later

So I suppose you know the Vigenere cipher, which is already really clsoe to your scheme.

1. difference: You alternate between adding and subtracting. But if we consider that subtracting one number is equivalent to adding another, this doesn't make a difference. All it does is allowing different keys. If the length of the password is odd, then it means we alternate between "start with add" and "start with subtract", basically doubling the password size. Example: $-5$ is equivalent to $+251$ modulo $256$

2. difference: Multiple rounds: The cmost crucial weakness of the Vigenere cipher is that in fixed intervals you have the same shift again. If your password has length 5, then every 5th letter is shifted by the same amount. The weakness is there, regardless if the length is 2,5,10,20 or 50. Let's consider your scheme with two passwords, both of length 5. Then write down the original string and the encrypted one and their difference. You will again notice, that the difference also has period 5, just like both passwords. And these differences are basically just one password, which combined both your passwords. If the password lengths are not the same, then the period will be the least common multiple of the password lengths. E.g. Passwords with length 3,5 and 10 will result in a total period of 30. But if the file is long engouh, the password length in Vigenere does not matter. It is still easily detectable through auto correlation. And once the password length is revealed, the rest is simple (breaking a couple of Caesar ciphers).

The Vigenere cipher is considered broken for ~150 years. Your changes actually don't change anything effectively. Probably it was a nice exercise, but this is not "hard to crack for the NSA", it is the oppsite.

Without extensive knowledge in cryptography (as a science), chances are basically zero to create an encryption scheme, which would be considered secure. This already starts with the basic assumption, that it is simply not enough to assume ciphertext-only-attacks. See more about that here