Principles and examples of "unbreakable" code.

Hello everybody, today i realised that my efforts of an unbreakable code have been thought about before, and have been published before, so i decided to do some research on them.
I found that the principles had already been published by people (someone nicknamed "oddballz194")

Here is it is explained by him -

Code:

---

There is only one unbreakable code. It is called the One Time Pad. To use it, we need two keys. One key is the same regardless of message: You simply assign numbers to the letters. Here's one example:
a-1 b-2 c-3 d-4 e-5 f-6 g-7 h-8 i-9 j-10 k-11 l-12
m-13 n-14 o-15 p-16 q-17 r-18 s-19 t-20 u-21 v-22
w-23 x-24 y-25 z-26
Now create the pad, which is the other key. To do this, simply use a random string of digits. They are usually square, like so:
914 894 237 414 507
733 193 129 394 912
903 478 284 271 327
549 854 485 456 938
495 638 585 203 485
I will give an example of encoding a message, which will describe the message. For example, to encode a message "Let's go out", we do the following:
The Letter L is 12 in our first key, so we add 12 to 914 to get 926. E is 5, so we add 5 to 894 to get 899. Continuing, we get:
926 899 257 433 514
748 208 150 414
To decode this message, we need BOTH keys. Presumably you gave the pad itself to your intended recipient already. All he has to do is take the coded message and subtract the numbers from the pad. In this case:
926-914=12
899-894=5
257-237=20
...And so on. When finished, he gets:
12 5 20 19 7 15 15 21 20
Now decoding, it becomes: letsgoout
This code is impossible to break without the pad itself. As a result, once the message is passed, you should destroy the pad used for that message. When decoding a message, the pad used to decode it should be destroyed. That way, no two messages are encoded with the same pad, and it becomes impossible to break. This code has been used, with some variations, by the intelligence services of several nations, including the USA and the USSR (back when it existed). It is mathematically impossible to break since without the pad there is no way to know which letter corresponds with a coded value.
Have fun!

---

In theory he is correct, and so, i decided to try and mimic this behaviour using Visual Basic, to my surprise it was quite easy.
(Please ignore messy code, i'm sure people will be able to improve on it, i'm just showing you how its possible)

I wrote the attached code earlier on today and thought you might like to see how it works.

Note: The code is still messy in places. The distirbution of the file may make it easier to crack, so be careful.

Enjoy.

Great one,

This is indeed unbreakable if the rule is followed. That rule is to never reuse ANY one-time-pad.

This rule, however, makes this technique impractical for most computer based applications. The question becomes, how do you get the one-time-pad over to the client app each time a message needs to be decoded? Any transmission of the pad would have to be encrypted and then your final encryption is reduced to the strength of the encryption you used to transmit the one-time-pad.

You cannot use an algorithm to generate pads since they must be random.

I suppose the client can be shipped with a finite number of pads and when that supply runs out new pads will have to be hand delivered from the source.

To see what can happen if a pad is reused look into a topic called "Venona Papers". In this case a Russian accidentally reused a pad and the US was able to decode a small chunk of very useful intelligence including lists of active spies within the US.

Good point, this is where the major flaw is...

Lets see.
Its easy to generate a new pad, you can do this by loading your Values file into a program like the following -

VB Code:

'You will need
'Listbox named List1
'CommonDialog control named CD
'Command buttons, Command1,2 and 3 respectively
Private Sub Command1_Click()
Dim ff As Integer
Dim Splitstr() As String
Dim str As String
ff = FreeFile
CD.ShowOpen
Open CD.FileName For Input As ff
Do Until EOF(ff)
    Line Input #ff, str
    Splitstr = Split(str, "•")
    List1.AddItem Splitstr(0)
    List2.AddItem Splitstr(1)
Loop
Close ff
Command1.Enabled = False
End Sub
 
Private Sub Command2_Click()
Randomize
        With List1
        For i = 0 To .ListCount - 1
            iIndex = Int((.ListCount * Rnd) + 1)
            sItem = .List((iIndex - 1))
            .RemoveItem (iIndex - 1)
            .AddItem sItem
        Next i
        End With
    Command3.Enabled = 1
End Sub
 
