WO2023017292A1

WO2023017292A1 - Encryption system and method based on random numbers from 1 to 1 quintillion (10^18) with no key and no metadata

Info

Publication number: WO2023017292A1
Application number: PCT/IB2021/022207
Authority: WO
Inventors: Svetlozar PETKOV; Marina PETKOVA
Original assignee: Petkov Svetlozar; Petkova Marina
Priority date: 2021-08-10
Filing date: 2021-08-10
Publication date: 2023-02-16

Abstract

A method for encrypting input text exchanged between Sender and Receiver with no key and no metadata is presented. The method is based on an Initial List of N generated random integer numbers from 1 to 1 quintillion ( 10^ 18) each shared between the two participants. Sender computes a new List of N numbers based on the input text referred-to as naked text, Elastic-Stretching N consecutive characters of the naked text, converted to ASCII codes. Then Sender combines said Initial List and the Elastic-Stretched text into one List, by adding the two Lists together in a member plus member fashion, rather than concatenating them and sends the merged List through the wire. Receiver gets the Encrypted Message and subtracts said Initial List from it, un-stretches the message into ASCII-list, and converts that ASCII-list back to the naked text.

Description

The Space our method operates on is presented in FIG.1 - every column may contain numbers from 1 to 1 Quintillion ( 10 18). In FIG.2 you see three arbitrary Sequences of Random Integer Numbers - each of them can be one of our encodings, as we will see.

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 (see FIG.2), 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 Encryption Method is not static - we can generate 10s of completely-different encryptions per second for the Same Message on the same computer so that " 1 billion times better" is a big understatement indeed.

Process Flow:

The process Flow is presented in FIG.4.

In the beginning Both Sides (Sender and Receiver) start the app with the same Single Parameter as follows:

- They both accept the Global Default and start with no parameter;

- They use their own Personal Default from the previous communication;

- They communicate a New Starting Parameter, valid till the next time they exchange a New Parameter (via Hard Token, Soft Token, SMS, etc.) This exchange is presented in FIG.3 and on the top-line of Fig.4.

The second step in FIG.4 is getting a Random integer Number Sequence (RNS) of N numbers, where N is the number of characters to be transmitted in one cycle (N = 80 for the Reference Implementations). Optionally, BOTH sides may perform a manipulation of the sequence, converting it in another sequence of N numbers through the manipulation library we provide, say they Rotate it Right by 1 element, the first element of 80 becoming last. This is determined by the Starting Number X which is the SAME for both sides and is valid for ALL "Optional Manipulation" blocks which you will find in FIG.4. Throughout, the word "Optional" means "depending on the Starting Number X" which the same for both sides (Sender and Receiver). After this point of eventual Optional Manipulation of the selected RNS, all manipulations are REVERS ABLE, meaning the Receiver does the OPPOSITE manipulation, depending again on the Starting Number X.

The dependency varies in terms of the remainder of division of certain sequence of numbers, for example we can ship the software with a Manipulation Sequence MS = {3, 7, 17, 25} which would mean that the behavior will depend on X%3, X%7, X%17, and X%25, and periodically change it, for example to MS = { 11, 2, 7, 19}.

Till this point (the first 3 steps) the Sender and the Receiver make the same 3 Steps. From now on, each has additional 4 Steps to conclude its work.

So now the Sender can do its work separately from the Receiver - note that the Naked Message to be sent is YET to come (the original Message is the message on the Sender side, while naked message is equal to original, but for both Sender and Receiver sides). Neither the Sender nor the Receiver know what it is, at the moment.

The first step (independently of the Receiver) the Sender does, is to get the first chunk of the Message (the first line of <= 80 characters in the Reference Implementations RI09 and RI 18). If the chunk (line in the RI) is less than 80 chars, it gets padded with Spaces to 80 chars.

Next, the Sender converts every character of this line of 80 (the naked message line) to its ASCII code, followed by Elastic-Stretching to 1 Billion in the reference implementation RI09 and to 1 Quintillion in RI18. That is explained next.

Elastic Stretching:

How do you stretch the letter 'm' to 1 Quintillion? And then "un-stretch" this number back to letter 'm'?

