AI Censor Engine

The dynamic encryption process described in other notes would require high processing power of user’s computer. Most of our computers are equipped with a single microprocessor, thus it may not powerful enough to crunch data, i.e. encrypt and decrypt messages.

Let’s make encryption tasks simpler for single microprocessor computer such as Windows 10, i.e. using AI Censor Engine.

The encryption of outgoing packets could be based on selected keywords stored in database, e.g. secret, classified, personal, confidential, etc. This way would also require the computer to open outgoing packets and check for selected keywords in order to perform encryption. This method also demands significant processing power.

The easiest way, computer could encrypt a few packets randomly in a bundle or set of outgoing packets, e.g. 2 packets out of 10 outgoing packets. This is like blacking out a few phrases or sentences.

Adding a field in a table without interrupting live traffic

Figure 1. Structure of data in a database table

Assuming that data fields (columns) in a table are stored using linked list in a hard drive, the last pointer is usually set to “null” to end a linked list.

Let’s say the original table has 2 fields at first. Users wanted to add the third field without interrupting traffic. The second field would point to a pointer with value “null”.

If the database engine is structured left to right, i.e. the first column would be indexed as 1, and second field indexed as 2. During a search, update, or delete a field the correct index is used. Indexing could be done by a compiler to compile an application program and translate those fields into database’s table indices.

So, when a user adds another field, the database engine would modify the original “null” pointer at the first construction to point to another field in the hard drive, i.e. connecting the second field to the third field. Of course, the third field would point to the “null” pointer again. This scenario is useful when doing live upgrading on the executive node with new data field introduced for additional software.

The index of the “pointer to third field” is not counted.

Removing a field is complicated because the database structure has changed. Doing so may cause corrupting data during live traffic due to incorrect indices.

The process to remove a second data field is described in figure 1 by updating the pointer and its index.

Live upgrade on executive node

This is a special case for system providers. If a system provider has come up with a system with all features developed and could load assembly codes on a live system such as APY.

The system provider could preconfigure database with all fields, tables and clear protocols between subsystems. Each subsystem is a feature communicating with other systems using a predefined dispatching protocol interface.

System provider can deploy a full database with tables and fields. If customers didn’t want a feature, the corresponding tables and fields would be empty. That subsystem’s codes would not be loaded.

If customer bought a feature at later date, system providers only need to populate those database fields, database tables, and load assembly codes of that subsystem on the executive node. After that they only need to activate the subsystem by a command.

Live upgrade with data transferring

Figure 1. Data and software upgrades

A. Data upgrade process

As shown in figure 1, the executive server and mirror server are receiving live data during a software upgrade with data transferring from the executive server to the mirror side in parallel.

The process could be described as follows:

1. Disconnect the mirror side from live traffic

2. Load new software or data on the mirror server

3. Start upgrading by allowing data with its timestamp from the executive server transferring to the mirror side in parallel with live data coming to the mirror server at the same time.

- The executive server keeps offering services to users during data upgrade

- Data coming from live traffic to the mirror server would have higher priority as compared to data updates with timestamp coming from the executive server, i.e. live data would be written to the mirror database if data collision occurred.

The process of data update is carried out orderly in the executive server while live data coming from the users randomly or unpredictably.

After data transferring from the executive server to the mirror sever completed, operators would run a command (or automatically by system) to switch the mirror server to executive side. Software and data would be transferred from the new executive server to the new mirror server. Both sides would be operated normally after software and data completely upgraded.

B. Exception

There is a case that life traffic data to mirror server are not completed or incorrect, because those are dynamic data.

For example, user is making a call and that call couldn’t be properly setup in the upgraded mirror server, because there was no physical connection of phones. However, data was properly written on the executive side. If those data fields had been transferred to the mirror server during data update with timestamp, the mirror server missed some live data.

In order to save some dynamic data, the software upgrade process could record data fields newly written that have created or written on the executive server, but those haven’t written in the mirror server. This is the second pass of data transfer. The executive server transfers those data to the mirror server.

Because live traffic is ongoing forever, the upgrade process must stop after the second pass or third pass. We must accept some data lost.

C. Additional pass of data transfer

The operating system could perform another loop of screening data to be transferred between the executive server and the mirror server. If data in the executive server is newer based on the timestamp, data would be copied to the mirror server again.

However, this is not a bullet proof method as data keep updating and the screening loop and data copy takes some time.

I heard that IBM and Ericsson came up with a better strategy to transfer missing data by the operating system in parallel. I think, this should be a better method.

Dispatching requests for server’s access

Figure 1. Diagram of settings to dispatching requests for server’s access

Currently there are talking about cloud servers, which locations of servers are unknown. One of those configurations would be block chain servers.

How could you offer a service to clients without knowledge of your servers such as encryption technology, admin personnel, and locations of those servers? If there was something wrong, how could you fix that or identify the problems?

Block chain’s service should be ruled out by governments as detectives couldn’t localize, locate, or identify any source of problems.

In the diagram above, it describes an example of configuration of Dispatching Interface Gateway for Google’s services.

Let assume that Canada and USA requires gmail server for their residents must be located in their soil. Any request access for gmail would be redirected to correct servers in either Canada or USA by the Dispatching Interface Gateway.

With this configuration, we could tap or monitor the Dispatching Interface Gateway to follow an access request in case of problems.

Encryption Protocol v1.1

Figure 1. Encryption protocol diagram