Private Sub Command3_Click()
Dim ff As Integer
Dim i As Integer
ff = FreeFile
CD.Filter = "Value Files(*.val)|*.val"
CD.ShowSave
If Not CD.FileName = "" Then
    Open CD.FileName For Output As ff
        For i = 0 To List1.ListCount - 1
    Print #ff, List1.List(i) & "•" & List2.List(i)
        Next
Else:
End If
End Sub

Maybe another developer could somehow find a way of making this work ?

:afrog: See if you can work this out.

0110001001100111001100110110100100001110100011010001010010001111000010100100010000011100010110000101 1110010101110100011000101001010111001101000100010100100011110100011101110011010100111000100101101101 0010101101111001100101010110001001100111000101001111010100010100100011110000101001000100011011010010 1011010000000000110100110001100000000101111001010111011000100110011100011001101101110001110001011000 0001010010001111000100011110010101000000000011110111111100010001010111001101000101000000000011010001 0001111001010001010010001111001100110110100101100010011001110100011000101001000100011110010100000100 0000000000001010010001000010000000000000000111000101100000010100100011110011000110000000

You will never work it out. When you give in I will give you the clues.

binary?

It is binary yes, but there is a message in there. It is a 32768 bit message, and I have a key for it. So it would be impossible to crack without the key, and also because it is 32768 bit.

No one will ever figure it out.

Quote:

---

Originally Posted by fictional

No one will ever figure it out.

---

Then what is the point?

Impossible?

really... if the same "pad" is used twice, then it's easy to crack, if it's unique everytime... then it may be good...

what happens when the same "pad" is used twice:

Encrypting string "let's go in..." with whatever key

You use the program to generate an encrypted message for yourself

it gets encrypted to let's say "JówŠ‹fò›íQðùx"

you compare each and every single character from start to end...

"J" with "l", "ó" with "e", "w" with "t" ...

calculate the difference...

and voila, the formula is reversed...

I've compiled a few "magic formula finders" which basically attemps to find how an output was generated from an input...

it's always the same, lookup what happened in the input and the result that was output...

now, if the "pad" is destroyed and always unique...

that's another story, the user really needs to get that "pad" to decrypt the whole thing...

but be careful... :), just how do you intend to to send that "pad" to the user in a very secure way... with another "pad"? and that other "pad", with another "pad"... ?

:wave:

That is sort of what i was working on before. I made a encryption that couldn't be cracked unless you knew 1-6 digit number.

|-------------------------|
|Tempest's Encryption Code|
|-------------------------|

This encryption works by a letter representing a number.

Ok so here is the things you need to know

|---------------------|
|Tempest's Number Code|
|---------------------|

A=01 B=02
C=03 D=04
E=05 F=06
G=07 H=08
I=09 J=10
K=11 L=12
M=13 N=14
O=15 P=16
Q=17 R=18
S=19 T=20
U=21 V=22
W=23 X=24
Y=25 Z=26

|------------------------|
|Tempest's Random Numbers|
|------------------------|

124892
368293
621357
948762
283518

|-----------------------|
|Tempest's Letter Values|
|-----------------------|
10=Z
20=Y
30=X
40=W
50=V
60=U
70=T
80=S
90=R

|---------|
|Explained|
|---------|

Ok so lets say we have the word David(My name) So we check the number codes and replace each letter with the number.(If single digit number add 0 in front). So David would be:


D=04
A=01
V=22 0401220904
I=09
D=04

Ok now to get to the next stage pick one of the random numbers. We will use 124892 and then multiply 0401220904 by 124892.

0401220904 * 124892 = 5010928114236

The next step is to change the tenth part of a 2 digit number into a letter. So 5010928114236(Using the letter values would be)

VZR2S1Z4Y3U8

As you see the 50 is equal to V and then 10 is equal to Z etc.

Well there you go! Piece of cake!

|-------|
|decrypt|
|-------|

To decrypt this just do each step backwards. Sinse you don't know the random number divide by all 5 of them.

That is what i made myself. It was probably made before but meh... lol i was bored so thought this up.

I bow to your encryption skill's man that just inspired me.

I created an encryption a month ago and it was each letter = a 7 digit number and when encrypted it would excrypt the string 7 times and on the 8 time it would encrypt it into binary then encrypt using 2 fish encryption then encrypted with blow fish encryption. it came out to be vertualy imposible to crack unless you knew how it was encrypted and what each number would be. Now tell me is that an impossible code to be cracked or it was just a waste of time? Matter of fact i might even try do do as you said on creating a random number generator that could be reversed so like that it could never be reversed.

