Thoughts on This Encryption Method, Please? 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.
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?