A new, key-less triple stage method for transmission of encrypted messages

A new, key-less triple stage method for transmission of encrypted messages

by John D. Swanne



Introduction

Until now, one of the issues behind any attempts for two people to communicate through coded messages was the fact that in most cases, the key has to be transmitted - a key which could be intercepted, decoded if it was coded, shared, etc. Thus, if Mary was to encrypt the message "Love you." before sending it to Ann, using a Caesar's square in which

L
O
V
E
_
Y
O
U
.

becomes

LEO
O_U
VY.

which is written as "LEOO_UVY.", then Mary will either have to tell Ann that her message follows Caesar's square encryption (the key), or try and make sure her message is readable to anyone who knows about the Caesar's square principle (the key). This makes the message very weak - because then it's possible, for someone else than Mary, to read the message.

But there is a way to forever avoid revealing the key of the message. It now becomes possible to absolutely encrypt the message, since the message doesn't need to be decoded by anyone else than the encryption author.



Chapter 1

Method to send and receive a message WITHOUT EVER HAVING TO TRANSMIT THE KEY (or the encryption's pattern):

With this system, the message stays coded at all times, although it requires several - three - sends. This system could be memorized as "Isis-Ymys-Isbis-Ymbyr", or "I Substitute, I Send. You Modify, You Send. I Substitute Back, I Send. You Modify Back, You Read.".

Let's say that Mary wants to tell Ann, "Meet me at 2:30 PM".

Mary will write her message but will apply a substitution pattern. Mary doesn't have to limit the pattern she will use to any known substitution patterns, as she will be the only one to decipher her own pattern. Thus she can use any substitution patterns. For instance, let's say here she chooses that

M=S
E=O
T=4
_=E
A=Y
2=F
:=K
3=J
0=U
P=A
M=T

Thus, Mary encrypts her message, which here becomes "SOO4ESOEY4EFKJUEAT". Mary isn't allowed to modify the character's positions, she is only allowed to subsitute the said characters.

She sends this message - "SOO4ESOEY4EFKJUEAT" - to Ann.

Ann receives the message "SOO4ESOEY4EFKJUEAT". As quite the opposite of Mary, Ann isn't allowed to substitute or change the characters, she is only allowed to modify the position, the sequence order of these said characters. Ann doesn't have to limit the pattern she will use to any known sequence-modifying patterns, as she will be the only one to decipher her own pattern. Thus she can use any sequence-modifying pattern. Let's say that Ann chooses that

character #1 becomes #8
character #2 becomes #10
character #3 becomes #5
character #4 becomes #14
character #5 becomes #9
character #6 becomes #4
character #7 becomes #13
character #8 becomes #15
character #9 becomes #3
character #10 becomes #12
character #11 becomes #7
character #12 becomes #2
character #13 becomes #16
character #14 becomes #11
character #15 becomes #6
character #16 becomes #1
character #17 becomes #18
character #18 becomes #17

Thus, Ann encrypts Mary's message, which here becomes "EFYSOUESEOJ4O4EKTA".

Ann sends back this message - "EFYSOUESEOJ4O4EKTA" - to Mary.

Mary receives the "EFYSOUESEOJ4O4EKTA" message. Mary deciphers the character's substitution pattern, without touching their sequence order. She reverses her previous convertion table, so that

S=M
O=E
4=T
E=_
Y=A
F=2
K=:
J=3
U=0
A=P
T=M

Once the operation is finished, Mary gets the message "_2AME0_M_E3TET_:MP". She sends this message back to Ann.

Ann receives the message "_2AME0_M_E3TET_:MP". Ann deciphers the character's sequence order, without touching their identity. She reverses her previous convertion table, so that

character #1 becomes #16
character #2 becomes #12
character #3 becomes #9
character #4 becomes #6
character #5 becomes #3
character #6 becomes #15
character #7 becomes #11
character #8 becomes #1
character #9 becomes #5
character #10 becomes #2
character #11 becomes #14
character #12 becomes #10
character #13 becomes #7
character #14 becomes #4
character #15 becomes #8
character #16 becomes #13
character #17 becomes #18
character #18 becomes #17

Once the operation is finished, Ann gets the original message which was, "MEET_ME_AT_2:30_PM".



Chapter 2

To strenghten the cipher's resistance (substitution part):

If used as shown in Chapter 1, the previously described method is still partially vulnerable. For instance, during the first stage, in which Mary sends her message, which is encrypted using substitution, to Ann. A good frequency analysis would easily deduce that "O" is really an "E", which would mean that "SOO4ESOEY4EFKJUEAT" could be partially deciphered to "See4ESeEY4EFKJUEAT". A more profound analysis regarding the identity of "S" could reveal the strong possibility that "S" is an "M", reducing the cipher to "mee4EmeEY4EFKJUEAT". A quick search in an english dictionary will show that one of the two words which starts by "mee" is "meet". At that point the code is almost decyphered, since we now have "meetEmeEYtEFKJUEAT". A bit more work will reveal that "E" is a space, "Y" is an "A", etc.

To eliminate that problem, one need only to choose several substitution characters, so that there is no characters that can be find more than once in the encrypted message.

Instead of

M=S
E=O
T=4
_=E
A=Y
2=F
:=K
3=J
0=U
P=A
M=T

Mary can choose to substitute all of the message's character with a character which will be different at each time:

M=E
E=O
E=R
T=U
_=X
M=J
E=T
_=M
A=D
T=I
_=Q
2=F
:=W
3=N
0=B
_=C
P=H
M=K

Thus, Mary could encrypt her "MEET_ME_AT_2:30_PM" message to "EORUXJTMDIQFWNBCHK", a message in which characters never appear more than once, and which, thus, presents no weakness to frequency analysis. All attempts for frequency analysis are effectively doomed to failure.

In the case that one has to write a message longer than 26 characters, it is of course possible to introduce non-alphabetic characters, such as !?/+-()%&*$#@1234567890"':;.,!=÷ or even characters from another alphabet, such as greek.



Chapter 3

To strenghten the cipher's resistance (modifying of position part):

When Ann will encrypt Mary's message by modifying the position of the message's characters, the result will be quite hard to decypher. But when Mary will remove her cypher, and send that message back (stage 3), Ann's encryption will be the only remaining defence against interception.

Stage 1: Mary sends the message to Ann:
Character's identity: Securely encrypted. Character's sequence order: Not encrypted.

Stage 2: Ann sends the message back to Mary:
Character's identity: Securely encrypted. Character's sequence order: Encrypted but weak to anagrammatical analysis.

Stage 1: Mary sends the message back to Ann:
Character's identity: Decrypted. Character's sequence order: Encrypted but weak to anagrammatical analysis.

An anagram expert will have no difficulties at discovering the real message using a bit of brute force. For instance, in our chapter 1, during stage 3, the message reads, "_2AME0_M_E3TET_:MP". Four spaces and one double-points suggests the message contains 5 words. An anagram expert can thus attack the cypher. All unlogical combinations, such as "203_ME:_PET_MEAT_M", can safely be discarded, and only a few strong possibilities will survive, amongst them "MEET_ME_AT_2:30_PM", and the content of the code would have been decyphered.

To eliminate that problem, one needs simply to make all combinations possible. This can be achieved by adding useless characters to the message.

One needs simply to add characters to Mary's encrypted message, so that any anagram expert will not be able to guess which characters are real and which are useless in the first place. But one has to make sure and insert these characters in a random fashion into the message.

After Ann received Mary's message during stage 1, "SOO4ESOEY4EFKJUEAT", Ann can then take the liberty to add new characters, which may and/or may not already exist in the original cypher - the quantity of characters to add should be the highest possible but, just like passwords, the quantity is often limited by the available time.

Let's say that Ann adds 8 new randomly chosen useless characters to Mary's message: "EBWOIDAQ", which gives "SOO4ESOEY4EFKJUEATEBWOIDAQ", a 26-characters message. Ann then modifies the character's order, to let's say

character #1 becomes #25
character #2 becomes #20
character #3 becomes #15
character #4 becomes #10
character #5 becomes #9
character #6 becomes #24
character #7 becomes #19
character #8 becomes #14
character #9 becomes #5
character #10 becomes #4
character #11 becomes #23
character #12 becomes #18
character #13 becomes #17
character #14 becomes #8
character #15 becomes #3
character #16 becomes #22
character #17 becomes #13
character #18 becomes #12
character #19 becomes #7
character #20 becomes #2
character #21 becomes #26
character #22 becomes #21
character #23 becomes #16
character #24 becomes #11
character #25 becomes #6
character #26 becomes #1

Once the operation is finished, the message, which here became "QBU4YAEJE4DTAEOIKFOOOEESSW", will be sent back to Mary. Mary will decypher the identity of all the characters - and, faced with the useless characters "B", "W", "I", "D" and "Q", which do not appear in her conversion table, she will have the right to translate those to any characters she chooses - let's say that here she decides that

B=E
W=H
I=T
D=A
Q=R

Thus she decyphers the message to "RE0TAP_3_TAMP_ET:2EEE__MMH". Mary send this message back to Ann. Now the message is resistant to anagram experts.

Stage 1: Mary sends the message back to Ann:
Character's identity: Decrypted. Character's sequence order: Securely Encrypted.

Ann inverses her conversion table and put the characters back in their original order, which gives "MEET_ME_AT_2:30_PM_EHETAPR". Ann eliminates the useless last 8 characters which she herself had added, and she gets, "MEET_ME_AT_2:30_PM".

I do some programming but to be honest with ya.
That sort of thing is over my head.

And honestly I've always wondered why we don't do encryption in the following way.

We take for example "meet me at 2 pm" and convert it to binary to get.

011011010110010101100101011101000010000001101101011001010010000001100001011101000010000000110010001000000111000001101101

And then we can take this since it's a number and apply a mathematical formula to it. Like take it and multiply it by 3 for example.
And then all the receiver has to do is know the reverse formula in order to "decrypt" the message.

Does that make sense?

reply to post by grey580


Yeah but it's still vulnerable to brute force attack. Some other guy can just try out all keys ("1", then "2", then "3", and so on) and easily figure out (here it'd take 2 shots if you use "3" as encryption key) the key to bust the code open.

