GATE Encryption [ my 2nd patent ] is based on GATE authentication [ my 1st patent ], if you know GATE authentication, you can go straight to [2] for GATE encryption

[1] How GATE Authentication works

First of all let's see why there is a need for a system like GATE. Current password system exposes user pins, if your password is : 123, each time when you enter them, a hacker next to you looking at your keyboard or someone who is hidden from you but can intercept your communications traffic, will easily get your pins : "1", "2", and "3", so the problem is obviousness, therefore in order to overcome this weakness, I came up with a solution called Graphic Access Tabular Entry [ GATE ], it hides user pins from clear sight. So even if your login session is observed or intercepted by a hacker, he won't be able to tell what your user pins [ in your passcode ] are. GATE works like the following :

[A] User selects a User Id : admin
[B] User selects some pins for his passcode [ for example : 1 2 3 ], the available symbols for user pins are listed on user registration screen for user to select by clicking on them [ see live demo online ] : http://gatecybertech.net/how_gate_works.jsp
[C] Save User Id and passcode [ admin / 1 2 3 ] on server by clicking a save button.

[D] During a login session, user enters User Id
[E] User Id is passed to the server to get saved user pins from user passcode, if User Id doesn't exist, server will deny user login request.
[F] The server randomly selects some user pins [ for example in the above case : 1 3 ] and mix the selected user pins with other symbols, then display the mixed symbols in some buttons, the buttons are organized in a 3 x 3 table, each button contains 4 symbols.
     The reason to randomly select some pins [ not showing all user pins all the time ], is to avoid being easily recognized by a hacker, if he intercepted multiple login sessions and do a comparison of each session, if all pins always appear all the time, he will easily know what the 1st pin is by looking at all sessions for the 1st entered buttons, and what 2nd pin is by comparing all 2nd entered buttons, so on.
[G] So after user enters User Id, he will see something like the following on the login screen : a 3 x3 table with 9 buttons :

1 Ⓩ        32 Ⓢ        21 Ⓗ
☻ ¡Â        ♤ +         ☾ ⏛

17 ^        14 Ⓐ        3 !
♦ ☝        ｨH ¡ù        ｡ﾟ ✂

6 ~        36 Ⓔ        12 Ⓣ
｡� −        ｡ ☣        ♠ ☮

===============================

[H] Now user will follow the order of his user pins in the passcode [ in the above example : 1 2 3 ], to select which buttons to enter, so because his 1st pin is "1", he will need to locate where this pin "1" is on the screen, in this example the "1" is on the first button, so he needs to click on this button to enter his 1st pin :

1 Ⓩ
☻ ¡Â

[I] Now user needs to enter his 2nd pin in his passcode [ 1 2 3 ], so he needs to locate where the pin "2" is on the screen, in this example, it's missing, so he can and must enter a wildcard/any pin in place of this missing pin, in our example, he may click on the 8th button, so after steps [H] and [I], user has entered the following buttons :

1 Ⓩ      36 Ⓔ
☻ ¡Â      ｡ ☣

[J] Since user has 3 pins in his passcode, he will now enter the 3rd pin, which is 3, so he looks at the screen for it, and it's on the 6th button, so he needs to click that button to enter his 3rd and last pin, his selected buttons will look like this :

1 Ⓩ      36 Ⓔ       3 !
☻ ¡Â      ｡ ☣      ｡ﾟ ✂

[K] User clicks a login button to pass the info on the above seleced buttons to the server for validation, the server goes through a validation process to see if user has entered the correct symbols, the process on the server looks like the following :

  [a] Checks to see if the number of buttons the user entered equals to the user pins in his passcode, so for the above example since user has 3 pins in his passcode 1 2 3, therefore he must enter no more and no less than 3 buttons, one for each user pin. But if he entered 2 buttons, or more than 3 buttons, server will deny user access.

  [b] Server goes through saved user pins one by one to see if user has enterd them correctly, so in our example, server will first look at the first user pin "1", check to see if it was in the buttons table shown to the user, in our case, it was in the table, and was in the first button, then server will look at the first button user enterd, is it equal to the first button on the table, in our case, it is equal, therefore user has entered the 1st pin correctly.
      Then server will look at the 2nd user pin "2", is it on any of the buttons shown to the user on the login screen, it was not, so sever will allow user to enter a wildcard/any button in place of that pin. So the server looks at the 2nd button user entered, is it on the tokens table, in this case it is, and therefore this check is valid.
      Then server will look at the 3rd pin in user's passcode, which is "3", to see if it was on any buttons shown to the user, it was, it showed up on the 6th button in the table, server then looks at the 3rd button user entered for that pin, that button equals to the 6th button in the table, which contain 4 symbols "3 ! ｡ﾟ ✂", and the third user pin "3" was among them, so user has entered the 3rd pin correctly. After the above check, server will validate that the user has entered the correct buttons and will grant user access.

      In the example above, if user enterd the 2nd button "32 Ⓢ ♤ +" for the 1st pin, then server will invalidate user, because the server will look for the 1st user pin "1" in the user entered button, but "1" is not among the symbols "32 Ⓢ ♤ +", therefore user would have entered a wrong button for his 1st pin "1".
 
