Here is how
we approach the problem of Cyber Security and Encryption - both of which are
ranked the #1 concern of the 3rd decade
of this century. That is till 2030 and probably beyond.
Just a couple of CEOs quotes, which we will address later:
Microsoft's S.Nadella:
There is a big crisis right now for cybersecurity.
Apple's T.Cook: If you put a key under the mat for the cops, a burglar can find it, too.
1. Space:
A bit is a
bit - it has values of 0, 1, and... That's it. Zero or one. You can crunch it,
scramble it, twist it, move it around, change places with other bits, XOR it with other bits, etc., but
it remains holding 2 values only. That's the nuts and bolts of it.
That's not
much space - even if you get a Random Number on it, anybody will have 50%
chance to guess it.
That's why
we went to the other extreme, blowing the Cyberspace to 1 quintillion in the
Reference Implementations RI09 and RI19, and beyond with our Experimental Implementations
EI27 and EI36, dealing with random numbers from 1 to 10^27 for EI27 and from 1
to 10^36 for EI36 (the symbol '^' is used in mathematics and Computer Science to
represent an exponent).
There are many encryptions
of ours on the website, including Shakespeare, SOAPs,
repeat messages, AES wrappers, Bitcoin wrappers, etc. so you will see how we handle
different situations.
Metadata has
two noticeable properties, which you have to keep in mind if you plan to mess
around the encryption challenges:
- It is with
legal protection next to none, and
- It is very
hard to encrypt properly.
That is why we don't have any.
None
whatsoever is carried by the Sequence of numbers - it is a pure message mixed with zero metadata.
However, you CAN use our method to properly encrypt YOUR metadata, provoded that
you expect it to move-aroud as MONOLITHIC TEXT BLOCK, rather than metadata. You
can see various examples of these under the 'Specifics' menu, inluding wrappers
around AES, Bitcoin, ect.
Keys (be it
Encryption keys, SSL keys, etc.) ... also none, so nothing to exchange but the message between the endpoints. The
endpoints are responsible for holding the actual message in naked form, because
only they have access to it - nobody else.
We included.
Encryption
key management or Encryption key insurance or Encryption key protection etc. reminds
us of Golf Tee Insurance against
breaking your tee at the tee-box while driving.
Doesn't make
much sense if you are not a Golfer :-)
We or your
Service provider for that matter, can only see and/or record the bag of arbitrary numbers - for us it
would be only a burden, a ballast that we can make no sense of, anyway.
Middle-points
are the data-in-motion vulnerability points. The more Mid-Points you have on
the way of the exchange, the worse it gets in terms of these Mid-Points being
able to acquire important information like Encryption Keys, SSL Keys, Metadata,
Passwords, etc. by either stealing it or buying it.
That's why
we have NO KEYS of any kind, and NO METADATA of any kind so we do not
care about Mid-points. The bag of arbitrary numbers you and we see, is 100%
pure user content.
That's why
Endpoint-to-Endpoint is the future in
Cyber Communication, anyway.
Data-at-rest
is a different beast altogether - then we have to preserve what the Endpoints
have, so ... we don't, since our mission is Data-in-Motion.
Actually,
Data-at-rest is something that we provide a perfect solution for if you are an Endpoint, since you already
have all the ingredients, and can choose what to persist and in what format.
There is a simple DB which you can keep locally.
You can also
wrap your existing Data-at-rest solution whatever it is, in Cyber Confidential solution.
Please go to the "Embedded" from the 'Details' menu to see wrapping
AES-encrypted data-at-rest for moving it safely around, undisturbed and
untouched.
That's conversion of Data-at-rest into
Data-in-Motion without any intrusion
The BFRI
(Brute-Force-Resistance-Index) is a very important measure in Encryption. It measures
what the name says - the Resistance against the attempts to crack-open the encrypted
material and generate/reach (trying every possible combination) the plausible naked
(original) content.
We claim a
BFRI which is more than 1 billion times better than the best BFRI reported so
far, but this is only for static
32-bytes-long data (256 bits) at a time and for statistical purposes only,
so the statisticians can compare apples with apples.
Our method
is not static - that's actually the real beauty of it. We can generate 10s of
completely-different encryptions per second so that "1 billion times
better" is just like a kid's toy, really.
But ... let
it be "1 billion times better" than the field.
We know you
are smart enough, since you are already here reading these thoughts.
But if you
are super-super-smart, and super-super-fast, equipped with your super-super-computers so you manage to
crack-open the message that has billions and billions of years of BFRI
(Brute-Force-Resistance Index), we have some bad news for you.
A second
after you are done with your gig out-there and getting ready to celebrate, it
would be something completely different for the SAME message handled on the SAME
laptop, so it will make you feel like Sisyphus going back to Square One.
......... Enjoy the walk through the website .........