The diagram above describes a simple communication between an originating node and a terminating node with dynamic encryption technology.

Each node could include an Encryption Key Engine with a set of encryption algorithms.

The Encryption Engine includes a set of encryption algorithms with dynamic names to make decrypting tasks harder for hackers as described earlier in separate notes.

If the Encryption Key Engine is equipped with a set of algorithms, the protocol must be different, so the terminating node would know how to generate correct SSD based on receiving RANDU, which is used in encrypting messages.

Let describe simple communications between nodes that used only 1 encryption algorithm in the Encryption Key Engine.

-         The Encryption Key Engine generates a random number/character, RANDU based on its encryption algorithm and a few keys uniquely identify the system. It also generates an SSD based on that RANDU. Assuming that those parameters called RANDU 1, and SSD 1.

-         The encryption engine would use “a random encryption algorithm” with SSD 1 as the key to encrypt the sending packet.

-         As described earlier notes, the originating node would send RANDU 1 and the encryption name (code) plus message to the terminating node.

-         The terminating node would send the RANDU 1 key to its Encryption Key Engine, so the key engine would send back the corresponding SSD 1.

-         The encryption engine would use the SSD 1 and received encryption name (code) to decrypt the message.

To make cracking tasks harder to hackers, each message is a packet. Each packet would be associated with a unique pair of RANDU and SSD.

Dynamic encryption pools used in public networks

A. General Information

Communications by telecom or Internet would use dynamic encryptions to protect its contents. The encryption algorithms don’t use a master decryption key, but dynamically changed encryption/decryption key.

The idea was from telecom technology in authentication. Telecom system authenticates a mobile phone using authentication by RANDU, SSD, and CAVE. We would use an SSD as a dynamic key to encrypt/decrypt a packet.

B. Internet and Telecommunications

1. Https

Currently we’re using https as an encryption technology in many countries, i.e. shared encryption technology.

2. Encryption

The issue was that there were not many encryptions available for many important organizations or general public use in telecom or Internet communications. So, computer industries would share a set of encryptions in many nations. Telecom industry should share another set of encryption algorithms.

It’s not easy to keep an encryption algorithm secret. The goal is to make hackers to crack any packets by running all cracking algorithms. This would take them months or years to decrypt a packet. By the way, a short email would include many packets, so hackers would be in trouble to decrypt an email.

3. Common pool and private pool of encryption algorithm

If there were many encryption algorithms, we could divide those in 2 pools of encryptions. Roamers from another place would communicate with a local telecom or Internet network by using the common pool of encryptions agreed by regulators or industries.

Private or local users could use either common pool or private pool of encryptions.

4. Methodology or protocol

Let’s assign the common pool of encryption by a unique version number or characters agreed in the applicable industry.

a. Common pool

-         The first communication message to an ISP or telecom network would be encryption version.

-         If the roamer couldn’t understand the private (local) version of encryption set, they would send a request to use the version of common pool.

-         The communication would then be in common pool’s algorithm.

Use of private encryption pool could be done easily with a version number. If the name of encryptions is changed, the version name would be changed, too.

b. Same set of encryption, but different names

Even hackers knew the encryption, but if they didn’t know which algorithm used in encrypting a packet, they must run all decryption possible algorithms to decrypt a packet, i.e. months or years to know the content of our message.

In a previous note, a computer and ISP must exchange encryption names and protocol to specify association of an encryption and a packet. This helps the ISP (or telecom operator) to decrypt a message easily as required by laws.

The key would be encryption names. If hackers didn’t know the encryption names, they would be forced to run all decryption algorithms.

To make decryption harder to hackers, we would change names of encryption algorithm or software regularly. Each location (ISP or telecom operator) could have different names for the same set of encryption algorithms. The protocol could be as follows

-          The first communication message to an ISP or telecom network would be encryption version or pool version.

-          If the common pool of algorithm was not available, the ISP would send a message to the user to download encryption software with unique names as well as its version number.

Because the whole industry only used a set of algorithms, thus let the user to download the encryption software should be fine, i.e. the device knew algorithm in other names.

C. Changing encryption names

Regulators or special teams could change names of encryptions or add new encryption algorithms at any time. They only need to change version names and allow users to download new encryptions.

Encoding local IP address

Figure 1. Sample of a network connection for an ISP

If we looked at the diagram, our computer is assigned a local IP address by our ISP for Internet communication, e.g. 192.168.2.1.

When we perform a remote access to another computer or server, our local IP address could be included in an Internet packet along with the global ISP’s IP address. This is to ensure that the return packet knew to route back to our ISP, and then our computer.

A typical IP address is 12 digits, i.e. 6 bytes.

If we encoded our local IP address in 3 characters or 3 bytes, we would save 3 bytes in communications. 3 bytes is 256 x 256 x 256 possible combination, i.e. ISP could offer unique connection to 16,777,216 computers within their network.

Let’s say our computer is temporarily assigned with a code ABF instead of 192.168.201.165. The ISP could insert this code, ABF, in the database, and send out a message to the gateway with its IP plus ABF as returned IP address, e.g. 265.378.109.243 + ABF instead of 265.378.109.243 + 192.168.201.165 in an IP packet. The Internet gateway only needs to route the return packet to 265.378.109.243, where the packet would be decoded and delivered to 192.168.201.165 based on the internal code ABF.

Similarly the Internet gateway could encode the IP address of its internal ISP server address before sending a packet out with its IP address and code of the internal ISP.