I hate to say this, but it is true. Any program that contains numbers assigned to letters is breakable. My basic encryption method uses no random numbers, and instead uses two keys for security of file. The keys are not contained within the file, but govern the decryption method itself. The advanced method i use, has multiple numbers for the same character, making it nigh on impossible to decrypt.

yes indeed true that is why i do not give my encryption program to anyone. i normaly use it to encrypt passwords for my personal use. And yes it is 100% crackable. I was hoping to learn how to make an uncrackable encryption (Unlikely but ill try) ill probly end up using binary and a bit of calculus on that part, i still say your encryption is pretty darn good and cheers on that one.


I was also wondering if you heard this years new uncrackable encryption method called CIPHERUNICORN-A? i read up on it and darn i say it would take about a couple of years to crack that baby. I'm hopping to make an algorithm like it in the near future (Highly unlikely ill succed :ehh: ).

sorry i forgot to correct my self. I meant "thegreatone"'s algorithm :)

Don't want to break anyones heart but you will never create unbreakable encryption on a "Deterministic machine".

Just my 2 cents.

It's always a matter of time before someone finds out how things were encrypted...

the easiest encryptions to crack are the ones that can be decrypted... such as adding 1 to the ascii character...

the hardest are the ones that can't be decrypted... such as MD5... (but it has been cracked...)

and when you can't crack it... you can always make a huge database of encrypted content to brute force it...

there is always a flaw... and when there isn't... you just have to make it :)

The code is breakable (any code is as long as you know the language of the original message and the number of cleartext characters and the number of coded characters is the same) - the only question is how long it takes to break any particular message. Using the fastest computers we have today, it could take months to break a short message, so the code is effectively unbreakable.

Quote:

---

Originally Posted by Al42

Using the fastest computers we have today

---

And the important part of the sentence is the plural to the word computers... of course a few super computers won't do... but thousands and thousands of sitting university computers, house hold gaming-cans and whatever techno-scraps connected to the net can help lowering the time... even mitnick went there...

Plus, a few websites actually encourage breaking encryptions using the unused processor cycles for the good cause of knowledge...

Anyhow... It always comes down to patterns... and when a program will be well made enough to analyse patterns effectivelly, it's gonna reduce the breaking time exponentially... I'm workin' on that a 'lil... but finding all encryption factors is hell... :p, yet challenging :)

good encryption will not be affected by the number of machines it runs on.
for example; let say that you use a base which would take the fastest computers a 400 digit number of centuries to decrypt.

lets assume that there are a billion of these fast machines, and that you control them all.

instead of a 400 digit number of centuries, you now have a 387 digit long number of centuries.
no big deal.

also, the first example, (the addition pad), would be make much more secure were it to employ mulitplication instead of mere addition.
you have to look at combinitorics- how many ways can the data be arranged? you will find that multiplying produces WAY more possibilities. also, aim to use a lot of even numbers in your pad- they factor out more ways, and thusly produce more dead ends.

finnally, DONT use the RND function to produce keys. its sequences are know and can thus be quickly cracked.

Now - I am not an expert by any means... which means - I will jump on a forum and pretend :)....

... anyway - I have thought about this a bit in practical terms.

One pad - unrealistic - to a degree.

Depends on the use. If its a use where you are transmitting from point A - to point B - and point B is supposed to be able to decrypt it always.... then its rather simple.

Obviously anything is as safe as the keys - no key security - no security .. but assuming that - one simple way to do a one time pad is ... (I am throwing this out off the top of my head - has been thought out - but this is all coming off the top of my head so might have some stupid mistake)....


I will just use md5 for the example - but any sort of hash would work - and is a major part of the security itself - just because - if the keys are secure - there is absolutely no way to know what hashing method you use - or even if its a known hashing method or a custom brewed one....

So I encrypt on my end - send it to the other side - encrypted - but no need for any other special care - doesnt matter who sees it or can grab it.

I then pick up the phone - call the other end - and tell them that the key to decrypt the file is ... say ... "key" :)

All in the clear - you can broadcast it over the radio station at a designated time if you want - and make sure everyone in the world knows its the secret key to the file that you just sent - and they have in their hands