You can use directly the ASCII message, but then every character will be between 32 and 128, which is in less than 100 interval and you lose this huge space from 1 to 1 Quintillion for nothing.

First let us have a look at Prior Art: Functional Stretching, and Algebra Stretching: Functional Stretching: f(x)=>g(x); f(x) fluctuates in the [0,1] interval, while g(x) is in the

[1, 10 18] interval.

Algebra Stretching: VERTICAL STRETCHES AND COMPRESSIONS

Given a function f(x), a new function g(x)=a*f(x), where a is a constant, is a vertical stretch or vertical compression of the function f(x). If a>l, then the graph will be stretched.

We claim Elastic ASCII Stretching where a point in 3-dimensional Space (the ASCII Code which has 3 digits) stretches its 3 components elastically, rather than multiplying them by the SAME number. The ASCII code of letter "m" is 109, stretching it by 1,000,000 will give us the value of 109,000,000 while the Elastic ASCII Stretching yields the number 049,048,057. Stretching it elastically to 1 Quintillion ( 10 18) would be 049,000,048,000,057,000 adding 000 after every ASCII member of the 3 - in our case of 'm' that is after 049, then after 048, and then after 057. What is achieved is a smooth stretch, rather than just shifting it up as in Algebra- Functional-Stretching which in our simple example of the ASCII code of the letter 'm' would yield 109,000,000,000,000,000 because 109 is the ASCII of 'm'.

Here we fill-in with 0's for easier reading but in the Reference Implementations we fill the "gaps" with Random Numbers again since we know the positions that matter (the ASCII numbers).

We go up to 1 undecillion (1,000,000,000,000,000,000,000,000,000,000,000,000), or 10^A36, but in these Experimental Implementations EI27 and EI36 we have to split the processing and the performance suffers, among other things. It may be useful for some applications, though, for example super-secret Data-in-Motion. Here is an example of such a big Random Integer Number:

Example: random. nextOct = 223,372,036,854,775,807,147,483,647

Back to the process Flow. We already have the Sender having: a) The Random Number Sequence of integers RNS b) The Elastic-Stretched ASCII naked message Independent Step #3 for him (#6 total) is to MERGE the RNS (set of 80 Random Numbers) with the Elastic-Stretched ASCII message (also 80 numbers from 1 to 1 Billion in RI09, or to 1 Quintillion in RI18).

Independent Step #4 for the Sender (#7 total) is to send the Merged line (all 80 numbers). In the reference Implementation SEND means writing to a file, which is later picked-up by a different Process (Receiver). Here by the word 'file', we refer to the Reference Implementations RI09 and RI18. Instead of file read by an external process, it can be ANY commination provider like Cellular, VPN, Wireless, SMS, etc.)

Now we continue with the main line for Receiver (Right-hand side of FIG.4).

If there is an Encrypted file (in the directory holding the Encrypted files in the RIs), the Receiver reads it in Independent Step #1 (#4 total for him).

Step #2 is to unmerge the RNS from the received encrypted file (he has the same RNS as the Sender, since it is in the common area). This simply means that he subtracts (if no manipulation function from our library is used) the RNS from the received set (two 80-numbers sets) in a member-by-member subtraction. The result is the Elastic-Stretched message.

Step #3 is for the Receiver is to un-stretch the message (via the reversed function).

The last Step #4 is to Convert the ASCII message into plain text and reach the naked message.

In FIG.5 and FIG.6 you see the sample transmission of the Shakespeare Romeo and Juliet - it is considered a benchmark in the encryption community. Here is the native message:

'What's in a name? That which we call a rose

By any other word would smell as sweet.'

Notice how different the two encryptions in FIG.5 AND FIG.6 are. Even just the first line of the Same Paragraph of Same document is so different in the 2 encryptions provided by the method. You can also wrap your existing Data-at-rest solution whatever it is, in our solution. FIG.7 presents wrapping of AES -encrypted data-at-rest for moving it safely around, undisturbed and untouched - see how it arrives at the point of decryption (bottom of FIG.7).

Similar wrapping of Bitcoin encryption in our method is presented in FIG.8.

FIG.9 presents the main potential applications of the Method (left column) and the main competing encryption methods at the moment (right column), although we can wrap each of them and convert them into Data-in-Motion so we actually cooperate rather compete.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG.1 The Space the method operates on

