CORAcsi introduces a new type of "Public Key"

Many might muse as to 'why would anyone want a million-bit encryption key'. The thought that AES, ECC or supersingular isogenies are more than enough is certainly prevalent in cyber security. Keeping an open mind and pushing the envelope often takes second seat to the financial rewards in the mainstream. Before diving into the new possibilities that CORAcsi's #PublicKeys, and #privatekeys empower, allow me to present this question:

Why not consider a 'probabilistic' approach that frees all stakeholders from new and unforeseen attack vectors or technologies, such as quantum computers?

If you have read other articles on our #QuantumSafe #encryption, then you already know that #CORAcsi calls these huge encryption keys #MUPs, and acronym for Multiple Use Pads. Sure, these MUPs are just reusable #OTPs, and might just as well be referred to as #Vigenère 3.0, however, there is so much more to these probabilistic encryption keys, which is the reason for today's article. CORAcsi proposes a minimum size of 1 million bits, however, each MUP can and should vary in size. For simplicity this article will consider Public keys having a random size between 150 kB (1.2 million bits) and 1 MB (8 million bits).

What you need to know about CORAfication (encryption using #CORA's MUPs) before embracing our Public/private keys is:

1. There are 3 basic control structures built into an encryption cycle besides the MUP, they are the mupHeader, the msa (Mup Support Array) and the primary normalization vector (i.e., an AES key, or RSA key, or other normalization control structure).
2. A single corrupted or missing byte in the MUP or control structures will render the solution completely unusable. Hence each of these 4 structures must be complete and 'properly sequenced' (order matters).
3. A CORA Public key houses all 4 of these structures. The cumulative size of the mupHeader, msa and normalization vector currently varies between 1 kB and 20 kB.

With this in mind, a single Public key of 150 kB will support billions of private keys. Unlike other public key methodologies in which a single public key matches a single private key, CORAcsi's Public key involves a randomly selected number of bytes taken from the public key, which then results in a unique MUP, mupHeader, msa and normalization vector.

Consider a random selection of 1,000 - 20,000 bytes that are removed to form the control structures for CORA. The remaining bytes form the MUP. Hence every private key will result in a different MUP.

• The number of permutations without repetition using a minimal public key of 150 kB and a private key of 5 kB exceeds 10^25,843.
• The number of permutations for a 1 MB public key and 20 kB private key exceeds 10^119,912.

If desired, a unique public-private key combination may both encrypt and decrypt messages. In this sense the term private key refers to a key combination that two users share to enable secure, 'two-way' communication.

If desired, a 'one-way' encryption / decryption may be used by implementing an RSA key pair as the normalization vector. The advantage here is that due to the probabilistic nature of CORA, this RSA key pair may be long lasting. CORA removes the need for ephemeral RSA key pairs.

At this time, SSL or TLS may be used alone, or in conjunction with a separate Diffie-Hellman key exchange, to communicate the randomization vector that will generate the private key. For example:

1. A unique Public key is available from a website - any trusted authority could host these services, however, allow me to use one of our websites as an example, namely CloudCORA.com.
2. A registered user would connect to CloudCORA.com and request a private key.
3. CloudCORA.com would generate a random sequence of bytes (randomization vector) which would then be shared securely with the user.
4. The randomization vector is used by the client to generate a unique MUP, mupHeader, msa and normalizing vector at the client.
5. This client is now capable of securely encrypting data with one-way, or two-way communication.

It should be noted that if 'one-way' is not selected, then this client may readily encrypt/decrypt files locally, comfortable in the knowledge that the public key is available should the local, private key be corrupted.

Finally, allow me to return to my original question about probabilistic encryption. How and why does probabilistic encryption free stakeholders from unforeseen attacks and technologies?

The bottom line is that with probabilistic encryption, the only attack is a brute force attack, and at one million (and more) bits, there isn't enough time throughout the age of our universe to reliably and consistently break such an encryption key.