Again - as long as the key is secure - everything is secure.

Now - the person on the other end - they go their little program - throw in "key" - and presto - they have their data decrypted (though presto might take a couple of minutes).

How this would be able to work is that you in fact are using a one time key.. as long as you never call up and give em the same key twice.

This part can be done any one of an unlimited ways - not just the way I describe it - and again - the security is in the fact that there is absolutely no way for anyone to know what you are doing.

When "key" gets put in as the unlock key - the program that is doing the decryption takes "key" - and makes a md5 string from it - so you have

3c6e0b8a9c15224a8228b9a98ca1531d

Then lets hash that and put it on the end of it

3c6e0b8a9c15224a8228b9a98ca1531d56f3db44e25e3057caa2b78751fa212c

and again do the same with that entire string -

3c6e0b8a9c15224a8228b9a98ca1531d56f3db44e25e3057caa2b78751fa212cf9105ce235797c1beff888517ce83de7

.. you can do that out as many times as you want.

Obviously not anything all that fancy at this point - and something anyone in the world could figure out sooner or later.

Now lets do some simple replacements to make it so its all alpha - and just use a preset manually randomized way to do it - changing the numbers to letters and the letters to different letters.

... and we get

rbbopsminbigwwtimwwmsninmbiigribgblrbsttowgorpghbiiwshmhgiliwiwblnipgbowrghnhbisollmmmgihbomrboh

you will notice the pattern matches the md5 above

Right now - we are actually at something pretty secure.

There is no way to know what sort of hashing method you are using - or if you are using something completly unknown and custom written for that even.

They have no way to know what it is I just did to that string above....

but as secure as it is - its not that that secure.

Now - your program that is doing the decrypting goes through a list it has.

This list would be whatever size you need it to be based on how often you would use - how long the string above would be - etc -

The list actually needs to be 16 lists. 1 for each letter above. In each list you have a long list of either dictionary words, names, randomly generated strings - or I would just do a combination of all three - so you end up with say 10,000 words a list (again - length depends on your needs - size is not a big deal - cause even at 1,000,000 words - its not going to all that big that it can not fit on a cd.)

Then you just run down the list - grabing the first r - hash it - the first b - hash it - stick it on the end of the first one you did - the second b - hash it- stick it on the end... and so on and so on and so on.....burn each one permantently as its used (if its a direct transmit - decrypted in the order it was encrypted on the other end - otherwise - you got to add in some way to know where its at - like - just automatically burn burn 100 words each day - and each day just run in order... or whatever you can dream up - as thats really the encryption here - just the ability to dream up ways to maniplulate not much of anything into something unduplicatable)

You can switch up hashing methods between different methods - that obviously follows the same pattern based either on a preset order or keys off the data its hashing and switches based on a predetermined method... etc. etc. etc -

the amount of different ways to do any of what I just said is unlimited ... based on if I just hashed my each of my words I pull from my word list - and stuck them on the end - I would be working with a key that is 3,072 characters long.

Now the data itself - use an encryption method that if you change one character at the start of what is being encrypted - and its like a hash - the entire returned encrypted data has no similiarity to the one that had one character difference- you can then add at the front of the data the time down to the millisecond - so even if you sent more than one thing with the same key - or the same thing 100 times - with the same key - each time you sent it - its going to look completely different.

The very first few words of the data should always be the same - or some thing along those lines as to provide you an anchor.

So you throw on "Secret Anchor Text - {time} - " .. pad or deliminate it out so and then attach the actual data.

Say what you send varies in size from 100K to a 2M .... to be safe you pick a number much higher than expected - say 3M (if you ever need more - send more than one file under a different key)

After you encrypt the file - you then create random noise - and seperatly encrypt that with the same key and method - and stick that on the end.

After you have stuck the randomly encrypted data on the end - now trim your file down to exactly 3 Megs.

and send it.

Pick up the phone - tell them their key ...

On their end - its obviously going to do the same exact steps with the key - then its going to start attempting to decrypt it - starting with the full 3 megs - check to see if it finds "Secret Anchor Text" at the start - if not - cut back one character - try again .... and continue doing that until it actually gets something that it wants.

Cuts off the front - and returns the data.

.... and thats that - a one time pad system that can be used in the clear - and I can not imagine being possible to break... primarily because everything I just stated could actually be done in an unlimited different ways..

