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
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:
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 is currently developing a scientific paper for submittal. Stay tuned.
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.
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.
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.
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: