Elastic Encryption: AI Empowered Cryptology

Abstract: Artificial Intelligence will associate a ciphertext with a set of plausible plaintext message candidates for the one message used to generate it. This emerging capability suggests a new paradigm for cryptology. The prevailing rigid (brittle) paradigm where the protected secret is either compromised or not, may be replaced with "elastic cryptology" focused on contextual entropy. Elastic ciphertexts strive to keep the message entropy registered by their unintended viewer as high as possible, up to the a-priori entropy before awareness of the ciphertext, while elastic cryptanalysis strives to crash this context entropy as close to zero as possible. Asymptotically elastic cryptology converges to the prevailing rigid cryptology. Elastic cryptology shifts power to the transmitter who can keep a threshold entropy that will withstand an omnipotent cryptanalyst. Elastic cryptography is realized through pattern devoid cryptography where security is projected via lavish use of randomness, instead of ever more complex mathematical challenges.  Prospective consequences may deserve preparatory foresight.

1.0 Introduction

The prevailing ciphertexts are "rigid" and "brittle". They hold in tact like a solid block of ceramics, but crack into crumbling pieces when hit by a strong enough hammer -- the tools used by the cryptanalyst. Introducing an alternative image: an elastic contrivance that yields to pressure, gets deformed, but does not split into smithereens: elastic cryptology.

The foundational notion of elastic cryptology is contextual entropy. This concept arises from the realization that cryptology is not happening in a vacuum. Admittedly in an academic setting one will be challenged to cryptanalyze a given ciphertext, having no situational knowledge as to the circumstances in which this ciphertext has been written.  This sterile academic attitude was prominent throughout the history of cryptology. In practice though, a ciphertext of interest is written in an adversarial, or at least competitive, or trust-lacking, or say privacy-guarding situation where the writer is trying to prevent an unintended reader from learning the contents of the concealed message. The writer, the intended reader, and the eavesdropper are all players in a given theater, and hence the message which the ciphertext is protecting is reflective of that theater. The theater is associated with some π plausible messages, each of which could have reasonably been the one which the ciphertext conceals.

A ciphertext C comprising c bits can be associated with b = 2c concealed messages if all bit strings are allowed. Given 96 printable characters in ASCII the number of concealed messages comprising printable characters would be. p = (96)c/8 . This count goes dramatically down when restricting to the 200,000 words in the dictionary, and further down (θ ) when we require a sensible text.

Further reduction from θ is contextual. (When one encrypts an investment advice it can be "buy", "sell" or "hold". It is not going to be "cook", "paint", nor "mold"). There are π plausible messages associated with a given contextual, situation (theater). We begin with the common case where the context, the situation, is known to both the ciphertext writer and to the aspiring ciphertext breaker. Their lists for the π plausible messages will be very similar.

And as of recent advancement in artificial intelligence, a valid credible π list (list of plausible messages that could have been the one hidden in a given ciphertext -- the proper message), can be generated automatically. And hence if we find a way to do cryptology driven by the π-list then it could be done fully automatically.

Let the π list be: P1, P2, ..... Pπ. The ciphertext writer knows that they constructed the ciphertext to conceal message Pw. where w is a value from 1 to π. So when the ciphertext writer evaluates the contextual entropy of the concealed message they conclude: Hw = 0. The intended reader equipped with the decryption key will also identify Pw as the concealed ciphertext and for them also the contextual entropy will be zero, Hr = 0.

The theater invariably includes a foe, (F), who reads the situation and compiles the π-list. Once the foe becomes aware that a ciphertext was sent from its writer to its intended reader, the foe, expressing their understanding of the situation would assign π probability measures to their π-list. This will associate the foe with a contextual entropy of:

Hf = -Σ pi * log2(pi)

Where pi is the foe's appraised probability for plausible message Pi where i= 1,2,....π.

We may assign this entropy to be the a-priori entropy, or Ha.

Since ciphertext C has been released in the open on its way to the intended reader, it is fair to assume that the foe gets a hold of it. Applying cryptanalysis to the ciphertext C, the foe will conclude that the probabilities have changed from pi to p'i for i=1,2,....π. And their contextual entropy would compute to be:

H'f = -Σ p'i * log2(p'i)

We regard H'f as the posteriori entropy: Hp = H'f 

If the cipher used to write the ciphertext C is the common "rigid" or "brittle" type then the foe has either cracked the ciphertext and extracted Pw or has failed to do so. The former case corresponds to Hp = 0, and the latter to Hp = Ha. There is no other option.

This binary choice over the span from Hp = 0 to Hp = Ha, when subject to Innovation Solution Protocol [14, 15 ] points to a nuanced outcome where the posterior entropy assumes any value between these two extremes:

0 ≤ Hp ≤ Ha

Any drop of the posterior entropy will be to the advantage of the foe, and to the disadvantage of the writer.

Since rigid or brittle cryptography is limited to the binary choice, one is motivated to look for a different paradigm to redefine cryptology as a battle between code writers who wish to keep the contextual entropy for the foe as high as possible, and the code breaker who strives for the opposite: to lower their posterior entropy. A compliant cryptography will be regarded as "elastic" to contrast it with the prevailing rigid or brittle paradigm.

1.2 The Vernam Angle

The Vernam cipher has been claiming its place as the ultimate cipher that cannot be cracked even by an omnipotent cryptanalyst.  Vernam does it by associating its ciphertext with every possible plaintext string of same length.  The idea of the here presented elastic cipher emerged from the realization that Vernam is an overkill.  It offers the same utility as a ciphertext that is pointing only to the plausible ciphertexts of the case in point.  This plausible list is much smaller than the Vernam range, and hence it can be accomplished without the inconvenience of Vernam.

2.0 Elastic Cryptography

A rigid ciphertext is committed to its generating plaintext. This commitment is the fundamental reason for the breakability of mainstay encryption. It is also the cause of its rigidity. To evolve into elasticity, it is required for the ciphertext to carry information about more than the concealed message itself. It must be related to at least one more plausible message.

With elasticity in mind, the one step below total failure for the code writer is the step where along with the concealed message, the attacker (the foe) ends up with one other message that could be the encrypted message. (equivocation). This will happen if the attacker identifies a key K that would decrypt C to plausible plaintext message P and in parallel they identify a key K' that  decrypts C to plausible plaintext message P'.

{C, K} → P; {C,K'} → P'; where K ≠ K' and P ≠ P'

In that case the posteriori entropy will be:

Hp = -(0.5log(0.5+0.5log(0.5) = 1.

For π=10 we have a-priori entropy:

𝐻a = − ( 10 × 0.1 × − 3.3219 ) = 3.3219

So while in a 'total cracking' the contextual entropy is crashed from 3.3219 to 0, in the least effective elastic case the drop on entropy is smaller: from 3.3219 to 1.

If somehow the writer manages to deceive the attacker to equivocate over 3 or more plausible  messages, then the loss or damage to the writer will be smaller. In the best case for the writer the attacker will end up regarding all π messages as candidates, which will leave the posteriori entropy at the a-priori levels. This case is equivalent for the rigid cipher not yielding to its attacker.

One is now guided to define elastic encryption efficacy, Eff as follows:

Eff = 1 - (Ha - Hp )/ Ha 

Eff=1 for Ha = Hp and Eff = 0 for Hp = 0.

Accordingly, for the case above with π=10 we have:

Eff = 1 - (Ha - Hp )/ Ha = 1 - 2.3219/3.3219 = 0.30.

In order for the ciphertext C to impress upon the attacker who extracted the concealed message Pw that a decoy message Pd is of equal probability relative to Pw, C has to include decoy parts that would be indistinguishable from the parts that point to Pw. We are looking then to a way to add misleading bits to C. Clearly though, it would be required that the intended reader, U, will be able to disregard the decoy bits and extract Pw without confusion. This analysis leads to an innovative target we call decoy tolerant ciphers, DTC. Ciphers where the nominal ciphertext is mixed with decoy parts by the writer, and these parts are identified by the intended reader, and disregarded.  In other words, the nominal or proper ciphertext comprising of content-bearing bits is to be mixed with "noise" content-devoid bits in such a way that a key holder can distinguish between these two categories.

2.1 Decoy Tolerant Ciphers.

We simplify the challenge to the case where the ciphertext C is a thread of pointing signs s1, s2, ..sq; each pointing to a section of the corresponding plaintext message Pw: m1, m2, .... so that

C = s1 || s2 || ... || sq 

and the pre-encrypted message Pw is:

Pw = m1 || m2 || ... || mq 

and where si → mi for i=1,2,...q

In the nominal paradigm the reader uses a key K to generate mi from si. Instead, one can make an exhaustive list of so called "building bricks" b1, b2, ..... bl, such that any possible plaintext message Pw could be built through a sequence of the l building bricks. A simple way to do so is through the 96 printable characters in ASCII, but many other lists of "bricks" will do. One can add to the ASCII printable characters, a list of common words in the English language: (the, be, and, of, in, to, have, it, that), and even a list of common phrases.

Given an arbitrary Pw message, it can be divided to q bricks. We use some rules (and a shared key) to generate pointers to each brick, a pointer being a randomized string of an arbitrary size. We can then string the pointers (concatenate them) to a pointers' sequence which we regard as the ciphertext C.

The ciphertext C is passed on to the intended reader, U. We set the ciphertext  C such that the intended reader can parcel C to the individual constituent pointers s1, s2, ... sq. This parceling out information may be an agreed upon procedure between the writer and the reader or it may be information that is extracted from C itself.

Once C is parceled out to the sequence of pointers, the reader takes each pointer one by one, and examines the plaintext bricks to find the brick pointed to by that pointer.

Here comes the fundamental idea: the reader activates a shared test procedure T that examines a given pointer versus a given brick, it results with T=1 if the pointer points to the examined brick. The test T results in T=0 otherwise.

For any given pointer s there are three possibilities: 1. T=0 for all bricks 2. T=1 for one and only one brick 3. T=1 to two or more bricks

Options 1 and 3 will result in discarding the pointer. Option 2 will be used to pick the pointed brick. We call it the pointing test.

The ciphertext writer constructing the pointers from the bricks will have to test each selected pointer, as above, and refrain from using it if the pointer fits to options 1 or 3.

When done the writer will write C as a sequence of q pointers. C will be passed to the reader, who will dissect it to the q pointers, then apply the test T on each pointer, this will point to the right brick to be put next to the former brick, and so brick by brick the plaintext will be constructed.

So constructed the writer could now inject d "decoy sections" between the q sections of the ciphertext: D1, D2, ..... Dd, resulting in an inflated ciphertext G, comprising c+d sections.  A decoy section is  a section that evaluates to either option 1 or option 3 in the pointing test. The reader will discard all the decoy sections because they fail the pointing test, and will evaluate the pre-decoy ciphertext C as Pw. An attacker not holding the key with which to conduct the T test will have to regard each section (assuming the attacker knows how to divide the inflated ciphertext to sections), as perhaps bona-fide and perhaps decoy, unable to resolve this dilemma, certainly not by hammering and analyzing the inflated ciphertext because the distinction is made through the key which is not written into the ciphertext.

We have now defined a decoy tolerant cipher, our choice tool to construct elastic encryption.

2.1.1 Plaintext Bricks

A plaintext message may be viewed as (i) a sequence of bits, (ii) a sequence of letters, (iii) a sequence of words, (iv) a sequence of phrases, etc. And also as combination thereto. For example:

M = "This bit string 01101101 is a secret code"

Can be viewed as a sequence of 34 characters:

T h i s b i t s t r i n g 0 1 1 0 1 1 0 1 i s a s e c r e t c o d e

where each of these characters will be regarded as a "brick" where each brick will be pointed to by a corresponding pointing sign in the ciphertext.

While it is necessary to regard all printable ASCII characters as bricks to that any plaintext can be bricks-expressed, it is cryptographically useful to add randomization to the encryption process. This can be done by adding say common words in the language as stand alone bricks.

"This" "bit" s t r i n g 0 1 1 0 1 1 0 1 "i s" a s e c r e t "c o d e"

The parties may agree that the words "This", "bit", "is" and "code" are bricks on their own and will be pointed to by a respective pointing sign in the ciphertext. Now the message is comprising 26 bricks, 22 characters and 4 words.

The phrase "a secret code" could be defined as a brick so the message is written as:

"This" "bit" s t r i n g 0 1 1 0 1 1 0 1 "is" a "secret code"

comprising 15 characters, 3 words, and 1 phrase, 19 bricks altogether.

2.1.1.1 Brick Count Consideration

The list of bricks may be viewed as a dedicated encryption language. The list must be comprehensive enough to support any possible plaintext message.  We have discussed above enlarged lists including words and phrases on top of letters and printable characters.  This creates duplication (e.g.: the word 'the' can be a brick word, or a sequence of three letter bricks) aimed at increasing the confusion facing the cryptanalyst.  However under different considerations the list of bricks can be limited to 2t letters. Base64 interprets any bit string as a sequence of bricks where each brick is a t=6 ordered bits.  The value of t can be higher or lower --great flexibility. In fact the binary language: brick 1 = '0' and brick 2 = '1' is a valid brick list.

The list of bricks may be the same for all the plausible messages, or different.

3.0 Construction

Discussing three construction strategies for elastic ciphers: (i) explicit construction , (ii) Implicit construction, (iii) hybrid construction.

The first is a method whereby elasticity is built in by constructing a ciphertext as a composite of two or more ciphertexts which each points to a different plaintext. The second is where decoy bits are added such that the probability for elasticity will be sufficiently high. The third strategy is a combination of the first two.

3.1 Explicit Construction

Explicit construction strategy calls for constructing a composite ciphertext, CC that includes different ciphertexts C1, C2, ... Ct, such that when a reader is processing CC with key Ki, they discard all the parts of CC that are not Ci, and then decrypt Ci to its corresponding plaintext Pi. In other words, CC is constructed to yield to an omnipotent cryptanalyst the above listed t plaintexts, each associated with a non-zero entropy that cannot be further improved (decreased). To the extent that t → π, CC → Perfection (mathematical secrecy, Vernam grade): Eff → 1. To the extent that t/π → 0, EFF → 0.

A sub-omnipotent cryptanalyst may find only t' < t plaintexts in CC and while they can write an explicit entropy formula over these t' messages, they are not sure whether the proper message has escaped their attention.

To carry out this explicit construction it is necessary to identify the π plausible plaintexts or a subset thereto. The aspiring identifier of these plausible plaintext messages must be well aware of the context, the situation giving rise to the ciphertext. One assigned to prepare and send off the ciphertext will not necessarily be learned about the context, and unable to identify plausible messages. In this case one runs the risk that the transmitter preparing the composite cipher text will identify non-plausible messages p*1, p*2, ..... p*r as plausible, and apply the Elastic cipher procedure to them next to plaintext Pw -- the true (proper) plaintext. A context-aware cryptanalyst will not guess the r non plausible messages and is likely not to flash them. But if they do flash them out they will be discarded because they are not included in the π-list. The cryptanalyst will then conclude that Pw -- which is plausible by definition is the communicated plaintext and defeat the elastic cipher. This shows that for the elastic encryption to work it is necessary for the transmitter to identify the proper plausible messages (the proper π-list).

To ensure proper identification of the plausible set at the transmitter edge, the transmission must involve a context-aware individual or team. This requirement severely limits the usability of elastic encryption. However recent development in artificial intelligence points out to applying AI to elastic encryption at the explicit mode.

3.1.1 Human Selection of the π list

It is a safe assumption that somewhere in the code transmission team there is an individual who is aware of the context and is in a position to pick up good decoy plausible messages. This is especially easy if the individual who manages the situation where the encryption is called for is weighting among two or more options for the next step. Selecting one such option will determine the actual message Pw, while the other considered moves will determine high probability decoy messages.

3.1.2. AI empowered elastic encryption

Public AI capability today allows one to describe an encryption-demanding situation (EDS) and extract an AI-compiled answer to the question of what is the likely content of a secret message delivered from one party to the other, and further extract a specified number of likely messages. These messages are AI-generated set of plausible messages, the π-list.

Given that the π-list is not necessarily a secret, there is no issue with consulting cloud-based AI. In more sensitive questions the context is under the 'fog of war' and one is reluctant to generate the π-list in the open.

Heavy duty elastic encryption users will install an on-board AI capability that would be tailor-trained to generate high quality π-list.

The main point of AI generated π-list is that it is automatic. The human operator will fill in a form that describes the critical parameters of the context, the situation, and the π-list will be generated automatically.

AI-generated plausible scenarios represent a semantic level scenario. There are multitude of literal messages that would all converge to reflect the same semantic message. Since encryption is processing literal messages, this gives the code writer a big advantage. It is easy to choose a literal message to represent a semantic message, it is infeasible to accurately guess (for the cryptanalyst) which literal message the code writer chose to represent a given semantic message.

Illustration: The following literal messages

  1. Joe and his wife jill are going to rob the bank tomorrow morning 

2. Jill and her husband plan to steal money from the bank before noon tomorrow 

3. The bank will be broken in tomorrow before lunch time, Joe and his wife will carry it out. 

are literally different but semantically equivalent.

Elastic encryption will be useful even if it is built from only two plausible messages regardless of their a-priori probability. However elastic cryptology is a new battlefield in which the binary range: cracked-or-not-cracked (per ciphertext) is replaced with the elastic measure of the gap between the a-priori and posteriorly context entropies. To improve its stance, cryptography will need to smartly choose the most plausible  decoy messages.

Illustration: if the code writer builds the composite text from the right message Pw for which the likelihood to be the encrypted message is pw = 75%, and a decoy message Pd for which the corresponding likelihood is 5%, then pw/pd = 75/5 = 15. An omnipotent cryptanalyst will conclude that  the composite ciphertext includes only two messages,  pw and pd  and hence appraise: pw + pd = 100%, and given the probability ratio (which has no reason to change), the cryptanalyst will end up with posteriori entropy Hp based on pw = 75*(100/80) = 94% and pd = 6%, computing to Hp = − [ 0.94 log 0.94 + 0.06 log 0.06 ] = 0.327

Had the code writer selected a decoy for which pd = 25%, then the corresponding entropy would have been:

H'p = − [ 0.75 log 0.75 + 0.25 log  0.25 ] = 0.811

A much higher entropy. H'/H = 2.5

For the code writer adding any decoy to the composite ciphertext is an effort, so they try to select the decoys with the highest probabilities to ensure the cryptanalyst faces a large as possible posteriori entropy.

Over time a dedicated AI system will improve its probability assessments for the π-list. The AI activator will instruct the AI to identify an arbitrary number t of plausible messages P1, P2, .... Pt such that. Σ pi over i=1,2,..t will be maximum.

In many practical cases a plausible message will incorporate a large number of factors, ending up with a very large number of plausible messages. In that case the AI will be tasked to group the scenarios to reduce their count and to increase the likelihood rating of each integrated option -- all to help the code writer build up a high as possible posterior entropy.

3.1.2.1 AI Plausible List Generator

An AI engine specifically engineered to generate the π-list may be comprised of:

 1. cloud level AI 

2. Case Tailored AI 

3. Human Dialogue AI 

The cloud level AI will use public domain relevant and semi relevant information to develop the π list. The case-tailored AI is an AI engine developed specifically for the type of circumstances that reflect the case in point. This is likely to be a proprietary engine, and it may work independently or on top of the cloud based version. The AI engine can further be programmed to ask pointed questions directed at  a human actor and build the π list accordingly.

3.2 Implicit Construction

Given a long enough random bit string, and given the ability to slice off this string to arbitrary slices, the remaining string (where the edges of the slices are attached next to each other) will eventually be equal to any arbitrary string.

Ilustration: the target string m='MESSAGE' can be carved from a random string r:

r = NJNGMMMESHHGSYTTAAHYUGYHHBVFDEKLLLOIIUNHJ

as seen ahead:

r = NJNG M MM E S HHG S YTT A AHYU G YHHBVFD E KLLLOIIUNHJ

This attribute of randomness motivates an elastic transmitter to mix a proper ciphertext with sufficient decoy bits so that an omnipotent cryptanalyst will find in the bit stream two or more plausible messages, and remained locked into a non-zero entropy. The advantage here is that the transmitter needs not worry about identifying the π list. The disadvantage is that one is never sure if the decoy volume is sufficient while in the explicit mode the transmitter knows how many plausible messages are pointed to by the transmitted ciphertext.

3.3 Hybrid Construction.  

A transmitter may build a composite ciphertext from a small base of t plausible messages including the real one, and then add randomized decoys to build the chance for more plausible messages to be associated with the transmitted ciphertext. This will save the need to add more messages in the explicit mode, and will offer a baseline guarantee for non-zero entropy for the user of the implicit mode.

3.4 Assembling the Composite Ciphertext (CC)

In the Implicit mode the transmitter ends up with proper pointers s1, s2, .... sq that when assembled comprise the proper ciphertext (no elasticity), and in addition the transmitter identified e decoy pointers d1, d2, .... de. The decoy pointers either don't point to any plaintext brick, or to two or more bricks. The transmitter will randomly or arbitrarily inject the e decoy pointers between the q proper pointers and the result will be the composite ciphertext. The intended reader, U, will readily discard the decoys, remain with the proper pointers and extract the intended message Pw.

In case of an explicit construction the assembly of the CC will be as follows:

Given t decoy plaintext messages and the proper message Pw, list all the messages in their ciphertext form per their sequential pointers, and move those pointers to the composite ciphertext as follow:

1. select randomly one of the (t+1) messages, x

2. select a random number, y, of pointers from plausible message x and set them up in their given order as the first y pointers in CC.

3. select randomly one of the (t+1) messages, x'

4. select a random number, y', of pointers from plausible message x' which is not empty and set them up in their given order as the next y' pointers in CC. ("empty" means that no more pointers are left per that plausible plaintext message).

5. If all plausible plaintext messages are empty, CC is fully constructed, otherwise return to (3)

By following the above procedure all the pointers for every message will retain their original order and the decryption will be straight forward.

The CC appears as a bit string in which the successive pointing signs (the pointers) must be properly identified. This can be done in several ways. If the cipher calls for fixed size pointers then a simple count of bits will do. If the pointers are of randomized size then the CC may be accompanied by meta data indicating how to parcel it out to pointers, or one may use "double-bitting": using the pair 00 to indicate bit 0 and the pair 11 to indicate bit 1, while the pair 01 will be used as border mark between successive pointers, with 10 used to start the finish the CC as an entity.  Another option is to examine CC from the first bit on until a "pointer end" bit is encountered such that the string from the first bit to the  pointer-end bit qualifies as a proper pointer.  The count will resume from the next bit until another "pointer end" bit is encountered, and defines the second pointer, and so on until the end of the composite ciphertext.  The cryptanalyst will not know how to parcel the composite ciphertext.

4.0 Collision

The implementor of elastic encryption is facing a fundamental challenge: collision. A ciphertext pointing sign, si, listed in order to point to plaintext brick pj using key Kk, may turn out to be pointing also to plaintext brick pl, using key Ke. The operation of elastic encryption is based on the condition where all the parts of the transmitted ciphertext that contain pointing signs not placed there to point to a plaintext brick on purpose, will not point to a brick when evaluated via a different key. Since such unplanned pointing will garble the message that is associated with the different key.

Illustration: Message 1 says: "Alice gives Bob books" is pointed to by four pointing signs: s1 → "Alice", s2 → "gives", s3 → "Bob", s4 → "books". Message 2 says "By noon go home" pointed to by s5 → "By", s6 → "noon", s7 → "go" and s8 → "home".

The combined ciphertext may look like this:

s1, s5, s2, s6 , s3, s4, s7 

Using Key K1 one will discard pointers s5, s6 , s7 since their pointing test T1 evaluates to T1 = 0, and then evaluate s1, s2, s3, s4 to message 1: "Alice gives Bob books".

By bad luck it so happens that when using key K2 s2 happens to point to plaintext brick "after", and s3 happens to point to plaintext brick "don't". In that case the reader of the plaintext who is using key K2 will interpret the ciphertext as:

"By after noon don't go home"

rather than the proper interpretation:

By noon go home

To prevent such confusion it is necessary to ensure that no part of the ciphertext is pointing to an unintended plaintext brick using any of the keys that are being used in explicit construction of the elastic encryption.

This is not a trivial requirement. One natural way to satisfy this is through Pattern Devoid Encryption.

It is easy to contrive t different pointing tests (T1, T2, ....Tt), based on algorithmic distinction such that a collision will not happen. But this will make these t algorithms vulnerable for cryptanalysis, and the very idea of elastic encryption will be defeated with one case of chosen plaintext. It is therefore that one prefers to build elastic encryption through pattern devoid cryptography where arbitrary parameters are minimized and random picks maximized.

4.1 Pattern Devoid Encryption

The basic approach of pattern devoid cryptography (PDC) is to match any plaintext brick, pgi, (plaintext brick i of plaintext bricks list g) with a large as desired number of "qualified targets" qgi1, qgi2, .... qgir, which are r (bit) strings of arbitrary size. |qgi1|, |qgi2|, .... |qgir|.

The respective T test will evaluate a ciphertext pointing sign sj against these r qualified targets. If:

Tg(qgik, sj) = 1

for one or more values of k, k=1,2,..r and:

Tl(qlik, sj) = 0

for l = 1,2,...(g-1),(g+1)....t  for all i=1,2,…b (where b is the number of bricks in each plaintext list of qualified targets), for all k=1,2,...r. then sj will properly evaluate to point to pgi, since no evaluator of sj via T1, T2, ...Tg-1, Tg+1....Tt and their corresponding qualified targets will yield a T test of 1 (all will be zero).

In order to comply with this necessary condition for elastic encryption one would opt for a sufficient number of large enough q-strings (qualified targets), large enough pointing signs, and a T test that would ensure that for a given qualified target there are many, X, pointing signs that evaluate to T=1 while X < < 2|si|.

This will ensure that the ciphertext builder has many options, X, with which to point to pgi, while keeping low the chance that a random string of size |sj| will score T=1 with any given qualified target.

Under these conditions the ciphertext builder will  easily find a pointer sign string to point to the plaintext bricks that express the plaintext message, Pw, the builder (writer) wishes to send to the intended reader.  And then when constructing the ciphertext pointing signs to point to the bricks of the first decoy message, the ciphertext builder will check every proposed pointer sign against all the qualified targets of the plaintext bricks associated with the proper message (Pw). If a proposed pointer (to the first decoy message) evaluates as T=1 with one of the qualified targets of the bricks associated with the proper message, then this proposed pointer will be disqualified, and the ciphertext writer will randomly pick another randomized candidate for ciphertext pointer sign for the first decoy, and check again. This check will continue until a pointer is found that evaluates as T=0 with all the bricks of the proper message, or evaluates to T=1 with two or more of the bricks used by the key for Pw (Kw). And so will be done brick by brick for the first decoy message.

The phrase "bricks associated with the proper message" refers to bricks used to construct the proper message (Pw) whether they appear in Pw or not.  The check is with the key material used to build the proper message, which means the qualified targets used for encrypting Pw.

In practice the bricks for the proper as well as the decoy messages may be the same, the difference is in the key material assigned to each brick -- the qualified targets.

The second, third, etc., decoy messages will undergo the same check as done for the first decoy message.  We note that collision between pointing signs to decoy messages are not disturbing the intended reader, U.

Under some considerations the collision tests can be expanded to ensure that a pointer for a brick in plaintext message Pi is not pointing to any brick in the sets of bricks used to build all other plaintext messages that are assembled into the composite ciphertext.

By making X large enough and the size of the qualified targets as well the size of the pointing sings large enough, the probability calculus will favor a quick resolution of the collision condition.

4.1.1 Illustration: BitFlip

In the BitFlip cipher [16] (basic version) the qualified target is a random bit string q, and the ciphertext pointer sign, s, is of same size (x bits) where the Hamming distance, HAM = h and the value of h is engineered to handle the collision challenge.

The number of strings of size x bits that have a Hamming distance of h from q is:

n(x,h) = x! / (h! (x-h)!)

the values of x and h need to be adjusted such that there will be many qualified pointers, on one hand, but that the probability for a random string of size x to be a pointer will be low.

Illustration: for x=100 and h=20, we have:

n(x,h) = 100! / (20! (80)!) = 7 * 1028 

which is a huge number. The chance for a random string of size 100 bits to fit is:

Pr = n(x,h)/2100 = 5%

So the chance that a pointer selected for the first decoy pointer to be free of collision with 8 bricks for the Pw proper plaintext is: (1-0.05)8 = 66%, so that by trying 3 times the chance to spot a pointer free of collision is 97%.    However if the the proper message is written by Base64 letters,  then there are 64 bricks, and the chance for a random string to be free of collusion is: (1-0.05)64 = 3% only.

By selecting h=10 the number are recomputed:

n(x,h) = 100! / (10! (90)!) = 1.73 * 1013 

Pr = n(x,h)/2100 = 0.86 * 10 -17 

with such small probability, there is no fear for collision.

 

4.2 Pattern Devoid Ciphers

BitFlip is one example. There are several dozen specified ciphers that qualify for elastic encryption. They all share the same structure where qualified targets are associated with ciphertext bricks, where these targets are of randomized size and randomized content. The T test is simple and allows for many fitting pointers, while making these fitting pointers sufficiently small in number that collision is not a serious impediment.

Being pattern devoid ensures that no smart mathematician will find any shortcut to cryptanalysis.

Detailed discussion of pattern devoid cryptography is given here [1]

 

5.0 Cryptanalysis

The rigid-cryptography cryptanalyst is never in doubt. They either cracked the ciphertext or not. The elastic-cryptography cryptanalyst is never free of doubt. If no plaintext candidate has emerged, it may be because either it is buried too deep, or because it does not exist, and the entire ciphertext is subterfuge.  And if a plaintext candidate was extracted -- is it the right one, or  a decoy?    If several plaintext candidates have been extracted from the ciphertext, is the right ciphertext among them, or are they all decoys?    It is better to be a doubt-free unsuccessful rigid-cryptography cryptanalyst than a doubt ridden elastic cryptography cryptanalyst who may act according to a misleading choice of plaintext.

The prepared cryptanalyst facing elastic encryption is aware of their inability to crack the ciphertext, like they do with brittle cryptograms, and their battle is to suppress the contextual entropy as low as possible.

If the elastic ciphertext is run with pattern devoid cryptography then there is no pattern to crack and the cryptanalyst is relegated to brute force attack. Unlike brute force over brittle cryptography, the elastic variety offers no end point. The shared key (the qualified targets for the plaintext bricks) is open ended. The attacker does not know if all of it was used before, and does not know which part of the key was used per every instance of encryption. This open-ended state invites the incorporations of decoy messages, keeping the contextual entropy at high level.

The omnipotent cryptanalyst will discover all the members of the π-list which are written into the captured ciphertext and will have to contend with the respective entropy, but a practical, sub-omnipotent cryptanalyst, after fishing some t plausible messages in the ciphertext will not know whether the true message Pw is included in the extracted list, or whether it has escaped detection.

The best strategy for the cryptanalyst is comprised of the following efforts:

  1.  On going brute for analysis of the ciphertext 

2.  Capturing the shared key 

3.  Applying AI to generate updated π-list, and extract maximum information from comparing it to the results of the on-going brute force analysis. 

Capturing the shared key is the most helpful activity, it will totally void the advantage of the encryption. It can be done through smart cyber-attacks, or physical theft.

As the attacker learns more and more the situation at hand, as it develops, then the look back onto the π list may become very helpful. Illustration: when an elastic ciphertext is being sent, the attacker considers plaintext messages P1 and P2 to each have a probability of 40% to be Pw, the proper message. Examining the ciphertext both P1 and P2 can be decrypted from the ciphertext. This is not helpful. Alas at a later point the cryptanalyst considers P2 to lose its likelihood rating, and P1 likelihood rises to 60%. Now a look back at the ciphertext will point strongly to P1 = Pw.

 

5.1 The Open-Ended Elastic Key

Applying the pattern-devoid paradigm, then at the very least the elastic encryption key is the identity of qualified target strings associated with each plaintext brick.  The list of bricks, in as much as it includes words and phrases, may also be part of the secret key.  The pointing test is optionally a secret, but it can as well be in the open.  Each plaintext brick (letter, word, phrase, etc.) may be associated with any number of qualified targets, where the choice among them is randomized. Therefore a cryptanalyst does not know which target was used. Even if a key was used for a long time the cryptanalyst does not know if there are yet unused targets.

The more targets per brick, the greater the risk for collision, and hence operational optimization is called for.

The identities and the brick association of the qualified targets constitutes the key. As to the identification of bricks and the pointing test, here secrecy is optional.

 

5.2 Evolving Cryptanalysis

We described here how artificial intelligence helps the cryptographer to challenge the cryptanalyst with an elastic ciphertext. However, the same technology will be used by the cryptanalyst who will be using AI to dynamically evaluate the competitive situation in which the ciphertexts are communicated. So while originally a cryptanalyst will assign 25% likelihood to 4 plausible plaintext messages detected in the ciphertext, at a later point AI will guide the cryptanalyst to change the likelihoods, and increase its measure for , say,  the first candidate. Thereby the contextual entropy for this particular ciphertext will diminish. The elasticity works both ways, a captured ciphertext may be quite unhelpful to begin with but quite helpful at a later stage. AI driven competitive situations are handled via extensive use of probability calculus which gives dynamic value to a cryptanalyzed elastic ciphertext.

We may be looking at evolving cryptanalysis where the posteriori entropy is suppressed over time and serves the cryptanalyst for the long run.

AI driven strategies are based on probability calculus wherein one assigns probabilities to adversarial attack strategies, building one's defensive strategies on the basis of these probabilities.  The contextual entropy measure fits right in.

5.3 Elastic Subterfuge

Elastic cryptography allows the ciphertext builder to put forth an easy to find plausible message, designed to mislead the cryptanalyst into a false sense of success. Even two or more 'easy to find' decoy messages can be built into the composite ciphertext, while the true message, Pw, is buried deep inside. The cryptanalyst, finding two or more plausible messages in the ciphertext will become falsely assured that one of these captured messages is the right one, and act accordingly.

From the point of view of the cryptanalyst the fear of falling to such a trap should give them a pause.

5.4 Chosen Plaintext

When attacking a pattern devoid cipher it is impossible to use a chosen ciphertext because it is randomly chosen. Chosen plaintext is possible and the easiest way is to repeatedly invoke the cipher with a single plaintext brick -- say, the letter "F". In the least protected way the ciphertext for "F" will be a growing set of ciphertext pointers from which the cryptanalyst will try to figure out the key part related to "F". The elastic cipher can make the list necessary for that purpose to be as long as desired. On top of it randomly mixing decoys into the ciphertext will further frustrate any attempt for cryptanalysis.

For illustration, using BitFlip, the brick "F" can be matched with an arbitrary number of qualified targets, and each time "F" is invoked a qualified target is selected randomly. This will keep the transmitter in control of the cryptanalytic burden.

5.5 Key Size Cryptanalysis

Elastic encryption can rise to Vernam security if the key is large enough. However, the greater the amount of ciphertext generated from the same key, the greater the chance that the key is not reaching Vernam levels. Elastic encryption may be regarded as Trans-Vernam, in as much as it may be exercised with security levels that are as close to Vernam as desired.

A Vernam ciphertext is associated with all possible plaintexts of its size, an elastic ciphertext is associated with all possible plaintexts of a smaller size. Given a size x of a key, Kx, associated with a given ciphertext C of size c, one could write any arbitrary plaintext, Py, message of some smaller size, y < x, and build a key Ky ≤ Kx to decrypt C to Py.

This can easily be done when a given pointing sign, S, can be associated with many (q) qualified targets, Q1, Q2, .... Qq, per a given brick, such that s → Qi for i=1,2,...q. The cryptanalyst will randomly pick Qi. If Qi is also pointed to by a different pointer in the ciphertext that is used to point to a different brick, then Qi will be replaced with another random choice from the set of q choices. This replacement will be exercised as often as needed. For q large enough and Ky small enough every arbitrary plaintext can be fitted to a given ciphertext. Say then that elastic encryption has Vernam properties per plaintexts smaller than the ciphertext (where the extra ciphertext is interpreted as decoys).

6.0  USE

The very idea of elastic encryption -- the battle on the contextual entropy is very fitting into the emerging world where AI plays a central role and probability calculus dictates moves. Cryptographers will attempt to keep the contextual entropy high, while cryptanalysts will try to keep it down. Beside writing and cracking, code players will be bombarded with AI advice and insight which will impact the probabilities of the π-list. Competition and adversity will take a new shape and elastic encryption will fit right in.

6.1 Operational Modes

Elastic encryption can be exercised in different modes:

1. dialing mode 

2. Built in AI

3. Negotiable AI 

4. Human Intelligence Mode 

5. continuous mode 

In "dialing mode" the transmitter does not relate to the π-list, is not engaging and is not served by AI. The transmitter uses a 'dialing needle' to indicate to the encryption apparatus the degree of decoy injection in the form of noise, content-devoid bits. The more significant and the more sensitive the encrypted information, the 'higher' the dial. The parties pay with increased communication load but gain increased security. The transmitter might be helped by a prepared chart that lists security levels against decoy levels. In this mode there is no engagement with AI. Security is based on probability calculus, the more decoys the greater the chance for a decoy plausible message to be interpreted as the encrypted message.

Built-in AI may either be in "box mode" or in "cloud mode". In box mode the AI software operates inside the "cipher box" -- not shared without. In cloud mode the AI capability is fed from cloud based sources, and so is more "intelligent" and its π-list is more credible. Negotiable AI may be per box-AI or per cloud-AI . In this mode the transmitter submits their insight to the AI to support all other sources.

In human intelligence mode there is no AI, the human operator actually writes down decoy messages and the cipher system generates for each such decoy system the proper ciphertext and then constructs the composite ciphertext.

In continuous mode, each transmitter is engaging in a fixed rate of decoy transmission where as necessary decoys are replaced with proper ciphertext. In this mode the extent and frequency of the communication is being concealed.

 

6.2 Sources of Randomness

Elastic encryption consumes a lot of randomness. A small part of it is pre-shared between the parties, but the vast majority is unilateral. The quality of the implementation depends on the quality of the randomness. It is better to apply non algorithmic randomness. Several technologies are available. Quantum quality randomness may be captured in a "rock of randomness"  [13] that might be physically incorporated in the 'cipher box' with identical copies held by the various parties.

7.0 Outlook

Operationally and conceptually elastic encryption represents a big shake-up in the daily routine of cyber security. Modern security procedures are very complicated, elaborate and rigid. They resist minor protocol changes, much more so large upheavals. Treating cryptology as a live entropy battle is certainly more than a minor adjustment.  The industry is expected to resist any embrace of elastic encryption. The most likely initial introduction of elastic encryption will be in the "Lifeboats on the Titanic" mode.[2] It is a compelling argument  that the post quantum cipher candidates offered by NIST are inherently suspect and face the risk of stealth breach which an adversary will unleash at a moment most serving their interest. Such a surprise breach might be devastating to both civil order and military order in the United States and in the West.  

Recalling the great history lesson of the Titanic: despite great trust in the maritime technology of this supreme sailing ship -- lifeboats were placed on board (not enough though) and saved live.  Similarly prudent cyber security centers will be well advised  to be prepared with elastic encryption, just in case.

Looking further into the future, the elastic format may become the cipher of choice among individuals and organizations suspecting smarter than expected adversary, or among those mistrusting their government and looking for safe communication.

An intriguing theory claims that governments hang on to complexity-based ciphers when facing the public, while in secret using elastic cryptography to safeguard their own secrets. This theory says that big cryptanalytic shops invest billions and eventually crack the complexity ciphers they recommend for use, and thereby enjoy useful visibility over people of interest. If true then one should expect massive resistance towards elastic ciphers which threaten to void the "smarts advantage" claimed by the powers that be.

8.0 Reference

1.   "Pattern Devoid Cryptography" https://www.intechopen.com/online-first/pattern-devoid-cryptography

2.     Lifeboats on the Titanic Cryptography  https://eprint.iacr.org/2025/587

3.     Transmitting Secrets by Transmitting only Plaintext. https://eprint.iacr.org/2025/438

4.     "Tesla Cryptography:" Powering Up Security with Other Than Mathematical Complexity. https://eprint.iacr.org/2023/803

5.     AI Resistant (AIR) Cryptography. https://eprint.iacr.org/2023/524

6.     The Prospect of a New Cryptography: Extensive use of non-algorithmic randomness competes with mathematical complexity. https://eprint.iacr.org/2023/383

7.     FAMILY KEY CRYPTOGRAPHY: Interchangeable Symmetric Keys; a Different Cryptographic Paradigm https://eprint.iacr.org/2021/458

8.     Finite Key OTP Functionality: Ciphers That Hold Off Attackers Smarter Than Their Designers. https://eprint.iacr.org/2024/129

9.     Polar Lattice Cryptography. https://eprint.iacr.org/2025/452

10.   Cryptographic Key Exchange: An Innovation Outlook https://eprint.iacr.org/2023/1372

11.   Randomness as Absence of Symmetry THE 17TH INTERNATIONAL CONFERENCE ON INFORMATION & KNOWLEDGE ENGINEERING (IKE'18: JULY 30 - AUGUST 2, 2018, LAS VEGAS, USA)

12.   NEPSAR: Secure Key Exchange https://www.bitmintalk.com/nepsar

13.  Samid G, Wnek GE. The “Rock of Randomness”: a physical oracle for

      securing data off the digital grid. MRS Communications. 2019;9(1):67-76.   doi:10.1557/mrc.2019.8

14. Innovation Solutions Protocol. https://innovationSP.net

15. AI Assisted Innovation https://www.intechopen.com/chapters/7515916. Popov, Samid "BitFlip: A Randomness-Rich Cipher" https://eprint.iacr.org/2017/366