And again - its as secure as the the two copies of the encryption/decryption program are. No key security - no security - simple little rule that always has been and always will be - for any method yesterday, tommorrow - or in the year 4628

(and if there is a flaw in this - tell me - cause I live to find out just how badly I can screw up the details :) )

Any encryption where it adds random values to obscure the original value junk... (maybe that's a harh word, but that's how I feel). You can't just mix your original text with some random values, and call it an encryption. The second reason I don't like it is that it increases the size of the file wich is not acceptable.
I agree that the one-time-pad is secure, but why add junk to that system ?

Quote:

---

Originally Posted by ZachFSW

Now the data itself - use an encryption method that if you change one character at the start of what is being encrypted - and its like a hash - the entire returned encrypted data has no similiarity to the one that had one character difference- you can then add at the front of the data the time down to the millisecond - so even if you sent more than one thing with the same key - or the same thing 100 times - with the same key - each time you sent it - its going to look completely different.

---

I agree to that, that's a safe encryption, the encryption I made has the same idea, and on top of that, i'm changing the key while it's encrypting, see this:
http://www.vbforums.com/showthread.php?t=232284

My thought process was primarily geared towards communication that needs to stay secure... only real serious use of encryption I have ever been involved with was when I was in the Air Force.

As serious as security was - there was always one thing that anybody with access to the higher classified info could use as valid justification to break every single reg in the book .... and send the info in the clear - give it over a non secure line...etc -- that being time.

That was sort of where I am coming from - more of a secure system of communication than anything else - in such a system - extra junk and size does not matter.

The data that is used for the keys can be generated on the spot every time also - as I said - its more of the idea behind it than the actual step by step process I went through - - the process can be changed literally an unlimited number of was.. change one tiny thing at the very start - and you end up at a completely different place at the end.

I happened to see yours yesterday after I wrote this - but I have not really looked at it as of yet (I was really just looking for a simple blowfish bas or cls to throw into something I am making :) )

There is absolutely no reason to need to add size to the file if its not needed - you leave that step off - and everything else I stated would work also.

In secure communication - there is an absolute vital need to add size to the data.

Yes - you may never be able to crack it - but if they can intercept and know how big the message is - they can over time crack your code without ever cracking it - say every time you send a message that is XX in size - they see a specific event happen ... doesnt take long before they put two and two together - and everything else you have done has been a waste of time when you are leaking info in a way that you never thought possible.

That step can also be easily left off if not needed - again - its just a theory of how to go about it - not an actual solution.

The one thing I didnt state - was the actual point - and that is that you can indeed make a system that is 100% secure if you really put some thought into it and use your imagination - and just add so many ridiculous steps that take milliseconds for a program to do - but would be impossible for someone with every supercomputer in the world to ever guess at what you did. Encrypting it and sending it - one time pad or not - there its crackable - since all they have to do is brute force that one method - adding different steps in the process - impossible to brute force because they will never know where they are at in the process -

Oh - and the one thing that is never mentioned when people say how long it would take to Brute Force this method or that method....

thats how long it would take to go through every possible combination - it could take them a second to brute force a one time pad if they were extremely lucky

Oh - and I didnt really understand your first line - I wasnt obscuring anything - or even using random anything. You actually could not use anything random that was a vital part of the key because then it would be impossible for both end points to be able to communicate.

Any place I used the word "random" - was just in generation of something that was then hardcoded - and at that point - is no longer random - its very specific.

Can anyone say NSA? These guys eat codes for a living. Their buget is astronomical. Besides, since we're forced to use finite mathematics in computer-science, all codes, given enough time, can be broken. Fact.

Now, when (if) we enter the age of quantum computers, all the cryptology that exists today will vanish in a flash. Scarry.

Quote:

---

Originally Posted by rjbudz

Besides, since we're forced to use finite mathematics in computer-science, all codes, given enough time, can be broken. Fact.

---

Ok - then do this for me.

I will do nothing fancier than character replacement here.

Decode this for me.

Code:

---

