Let us introduce
you to some more details of our vision to the problems of
Cyber Security and Encryption that will make you think deeper.
1. Speed:
IoT, Audio,
and Video companies may be interested in our method since we are orders of
magnitude faster than the status quo.
However,
speed is on the back-burner for us as we provide only general RI09 and RI18
Reference Implementations as of 2021, with experiments with EI27 (Experiment
Implementation with random numbers from 1 to 10^27) and EI36 (Experiment
Implementation with random numbers from 1 to 10^36). We certainly are ready to
cooperate with projects in these fields, though.
The reason IoT, Audio, Video etc. may be interested in our Speed alone
is that we may provide encryption without hindering the Audio or Video process
itself (which in turn is the definition of 'real-time' encryption).
IoT can be
various things actually, so it depends on what kind of IoT
it is. It may be interested in speed, it may be interested in the exceptional
BFRI, or ... it may not be interested at all.
Already 90%
of the Internet traffic uses https. VPN, SSL, etc. come on top of that,
resulting in slow, slow, slow. The more Security, the
slower your communication is - that's the common trend in the Old Way of
communication.
1. Total
Internet users growth projected to
grow "from 3.9 billion in 2018 to 5.3 billion by 2023"
2. Total
Internet users growth projected to grow "from 51% in 2018 to 66% of the
global population in 2023"
3. Consumer
segment share of total devices and connections will be 74 percent, business -
the remaining 26 percent.
The New
Method is not only orders of magnitude
FASTER as encryption than the Old Methods, but much FASTER as transmission, too, since it doesn't need in itself
all these HTTPS, VPN, SSL, etc. that slow down the transmission process we discuss.
Businesses revolve around active processes, rather than snapshots from the past.
It is Real-time Data, Data-in-motion rather than Data-at-rest. Data-now, rather
than Data-then. That's why the accent shifts from encrypting Data-at-rest to
encrypting Data-in-motion.
And that's why encryption-performance, as well as transmission-performance matters, too.
Since the US
Government, Google, Microsoft, etc. use AES to encrypt Data-at-rest, let's see
how AES could be moved around WRAPPED
safely in our Data-in-motion method and moved undisturbed, so there is no
need for any transformation inside, be
it before or after the transfer itself.
You feel
confident enough in your Data-at-rest encryption, but you have to transfer it
from point A to point B through dozens and
dozens of Mid-points you have no idea about, and you still want to preserve
your original encryption while the data is transferred through the chain of
Mid-points you (and we, for that matter) have no control over.
Let's use
the Shakespeare's Romeo and Juliet benchmark you are already familiar with,
since we presented it both in Google Cloud and Microsoft Cloud. Here is a link
to the encryption using AES from TechJury:
https://techjury.net/blog/what-is-aes/#gref
Here is the
same Shakespeare's original we did separately and independently from anything
else, under the 'Examples' menu:
You want to
TRANSFER it securely, without any disturbing of AES encryption whatsoever. Here
is how this double-encrypted message will look like in the Cyberspace:
Here is what
is read and what is received back-to-beck, just for easy reading:
Received =CDrSpLOilx0tDY46n5dQsVM7639A36PcnJQJQmgprvzh/Yj+BHZxspoGGXq4Pln5jOBOVbIP08z76...
This is wrapping
AES in our encryption and then back, without touching AES itself. 2-in-1 "suitcase" for
traveling through the Mid-points undisturbed.
Can you see
the AES encryption underneath ours in the Bag of numbers
above?
Well, we can't
either.
Virtually all the methods currently in use (AES, DES, Public/Private, etc.) were invented in the Last Century when
Computers were not that fast and the Internet was in its infancy. They were good for their time during the last century, though.
The NIST definition of Post-Quantum Encryption states that the future Encryption Methods
should be able to "interoperate with existing communications protocols and networks".
Cyber Confidential achieves that via the wrappers.
Crypto-currency
suffered multiple break-ins, scams, etc. reportedly based, among other things,
on inadequate encryption. You know,
of course, that most of 1,000 or so encryption methods claim that they are the
"best of bread" and they
very-well may be - for your particular case. It can be famous, it can be
infamous. The only way to find out is to TRY them and study the results.
A simple
Bank Transaction - the sample is taken from Wikipedia - would be:
"West
Lion;2006;159;29.99"
It certainly
can be encoded in hundreds and hundreds of different ways, but our cyber
transfer-encoding would be:
Point being
is that for us it is just another
content like any other content. The meaning of it is nothing we are concerned with or handle, for that matter. We simply
provide the environment.
Just like in
the Romeo and Juliet example and the wrapping around the AES encryption.
- cannot be left
on the table so that everyone can see it and there is no need for anyone to
break-in or eavesdrop over the network
- can be
read by someone different from the Sender and the Receiver, including the
software developers who developed the method
Then you
have to find a ... new encryption method.
That is so
important, that we have a version of it on the banner of our website.
It may be
considered contradicting to "What is hard is creating an algorithm that no
one else can break, even after years of analysis." (Bruce Schneier, 1998), but only at first glance. When you read it
carefully, it is the same thing.
It always
makes us sad when businesses complain to the press that data of millions of
their customers "has been compromised". Unless done on purpose internally,
of course. You have heard the expression "No encryption is unbreakable,
given enough time". Actually what they mean is "No encryption WE MAKE
is unbreakable, given enough time". That would be more accurate.
We like
though, what E.A.Poe said more than a
century-and-a-half ago: "human ingenuity cannot concoct a cipher which
human ingenuity cannot resolve." Shhh... :-)
Back to our
communication method and system, it is not dependent on any Service Provider,
be it a Cellular Network, or VPN, or IoT, or Cloud,
or Crypto, etc. It is working perfectly well with all the providers since the
carrier is out of the equation.
The Service
Provider may identify the famous Bob and Alice (often used in encryption as
fictional characters) and their encrypted exchange, but what they see is what
we see - a bunch of arbitrary numbers varying from 1 to 1 quintillion (in RI09
and RI18) and beyond (with the EI27 and EI36).
Some 80 of
these (if you transfer a 80-char-line like we do in
the Reference Implementations) or 640 of these arbitrary numbers (if you
transfer an average paragraph).
Only Bob and
Alice and no one else can actually make sense of all this bag of numbers. It
doesn't get more confidential than that. Confidentially
andconfidently saying "Hi,
Alice", receiving back confidentially
and confidently "Hi, Bob".
The strange
part of it is that we really have no idea what Bob and Alice are doing - we
don't even hold a record of their ENCRYPTED information (let alone the naked messages
which we never see). The Service provider or the carrier, though, may hold the
Encrypted information, along with THEIR (the Service Provider's that is)
metadata, like time of transmission, for example.
Says prof. Steve
Ward, CS in MIT: 'They are (Computers are) deterministic, which means that
if you ask the same question you will get the same answer every time. They do this by following rules and relying
on algorithms. That means it starts with a common 'seed' number and then
follows a pattern. They are what we call 'pseudo-random' numbers.' True
randomness requires nondeterminism and
rules-out predictability.
And he
continues that 'pseudo-random' numbers are 'perfectly acceptable where
there's no quantitative advantage in the degree of randomness.'
You
shouldn't be misled here with the scandal
years ago with a cryptography based on the Android Random-numbers generator at the time, which had a "back door" for reverse-engineering
the random sequences by hackers - that's something completely different.
The
'Pseudo-Random Numbers' we use, are passed though 2 pre-processing stages via our pre-processing
library, so even we cannot tell the original sequence of Random Numbers.
Let us
tell you one more thing, so your peace of mind is undisturbed - even the
long-gone Android Random-numbers generator with the back door mentioned above,
would do just fine for us due to our two
pre-processing phases.
On top of
that, your Service Provider certainly can use a "side" true
Random-numbers generator based on unpredictable processes (seismic,
atmospheric, electromagnetic, etc.) instead of being generated
deterministically by a computer.
As Von
Neumann himself said, 'Anyone who considers arithmetical methods of producing
random digits is, of course, in a state of sin.'