[K] There is a chance that all user pins may all appear in the table, in that case, user will need to eanter all the buttons that contain his user pins. And there will be no wildcards.

[L] There is also a chance that a wildcard user entered equals to one of the other non-wildcards, which will confuse a potential hacker. For example in the above case if user entered the following buttons, he can also login seccessfully :

1 Ⓩ      3 !       3 !
☻ ¡Â     ｡ﾟ ✂     ｡ﾟ ✂

The 2nd button user entered is the same as the 3rd button, since the 2nd button is a wildcard, it can be any of the 9 buttons, so it is valid, but when a hacker looks at it, seems the 2nd user pin is the same as the 3rd user pin, but that's not the case.

Each time when user logs in, the server will rendomly generate a differsnt set of symbols on the buttons, therefore user pins will not be exposed.

So to summarize, the purpose of GATE is to make user pins not obvious during the login process, is to hide user pins among other symbols, and at the same time widen the eligible symbols for passcode to go byound symbols available on the keyboard, so user can come up with more creative passcodes and avoid dictionary attacks.

The number of symbols on each button can be customized, 5 or 6 is doable, the number of buttons in the table is also customizable, can be 2 x 5 [ better for mobile phone screen ], or 4 x 4. The whole purpose of the multiple buttons and multiple symbols is to hide user pins to obscure them.

[2] How GATE Encryption works

In the GATE system above, the table has 9 buttons, each button has 4 symbols, the table is like a lock, the buttons user enters is like a key to open that lock [ table ], so in the example above, the lock looks like this :

==============================
1 Ⓩ      32 Ⓢ      21 Ⓗ
☻ ¡Â      ♤ +       ☾ ⏛

17 ^      14 Ⓐ      3 !
♦ ☝      ｨH ¡ù      ｡ﾟ ✂

6 ~      36 Ⓔ      12 Ⓣ
｡� −      ｡ ☣      ♠ ☮

==============================

The key to open this lock looks like this :

1 Ⓩ      36 Ⓔ       3 !
☻ ¡Â      ｡ ☣      ｡ﾟ ✂

==============================

And the passcode to validate the correct key is : 1 2 3

----------------------------------------------------------------------------------------------

Here is another example, the passcode is : Ⓘ ♥ 2 ✉

The lock [ table ] looks like this :

=============================

