It all depends on how much time and effort you are willing to devote to breaking it.

+1, you can always analyse patterns for an encryption by taking examples of very short strings and passwords. This will take the time but at last you have the precious bit of information

This thought that encryption can always be broken if you work hard enough at it is a misconception created by the almost universal use of imperfect encryption.

Perfect Encryption exist but it is very inefficient and is not used because imperfect encryption is so good and much more efficient.

My script is not the end all and be all of encryption. It is a fun implementation of some fundamental encryption techniques that I did for fun to see what I could get to work without using other peoples work.

And as a side note for those that were not away of mathematical perfect encryption I stated that if you made the key length the same length as the string it becomes an implementation of one-time pad encryption. Which I believe it does but I am no expert in coding or encryption I could have made a mistake. But it is at least an attempt at coding one-time pad encryption. Now if your key is not random it is a poor execution of using the one-time pad encryption. To get perfect encryption and to be mathematically unbreakable the key has to be perfectly random.

Getting a random key with a computer can be tricky. You can not get a truly random number from a computer with a purely software solution. But there is also a misconception that computer random numbers are predictable. You can get random enough from a computer for many applications. If I only want to encrypt a string that is less than about 600 characters I can use the random built into AHK as its pattern cannot be discerned without analysing at least 600 consecutive numbers. And it is worth noting that the number generated by AHK is not a purely software process, it uses a clock that starts at the unpredictable time that the computer is turned on and a keyboard that the user pushes at an unpredictable time. By rehashing random numbers together and using outside input like the user or some analog source a computer can generate random numbers that while maybe not mathematically perfect are good enough to generate a number that is non-predictable long enough to encrypt every word that has ever been written by humans. The problem is when you introduce infinite it gets just about infinitely hard to do.

Also a random key is only need to get mathematically proof perfect encryption. If you use a simple key that has some meaning to encrypt a string that has some simple meaning, the person decrypting it will assume that when they find a simple looking key that produces a simple looking string they have found the right key and solution combination. That is an assumption. Even if the key is not random it only allows the decrypter to make assumptions. Assumptions that may or may not be correct. It is possible to create a key and string combination that can fool the decrypter by making them assume they have found the solution when they have not. It is possible to create a encrypted string so that when a certain key is tried the solution is a nice pretty looking sentence that says "The missile launch code is: redbull" but that is not the correct key, when the correct key is entered the solution is a jumbled mess of characters that is the real launch codes to the nuclear missile. A non-random key only allows the decrypted to assume they have found the correct key based on assumptions of what the solution is suppose to look like.

Not to get side tracked my code is an implementation of one-time pad encryption if you make the key length the same length as the string. One-time pad encryption is a mathematically proof perfect encryption when the key is mathematically proof perfect random.

And of course this all goes without saying the encryption is only unbreakable from analysis. A key can always be obtained by other means like finding it on a postit note stuck to the computer or paying someone a dollar to tell it to you.

Now all that said if you use a key shorter than the length of the string like I did in my example, that is a totally different beast than one-time pad encryption. You end up with an encryption that is great... if you were using it about 100 years ago. But like I said this thread seems to be about fun encryption without using others peoples prior work which is what I did.

Now if I wanted to improve on it. I would slice and dice the resulting encrypted string and then encrypt it again. Repeat, repeat, repeat... etc. Slicing and dicing the string each time in a particular but hard to predict way based on the key so that I could unslice and undice it to decrypt. I imagine with enough rehashing I could get an encryption that could hold up to modern analysis but would be incredible slow and resource intensive compared to modern encryption.

And I totally agree with rbrtryn if you want to encrypt something for practical purposes there is no reason to try to reinvent the wheel because there are plenty of free and very effective encryption softwares out there. Plus it is more like reinventing the fighter jet engine, you are not going to reinvent modern encryption unless you put a lot of work and knowledge into it.

FG