reply to post by swan001


Well the example I posted was simple.
We'd have to run the number through a few different equations. Maybe some Trig or algebra or something.
And then run them back and through to decode. then convert from binary to text.

Brute force vulnerability I think would be mitigated. Especially on larger messages.
They would have to know in what order the math formulas were applied. And those can be randomized.

reply to post by grey580


Yeah, that should work.

But you still have to communicate the key to your correspondent... and to avoid your key being discovered by some third party, you'd have to encrypt it using another key... and so on.

In my OP I show how to never disclose that key.

And avoid using algebra...

I dont log in often, but this one deserves it! We used to decypher newspaper cryptos for bonus points in history way back when. This is actually a decent code and I like it a lot.

reply to post by TheQuantumAnomaly


Thanks!

It's a variation of a riddle I stumbled upon once. You know, the one where you have to send a box though Mail but the box must always be locked.

reply to post by swan001


There are pros and cons to everything. However I'm glad you thought my idea had some merit.

I would think that the only con to your proposed system is that it would be susceptible to middle man eavesdropping. If an attacker knows the data going back and forth then it could theoretically be decoded.

"Until now, one of the issues behind any attempts for two people to communicate through coded messages was the fact that in most cases, the key has to be transmitted"

Simply not true. en.wikipedia.org...–Hellman_key_exchange