2 ¦Φ       25 ¦Α      12 ¦Η
☻ ☏      ◒ ¡ù      ♢ ✂
[#1]     [#2]      [#3]

21 ¦Μ      38 Ⓐ      39 Ⓘ
｡� ₮       ☑ *     ｡� ✉
[#4]     [#5]      [#6]

31 Ⓚ      50 ¦Κ      45 Ⓔ
♣ ₭        ☪ ☨          ｡� ☸
[#7]     [#8]     [#9]

=============================

The key to open this lock looks like this :

39 Ⓘ      50 ¦Κ      2 ¦Φ      39 Ⓘ
｡� ✉       ☪ ☨          ☻ ☏        ｡� ✉
[#6]    [#8]      [#1]     [#6]

----------------------------------------------------------------------

Note : In the above illustration, I use "[#?] to indicate the position of the button, so [#1] points to the first button [ 2 ¦Φ ☻ ☏ ], and [#9] points to the last button [ 45 Ⓔ ｡� ☸ ], so on. Therefore the key above can be shown as :

[#6]      [#8]      [#1]      [#6]

The above key means it is consisted of four buttons : No. 6 button  +  No. 8 button  +  No. 1 button  +  No. 6 button

So, for the lock [ buttons table ] above, [#6][#8][#1][#6] is a vlid key. Let's simplify it to : #6816
If we use this convention, then the first example with a user passcode of : "1 2 3" will have a valid key of : #186 [ which means the first button, the 8th button and followed by the 6th button ] 

The server can generate a table with user pins in the buttons, as shown above, GATE uses a table generation algorithm to do that, it goes like this : first load user pins [ for example : a 2 3 b 5 g ] from User Id, then pick a random number of pins from them [ 2 b 5 g ], then generate 9 buttons with random symbols on them, and include the selected user pins [ 2 b 5 g ] among the symbols on the buttons.

The server can also generate a valid key, GATE uses a valid key generation algorithm to do that, it goes like this : from user Id load user passcode, go through each user pin in the passcode, see if it is in the table generated above, if that pin is on a button in the table, select that button's content [ 4 symbols ], if a user pin is not on any button in the table, then select any random button's content for that missing pin.

The server can also generate an invalid key, GATE uses an invalid key generation algorithm to do that, it goes like this : first set up a boolean "Done_Fixing" to be false, from user Id load user passcode, go through each user pin in the passcode, see if it is in the table generated above, if that pin is on a button, select a different button's content [ 4 symbols ], this step intentionally picks a wrong button, and therefore the key generated by this algorithm will be invalid. After doing this, sets the boolean value "Done_Fixing" to be true, which means it has done it's job to fix the key, if a user pin is not on any button in the table, then select any random button's content for that missing pin. If another user pin shows up in the table, it can select the button that contains that pin, and it won't matter any more, the wrong thing [ fixing ] has already been done.

So let's summarize what the GATE system can do so far :
[a] From user passcode, GATE can generate a 3 x 3 buttons table with 4 symbols on each button, some randomly selected user pins are among the symbols on the buttons.
[b] GATE can validate whether the buttons user entered are correct, if they are correct, user is validated, if they are not correct, user is invalidated.
[c] GATE can genarate valid key for a table
[d] GATE can also generate invalid key for a table

Let's introduce another concept : token
The above example shows a 3 x 3 table with 9 buttons, each button has 4 symbols, in a graphic user interface [ GUI ], user can see the 9 buttons displayed on the screen, yet behind the scenes, information is processed in text format, so for each button, only it's content is passed between the client and server, therefore the content of the button needs a name, so I called it "token".

For example, in the above example, the 6th button is :

39 Ⓘ
｡� ✉

The content of the button is : 39 Ⓘ ｡� ✉
Which means there are for symbols : "39", "Ⓘ", "｡�", "✉"
And these 4 symbols were passed between the client and the server, there is no button being passed around, the button is just used to display these 4 symbols as a group and is used for user to select and click on those 4 symbols so they can be entered together as a group.
Therefore we need a proper name for the group of these 4 symbols, so let's just call this group of 4 symbols a "token".

So, after the introduction of the concept of token, we can discribe GATE like this :

[a] The GATE system can generate a 3 x 3 table with 9 tokens [ shown as buttons ], each token contains 4 symbols.
[b] GATE can validate whether the tokens [ buttons ] user enter are correct, if that are correct, user is validated, if they are not correct, user is invalidated.
[c] GATE can genarate valid key tokens for a table
[d] GATE can also generate invalid key tokens for a table

Another aspect of GATE is : the available symbols for user to select his pins are grouped into 4 categories, as shown in the examples above :
[a] The 1st category is numbers : 1 , 2 , 3 , ....
[b] The 2nd category is alphabets : a , b , c  [ they might appear in circles, but they are alphabets none the less ]
[c] The 3rd category is symbols : ☻ , ♤ , ☾ , ♦ ...
[d] The 3rd category is other signs : ?, + , ⏛ , ☝

The position of each group is fixed in any token [ button ], therefore symbols from the 1st category always appear in the 1st position [ upper left side of any token], symbols from the 2nd category always appear in the 2nd position [ upper right ], symbols from the 3rd category always appear in the 3nd position [ lower left ], so on, this will help user to quickly locate his pins, for example, if a user has "3 6 9 1" as his passcode, then during the login process, he only needs to look at the upper left [ the 1st position ] of any token [ button ] to see if his pins are in the table, because numbers won't appear in 2nd, 3rd or 4th position.

One thing to be clear is : user passcode and key are 2 different things, in our examples above, the user passcode in the 1st one is : "1 2 3", the key is : #186
In the 2nd example, the user passcode is : "Ⓘ ♥ 2 ✉", the key is : #6816
User passcodes can be any combination of available symbols, with a suggested length of 4 to 6 digits long, they may or may not be pure numbers, so the following are all valid passcodes : axd2top , 267830 ,  $=MC2☻
On the other hand, keys are the [ positions of the ] tokens selected by the user to try to login, so they look like this :

39 Ⓘ      50 ¦Κ    2 ¦Φ    39 Ⓘ
｡� ✉       ☪ ☨      ☻ ☏      ｡� ✉

This means it has a length of 4, they are each selected from a token [ button ] displayed on the screen in the 3 x 3 tokens table, so to indicate the positions of the tokens in the table, they look like this :

39 Ⓘ      50 ¦Κ     2 ¦Φ     39 Ⓘ
｡� ✉       ☪ ☨       ☻ ☏        ｡� ✉
[#6]    [#8]    [#1]     [#6]

Since only a position is enough to represent the information, we can simply use the follwing notion :

[#6]      [#8]      [#1]      [#6]

This notion can be further simplified to : #6816 [ which means the length of the key is 4, because user passcode is 4 digits long, so user needs to enter 4 tokens, one for each pin in the passcode, and the positions of the tokens user entered are : #6 , #8 , #1 and #6. 
The symbols appearing in each table are unique, no 2 symbols will appear twice in a 3 x 3 tokens table.

If a user has a passcode which is 6 digits long, then a valid key will also contain 6 tokens. One token for each user pin in the passcode.

Tables can be of different sizes in each implementation of the GATE system, for example in the above examples, they are 3 x 3 like this :

[#1]  [#2]   [#3]

[#4]  [#5]   [#6]

[#7]  [#8]   [#9]

It can be 2 x 5 like this :

[#1]  [#2]   [#3]   [#4]   [#5]

[#6]  [#7]   [#8]   [#9]   [#10]

Or 4 x 4 like this :

 [#1]   [#2]    [#3]    [#4]

 [#5]   [#6]    [#7]    [#8]

 [#9]  [#10]   [#11]   [#12]

[#13]  [#14]   [#15]   [#16]

Number of symbols in each token can also be customized to something like is :

39  Ⓘ
  #
｡�  ✉

In this case it has 5 symbols in a token : 39 Ⓘ # ｡� ✉

GATE_4 has 4 symbols in each token/button, GATE_5 [ above ] has 5 symbols in each token/button.

But a 3 x 3 table with 4 symbols in each token [ GATE_4 ] seems more user friendly, so we will use that as example here.

Now here comes a conceptual leap !

From GATE authentication I came up with the idea of GATE encryption, the thought process went like this :
  [a] If a user knows the passcode and entered the buttons correctly, he gets logged in, and he is valid.
  [b] If a user entered the buttons incorrectly, he won't get in and he is invalid.
  [c] Imagine there are 10 users, 3 of them are valid, 7 of them are invalid. The 3 valid users are the good guys who are authentic, the 7 invalid user are bad guys who are fake.
  [d] Now I will use this process to encrypt massages, I'll chop my message in to 3 pieces [ info elements ], for example if my message is : d3k, I'll chop it in to "d", "3", and "k", then generate some fake pieces of message "V", "w","G","U","w", next I'll mix original info elements with fake info elements, so the result will be : V d w 3 G U k w

So message encryption is done : from the original message "d3k" to the encrypted message of "Vdw3GUkw"

Well, how to decrypt the above encrypted message ? Afterall, if you can't recover the original mess, it will be useless.

OK, let's use what I introduced earlier to get it done.

Remember that GATE can generate tokens table according to a given passcode ?
Remember GATE can generate valid key from a tokens table for a given passcode ?
Also remeber GATE can generate invalid key from a tokens table for a given passcode ?
Let's put them to good use.

In order to explain efficiently, let use the following notions :

[a] Use this to represent a tokens table : [ T ]
So a table like the above :

===========================
1 Ⓩ      32 Ⓢ      21 Ⓗ
☻ ¡Â      ♤ +       ☾ ⏛

17 ^      14 Ⓐ      3 !
♦ ☝      ｨH ¡ù      ｡ﾟ ✂

6 ~      36 Ⓔ      12 Ⓣ
｡� −      ｡ ☣      ♠ ☮
===========================

Can be simplified to [ T ]

[b] Use this to represent a valid key [ v ]
So a key like the above :

39 Ⓘ      50 ¦Κ     2 ¦Φ     39 Ⓘ
｡� ✉       ☪ ☨        ☻ ☏       ｡� ✉
[#6]    [#8]    [#1]     [#6]

or

[#6]      [#8]      [#1]      [#6]

or

#6816

Can be simplified to [ v ], the "v" means it's a valid good key

[c] Use this to represent an invalid key [ x ]
So a key like the above :

31 Ⓚ      50 ¦Κ     2 ¦Φ    39 Ⓘ
♣ ₭        ☪ ☨       ☻ ☏       ｡� ✉
[#7]    [#8]    [#1]    [#6]

or

[#7]      [#8]      [#1]      [#6]

or

#7816

Can be simplified to [ x ], the "x" means it's a invalid bad key

Now comes the interesting part, it will effectively encrypt and decrypt a message :

Let's call pieces of information from original message : original info elements, in the example above : d , 3 , k
Let's call pieces of information randomly generated by GATE : filler [ fake ] info elements, in the example above : V , w , G , U , w

[1] Given a passcode [ for example : Ⓘ ♥ 2 ✉ ], GATE generates a tokens table [ T1 ] and a valid key [ v ], attach them to an original info element :

d       <-- original info element
[ T1 ]   <-- a tokens table
[ v ]   <-- a valid key

[2] Given a passcode [ for example : Ⓘ ♥ 2 ✉ ], GATE generates a tokens table [ T2 ] and an invalid key [ x ], attach them to a filler info element :

w       <-- filler info element
[ T2 ]   <-- a tokens table
[ x ]   <-- an invalid key 

[3] Do the above steps [1] and [2] for each peices of info elements to encrypt the message, the result will look like this :

V 
[ T1 ]
[ x ]

d
[ T2 ]
[ v ]

w
[ T3 ]
[ x ]

3
[ T4 ]
[ v ]

G
[ T5 ]
[ x ]

U
[ T6 ]
[ x ]

k
[ T7 ]
[ v ]

w
[ T8 ]
[ x ]

[4] The above is a simplified version of reality, in real time it looks like this :

[data]V[/data]
23 ~ ♣ ✉ 9 # ｡� ?36 : ☺ + 7 Ⓨ ☓ ¦Λ 5 Ⓝ ☪ ☮ 18 Ⓚ ♤ ｡ﾋ 34 Ⓔ ☻ ✂ 35 Ⓧ ♢ ｡ﾞ 12 Ⓤ ｡� ☨ 21 % ｡� ?11 Ⓕ ☼ ¦Χ 2 Ⓟ ｡� ☯ 24 ! = ☣ 31 Ⓥ ♦ ｡ﾆ 22 Ⓙ ｡� ¦Π 10 Ⓣ ｡ ?
2 8 13 0
[data]d[/data]
1 @ ｡� ☮ 16 Ⓕ ｡� ✂ 9 Ⓝ ｡� ☨ 2 & ｡ﾟ ｡ﾆ 27 Ⓚ ✓ ♨ 22 Ⓘ ｡� ₣ 7 : ♢ + 34 Ⓑ ｡� ☞ 5 Ⓓ ｡� ¦Π 4 Ⓜ ｡� ☯ 12 # ☾ ☸ 30 Ⓤ ♥ ?28 Ⓟ = ☜ 18 Ⓖ ｡� ?10 Ⓨ ♧ ☝ 11 Ⓦ ｡ﾙ ☟ 
5 11 3 14
[data]w[/data]
1 ^ ｡� ☜ 35 Ⓚ ☪ ｡ﾋ 13 Ⓓ ｡� $ 20 Ⓗ ｡� ☣ 25 Ⓞ ｡� ?2 Ⓨ ♡ ✂ 24 Ⓘ ✓ − 8 Ⓢ ♦ € 3 ! ｡ﾟ ₪ 6 Ⓝ ｡� ✉ 21 Ⓟ ♥ ☢ 16 Ⓑ ｨH ¡ù 30 Ⓧ ☾ ｡ﾆ 31 Ⓒ ♢ ¦Λ 28 Ⓠ ☻ ⏛ 19 Ⓔ ｡� ｡ﾞ 
3 10 5 9
[data]3[/data]
14 Ⓗ ｨH ✂ 21 Ⓤ ｡� ｡ﾆ 35 Ⓠ ｡� ¦Π 36 Ⓧ ｡� ☢ 24 Ⓡ ☻ ♫ 10 Ⓒ ✓ ✈ 29 ~ ｡ ☞ 26 Ⓐ ♥ ?13 Ⓞ ｡� ☝ 18 ! ☾ ?2 Ⓘ ☓ ☸ 33 Ⓓ ♦ − 7 ^ ｡� ₣ 16 Ⓨ ｡� ¦Λ 15 Ⓕ ｡ﾙ € 19 # ｡� $ 
10 7 10 7
[data]G[/data]
4 * ☪ ₪ 18 Ⓜ ｡� ?5 Ⓖ ♢ ?25 Ⓗ ｡� $ 11 Ⓞ ｡ − 35 Ⓦ ｨH ☞ 1 : ｡� ☟ 30 Ⓔ = ¦Χ 22 Ⓐ ☼ ✂ 32 Ⓠ ｡ﾙ ｡ﾆ 12 ~ ｡� + 14 ! ｡� ⏛ 16 ? ♣ ¡ù 26 Ⓕ ♦ ✉ 10 Ⓑ ｡� ☣ 34 Ⓘ ｡� ♫ 
9 3 13 13
[data]U[/data]
32 Ⓥ ｡� ?5 Ⓒ ☪ ✈ 22 ^ ｡� ¦Χ 1 % ｡ ?29 Ⓟ ｡� ¡ù 34 Ⓨ ♡ $ 26 Ⓗ ｡� ｡ﾞ 2 ? ♤ ?25 Ⓐ ｡� ¦Λ 23 Ⓕ ✓ − 35 ~ ☻ ?17 Ⓦ ｨH + 12 Ⓖ ｡� ☞ 11 Ⓝ ｡� ♨ 18 Ⓢ ｡ﾟ ✉ 8 Ⓩ ☓ ☟ 
4 4 12 14
[data]k[/data]
8 Ⓧ ☺ ☞ 21 & ♦ ?2 ? ｡� ✉ 17 Ⓐ ｡� ☟ 33 Ⓗ ｡� € 27 Ⓣ ♤ ¦Λ 18 * ♢ ☝ 26 Ⓜ ｡� + 6 Ⓢ ♡ ?32 Ⓘ ｡ﾙ ｡ﾋ 20 Ⓖ ｡ − 15 ^ ☾ ♫ 23 Ⓡ ｡� ☮ 3 Ⓕ ♧ ☣ 36 Ⓑ ｡ﾟ ¦Π 11 Ⓒ ☂ $ 
9 3 2 2
[data]w[/data]
31 Ⓞ ☼ ☟ 2 Ⓦ ｡� ₪ 9 Ⓑ ｡� ☏ 20 ^ ♢ ?36 Ⓠ ｡ﾙ ☣ 19 Ⓕ ☪ ☯ 8 Ⓟ ｡� ?1 @ ｡� ☨ 15 Ⓣ ｡� ☜ 5 & ｡� ¦Λ 33 Ⓩ ✓ ｡ﾋ 25 # ｡� ☮ 27 Ⓖ ｡ ☞ 26 Ⓤ = ♫ 23 Ⓢ ♣ ｡ﾆ 28 Ⓔ ☾ ☸ 
14 13 8 2

[5] In the simplified version, we can easily tell the info elements with an invalid key [ x ] are filler [ fake ] elements, and can be deleted during decryption, but in real time, the keys show up like the above.
So the key for the first info element is : 2 8 13 0
Notice in realtime example, the tokens table is 4 x 4 with 16 tokens, so the key represents the selected tokens positions of #2, #8, #13 and #0, which means the 1st token in the key is : 36 : ☺ + 
The last token in the above key is [ 0 points to the first token ] : 23 ~ ♣ ✉

In this example, the passcode is : Ⓘ ♥ 2 ✉ 
Since Ⓘ ♥ are not in the table, so wild card is allowed, therefore #2 and #8 are 2 valid tokens, but the symbol "2" [ 3rd user pin ] is in the table on the 11th token "Ⓕ ☼ ¦Χ 2 ", and yet the key has #"13" in it's place, so this key is invalid [ it was intentionally generated by GATE for fake info elements, remeber ?! ], and therefore the info element with this key is also invalid should be deleted during decryption.

So, during the decryption process, GATE goes through the above steps to check each info element, get rid of the fake ones to get to the original message.

Keep in mind, in my example, I chopped the message into letters, but in real world [ production ] use, the info will be chopped into bytes or bits, so instead of "V d w 3 G U k w" being encrypted, it will be something like "1011010001010011110010101001101010100010101100101110101000011", and each "0" or "1" will be attached to a tokens table and a key [ valid keys for "0"s and"1"s from original info elements, invalid keys for GATE rendomly generated filler/fake "0"s and "1"s], so the encrypted information will be inflated many times.

==============================================================================

My 2nd utility patent was just granted, it's GATE encryption. Using GATE [ https://gatecybertech.com ] as the basis to encrypt/decrypt information, it's quantum computer resistant, the reason I say that is : most of current encryption/decryption systems use prime numbers to encrypt information, and since large prime numbers will take a long time for conventional computers to crack, so those algorithms are safe from traditional computers, but since quantum computers can quickly find the prime numbers used to encrypt the info, those encryption/decryption systems are at risk as quantum computers come to market.

GATE does not use prime numbers to encrypt information, it uses the patented GATE authentication system to authenticate each piece of information element. During the encryption process, original information is broken down into multiple information elements [ characters, bytes or bits ], then mixed in with other filler [ fake ] information elements, each information element is attached with a GATE tokens table [ equivalent to a lock ] and some key tokens [ equivalent to a key ].

For each original information element a valid tokens table [ lock ] and a set of key tokens [ correct key ] are attached to it, for each filler [ fake ] information element automatically generated by the GATE encryption algorithm, a tokens table [ lock ] and a set of invalid key tokens [ wrong key ] are attached to it, whether a tokens table [ lock ] and the set of key tokens [ key ] attached to it can validate each other depends on the passcode, so if you have the right passcode, you can tell which information elements are part of the original information, and which information elements are invalid filler elements and should be get rid of during decryption to get the original information.

Therefore, even when faced with a fast quantum computer, if you don't know the passcode which is used to encode the original message, you will just get the wrong answers faster, and there are multiple combinations of possible wrong answers [ if you used a wrong passcode, you just open some wrong locks which contain some wrong information elements ], and none of them is telling you which one among them is part of the original correct information.

The GATE encryption/decryption system has the following characteristics :

[1] Encrypted data size adjustable.
Depending on how fine you chop up the information, the finer you chop up the original message, the larger the encrypted message will become and more secure it becomes.

For instance if you use word as an information element, then the following message will have 3 information elements : How are you.

If you use character as information element, then the above message will have 12 information elements : H o w _ a r e _ y o u .

Or you can use byte or even bits as information elements, if so, the encrypted file will be larger and more secure.

[2] Use GATE passcode, not prime numbers to encrypt data.
Since GATE encryption uses GATE authentication as basis to encrypt message, only when you know the passcode that is used to encrypt the original massage, will you get back the original information after decryption using the same passcode, otherwise, if you use a different [ wrong ] passcode to decrypt the encrypted message, you will get a different [ wrong ] message from the original information. With a fast quantum computer, you just get the wrong message faster.

[3] Extremely large size of encrypted file automatically deter most run-of-the-mill hackers.
With GATE encryption, since the encrypted message will grow many [ at least 350 ] times larger, it will become very hard for a potential hacker to attempt different possible combinations of passcodes to try to get to the right answer, it takes a lot of space and time to encrypt/decrypt messages. Which means, if a message is encrypted with a giant powerful computer, then the encrypted message will be too large for a run-of-the-mill hacker to even try to crack it, because the information is simply too large to handle, way beyond their capability. This will significantly reduce the potential threat. For example, if your original file size is 100 MB, after the GATE encryption, the encrypted file can easily be as large as 700 GB [ 7,000 times larger ] if you set inflate index to 5. The inflate index range from 1 to 999 which can be adjusted according to your needs [ I choose 999 in my app because it's WAY LARGE enough for my PC, but this index can be as large as your computer can handle ], no upper limit.

[4] Even with powerful computers, it's hard to determine the original order of the chopped up large data chunks before decryption.
Since GATE encryption will result in a large encrypted file, it will then be chopped up and named in seemingly random order [ yet the GATE system knows how to put them back in the correct order ], so even if those chopped up encrypted files are in hackers' hands, it will be hard to even put them [ like pieces of puzzles ] back in the correct order before trying to decrypt them.

More info and demo can be found at :
[1] https://gatecybertech.com
[2] https://gatecybertech.com/gate_encryption.html#encryption
[3] https://gatecybertech.com/gatecomparison.html

Ni , Min  [ Frank ]
nm67@yahoo.com