(#@

---

Thanks.

If your entire encryption scheme is dependent on a mathmatical formula - you have a very crappy encryption scheme.

If your entire encryption scheme is dependent on using something like blowfish - and encrypting it - and thats it - you have a very crappy encryption scheme (though may be good enough)

But the above really simple example is more than enough proof that you can indeed have 100% secure encryption.

Figuring out what that says above - is imposssibe. The above could range from "aa " to 43,046,721 - and then some.

If you can figure out what I was actually thinking when I wrote those three characters - then you are not in any way an expert at cracking code - you are an expert at reading the mind of someone - through the internet - that you have never met before -- and that would actually be damn impressive.

Are we talking practicality, or just a code? Your coded message: (#@ could mean anything, of course. So what?

Coding is most often a character replacement scheme, one or more characters indicate a single character. In a one-time-pad it’s often:

QW RT S3 IP Y6 …
R9 A B C D E
DW L M N O P
LE V W X Y Z
...
Breaking it is dependent on detecting patterns, associating them with common characters within the language (‘e’ in English for example), then working from there. Like Wheel of Fortune I can derive E from the frequency of Y6R9, and guess that Y6LE is ‘X’ based on its placement, say: Y6R9Y6LEY6R9.

of course, QWR9 could mean "Go to the store" and DWID could mean "Buy Bread, and LEY6 could mean "Sourdough". This is where one of the dangers of multiple use of the pad comes into play, as both messages won't (likely) be of the subject

Now, if your three letter code is meant to set off a predefined set of actions, say:

1) Go to the store
2) Go to the mechanic
3) Wash the dishes

And you sent (#@, which means 3, why not just say 3? The list is already secret, so no one else knows what it is anyway.

Because if you call back up and say 3 again - then you just broke the code for them.

As I threw out earlier - my only real experiance with this was in the Air Force - dealing with communications.

.. and as such - that is really what I said is directed towards. You need to communicate on a regular basis with different points. While the bulk of the Military's stuff is in a system where, while they still encrypt everything as tight as possible - its a secondary protection scheme to the simple fact that they have have a worldwide closed lan that they use.... but even still - I dont think they have figured out a way to hardwire the Carriers and the Planes yet :)

If you are sending short simple things back and forth - or something that can be based off of a list known before hand - then you for sure use anything like that. Be it in a program or what not. If what you encrypt will only make sense to the end - again -you do that. You do all of that - and then some.

Your list of go to the store etc above - is in reality the cliff notes of what my first post was about.

You have list determined ahead of time - or a way to generate a list on the fly - that based on one word (which actually could just be written in a header of what is sent, with the encrypted data attatched) - based on that one word - and the before hand known list - you generate the encryption key.

Which gives you one time pad protection. You also throw in variety of other steps to make it impossible to brute force - because they are not known - and are not mathmatical.

I think we're in full agreement on all points. BTW, my code experience is doing intel for the US Navy, so we come from similar backgrounds. They use scrambling, coding, double-coding and plastic wrap to keep even non-classified communications safe.

BTW, I've met a number of the NSA folks. They’re a very intelligent and scary bunch.

Quote:

---

Originally Posted by rjbudz

Can anyone say NSA? These guys eat codes for a living. Their buget is astronomical. Besides, since we're forced to use finite mathematics in computer-science, all codes, given enough time, can be broken. Fact.

Now, when (if) we enter the age of quantum computers, all the cryptology that exists today will vanish in a flash. Scarry.

---

They'll just upgrade the keysize and move on.

Quote:

---

Originally Posted by ZachFSW

Oh - and the one thing that is never mentioned when people say how long it would take to Brute Force this method or that method....

thats how long it would take to go through every possible combination - it could take them a second to brute force a one time pad if they were extremely lucky

---

The problem with encryption is not the ciphers per say, it's the random number generator. You could break the perfect cipher for example, if the random number generator isn't producing truly random numbers. This is in effect what happens in computer security. Software isn't capable to generating truly random numbers due to being ran on deterministic machines.

You cannot brute force encryption done by the one time pad cipher. You have no way to know if that is the correct plaintext because it looks like just any other plaintext.

For example take the ciphertext:

ADFWAFERSFHRYTJHDZHI

This could mean:
A TURNIP CURES ELVIS

It could also mean:
UNIVERSAL PICTURES!!

On a side note, can you name the movie that is off of?

‘Sneakers’, of course. (and, no, I did not have to look it up). Most everyone with a background in, or more than a passing interest in codes and ciphering should know that one! :)
You’re so right on about the problem with computers and random numbers.