## Preliminary Timing Results

The handshake was evaluated on a computer running at 2.7 GHz, while processing 336 bit encryption keys. The table below shows the time it takes to process the public/private keys, not including transmittal time. (cycles) is defined as how many computer cycles were needed to process the data. Divide the cycles by the speed of a device to calculate processing time. For comparison, the competition range listed are values published on Github (https://github.com/mupq/pqm4/blob/master/benchmarks.md)

# Frequently Asked Questions

## Canada and Quantum Technologies:

Quantum Industry Canada currently lists 29-member hardware and software companies based out of Canada or with a major Canadian office, of which CEW Systems Canada is proud to be a member.

List of Members — Quantum Industry Canada

## Published:

A CTO funded technical review of our encryption software was undertaken by Dr. Cyril Coupal of Saskatchewan Polytechnic Institute’s Digital Innovation Center of Excellence (DICE), which was publish on InfoQ on Oct 5th, 2021 and can now be downloaded from:

Post-Quantum: Bi-Symmetric Hybrid Encryption System – News Priviw.

Dr. Coupal was supplied with a dedicated computer preloaded with the full encryption software code for evaluation as the major undertaking of the study.

## Publishing Full Source Code?

At this time, CEW Systems has elected not to publish the full algorithms. Dr. Coupal recommended not to take this step as doing so will aid in hacking the keys:

“Take for example the widely used freely downloadable messaging software Signal. A post published in December of 2020 by the software firm Cellebrite, claimed that they are able to easily decrypt messages stored on any device encrypted by the Signal software. The post claims that by simply reading through the published algorithms, they were able to find where the encryption key is stored and used to encrypt stored messages.”

By telling the world exactly how Signal encrypt their data, we feel they left a very large back door completely open. For this reason and for ease of explanation, where examples are required, Bi-Symmetric encryption is described using a deck of playing cards.

## Internet of Things (IoT)

Bi-Symmetric encryption was originally designed for IoT devices such as remote keyless systems (car FOBS). The idea for the Bi-Symmetric came from studying how car thieves break into and steal car FOB equipped vehicles. Two attacks are used, brute force attacks and rolljam attacks. Rolljam attacks require recording the intercepted repeating command codes for a remote keyless system and replaying them back at a later time to gain access to a vehicle.

To thwart both attacks we designed a handshake that used pre-shared private keys in which a two encrypted randomly generated numbers, called the challenge and counter challenge code are sent, instead of encrypted passwords, from the FOB to the vehicle in a 4-step handshake. Intercepting and recording the signals will not work because each set of numbers are essentially never repeated. Sending a brute force attack incrementally sequential set of numbers, for example from 0000 to 9999, looking to unlock the car will not work because with each attempt the unlock counter challenge code will change with each and every attempt.

The command being activated is identified by using a difference command code, or key, to modify the counter challenge code. The receiving device tests the counter challenge code against all the known command keys and the key found to correctly match the send challenge data defines the command the user activated.

## Quantum Resiliency

Quantum resiliency was realized by expanding pre-shared private keys using key expansion keys in form of circular encryption.

## Key Expansion Key

With AES encryption, a key expansion is where one key is taken and used to create a series of other round keys. See link for full description.

## Initialization Vector

Within cryptography, an Initialization Vector (IV), also known as a starting variable, is used to setup the initial state of the encryption key. IV is either random, pseudorandom or unique numbers used to modify the keys so that when repeating data is encrypted, the resulting cipher blocks are non-repeating. This is important because with all encryption, the data is usually encrypted in small blocks. AES encrypts in blocks of 16 bytes each. When data is repeating, let’s take for example a screen capture bitmap with the majority of the pixels being grey, the vast majority of the encrypted blocks would be identical. An attacker would see that and could reverse the encryption process to determine what the original keys are. With IV, the key is modified before encrypting each block of data. This helps ensure that repeating identical data does results in non-repeating encrypted blocks of data.

## Circular Encryption (a Form of Initialization Vectoring)

What is circular encryption? After all, we think of a circular calculation as bound to fail, right? Circular encryption is the term we’ve used to describe a modified type of Initialization Vector which builds on the Key Expansion Key concept. With the exception of the hashed user ID, add data transmitting during the Bi-Symmetric Handshake is 100% randomized data, we can use the randomized data as the Initialization Vector. This allows the software to take a small portion of the data that is to be encrypted and modify each set of keys before encrypting the data with the new modified/encrypted keys. This is done to complicate the resulting possibilities an attacking computer needs to process.

It’s best explained with this simple example. Alice takes a deck of cards and removes the tenth card. She uses this card to modify her copy of the keys. Then shuffles the deck using the modified keys and reinserts the card in the tenth spot and hands it to Bob. Bob removes the tenth card and uses it to modify his copy of the keys, de-shuffles the cards and reinserts the card in the tenth spot. Since the original keys contains the identifier for which card to pull out, and an attacking computer doesn’t, it will need to test not only every possible key combination along with every possible key card location. The important part is that the key variations goes up by, in this example a factor of 52 and the total possible results grows from 10^68 (How Many Times Should You Shuffle a Deck of Cards? | The Science Explorer) to 52*10^68. While a single pass of shuffling leaves one card unshuffled, taking a second card, for example the 20th card, from the pile and reshuffling again will cause the first unshuffled card to become shuffled, completing the shuffling of the entire deck. The second more important factor, the key variations an attacking computer will need to process further grows exponentially to become:

## Expanded Keys and False Duplicate Results

Continuing with the playing cards example, the pre-share private keys, or the new session keys that are transmitted will be, 52 numbers for shuffling plus 2 to identify which two cards to pull during shuffling, multiplied by 8 to convert the numbers to bits:

##

With the keys being expanded by the circular key expansion, this means the data being sent also holds some the keys used for encryption. Let’s call these key cards. Each key card will be found to have one of 52 different values, this means that the original keys will be modified in one of 52 different ways. An attacking computer won’t know which two cards were used to modify the keys, or what their values were, therefore, it’s forced to calculate all possible variations or combinations of the keys, for each possible value of both key cards.

When attacking an intercepted encrypted shuffled deck of cards, you can understand that with expanded key size (44,927 bits) being much larger than the data being encrypted (52 * 8 = 416 bits), there will be a large number of key combinations that will produce the same exact intercepted results. We call these false duplicate results. The false duplicate results (FDR) are calculated as:

##

##

##

##

There will be approximately 10^13,370 key combinations what will produce the exact same values as the intercepted shuffled deck of cards.

## Initialization Vectoring with Standard Data

When encrypting large sets of true data, Bi-Symmetric Encryption instead inserts random padding rather than using the data to be encrypted, to conform with standard Initialization Vectoring. This is required because there are many file formats which start with a standardized header which an attacker may likely know and could use to reverse the encryption process using what the attacker is expecting to see in the first few blocks of data. Take for example the xml file format which typically starts with the following 38 characters:

<?xml version="1.0" encoding="UTF-8"?>

By changing to standard Initialization Vectoring and incorporating some random padding, the key expansion keys will be unique an unknowable.

## Processing a Password without Sending the Password?

While the idea of processing a password authentication without actually transmitting the password directly, is new and one may wonder, how is this achieved? It’s really quite simple. To describe in very simple terms, when Bob sends Alice the session keys, he also includes a random number, called the test data. She encrypts the random number using her password turning it into a counter challenge code, then re-encrypts it once more with the session keys and returns it to Bob. Bob looks up Alice’s password and decrypts and de-modifies test data. If the test data numbers that were sent and received match, it means Alice processed her password correctly. The password was never directly sent. When using the above card shuffle technique, an attacking quantum computer will need to process the intercepted data with the formula:

## Keys = (52 + 2) * 8 = 432 bits

## Expanded Keys = (52 + 2) * 8 * (52 + 52) = 44,928 bits

## Built-In Password Manager

It was realized after the handshake was developed that it can also be used for standard encryption situations. Typical user passwords are far too simple to use as the pre-shared private keys. By programming a built-in password manager, the simple passwords are combined with unique data from the user’s device to create an extremely complex two-part password. The first part is used as the initial pre-share private key. The second part it is used to modify the test data into a counter challenge code. Where commands are being sent to device, the second part of the keys are not required.

## Expanding for Other Uses

It was realized after the handshake was developed that it can also be used for standard encryption situations and is most effectively suited for e-commerce applications. A banking app login or credit card transaction can be processed without actually sending the bank card or credit card numbers. With current online credit card transactions, we all know you have to type in your card numbers, expiry date, secret code, address, phone number and email address. Adapting the handshake to use this sufficiently large enough set of data as the two-part pre-shared private keys allows the challenge and counter challenge codes to authenticate the credit card data without actually sending the typed in data.

## Exponentially Huge Possibilities?

How can the total number possible encryption outcomes be so extremely large as reported by CEW Systems and as listed in Dr. Coupal’s paper? The previous FAQ answers gives some clues. At CEW Systems we designed our encryption to take advantage of functions which mathematically compound the possible variations a quantum computer would find. Encrypting random numbers, in the form of challenge and counter challenge codes encrypted using the pre-shared private keys, two-part passwords and session keys and using circular key expanding keys. With each of these multiple layers, each function designed to increase complexity or close a back door adding to the exponential possibilities resulting in the 16 level exponentially nested formula shown below. The intention of all the different described encryption layers was to exponentially expand upon the false duplicate results creating extremely large number of possible key combinations, such that an attacking quantum computer looking for the original password will find more false duplicate results then there are grains of sand on all the beaches of the world. The formula below is not the encryption formula, rather it’s the formula a quantum computer must process when attacking an intercepted Bi-Symmetric Handshake. Vt is the total number of key variations which could possibly exist.

## User Interface for 2 Factor Authentication

With the Bi-Symmetric Handshake relies upon pre-shared private keys, how does one setup an account for the first time? This has always been the question with symmetric encryption. With IoT, the devices come with the keys pre-installed and printed on the device or a pamphlet allows the user to enter the keys directly into their device or computer.

For all other applications, there are two main options, using some form of 2 factor authentication, or a trusted third-party authenticator.

When using 2 factor authentication, we suggest using two separate means by which to send account activation codes, for example, send one half of the codes through an email and the other half through a cell phone.

One approach for entering activation codes, we suggest, involves using rotation wheels of characters similar to rotating wheel combination locks found on luggage, as shown here:

As Dr. Coupal describes:

“Each time an entry of data is required, a number of wheels appear with randomly generated characters. Thus, it cannot be predicted from which start character the user will click the wheel to find the correct data element. Key logging can count the clicks but without knowing the start position of the wheel, the count is meaningless. Although this is an issue with all security systems during critical initial data entry, the approach suggested here decreases even further any likelihood of easily capturing secret data.”

## Trusted Third Party Authentication

It has been suggested that the idea of involving credit card companies as trusted third party sounds ridiculous. Trusted third parties do currently exist, both Google and Facebook offer this kind of service to aid in user friendliness with logging into online servers. Our website host server uses both as user friendly login options. Instead of typing in a username or email and a password, many sites now have the option of “Continue with Facebook” or “Continue with Google”. Not to mention the many online industries that currently rely upon credit cards to verify the authenticity of new customers, which includes, online video streaming service such as Netflix, Amazon Prime, online dating services and online gaming services, just to name a few.

## Man-in-the-Middle Attack Proof?

Man-in-the-middle attacks are thwarted in the same way. Trapping the data in the middle and changing it out for data you’ve encrypted won’t work as the Bi-Symmetric handshake requires both people at each end to have a set of the authentication keys.

## Timing Results

Why did the benchmark timing results described in Dr. Coupal’s paper list as being faster than those of post quantum asymmetric encryption algorithms listed on Github? Symmetric encryption algorithms have always been known to compute faster than asymmetric because of the lack of complex mathematical computations. Bi-Symmetric Encryption is no exception. Post quantum asymmetric encryption algorithms typically encrypt at the bit level, which means they are encrypting very large amounts of data (the Github post lists the ranges between 3k to 40k bytes) with small keys. The Bi-Symmetric system is opposite, a small amount of data (typically less than 50 bytes) is encrypted using very large keys, allowing for faster computation times.

This is why we call our Bi-Symmetric handshake system the fastest, smallest, largest of the encryption handshakes.

## Shor’s and Grover’s Algorithms

Dr. Coupal’s paper describes both Shor’s algorithm, which is designed to be used by a quantum computer to process current asymmetric encryption and Grover’s algorithm, which is the only published algorithm that can be used by a quantum computer to process symmetric encryption algorithms. With Bi-Symmetric being based upon symmetric encryption, only Grover’s algorithm can be used to process intercepted data, not Shor’s.

Going back to the double shuffle playing card deck, it is important to point that that if both shuffles use the same symmetric cipher, a quantum computer could potentially be programmed to process the data quickly and efficiently. However, if the two shuffles use to different ciphers, it forces a quantum computer to stop and process each possible 1st shuffle possibility with each possible 2nd shuffle possibility. Grover’s algorithm states that a quantum computer can process a symmetric encryption using 2 to the power of one half the number of bits used to encrypt the data. Therefore a 128-bit AES symmetric key is calculated with 264 iterations and a 256-bit AES symmetric key is calculated with 2128 iterations. If an incredibly fast one picosecond per iteration is assumed, then a 160-bit AES keys will process in 38,335 years. The shuffle card example uses 416-bit encryption which becomes 2 to the power of 208. With multiple shuffles of the card deck, then processing Bi-Symmetric Encryption requires nesting Grover’s Algorithms:

When attempting to process the test data for the password from the above shuffling example, processing Bi-Symmetric Encryption requires multiple nesting of Grover’s Algorithms:

When trying to calculate an entire intercepted Bi-Symmetric Handshake looking for a two-part passcode, or credit card number, the processing time required is calculated using a 16-level nested Grover’s Algorithm, the Key Sizes (ks) vary depending upon encryption level, consumer, corporate or government:

## Compounding Encryption Weaving (CEW)

All previous encryption methods rely upon an algorithm which uses either a single or few steps to process the data. The Bi-Symmetric Handshake is different. The handshake was designed to use extremely complex arrangement of Compounding Encryption algorithms which Weave (CEW) the data into an unintelligible set of encrypted data. Each step was designed with intentional purpose to compound upon the previous step, some steps designed to close vulnerabilities, most steps designed to exponentially increase the compounding complexity of the encryption, some are designed to increase the possible variations, while others are designed to increased computational time.