Hackers break into big-business computer systems for one of 2 reasons mainly, rarely both:
- to steal the information from your systems and/or (mis)use it;
- to destroy your information without regard for content.
We address only the former, rather than the latter like DoS (Denial of Service) or
BaD (Break and Destroy) - you have to take care of your infrastructure without us.
Below we shortly address the fight against stealing - encrypting that is.
In the table, we present a few examples of Application and the Encryptions the these application use.
Several years ago Mr. Schneier (one of the respected members of
the Cryptographic community) made a survey listing more than 500 crypto-products from
more than 50 countries outside USA itself
so obviously we cannot put everyone in the table below, but here it is nevertheless:
Virtually all the methods use a static crunching and
scrambling 'on the spot', to an extend that the word 'encryption' is used as an aternative
for 'cruching and scambling' in this tiny little space.
This is not what we do.
First, our method is not static to begin with.
It is actually the MOST important thing about our encryption method - it constantly changes,
could be on the next line, or next paragraph, or next document, or next day, or next week ...
it all depends on the Sender and Receiver - we don't even see any of that.
You may think that all the burden would be on the Sender and the Receiver, who have to be Technically-savvy.
Nothing can be further from the truth, actually.
Let's say that the famous Bob and Alice have to exchange the following
'important' sequence, initiated by Bob:
'Hi, Alice' and she replies 'Hi, Bob'.
BOTH of them see nothing that actually goes into cyberspace, or happens
'under the hood' - they are just oblivious to all that.
The notion of semantic security is 50-years-old already, and in layman terms it means (Wikipedia, the
symmetric-key algorithms) that an adversary must not be able to compute any
information about a plaintext from its cipher text (we use the common term
naked text instead of plaintext throughout this site).
A more realistic term is BFRI or Brute-Force-Resistance
Index. It is a bit down from "not be able to compute any information
about a plaintext" but still realistically measures the strength of a
specific encryption.
Let's have a look again on the AES encryption wrapped
into our encryption:
Let us start with the fact that there is nothing in the CURRENT version that has anything to do with any of that.
Our parrent company though, has consultants with deep background in Big Data, Kafka, Spark, Flink, FlinkCEP, Scala, etc.
so naturally they pushed towards this field in the beninning.
At certain point we had versions where even the number of partitions
carried encryption information, which was furthered via the internal Kafka Streams re-partitioning and so on.
Let us say that you do not care about your Service Provider to deliver real
Random Numers for you to use, but you are OK with the Random Numers your Computer would deliver
upon invoking random.nextInt or random.nextOct like this:
Naturally to use the Space, a HashMap would do the mapping between the chars and the numbers
(no synchronisation needed, so you don't use HashTable):
HashMap( "a" -> 327917583, "b" -> 946154739), and x("a") = 327917583.
You will have to change it in a loop with the next Random Number, or use map(random.nextInt),
for example.
Better yet, you can shove this inside the HashMap like this:
HashMap( "a" -> random.nextInt, "b" -> random.nextInt)
and achieve the goal with no loop and no map(random.nextInt).
Result would be HashMap(a -> 1186740878, b -> 1020167837), next time it would be HashMap(a -> 231995163, b -> 382398110),
etc. That's one of the beauties of Functional Programming - functions are like Integers or any other object and they can
be shoved in any "hole". Looks good.
Problem is that ANY time you have a repeat symbol, it will encrypt to the SAME number.
Our "aaaaaaaaaa..." message will look like this:
Pretty ungly, right? Looks like Cesar Encryption from more than 2,000 years ago. It would take a hacker a couple of
minutes to try a, then b, then c, etc. and crack it open. True, next time your computer will generate totally-different numbers,
but chances are that hacker's computer is faster, so he will catch-up. And it is safe to assume that he is smarter than you, too.
BUT - this is NOT the bad news.
The bad news is that every time you have to TRANSFER the NEW HashMap as a separate message, or via metadata, or
somehow, and you have to do it EVERY TIME you go through the HashMap. It could be every LINE as we do it, for example.
But if you have such an EXTERNAL-SIDE-CHANNEL to transmit the HashMaps generated,
why don't you use this channel to simply tell Her whatever you want to tell Her? No encryption, Ma! Simple - lucky you!
Now you know that it is not that easy. This is why we have NO metadata and NO Key.
THAT is the Key :-)
Again Apple's CEO Tim Cook: 'If you put a key under the mat for the cops, a burglar can find it, too.'
You remember our friend's "Is this real?" question above. In fact, it was a little longer than that:
"Is this real? Can't you fake it?"
Of course you can - you can fake almost everything with computers. Here is the "Entire System"
in a single function:
def CyberFakeConfidential( m: String) : Unit = {
val r = scala.util.Random
val x = List.fill(80)(1000000000).map(r.nextInt)
println("\nREAD : " + m)
println("\nSend : " + x)
println("\nRecv : " + m)
}
You can produce almost everything on this website with this CyberFakeConfidential funcion, in fact.
So... what is the difference between CyberFakeConfidential and the real CyberConfidential?
It actually is as simple as the difference between 1 and 2. The CyberFakeConfidential runs in 1 JVM,
while the real CyberConfidential runs in 2 JVMs, the second one could be across the Ocean on another continent
using your Cellular Network, or your WiFi, or VPN etc. even your FTP like FileZilla for example, since x can
be written into a simple TXT file on your hard-drive, as we do. The thing is that the 2nd JVM is a SEPARATE PROCESS.
All the Cyber Communication does is just a File Transfer
between points P1 and P2 via some media, be it Celular, or WiFi, or VPN, or FTP, eMAIL, SMS, etc. The IMPORTANT THING is the encryption. In fact,
encryption is THE ONLY IMPORTANT THING,
the rest is just a File Transfer, P1 and P2 being on the same network or on different networks.
Most of our communication actually doesn't need encryption, though - "Hi, mom", for example.
But "Hi, mom - you can already use my account #1234567895... with Online Passord=MyOnlinePass..." probably does.
Now, when 2nd JVM is involved, you have to send something on the "other side" too, ether m ot x ... If you send m, it is the naked message; if you send x instead,
it is Encrypted. If you send x on the "other side", it has to be decrypted and the last line of code would look like:
println("\nRecv : " + decrypt(x) )
Do it first in 1 JVM, then in 2 JVMs as separate processes, storing x in a text file, read by
the second JVM. Want to think about it? OK.
1. Can you make 'End-point
1 == End-point 2' and what can you use it for?
2. Can you send the "bag-of-numbers" to someone that doesn't suspect anything since he
is not a part of the conversation?
Well, on the first question ... it doesn't make much sense
to send to yourself an encrypted message, when you already have to naked one!
This was the case till very-very
recently - we are talking about the Second Half of 2021!
What happened then? Well, you can read it read it here:
You actually do not need the API per-se, since you are not
building anything.
You or your Service Provider just need THE SPACE where you
can store your ENCRYPTED files, just as we do in our Reference Implementations,
so that another process (End-point 2 that is) can access it. Simple...
No Keys, no Metadata
in there, as you already know.
So ... what's the big deal and how you can use it, you
ask...
You can make 'End-point
1 == End-point 2' and use Google
Workspace as a storage of your encrypted files. If you are a BIG BUSINESS,
you would know the value. You encrypt, you decrypt.
GMail has 1.5 billion subscribers
and WE are there too. But as anybody else would know, our communications through GMail is not truly-private and that's OK for things that
for one reason or another don't need us
to encrypt them. OTHRWISE you or your Service Provider can use Google Workspace instead of GMail.
Yes, they are BOTH
Google.
Nothing against Google actually - just imagine that Google
doesn't exist for ONE DAY only.
Can you feel it?
On the second question - yes, you can, but ... he will see
what we see and what you suspect - the 'bag-of-random
big numbers'.
Last note, related to "it is either Google Workspace or Google Mail" - we don't
get paid a red cent for saying that, it is just our opinion. You are not going
to also see any video of people dancing around in dismay :-)
It is just an OLD-WAY website about the
NEW-WAY of Cyber Security.