The above it cute for an example but falls apart with a man in the middle who can retrieve partial key information from the multiple exchanges.

reply to post by grey580


Because of a process known as "collision". Different phrases will equal the same numbers.

Originally posted by Zaphod
Simply not true. en.wikipedia.org...–Hellman_key_exchange

I followed your link. The key is not exactly transmitted, but it's still made public nevertheless.

The method was followed shortly afterwards by RSA, an implementation of public key cryptography using asymmetric algorithms.

Wait a minute. Hey, I just found out my system uses an asymmetric algorithm.

A postal analogy
An analogy that can be used to understand the advantages of an asymmetric system is to imagine two people, Alice and Bob, who are sending a secret message through the public mail. In this example, Alice wants to send a secret message to Bob, and expects a secret reply from Bob.
With a symmetric key system, Alice first puts the secret message in a box, and locks the box using a padlock to which she has a key. She then sends the box to Bob through regular mail. When Bob receives the box, he uses an identical copy of Alice's key (which he has somehow obtained previously, maybe by a face-to-face meeting) to open the box, and reads the message. Bob can then use the same padlock to send his secret reply.
In an asymmetric key system, Bob and Alice have separate padlocks. First, Alice asks Bob to send his open padlock to her through regular mail, keeping his key to himself. When Alice receives it she uses it to lock a box containing her message, and sends the locked box to Bob. Bob can then unlock the box with his key and read the message from Alice. To reply, Bob must similarly get Alice's open padlock to lock the box before sending it back to her.
The critical advantage in an asymmetric key system is that Bob and Alice never need to send a copy of their keys to each other. This prevents a third party – perhaps, in this example, a corrupt postal worker – from copying a key while it is in transit, allowing the third party to spy on all future messages sent between Alice and Bob. So, in the public key scenario, Alice and Bob need not trust the postal service as much. In addition, if Bob were careless and allowed someone else to copy his key, Alice's messages to Bob would be compromised, but Alice's messages to other people would remain secret, since the other people would be providing different padlocks for Alice to use.
In another kind of asymmetric key system in which neither party needs to even touch the other party's padlock (or key), Bob and Alice have separate padlocks. First, Alice puts the secret message in a box, and locks the box using a padlock to which only she has a key. She then sends the box to Bob through regular mail. When Bob receives the box, he adds his own padlock to the box, and sends it back to Alice. When Alice receives the box with the two padlocks, she removes her padlock and sends it back to Bob. When Bob receives the box with only his padlock on it, Bob can then unlock the box with his key and read the message from Alice. Note that, in this scheme, the order of decryption is the same as the order of encryption – this is only possible if commutative ciphers are used. A commutative cipher is one in which the order of encryption and decryption is interchangeable, just as the order of multiplication is interchangeable (i.e. A*B*C = A*C*B = C*B*A). A simple XOR with the individual keys is such a commutative cipher. For example, let E1() and E2() be two encryption functions, and let "M" be the message so that if Alice encrypts it using E1() and sends E1(M) to Bob. Bob then again encrypts the message as E2(E1(M)) and sends it to Alice. Now, Alice decrypts E2(E1(M)) using E1(). Alice will now get E2(M), meaning when she sends this again to Bob, he will be able to decrypt the message using E2() and get "M". Although none of the keys were ever exchanged, the message "M" may well be a key (e.g. Alice's Public key).

That exactly how my system works!

But...

This three-pass protocol is typically used during key exchange.

They use it only to send a key, not information. Obviously, since information nowadays can be anything else than text.

Three-pass (or three-stages) "assymetric algorithm" be used like I showed in my OP, in a quick, simple fashion to transmit messages in the event your computer is down.

This is fun!

Originally posted by grey580
I would think that the only con to your proposed system is that it would be susceptible to middle man eavesdropping. If an attacker knows the data going back and forth then it could theoretically be decoded.

edit on 4-4-2013 by grey580 because: (no reason given)

In theory. I'm not sure. I'll give it more thoughts. The first stage is invulnerable, and the message's growth in the 3rd stage makes the code impossible to decipher correctly (for a middle man), even by comparing it to the first stage, 'cause the first stage gives out no useful information, but maybe comparison of stage 3 with stage 2 could give out a clue... I'll have to check. Thanks for telling me!