FIG.2 Three arbitrary Sequences of Random Integer Numbers in the Method Space

FIG.3 External Exchange of Starting Numbers

FIG.4 Process Flow

FIG.5 First Shakespeare encryption (Google)

FIG.6 Second Shakespeare encryption (Microsoft)

FIG.7 Wrapping of AES Encryption

FIG.8 Wrapping of Bitcoin Encryption

FIG.9 Encryption-related Applications and Methods

Claims

CLAIMS:

1. A method for encrypting input text exchanged between Sender and Receiver, based on an Initial List of N generated random integer numbers from 1 to 1 quintillion ( 10 18) each, the method comprising the steps of: a) Said Sender and said Receiver both get said Initial List of N Random Integer Numbers; b) Said Sender computes a new List of N numbers based on said input text referred-to as naked text, Elastic-Stretching N consecutive characters of the naked text converted to ASCII codes; c) Said Sender combines said Initial List and said Elastic-Stretched text into one List, by adding the two Lists together in a member plus member fashion, rather than concatenate them; d) Said Sender sends said one merged List called Encrypted Message through the wire; e) Said Receiver gets the Encrypted Message and subtracts said Initial List from it; f) Said Receiver un-stretches the Elastic-Stretched message into ASCII-list and converts the ASCII-list to said naked text.

2. A method according to claim 1 wherein said number N is the number of characters sent at once in a loop through the naked text, N being 80 in the Reference Implementations of the Method.

3. A method according to claim 1 wherein both said Sender and said Receiver start with the same number X as a Starting Parameter, exchanged in advance via Token, SMS, Text message, or other external means.

4. A method according to claim 1 wherein said Elastic-Stretching of said naked text converts every character's 3 -digit ASCII code into a 9-digit number or into an 18-digit number.

5. A method according to claim 4 wherein said Elastic-Stretching of said naked text converts every character's 3-digit ASCII code into a 9-digit by converting every one of the 3- digits ASCII code into ASCII code itself, resulting in 3 x 3 = 9 digits.

6. A method according to claim 4 wherein said Elastic-Stretching of said naked text converts every character's 3-digit ASCII code into a 18-digit by converting every one of the 3- digits ASCII code into ASCII code itself, then inserting '000' after each triplet of said ASCII numbers, resulting in 9 x 2 = 18 digits.

7. A method according to claim 1 wherein said Initial List of N generated random integer numbers, where each random number varies from 1 to 1 quintillion ( 10 18) each, which is more than 10 15 times bigger than the space used by the current methods encrypting the message on the spot, meaning the interval of operation remains between the printable characters, which is between 032 and 126.

8. A method according to claim 1 wherein said Sender adds the Initial List of N generated random integer numbers to the Elastic-Stretched message and sends the resulting list through the wire, where the word wire is used to present the transmission ways, varying from a flat file to Internet and beyond.

6

9. A method according to claim 6 wherein said Sender may insert any 3-digit arbitrary number between 0 and 999 with leading Os when necessary to reach 3 -digits, since these numbers are fillers rather than carrying useful information.

10. A method according to claim 6 wherein said Sender may insert any 3-digit numbers before or after the significant triplets of Elastic-Stretching to 9-digits to make it 18 digits.

11. A method according to claim 7 wherein said space of printable ASCII is expanded vertically to 10 3 for the current methods to be safely included in the current list of Claims, as the claimed space of expended printable ASCII is expanded beyond 10^A3 to 10^A36 in the Experiment Implementations.

12. A method according to claim 11 wherein said space of longest Keys is expanded from 32 bytes or 256 bits to 40 bytes for the current methods to be safely included in the current list of Claims, as the claimed space is expanded horizontally beyond 40 bytes to 80 in the Reference Implementations and to a paragraph of 640 in the Experiment Implementations.

13. A method according to claim 1 wherein said method is used in a way of 2-in-l wrapper of other encryptions like AES, Crypto-currency like Bitcoin and other Data-at-Rest previous encodings to enable the wrapper in said method to carry the Data-at-rest encryptions in a Data- in-Motion way, keeping the Data-at-Rest untouched and undisturbed.

7