38 replies to this topic

[A v i]

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

 

I mean impossible to break by any means in the universe. Mathematically perfect encryption.
http://en.wikipedia....ki/One-time_pad

Very impressive. I think I will read more and more articles before having a final go at the topic. I will also try challenging myself and others (later) with small (Strlen = 3 or less) meaningful encrypted texts and passwords, in order to check how secure can it get.

[rbrtryn]

The script does NOT implement one-time pad; rather a computer version of the Vigenère cipher with a repeating key; this is trivially easy to break. Even if the key were non-repeating, you could still figure it out because you used actual non-random text and that has special properties.

+1 and even if it were a OTP, the OTP's many practical problems would prevent perfect security. I have nothing against the code itself, but the claims of its strength and security are over blown.

I'll stick with proven methods like TrueCrypt and GnuPG

[ErrorOnLine1]

@Fanatic Guru - Interesting wikipedia article. Thanks for posting the link.

 

I've been fascinated by encryption\secret messages since reading the 'Gold Bug' as a kid. I was heartbroken when my Sky King Secret Decoder Ring got lost in the mail.

 

[Fanatic Guru]

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

[Fanatic Guru]

I've been fascinated by encryption\secret messages since reading the 'Gold Bug' as a kid. I was heartbroken when my Sky King Secret Decoder Ring got lost in the mail.

There is something fascinating about encryption\secret messages.

I loved that stuff as a kid too.

And I have spent the past couple of days fooling around with it which I had no intention of doing but it lured me in.

My final script is simple but I spent hours working on a more complex script before making the one I posted.

My first attempt handled things in blocks instead of one character at a time and I just could not get it to work. I had trouble with losing leading zeros and partial blocks and other things that I never worked out.

I did discover that encryption code is very hard to write because it is very hard to debug. It is hard to figure out when something is going wrong because all your variables contain gibberish.

After failing to debug my original script I broke down and wrote the draft of the script that I posted in about 10 minutes. I was surprised how easy it was. It only had one function. You sent in a string and key and you get back out a encrypted string. Send the encrypted string in and the key and get back out the original string.

But it had problems with getting control characters that messed things up so I had to figure out how to avoid these control characters. It took about another 20 minutes to figure out I could divide it into two functions and shift the range of characters used higher.

It all started with the realisation I could do this:

Number := "1234567890987"
Key := "1371113171923"
Coded :=Number ^ Key
Decoded := Coded ^ Key
MsgBox % "Number:`t" number "`n`nKey:`t" Key "`n`nCoded:`t" Coded "`n`nDecoded:`t" Decoded

This is basically one-time pad encryption in a nutshell. It is very easy when using just numbers.

FG

[pajenn]

\snip

 

This is basically one-time pad encryption in a nutshell. It is very easy when using just numbers.

FG

 

 

I saw someone in another forum post their version of a one-time pad (OTP) encryption/decryption implementation. I think it's in c++ but it might still be of interest to you or others here working on one-time pads.

 

Here's the link: http://16s.us/FreeOTP/

 

As I understand it, OTP is well-suited to encrypting short messages, like IMs, and is unbreakable without the key, so it would be pretty awesome to have assuming of course that modern computers can generate sufficiently random keys.

[T_Lube]

I can see that what you have done seems really simple. A lot easier than the stuff that I have done with encryption. I guess I began to wonder what causes an industrial strength encryption can be doing that makes it so random and therefore hard to crack.

[T_Lube]

I think no matter what a substituion cipher is a bad way to go, it has predictability.

[kaka]

At this point it is more just a mental challenge to see what kind of encryption I can come up with without looking at any references or others work and not using the Random command as that relies heavily on someone else's work that I could not reproduce independently.

Simple Commands Encryption:

String := "Each script is a plain text file containing commands to be executed by the program (AutoHotkey.exe). A script may also contain hotkeys and hotstrings, or even consist entirely of them. However, in the absence of hotkeys and hotstrings, a script will perform its commands sequentially from top to bottom the moment it is launched."

Key := "Creating a script"

Coded := XOR_String_Plus(String, Key)
Decoded := XOR_String_Minus(Coded, Key)

MsgBox % "String:`n" String "`n`nCoded:`n" Coded "`n`nDecoded:`n" Decoded

XOR_String_Plus(String,Key)
{
	Key_Pos := 1
	Loop, Parse, String
	{
		String_XOR .= Chr((Asc(A_LoopField) ^ Asc(SubStr(Key,Key_Pos,1))) + 15000)
		Key_Pos += 1
		if (Key_Pos > StrLen(Key))
			Key_Pos := 1
	}
	return String_XOR
}

XOR_String_Minus(String,Key)
{
	Key_Pos := 1
	Loop, Parse, String
	{
		String_XOR .= Chr(((Asc(A_LoopField) - 15000) ^ Asc(SubStr(Key,Key_Pos,1))))
		Key_Pos += 1
		if (Key_Pos > StrLen(Key))
			Key_Pos := 1
	}
	return String_XOR
}

There does not really have to be two functions. There are two functions only because I wanted to push the character range up into more interesting characters and out of special control characters so add 15000 in one function place and subtract it in another. If you don't want to shift the character range the same function encodes and decodes but you can get funky undisplayable control characters that can mess things up.

It is possible certain Key and String combinations can create control characters that AHK will have trouble processing. If everything was low level file to file it probably would not matter but attempting to display every character that Chr() can produce can probably have weird results when you try to display them.

Also if you are willing to make the Key as long as the String being encoded then the code becomes unbreakable.

Output:


FG

 

Wow. Great script. Can you please make it compatible with basic version of AHK??? i would be great help.