Earlier this year I discussed some noteworthy examples of crackpot cryptography and snake-oil security on this blog.
In this post, I’m going to analyze the claims made by CEW Systems Canada about “Post-Quantum Encryption” and argue that their so-called “bi-symmetric encryption” is another example of the same genre of crackpot cryptography.
Let’s get the disclaimers out of the way: This post was written solely by some security engineer with a fursona that has happens to have a lot of opinions about cryptography. This post is solely the opinion of said author, who also claims to be a blue anthropomorphic dhole, and not the opinion of any employer (especially his).
It’s entirely up to you whether or not you want to take me seriously, knowing all of that.
Additionally, by “fraud” I am not speaking in a legal sense, but a colloquial sense.
What Is “Bi-Symmetric Encryption”?
CEW Systems, a Canadian company incorporated in December 2020 by Chad Edward Wanless, claims to have developed a technique called “bi-symmetric encryption”, which they describe as follows:
What exactly is Bi-Symmetric encryption?(source)
Bi-symmetric encryption is an internet communications handshake protocol that uses public/private keys similar to typical asymmetric encryption, but instead uses an underlying symmetric encryption system as the encryption backbone.
Their FAQ page goes on to claim:
Why is it called Bi-Symmetric?(source)
We chose bi-symmetric encryption as the name because the encryption handshake is a hybrid of both asymmetric and symmetric encryption. It uses public/private keys just as asymmetric encryption does, while using symmetric encryption called CEW encryption as the underlying encryption software routine.
Ah, what a contradiction! According to this page, bi-symmetric encryption is a handshake protocol that simultaneously:
- Uses public/private keys just as asymmetric encryption does, but
- Uses an underlying symmetric encryption system
But if your underlying encryption for the handshake is entirely symmetric, where do the asymmetric keypairs come in?
Asymmetric cryptography has public/private keypairs because their security is based on a hard computational problem (large integer factorization, the elliptic curve discrete logarithm problem, etc.). You can generally take a private key (or some secret seed that generates both keys) and easily derive its public key, but doing the opposite is prohibitively expensive.
If you’re only using symmetric cryptography, you don’t have this hard computational problem in the mix, so where do the keypairs come in?
The FAQ goes on to imply that bi-symmetric encryption is resistant to brute-force attack, and then vaguely describes One-Time Passwords (a.k.a. two-factor authentication codes).
Brute force attacks on an ordinary computer work by incrementally testing possible values until the desired output response is found. For example, if a vehicle was locked and a smart device is used to hack it, the brute force attack would start at 0,000,000 and say, the unlock code was 1,234,678, the device would resend the code incrementally advancing the value by 1. The signals would repeat until the correct value was eventually found and the vehicle unlocked. Bi-symmetric software works by using a challenge code and test data combination that changes the unlock code for each attempt. Staring at 0,000,000 and incrementing to 9,999,999 would not unlock the vehicle as the unlock could would always be changing with every attempt.(source)
Even if you’re not a cryptography expert, I hope it’s clear that “synchronized random numbers” (one-time passwords) and “mangling a message so no one else can understand its contents without the key” (symmetric encryption) are totally disparate operations, and not at all interchangeable.
But here’s where things get really funny. After all this confusing and contradictory bullshit, they say this:
Another reason is that asymmetric encryption relies upon a math formula to determine what the private key is by factoring the public key. Bi-symmetric encryption does not mathematically correlate the two, instead one is encrypted by the other.(source)
Yeah, that concept already exists. It’s called envelope encryption, my dudes. There’s nothing magically post-quantum about envelope encryption, and it doesn’t obviate the need for asymmetric cryptography.
And if both keys are symmetric, and you’re communicating them in the clear, then what’s to stop someone from using the algorithm the same way a legitimate user does?
Of course, now that we’ve gotten to the meaty center, the remainder of the FAQ entry is the other half of the bullshit sandwich.
The largest reason asymmetric encryption is vulnerable is that the entire plain text being encrypted is mathematically modified using a math formula.(source)
What are they even talking about?
There are a lot of problems with asymmetric encryption. For example: Developers encrypting directly with RSA. This is an antipattern that I’ve complained about before.
But asymmetric encryption isn’t, as a whole, “vulnerable” to anything.
The reason NIST and other standards organizations are focused on post-quantum cryptography is that the currently-deployed asymmetric cryptographic algorithms (RSA, ECC) are broken by a quantum computer (if it ever exists). The solution is to study and standardize better asymmetric algorithms, not throw out the entire class of algorithms, forever.
The fact that quantum computers break RSA and ECC has nothing to do with “the entire plain text being encrypted”, as CEW Systems claims, because that’s generally not what’s actually happening.
If you use TLS 1.2 or 1.3 to connect to a website, one of the following things is happening:
- You have an existing session, no handshake needed.
- Your browser and the webserver use Elliptic Curve Diffie-Hellman to establish a session key. The server’s ephemeral public key is signed by the ECDSA or RSA key in their Certificate, which has been signed by a Certificate Authority independently trusted by the browser and/or operating system you use.
- Your browser encrypts a random value, called the pre-master secret, using the RSA Public Key on the Certificate. The pre-master secret is used by the server to derive the session key for subsequent connections. This doesn’t have forward secrecy like option 2 does, but it’s otherwise secure.
At no point is “the plain text” ever encrypted directly. The ECC option doesn’t even do asymmetric encryption the same way RSA does. ECC is used for key agreement, exclusively.
Understanding the basics of “how cryptography is used” is table stakes for even thinking about inventing your own cryptography, and CEW Systems cannot even clear that bar.
With the under lying encryption of bi-symmetric, each individual letter is modified separately, there is no mathematical link to the entire plain text being encrypted.(source)
The charitable interpretation is that they’re describing a stream cipher, or a block cipher used in Counter Mode.
A more likely interpretation is that they’re encrypting each letter independently in something like ECB mode, which offers no semantic security.
The less charitable interpretation is reinforced by this image included in their FAQ page that archive.org did not successfully capture:
This obsession over big key sizes is oddly reminiscent of the DataGateKeeper scam on KickStarter in 2016.
The about page further cements the insanity of their proposal:
This encryption method is a hybridization of asymmetric public/private keys combined with symmetric encryption to modify each character individually and not the data packets.(source)
A great example that demonstrates how bi-symmetric encryption works: If one were to encrypt, for example, a credit card number, a brute force attack would produce every possible credit card number between 0000 0000 0000 0000 and 9999 9999 9999 9999 with no means to determine which output would be the correct value.(source)
This just in! Crackpot company that claims to have solved post-quantum cryptography using only symmetric cryptography also hasn’t heard of authenticated encryption. Film at 11.
It’s frustrating to read bold claims from someone who flunks the fundamentals.
Credit Card Numbers adhere to the Luhn Algorithm, so an attacker isn’t going to even bother with 90% of the possible card numbers in their brute force range.
(Because of the Luhn Algorithm, there is only one valid checksum value, stored as the last digit, for any given combination of the first 15 digits, which is a 10x speedup in guessing. This mostly exists to detect typos before sending a payment request to the bank. Also not every credit card number is a full 16 digits; they can be as short as 13 or as long as 19.)
Also, for posterity, here’s my actual credit card number, encrypted with a 256-bit random key with a scheme that exists and is widely deployed today (n.b. NOT their snake-oil). You ain’t gonna brute force it.
In short, bi-symmetric encryption is the term CEW Systems uses to describe their crackpot cryptographic algorithm that is, allegedly, simultaneously a one-time password algorithm and an envelope encryption algorithm, which involves public/private keys but doesn’t involve an asymmetric mathematical problem that calls for mathematically related keys.
This contradictory and convoluted definition is almost certainly intended to confuse people who don’t understand advanced mathematics while sounding convincing and confident. It’s bullshit, plain and simple.
More Crackpot Claims
If you feel like you haven’t suffered enough, the team behind “bi-symmetric encryption” goes on to make claims about password protection.
Because of course they do.
CEW systems has given great thought to how to protect users’ passwords. As noted in the man-in-the-middle attack, passwords are combined with unique identifying data from users’ computers or smart devices, such as serial numbers, before being modified into encryption keys.
Wrong. So wrong.
Password hashing and password-authenticated key exchanges are an entire discipline that I don’t want to delve into in this post, but passwords are salted and stretched with a computationally difficult symmetric algorithm (usually a password hashing function), especially when they’re being used to derive encryption keys.
There are schemes that use TPMs or secure enclaves to produce key material from a given password, but that doesn’t rely on a “serial number” the way they’re implying.
Additionally, CEW systems created a patent pending and copyrighted custom user interface password edit box. This new user interface tool displays a dropdown window that contains “Forgot Password”, “Change Password” buttons and a phishing email warning tip window that informs and reminds users that the only means by which to change the password is through the software they are currently using.(source)
That is a lot of, well, something. Good luck getting a patent awarded on something that almost every corporate intranet has implemented since Hackers came out in 1995.
I’m also deeply curious how they propose to implement account recovery in their systems for when a users forgets their password.
If anyone reading this ever finds themselves making security decisions for a company, warning labels like this are not effective at all. A much better solution to phishing (and weak passwords, while we’re talking about it) is WebAuthn with hardware security keys (i.e. Solo V2).
Hanlon’s Razor is an adage that states, “Never attribute to malice that which is adequately explained by stupidity“.
To call something fraudulent, it’s not sufficient to merely conclude that they have crackpot ideas (which would be stupid), you also have to demonstrate deception (which is a form of malice).
(To be clear: Me calling something fraudulent, in my opinion, isn’t the same bar that the law uses. Do not misconstrue my statements claims about the legal system. I’m not a lawyer, and I am not making a legal case.)
In the previous section, we’ve looked at enough evidence to justify calling bi-directional encryption an instance of crackpot cryptography. But when does it stop being overconfidence and start becoming a grift?
I submit to you that the line of demarcation is when a crackpot attempts to gain money, fame, notoriety, or a reputational lift for their crackpot idea.
To begin, let’s look at some red flags on the CEW Systems website. Then let’s dive a little bit deeper and see what we can dredge up from the Internet.
The front page of the CEW Systems website claims to have a “Third Party Academic Independent Review” from Dr. Cyril Coupal from Saskatchewan Polytechnic’s Digital Integration Centre of Excellence.
Immediately after this claim, the website states:
Dr. Cyril Coupal’s CTO report currently can be made available to those who have signed a Non-Disclosure Agreement.(source)
Let me tell ya, as a security engineer, I’m used to dealing with Non-Disclosure Agreements. NDAs are almost always a prerequisite for getting contracted to review a company’s source code or conduct a penetration test on their networks.
Almost nobody working in cryptography today would ever sign an NDA in order to read a third-party academic review of any cryptographic system. That’s bonkers.
The “How It Works” Page
A common tactic of scammers and frauds is to sponsor a talk at a prestigious conference and then use the film of your talk at said conference to artificially inflate the credibility of your claims.
This is what we saw with TimeAI at Black Hat.
CEW Systems took a different route than Crown Sterling:
They joined with two other companies (Uzado, Terranova Defense) to form the so-called TCU Alliance in February 2020 (source), then invited a Constable from the Toronto Police Department’s E3 Cyber Security Division to deliver a talk and give legitimacy to their accompanying talk (archived).
Interestingly, their page about this TCU Alliance also states:
This alliance came together during 2020; while bidding on government proposals being issued by the Innovation for Defense Excellence and Security (IDEaS) proposals.(source)
This detail alone is sufficient in establishing the financial incentives needed to claim “fraud”. They’re out to win government contracts.
Will This Save America From Cyber-War?
Speaking of Terranova Defense, their Chairperson James Castle wrote an opinion piece (in response to a The Hill article) that claims:
I would be thinking that collaboratively with our quantum proof encryption software, We “COULD” Survive a Cyber War!!(source)
I wish I was making this up.
Time What Is Time?
If you cannot reasonably establish the history and timeline of the company you’re talking to, they’re probably up to no good.
Is It Really Fraud?
Aside from the abundant red flags, and the establishment of financial incentives, and the convoluted claims about the company’s timeline, the other significant modicum of evidence for fraud isn’t found on the CEW Systems website.
Rather, it’s kind of meta.
The entire reason that I’m writing about this at all is because CEW Systems pitched their crackpot cryptography to a current Dhole Moments reader, which led to me being alerted to the existence of CEW Systems and their so-called “bi-symmetric encryption” in the first place.
Crackpot ideas are stupid; trying to sell your crackpot ideas to others is fraud.
I don’t know if it was desperation or greed, but they tried to sell their crackpot product to an audience with someone attending that was just clueful enough to realize that something’s amiss. If they hadn’t been trying to sell their crackpot ideas, I would never have even heard of them.
When you add those facts together, I can only conclude that bi-symmetric encryption is a fraud being perpetuated by Chad Wanless of CEW Systems in Canada.
What Did Dr. Coupal Reveal?
If you recall, CWE Systems erroneously leaked the same “CTO Report” that they claimed would only be made available to parties that agreed to their Non-Disclosure Agreement.
I’d like to take this opportunity to annotate some of the interesting revelations from Dr. Cyril Coupal’s report. Feel free to skip this section if you aren’t interested.
The Analysis Was “Short”
The introduction of the CTO report states:
CEW Systems Canada Inc. has asked the Saskatchewan Polytechnic Digital Integration Centre of Excellence (DICE) group to perform a short CTO-funded analysis on their Bi-Symmetric Hybrid Encryption System.
I don’t know what “short CTO-funded analysis” (a unique phrase that doesn’t exist online outside the context of CEW Systems) even means, but any short analysis is unlikely to be a careful one.
How the “Encryption” is Achieved
The bottom of page 1 (Overview of the Approach) states:
The encryption itself is achieved by randomly generating keys and interweaving them with portions of unencrypted data to be transmitted, applied to single bytes of data rather than long byte collections.
This is basically how the broken stream cipher, RC4, was designed. There’s not much novel to say about this. RC4 sucked.
The top of page 4 contains this gem of deception:
- This should really use a logarithmic scale.
- The powers of 2 being discussed are small potatoes. If you’re trying to factor 2048-bit numbers, your X axis needs to extend way past 30.
I’m honestly not sure if this is because the author was in a rush, or if they’re in on the scam. I sent an email and will update this post when I have any further light to shed on this matter.
Trusted Setup Required
Towards the bottom of page 8 (under the heading: What about initial secret exchange and account setup?) states:
Common secrets, known to both server and client, must be exchanged when initial set up of accounts is made. Various methods exist to do this, but most involve the human factor, which is dangerous.
Way to bury the lede! I can already devise and deploy purely symmetric system that requires pre-shared keys today. That doesn’t make such a system practical or reliable.
Revenge of the Immortal Security Questions
At the top of page 10, Dr. Coupal was kind enough to include a screenshot titled “Forgot Password Example” which shows the breathtaking cluelessness of CEW Systems.
Security questions are an anti-pattern. There are better mechanisms available. Why would anyone intentionally design a new system that uses password-equivalents that users don’t realize are as sensitive as their actual passwords?
It doesn’t matter how you’re encrypting the answers if they can be leaked from third party apps, and are rarely (if ever) revoked.
Cursed User Interface
Just look at this monstrosity.
This is absolutely cursed.
The Smoking Gun
The entire discipline of Cryptography has a tenet called Kerckhoffs’s Principle: a cryptosystem should be secure, even if everything about the system, except the key, is public knowledge.
At the bottom of page 11 of the CTO Report, Dr. Coupal states:
The implementation algorithms cannot be open source.(Emphasis mine.)
Knowing the procedures would aid in hacking the keys, therefore, the actual implementation of the algorithms, as well as the algorithms themselves, must be kept secret. The interweaving protocol is not mathematically based, but procedurally based. Of course, the data secrets for each client-server interchange must also be known, which is highly unlikely. CEW has many protocols in place to keep their application code secure. However, this may cause difficulty in obtaining certification by security agencies if they cannot inspect the code for security issues and thoroughness. Finally, it is not currently known how easy it would be to reverse engineer a copy of the executable code.
While cryptographic snake-oil salesmen aren’t peddling sex lube, they’ll be quick to fuck you just the same.
In this author’s opinion, “Bi-Symmetric Encryption” is a crackpot fraud, just like MyDataAngel, TimeAI, Crown Sterling, and so many other bullshit products and services before them. Don’t give them any money.
This story has a silver lining: Someone who felt something was amiss spoke up and the fraud was thus detected.
As @SwiftOnSecurity is quick to remind us when discussing their history as a Help Desk worker, your users are your first line of defense against security threats. They’ll be exposed to bullshit that you never will. (Chad Wanless never posted a paper on IACR’s ePrint, after all.)
I think it’s safe to conclude that Dr. Coupal isn’t a disinterested third party. I have not updated the relevant section to reflect this new evidence.
Sophie Schmieg points out that the factorization graph clearly used trial division rather than an optimized factoring algorithm.
If you look at the graph from Cyril Coupal’s “CTO Report”, it’s pretty clear that he didn’t terminate the algorithm after reaching the square root of the number they were attempting to factor:
When factoring a large integer, if you don’t encounter a factor after reaching the square root of that integer, you know the number is prime. After all, the only way for there to be a factor of N that’s larger than sqrt(N) is if there’s also one smaller than sqrt(N). If you reach sqrt(N), inclusively, and don’t find a factor, your number is prime. You can stop searching.
(Before a mathematician objects: Yes, I know I’m completely ignoring Gaussian Integers which have factors in the complex number space, but no factors in the real space. We’re not talking about those.)
This observation has the effect of doubling the X axis for the curve plotted. Factoring a 32-bit integer should require no more than 65,536 trial divisions.
I’m astonished that someone who claims to have a Ph.D in Computer Science doesn’t know this. Makes you wonder about his credentials a bit, doesn’t it?