Methods and systems for deterministic encryption having improved security

Abstract

The present disclosure provides a system and method for secure data processing and transformation. The system includes an input comprising multiple data blocks, multiple processing stages, and an output. The processing stages include parallel processing paths with oracle functions, permutation functions, and data combination points using XOR operations. The system processes an initial data block and a first round data block through a first oracle function and a first permutation function to generate a second round data block. Concurrently, the system processes the first round data block through a second oracle function and a second permutation function. The system combines the processed data using XOR operations and further processes it through a third permutation function to generate a third round data block. The system then applies a trapdoor permutation function to produce a final output comprising an encrypted block and a final round data block.

Description

[0001]METHODS AND SYSTEMS FOR DETERMINISTIC ENCRYPTIONHAVING IMPROVED SECURITYCROSS-REFERENCE TO RELATED APPLICATIONThis application claims the benefit of U.S. Provisional Application Ser. No. 63 / 634,412filed April 15, 2024, the content of which is incorporated by reference herein in its entirety.FIELD OF THE INVENTIONThe invention relates to deterministic encryption, and in particular to deterministicencryption based on an improved security definition.BACKGROUND OF THE INVENTIONDeterministic public key encryption (DPKE) aims to securely encrypt messages withoutrandomness. Such encryption has potentially numerous benefits: it is hedged against weakor even subverted randomness sources, it allows for checking the equality of plaintexts thusenabling searching over encrypted data, and it does not inherently require ciphertext expan-sion unlike probabilistic encryption. However, the same features which make deterministicencryption attractive also render semantic security impossible, since an attacker can checkany guess for the plaintext by encrypting it for himself.Just because semantic security is impossible does not mean deterministic encryption isuseless. Indeed, Bellare, Boldyreva, and O’Neill (Mihir Bellare and Alexandra Boldyreva andAdam O’Neill, Deterministic and Efficiently Searchable Encryption (BelBolONe07)) observethat the impossibility does not necessarily apply if the plaintext has sufficient min-entropy,since the adversary would not have any guess for the plaintext. In many real-life scenarios,the adversary would not have such a guess, and so we may hope to achieve the benefitsof deterministic encryption in these cases without sacrificing security. Bellare et al. go onto define a PRIV security notion, a relaxation of semantic security where the adversaryis required to produce a distribution of sufficient min-entropy for its challenge. Since itsintroduction, deterministic encryption has been widely studied, with many positive andnegative results.Weaknesses in the Prior DefinitionsWe first recall the PRIV definition from BelBolONe07. An adversary comes in two parts: amessage sampler D and distinguisher A. The experiment works as follows:1. First, a tuple (m, t) ← D() is sampled from D, where m is a message vector, and t istarget information the adversary is trying to learn.2. Next, the public key / secret key pair pk, sk is sampled.3. m is encrypted message-by-message to obtain the ciphertext vector c.4. A is given pk, c, and tries to produce t.PRIV security stipulates that the adversary’s success probability in the above experiment isclose to the success probability where m is replaced with an independent sample(m′, t′) ← D() (but the adversary still tries to output t).Standard semantic security of probabilistic encryption allows for proving PRIV securityvia a standard hybrid argument. But with deterministic encryption, whether or not securityis possible depends heavily on the distribution D. For this reason, BelBolONe07 define PRIVsecurity as only requiring negligible closeness when D satisfies certain properties:1. Each entry in m must individually have high min-entropy, so that the adversary cannotguess and check.2. The equality pattern of m – which entries are equal vs not equal – must be fixed, withevery m produced by D having the same pattern. This is because the equality pattern ispreserved in the ciphertext vector c, and insisting on fixed equality patterns prevents theequality pattern from revealing any useful information.3. The distribution D must be chosen independently from the public key pk. If D can dependarbitrarily on pk, then there is a simple attack: let m be a uniform message, and lett = Enc(pk, m), which is a deterministic function of m. m has high entropy, but it istrivial to learn t from its encryption.Throughout this introduction, we will use the case of subverted randomness as motivation:to create a PKE scheme that is hedged against weak or subverted randomness, simplyencrypt m||r using a deterministic scheme, where r are some random coins. As long as r hasmin-entropy, m||r will as well, even if m is fixed. Thus, we would expect PRIV security toimply standard semantic security as long as r has min-entropy. Unfortunately, this is not thecase, and for this reason works on hedged PKE such as Mihir Bellare and Zvika Brakerskiand Moni Naor and Thomas Ristenpart and Gil Segev and Hovav Shacham and Scott Yilek,Hedged Public-Key Encryption: How to Protect against Bad Randomness (BBNRSS09) proveboth PRIV security when r is non-uniform, as well as separately prove semantic securitywhen r is uniform. To the best of our knowledge, no prior work proves semantic securitywhen r has min-entropy but is non-uniform. We now dig deeper into this and other issues.Selective vs adaptive security. Semantic security for ordinary PKE allows the challengemessages to be chosen adaptively based on the public key. As discussed above however, PRIVsecurity on the other hand is selective, meaning the message distribution does not depend onthe public key. This means that PRIV security, when encrypting m||r in order to protectagainst subverted randomness, actually only achieves selectively secure semantic security. Thisis true even if the randomness is not subverted at all. The distinction between adaptive andselective security a major subject of study throughout cryptography, and it is an importantgoal for (deterministic) PKE schemes. This also leads to the unsatisfactory setting mentionedabove where existing solutions for hedged PKE require separate definitions and proofs forthe case where randomness is subverted vs when it is not, with the adaptive setting offeringno hedging at all.While widely studied in many other areas, for DPKE there are only two prior workswhich consider adaptive security: Ananth Raghunathan and Gil Segev and Salil P. Vadhan,Deterministic Public-Key Encryption for Adaptively Chosen Plaintext Distributions (RagSeg-Vad13); and Mihir Bellare and Wei Dai and Lucy Li, The Local Forking Lemma and ItsApplication to Deterministic Encryption (BelDaiLi19), and only the former RagSegVad13considers an indistinguishability notion. (The latter (BelDaiLi19) considers full message recov-ery, which is a far weaker notion.) Later, we will dive into the specifics of how RagSegVad13avoid the issue in 3 above. Here we discuss one particular requirement of their definition: theyrequire that the adversary always outputs a D with min-entropy above some threshold, sayH. By always, we mean that D has min-entropy above H for every single public key in thepublic key space. This includes not only honest public keys that appear in the “real world,”but also fake public keys that may appear in the proof. This seems like an odd restriction:why should the security of the protocol depend on how an adversary behaves on keys thatnever actually appear?It turns out that this definition is actually crucial to getting the security proof inRagSegVad13 to go through. RagSegVad13 utilize a lossy trapdoor function (LTDF) (ChrisPeikert and Brent Waters, Lossy trapdoor functions and their applications (PeiWat08)) inthe public key, which in the real world is in the injective mode. The proof switches to ahybrid with the function in lossy mode, where the range size R of the function is somewhatsmaller than 2H . The scheme is information-theoretically secure in this setting, as it is arguedthat the lossy mode LTDF applied to the message distribution is essentially extractinglog2 R uniform random bits from the distribution, independent of the choice of distribution.This information-theoretic security only holds, however, if the message distribution stillhas min-entropy at least H even if the LTDF is in the lossy mode. This is because if themin-entropy in the lossy mode, say H ′, shrinks too much, there is no way we can extract random bits.In fact, there is a simple “attack” on their proof. Namely, we can set the message to be arandom output of the LTDF, which can be efficiently sampled by simply applying the LTDFto a uniform input. In the injective mode, this will have high min-entropy. But in the lossymode, the min-entropy will be at most log2 R. As randomness extraction requires some lossin entropy, there is no way to extract log2 R uniform bits from this distribution. It is alsoeasy to come up with specific LTDFs that have lossy range size R, along with key-dependentdistributions that have high min-entropy in the injective mode, but min-entropy much smallerthan log2 R in the lossy mode. The analysis in RagSegVad13 will fail for adversaries thatoutput such distributions.We stress that this is not a bug in the proof of RagSegVad13, but rather a subtle flaw inthe security definition. Indeed, the attack outlined above would not be considered a validattacker in the model of RagSegVad13, since on some public keys (namely, the lossy modeLTDF) which do not appear in the “real world,” the attacker fails to output a large-entropydistribution. However, it seems strange to allow public-key-dependent plaintext distributions,but not allow distributions that actually use the LTDF to sample the plaintext. Our exampleabove is also not an attack on any particular scheme, because it may be that the schemeis still secure even if the lossy mode is not extracting uniform bits. However, our exampleshows that the existing analysis is not sufficient to reason about very natural distributionsthat can be adaptively chosen based on the public key.Remark 1. One may be tempted to argue that, if on “real world” public keys the adversaryoutputs a D with high min-entropy but on the invalid public keys occurring in the proofthe adversary outputs a D with low min-entropy, then the adversary is distinguishing realfrom invalid public keys, which would presumably break the assumed indistinguishabilityof the real and invalid public keys. This is simply not true, however: the min-entropy of adistribution is in general not efficiently computable, with LTDFs being an explicit examplewhere this is hard. The example “attack” above shows an explicit setting where this indeedhappens, despite the real and invalid public keys being indistinguishable.We believe a more reasonable definition would only stipulate a min-entropy requirementon plaintext distributions occurring in the real world. But even this requirement seemstoo strong, and results in a very fragile definition. For example, suppose we changed theinjective mode distribution to, with negligible probability, sample from the lossy distribution.This would introduce some negligible correctness error, which would typically be consideredacceptable. However, now even if we only require high-min-entropy plaintext distributions onhonest public keys, this requirement covers the lossy mode as well, allowing us to resurrectthe security proof of RagSegVad13. However, we have not actually changed anything aboutthe security of the protocol since the public key distribution only changed negligibly, and yetwe allowed a security proof to go through that would not go through previously. Likewise, wecould imagine a slightly different definition where we only ask that the adversary outputs ahigh-entropy definition with overwhelming probability. Since the adversary’s behavior undersuch a restriction is negligibly close to an adversary that always outputs a high-entropydistribution, this change in requirements should not actually result in a different definition.But in the case where the injective mode is actually lossy with negligible probability, thiswould again break the security proof of RagSegVad13, even if we restrict to only considering“real world” public keys: a uniform output of the injective mode will be high-entropy withoverwhelming probability (namely, whenever the function is actually injective), meaning our“attack” which on their proof is considered a valid attacker.In order to get around these issues, it seems the only option is to consider a securitydefinition that allows the adversary to sometimes output low-entropy plaintext distributions,even on honest public keys. This precludes all known standard-model techniques to reasonabout the adaptive security of DPKE under standard assumptions.Remark 2. The above is not an issue for the more common selective variant of PRIV, ashere by definition the public key and the message distribution are independent. Switching tothe lossy mode will not change the message distribution, and it will therefore still have highmin-entropy as needed for the proof.We will now discuss a handful of other limitations of existing definitions.Deterministic Equality Patterns. For deterministic encryption, the equality pattern ofm is revealed by c. Unfortunately, the equality pattern may reveal non-trivial information.For example, suppose we are encrypting the identities of users in various transactions. Theequality pattern would then reveal when two purchases were made by the same individual.It is not hard to come up with (contrived) distributions where the equality pattern evencompletely reveals m, despite m having high min-entropy. For this reason, PRIV securityrequires a fixed equality pattern.However, fixing the equality pattern is extremely restrictive. Why should each messagehave individually high min-entropy, but then require such a low-entropy relation betweenthem? For example, suppose two messages are simply independent random values fromsome high-entropy distribution. Then the equality pattern is not fixed, since there is a tinychance that the two messages will be the same. But this is exactly what happens whenusing deterministic encryption to hedge against bad randomness: in order to devise anencryption scheme robust to bad randomness, one would naturally encrypt (m, r) under adeterministic encryption scheme, where r are the random coins. Under this use case, however,two encryptions of the same message – even under ideal randomness! – would not have adeterministic equality pattern. As such, the PRIV definition alone gives no direct guaranteesfor this use case. Of course, this distribution is statistically close to one where the r’s arerandom but disjoint, and so a simple hybrid argument would allow for justifying semanticsecurity from PRIV security. But it already points to a weakness of the PRIV definition thatsuch an implication is not immediate.The situation gets worse when considering other potential applications. For example,in the transaction application above, while not ideal, perhaps leaking when the same usermakes multiple transactions is acceptable. Similar leakage is tolerated, for example, incryptocurrencies. We would still like pseudonymity, preventing linking any particular userto any individual transaction. But insisting on deterministic equality patterns seems veryrestrictive. Maybe Alice pays to see a movie every Friday, but sometimes she decides to buya meal at a local restaurant first. Existing notions would say that the equality pattern ofuser identities is not fixed, and therefore offer no security at all for Alice’s identity. Moreabstractly, we would ideally have a notion that is compatible with message distributionswhich allow for messages to sometimes be equal and sometimes not.Overly Pessimistic Entropy Requirements. Consider the case of a single message m,and suppose that m = 0n with probability 0.001, and otherwise m has high min-entropy. Thismay arise, for example, when using deterministic encryption to hedge against bad randomness.Suppose the system usually produces sufficiently random coins, but sometimes – say, if thesystem has just booted up and has not yet collected enough entropy from its environment –it fails. A rare leakage of the message may be unavoidable, and we would like to understandwhat security we can still hope for. We would like, for example, to be able to say that if thebad event does not happen, then the message m remains secure. Existing security modelswould instead just say there is no security since the message distribution has low min-entropy.For another example, consider the case where Alice and Bob are both encrypting messagesto Charlie. Alice may be encrypting only high min-entropy messages (say, she is encryptingm||r for truly random r). Meanwhile, Bob is encrypting messages unrelated to Alice, butthey are low min-entropy (say, his randomness has been subverted). To model security in thisscenario, we would have that Charlie receives a vector of messages including those from bothparties, meaning some of the messages have high min-entropy and some have low. StandardPRIV security would simply say that the scheme is insecure for this use case. But this isunsatisfactory, as Alice’s usage alone should be considered secure. Yet the definition somehowseems to be suggesting that Bob’s additional messages, despite being independent of Alice’s,are breaking Alice’s security. We would like a definition that allows for Alice’s messages tobe considered secure, while Bob’s are not. Likewise, consider the case where Alice’s messageshare the first half the bits with Bob’s message, but is otherwise independent. Clearly Bob’smessage may be insecure, revealing the first half of Alice’s message. But the second half ofAlice’s message should stay hidden. Existing definitions do not guarantee this, since theywould just say that there is no security due to Bob’s low-entropy messages.Auxiliary inputs and everywhere unpredictable distributions. Sometimes, theadversary may have auxiliary information about the messages beyond just the ciphertexts;the equality patterns discussed above are one example. While the original PRIV definitiondoes not model auxiliary inputs, Brakerski and Segev (Zvika Brakerski and Gil Segev, BetterSecurity for Deterministic Public-Key Encryption: The Auxiliary-Input Setting (BraSeg11))define a model capturing such side information. Even more, their model allows for themessages to be information-theoretically determined, as long as they are computationallyunpredictable given the auxiliary input.A key issue, however, is that the messages must be unpredictable for all (or at least, anoverwhelming fraction of) auxiliary inputs. In real-world scenarios, this may not be reasonable,and there may be variability in the unpredictability of the message. For example, we could tryto model the m = 0n scenario above by having the time since booting be a piece of auxiliaryinput. In this case, for auxiliary inputs corresponding to a large time since boot, the messagewill have sufficient entropy. But for auxiliary inputs corresponding to a small boot time, themessage will have low entropy. Similar to the discussion above, existing definitions wouldsimply not allow such a distribution and thus offer no security guarantees. But this may beoverly pessimistic, and we would at least like to understand what security is still offered evenin such an un-ideal setting.Large public keys for adaptive security. In order to get around the impossibilityof adaptive security discussed above, RagSegVad13 constrain the adversary to selecting adistribution from among a set of size 2L for some polynomial L. They then have the publickey to be much larger than L, meaning that there is no way for the messages sampled by thedistribution to depend on the public key in its entirety, which defeats the trivial adaptiveattack. Unfortunately, it is unclear what L should be. In order for the m||r application toimply adaptive semantic security under uniform r, it suffices to set L = |m|. But for moregeneral settings (say m||r where r is non-uniform but with high min-entropy), how to set Ldepends on the potential process by which the adversary can have the public key influencethe distribution. If the process can be truly arbitrary, except for a constraint on runningtime, L can end up being quite large. For example, in order to handle circuits of a milliongates (corresponding to less than a millisecond of computation on modern hardware), onewould need to set L to be somewhat larger than a million, resulting in public keys that areseveral megabits. Encryption time must is also inherently larger than L with this approach.BRIEF SUMMARY OF THE INVENTIONThis summary is provided to introduce a selection of concepts in a simplified form thatare further described below in the detailed description. This summary is not intended toidentify key features or essential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subject matter.According to aspects of the present disclosure, methods, systems, and non-transitorycomputer-readable media are provided for secure message encryption and decryption. Themethods, systems, and media include executing a setup routine that selects one or moreresource hard functions, establishes a trapdoor permutation, and generates a public key andsecret key pair. An input plaintext message is received and split into a first segment and asecond segment. The segments are processed in a Feistel network executing at least threerounds, where each round comprises at least one hash function and the network includesexecution of a first secure resource hard function and a second secure resource hard functionin separate rounds. A trapdoor permutation is applied to at least a portion of the Feistelnetwork result to generate a first ciphertext portion. The first ciphertext portion is combinedwith a remaining portion of the Feistel network result to generate a ciphertext message havingthe same length as the input plaintext message. The ciphertext message is then transmitted.According to other aspects, the methods, systems, and media may include one or moreof the following features. The first and second secure resource hard functions may be thesame function. Alternatively, the first and second secure resource hard functions may notbe the same function, but may be considered hard in the same dimension, such as parallelcomputation time, sequential computation time, or computational depth. All the hashfunctions in the Feistel network may be identical functions. The resource hard functions maybe selected from deterministic proofs of work taking significant parallel computation time toexecute, memory-hard functions taking significant storage to execute, and delay functionstaking significant sequential computation time to execute.The Feistel network may comprise applying a first oracle function to the second segment,applying the first secure resource hard function to the result of the first oracle function,applying a first permutation function to the second segment and the result of the first secureresource hard function, combining the result of the first permutation function with the firstsegment using an XOR operation to produce a third segment, applying a second oraclefunction to the third segment, applying the second secure resource hard function to theresult of the second oracle function, and applying a second permutation function to the thirdsegment and the result of the second secure resource hard function.The ciphertext message may be stored in a database and indexed for later retrievalwithout requiring decryption, thereby enabling searching over encrypted data. The methods,systems, and media may also include receiving the ciphertext message, applying an inverse ofthe trapdoor permutation to the first ciphertext portion to generate a decrypted portion,combining the decrypted portion with the remaining portion of the ciphertext message andsplitting the result into two segments, processing the two segments in the Feistel networkexecuting at least three rounds in reverse order, and storing the result as a decrypted plaintextmessage. The methods, systems, and media may be implemented in various computing architectures,including client computing systems with specialized processing units for cryptographicoperations, and server-client network architectures supporting secure communication anddata processing across multiple interconnected components.The foregoing general description of the illustrative embodiments and the followingdetailed description thereof are merely exemplary aspects of the teachings of this disclosureand are not restrictive.BRIEF DESCRIPTION OF THE DRAWINGSNon-limiting and non-exhaustive examples are described with reference to the followingfigures. FIG. 1 illustrates a security experiment diagram, according to aspects of the presentdisclosure. FIG. 2 depicts a block diagram of an encryption system, according to an embodiment.FIG. 3 shows a flowchart of a method for processing and encrypting plaintext messages,in accordance with example embodiments.FIG. 4 presents a flowchart of a method for decrypting ciphertext messages, according toaspects of the present disclosure.FIG. 5 illustrates a client computing architecture, according to an embodiment.FIG. 6 depicts a server-client network architecture, according to aspects of the presentdisclosure.DETAILED DESCRIPTIONThe following description sets forth exemplary aspects of the present disclosure. It shouldbe recognized, however, that such description is not intended as a limitation on the scope of thepresent disclosure. Rather, the description also encompasses combinations and modificationsto those exemplary aspects described herein.A detailed description of systems, devices, and methods consistent with embodiments ofthe present disclosure is provided below. While several embodiments are described, it shouldbe understood that disclosure is not limited to any one embodiment, but instead encompassesnumerous alternatives, modifications, and equivalents. In addition, while numerous specificdetails are set forth in the following description in order to provide a thorough understandingof the embodiments disclosed herein, some embodiments can be practiced without some or allof these details. Moreover, for the purpose of clarity, certain technical material that is knownin the related art has not been described in detail in order to avoid unnecessarily obscuringthe disclosure.1 Preliminaries and NotationAlgorithms. Our results will hold for both Turing machine and circuit models of computa-tion. We will therefore not specify a single model of computation, but instead simply talkabout “algorithms”, which can be considered entities in any reasonable computational model.We will consider an algorithm as having an internal state which starts out as being set to theinput. Then the algorithm consists of a number of steps, each step transforming the state insome way. The output is then some subset of the final state of the algorithm.We will be considering both algorithms of arbitrary input size, as well as algorithms offixed input size. In general, cryptosystem algorithms and adversaries will have arbitrary inputsize. We will also allow an algorithm A itself to output (the description of) another algorithmD; in this case, D will always be an algorithm of fixed input and output size. We will alsomodel fixed input-size algorithms as having a fixed running time. We will also assume thatD is always represented in a way that its running time is bounded by a fixed polynomial inits description length. This way, the running time of D cannot be too much more than therunning time of the algorithm A which produced it. This convention is inherent to the circuitmodel of computation. For A which output Turing Machines, we will simply require A topad the description of D to be, say, equal to the desired running time.A probabilistic polynomial time (PPT) algorithm is an arbitrary input-length algorithmwhose running time is bounded by a polynomial p in its input size. A negligible function is afunction that is smaller than any inverse polynomial, for sufficiently large input.Given a fixed input size algorithm A, let AT0→T1 be the algorithm which runs A fromtime-step T0 to time-step T1, where the state at time-step T0 is the input to AT0→T1 , and theoutput of AT0→T1 is the state of A at time-step T1.Define a trivial function as one composed only of the following operations: concatenationby a constant, deletion of a bit, copying of a bit, and permuting bits. Then we say that A′ isa truncation of A if it has the form of h ◦ AT0→T1 ◦ g for trivial functions g, h.For a set of fixed input size algorithms R, we call the truncation closure of R as the setof all truncations of algorithms in R. For most natural sets of algorithms R, the truncationclosure of R is simply R.2 Defining Deterministic EncryptionWe first recall the syntax of deterministic encryption, which syntactically is identical toprobabilistic encryption except that the encryption algorithm is now deterministic:Definition 1. A deterministic encryption scheme for message space M = (Mλ)λ is a tripleof algorithms Π = (Gen, Enc, Dec) such that:– Gen(1λ) is a probabilistic algorithm that samples a public key / secret key pair (pk, sk)– Encm– Dec cand outputs a message m.– Correctness: For all λ, except with negligible probability over (pk, sk) ← Gen(1λ), wehave Dec(sk, Enc(pk, m)) = m for all m ∈ Mλ. 2.1 Semantic Security for Resource-Constrained SourcesWe now give our new security definition for deterministic encryption. This is a simulation-based notion whereby the simulator is able to simulate the view of a real-world adversarywithout access to any ciphertexts at all. In the setting of probabilistic encryption, such asimulation notion is known as semantic security, and simulation is possible knowing nothingabout the plaintexts. In deterministic encryption however, the adversary can always checkif a ciphertext is an encryption of a given message by simply encrypting the message andchecking that the same ciphertext is obtained. To model this in our notion, we allow thesimulator an equality checking oracle.The second challenge is that of adaptive security, where the distribution of messagesdepends on the public key. In this case, the distribution could be a uniformly randommessage except conditioned on the first ciphertext bit being 0. The adversary can clearlylearn information about the message by then simply looking at the first ciphertext bit.In RagSegVad13, the solution to this latter problem was to upper bound the descriptionlength of the distribution, and ensure the public key is larger than this description. Wegeneralize this approach to allow constraining some resource of the distribution. This resourcecould be, for example, computational time or depth instead of description size. We thenensure that encryption takes more of the resource than the distribution. More generally, thedistribution is simply constrained to come from some restricted set R = (Rλ)λ. Examples ofsuch R could include algorithms with a certain running time, certain computational depth,certain description size, etc.Our security notion. With this intuition in hand, we are now ready to give our securitynotion. For a vector m, let EqPat(m) denote the partition of m into identical elements; thatis, EqPat is the informaiton about which mi ∈ m are equal. In particular, EqPat(m) revealshow many messages are in m. For an algorithm A, let be the entire program trace ofA, the list of the initial, final, and all intermediate states of A; in particular ProgTr includesthe inputs and outputs of A. When necessary, we will think of ProgTr as being an additionaloutput of the algorithm, so we will write (x, ProgTr) ← A() where x is the original output ofA. Let R = (Rλ)λ be a collection of algorithms, let A = (A0,A1) be an adversary, and S asimulator. Consider the following games SEMReal(R, λ) and SEMSim(R,S, λ) between A,Sand a challenger:(sk, pk) ← Gen(1λ)(D, ProgTr) ← A0(pk) where D ∈ Rλ(aux, m∗, P) ← D() where m∗ ∈ M∗λc∗ = (c∗ ) where c∗ ∗i i i ← Enc(pk, mi )^^^A (ProgTr, aux, c)inf ← 1 in SEMReal ^^SGtChm∗ (ProgTr, aux, EqPat(m∗)) in SEMSimwhere GTCh ∗m(i, m) = 1(m == mi )w ← P(inf)Above, GtCh stands for “guess-then-check.” We assume a model of computation for D() wherethe running time for D() is bounded by some fixed global polynomial in the bit-length ofthe description of D. Circuits automatically satisfy this notion. For Turing machines, we justinclude in the description of D() the running time represented in unary.The distribution D() produces a tuple where m is the plaintext distribution, aux theauxiliary input, and P is a predicate. Note that we allow the number of messages in m to benon-constant. In BelBolONe07, P is replaced with inf, and the adversary’s goal is to outputinf. In our setting, this is modeled as having P be a point function that accepts only inf. Ournotion is more general. For example if the goal is to compute a string that is very “close”to inf for some notion of closeness, we can simply have P be the predicate that accepts allstrings close to inf. P is kept secret to model the fact that the adversary is not supposed tobe given inf in the clear, but rather compute it (or an approximation thereof) using c.Let w (standing for “win”) be the output of the experiment, which we denote by w ←SEMReal(R, λ) or w ← SEMSim(R,S, λ).Definition 2. A deterministic encryption scheme Π = (Gen, Enc, Dec) is R-Strongly Se-mantically Secure (SS Secure) if, for all PPT adversaries A = (A0,A1) and all inversepolynomial ^, there exists a PPT simulator S such that |Pr[1 ← SEMReal(R, λ)] − Pr[1 ←SEMSim(R,S, λ)]| ≤ ^(λ).Security in the Random Oracle Model. In this work, we will be giving constructionswith security proofs in the random oracle model (ROM). Modeling deterministic encryptionin the ROM involves some non-trivial choices.For this work, we will model the random oracle as follows. A uniform oracle O is sampled.Then A and S are given query access to O. Moreover, we will allow S to view the queriesA0 makes to O (since these would naturally be included in ProgTr), but cannot influencethe query responses. Preventing the simulator from changing query responses corresponds tothe non-programmable ROM (Jesper Buus Nielsen, Separating Random Oracle Proofs fromComplexity Theoretic Proofs: The Non-committing Encryption Case (Nielsen02a)), whichavoids certain problematic impossibilities. The probabilities in Definition 2 are taken over Oin addition to the randomness of the experiment.2.2 Stateful Deterministic EncryptionHere, we define stateful deterministic encryption, which allows the encrypter to maintain astate that is updated with every encryption. We wish to allow multiple encrypters, but do notwant to require the different encrypters to coordinate a shared state. Instead, each encrypterwill maintain their own private state. However, we ultimately want to prevent two encryptersfrom accidentally outputting the same ciphertext if encrypting the same message, so as tohide the equality pattern of ciphertexts. This is unavoidable if all encrypters are identicaland deterministic. Therefore, we introduce identities, and give each encrypter a unique –though public and potentially predictable – identity, which is used during encryption. Theidentity may be updated with each encrytion operation. We here do not specify how identitiesshould be updated, but we will insist that no two ciphertexts are ever created under the sameidentity. So for example, we can imagine that an encrypter’s identity is id = s||ctr, where s isa unique identifier for that encrypter, and ctr is a counter, initially 0, indicating how manytimes that encrypter has encrypted a message.Definition =(Gen, Enc, –Gen(1λ) is a probabilistic algorithm that samples a public key / secret key pair (pk, sk)– identity c.– Dec(sk, c) is a deterministic algorithm that takes as input a secret key sk and a ciphertextc and outputs a message m.– Correctness: For all λ, except with λ probability over (pk, sk) ← Gen(1 ), wehave Dec(sk, Enc(pk, id, m)) = m for all m ∈ Mλ, id ∈ {0, 1}∗.Security. We now observe that stateful deterministic encryption means that repeatedencryptions of the same message potentially give different ciphertexts, thereby potentiallyhiding when two messages are identical. This gives rise to a stronger notion of security.Let R be a collection of algorithms, let A be an adversary, and S a simulator. Considerthe following games SEM′ ′Real(R, λ) and SEMSim(R,S, λ) between A,S and a challenger:(sk, pk) ← Gen(1λ)(D, ProgTr) ← A0(pk) where D ∈ Rλ(aux, id, m∗, P) ← D() where m∗ ∈ M∗λc∗ = (c∗ ) where c∗ ← Enc(pk, i ∗i i i di, mi )^^^A (ProgTr, aux, id, c∗) in SEM′inf ← 1 Real^^ SGTChm∗ (ProgTr, aux, id) in SEM′Simwhere GtCh ∗m(i, m) = 1(m == mi )^(inf) if all id ∈ id are uniqueotherwise Let w be the output of the experiment, which we denote by w ← SEM′Real(R, λ) or w ←SEM′Sim(R,S, λ).Definition 4. SS’secure if, for aPPT simulator Note that it is necessary that all identities in id be distinct in order to avoid equalityqueries, since if two identities are the same and used to encrypt the same message, thenthe ciphertexts will be equal. On the other hand, since id is considered public, it is stillpossible for the adversary to perform a guess-and-check attack. Therefore it is necessary forour simulator to be able to make such queries.1. Letas . Proof. We simply include the vector of id as part of the auxiliary input, which is fine sincethey are public. Since the id’s are distinct, the equality pattern of id||m is the trivial patternsaying that all messages are distinct.2.3 Other VariationsOther variations of our definition are possible. We can imagine a static security notion byrequiring that A0 produce D before seeing pk. We can allow for computationally unboundedbut query bounded simulators. In this case, we can also consider relaxing the query bound tobe, say, sub-exponential. We can also imagine allowing S to simulate pk, which we call weaksemantic security.3 Resource Hard FunctionsA crucial tool we will be using in this work is the notion of a resource hard function (RHF),which generalizes concepts like delay functions. Let R = (Rλ)λ where each Rλ is a collectionof algorithms.Definition 5. A Resource Hard Function (RHF) for a collection of algorithms R is a pairof algorithms (Setup, F ) such that:– Setup(1λ) is a probabilistic algorithm which takes as input λ and outputs a commonreference string crs.– F (crs, x) is a deterministic algorithm which takes as input crs and an input x ∈ {0, 1}λ,and outputs a y ∈ {0, 1}λ.– Security: For any polynomial-time algorithm A (which may or may not be in R) thereexists a negligible negl such that:[ ] PrF(x) = F < negl(λ) Note the role of A is to allow a pre-processing stage that depends on crs but not x, which isrequired to be polynomial time but may be outside R.We can consider several different families of R, giving rise to known concepts:– Rλ is the set of algorithms running in time at most p(λ), for some polynomial p. An RHFfor such Rλ are then functions that require significant time to compute. These strengthenproofs of work (Cynthia Dwork and Moni Naor, Pricing via Processing or CombattingJunk Mail (DwoNao92)) by requiring an actual function rather than just a proof. Wecan construct such a function by de-randomizing proofs of work. For example, if O is arandom oracle, then we can let F (crs, x) = (y1, · · · , yλ), where yi is the first (under someordering) value such that O(crs, x, i, y ℓ 1i) = 0 , for an appropriate ℓ .– Rλ is the set of algorithms of computational depth less than p(λ), where p could be apolynomial or perhaps a logarithmic function. An RHF for such Rλ are commonly knownas delay functions.– Rλ is the set of algorithms that have storage capacity less than p(λ). An RHF for such Rλare then functions that require significant space to compute. These are related to memory-hard functions. Indeed, certain memory-hard functions give such a space lower-bound(Joël Alwen and Jeremiah Blocki and Krzysztof Pietrzak, Sustained Space Complexity(AlwBloPie18)). –Rλ is the set of algorithms whose description size is at most p(λ). Such RHFs are functionsthat require storing a long description to compute. We can easily construct such a functionas F (crs, x) = f(x), where f is a k-wise independent function contained in crs. Thisconstruction is implicit in RagSegVad13.1 ℓ will be logarithmic, which means that yi will be guessable with non-negligible probability without putting inany work at all. Therefore, we need several yi to ensure that the whole vector is only guessable with negligibleprobability.3.1 RHFs with ROM AdversariesIn this work, we will consider a variant of RHFs where A,F are allowed to make queries to arandom oracle O. Note this is a random oracle that is independent of the construction; theconstruction may or may not make use of random oracle, but if it does it will be an oraclethat is independent of O. Instead, this oracle O serves just to aid the adversary. Normally incryptographic definitions, an adversary can always simulate a random oracle for itself using,say, lazy sampling or a k-wise independent hash function. Depending on the set of algorithmsR, this may not work for RHF adversaries, however. The reason is that A would need tocommunicate to F the lazily-sampled values or k-wise independent function, and just havingthe ability to receive these values may put F outside of R. Indeed, if the description size ofF must be very small, this would limit the number of simulated random oracle values thatA can pass to F . Therefore, we will model the random oracle O as an extra resource. Thisgives rise to a stronger definition of RHFs.Definition 6. A ROM-secure Resource Hard Function (RHF) for a collection of oracle-aidedalgorithms R = (Rλ)λ is a pair of algorithms (Setup, F ) such that:– Setup(1λ) is a probabilistic algorithm which takes as input λ and outputs a commonreference string crs.– F (crs, x) is a deterministic algorithm which takes as input crs and an input x ∈ {0, 1}λ,and outputs a y ∈ {0, 1}λ.– Security: For any polynomial-time oracle aided algorithm AO (which may or may not bein R) there exists a negligible negl such that:^ ^Pr^FO(x) = F < negl(λ) where FUNC represents the uniform distribution over oracles O.Observe that in the cases discussed above for ordinary RHFs, we can readily adapt toROM-secure RHFs:– Rλ is the set of algorithms running in time at most p(λ). In this case, we can simulate therandom oracle with a modest blow-up in running time using, say, lazy sampling, whichcan be accounted for by using a slightly larger polynomial p. Thus, security for oracle-freeR implies security for oracle-aided R.– Rλ is the set of algorithms of computational depth less than p(λ). Here again, we can uselazy sampling.– Rλ is the set of algorithms that have storage capacity less than p(λ). Here, if the depth islow enough, lazy simulation or k-wise independent hashing may not be feasible. However,we can simulate instead in low space using a pseudorandom function (PRF). Thus, aslong as there are PRFs computable in space roughly p(λ), we can again conclude thatsecurity for oracle-free R implies security for oracle-aided R.– Rλ is the set of algorithms whose size is at most p(λ). Again here, we may need to use aPRF in order to simulate.4 Deterministic Encryption from Public Key EncryptionHere we present our first construction of deterministic PKE. This is a riff on the constructionfrom BelBolONe07, generating the randomness for a probabilistic PKE by hashing themessage. The difference is that we incorporate a resource-hard function (RHF), which isneeded to get adaptive security against resource-constrained distributions. We assume thereader is familiar with the notion of PKE; for completeness the definition is provided inAppendix A.LetLet= ) Output c ← EncPKE(pkPKE, m; r)Dec (sk PKE, c) : Ou ′DPKE D tput m ← DecPKE(skPKE, c)Above, the notation EncPKE(pkPKE, m; r) means to run EncPKE(pkPKE, m) using random coinsr.5 Deterministic Encryption Without Ciphertext ExpansionHere, we give our construction of DPKE using a trapdoor permutation. This has somesimilarities to OAEP, in that is combines a Feistel network with a trapdoor permutation(TDP). We assume the reader is familiar with the notion of a TDP; for completeness thedefinition is provided in Appendix A.Construction 2 Let ΠTDP = (GenTDP, TDP, TDP−1) be a a TDP with message lenghth ℓm.Let ΠRHF = (Setup, F ) be a secure resource hard function for a collection of algorithms R.Let O1,O2,P1,P2,P3 be five hash functions, which we will model as random oracles. Then letΠDPKE = (GenDPKE, Enc, Dec) be the following deterministic encryption scheme with messagespace Mλ = {0, 1}2×ℓm(λ):Gen (1λ) : (pk , sk )← Ge λ λDPKE TDP TDP nTDP(1 ) , crs← Setup(1 )Output (pkDPKE = (pkTDP, crs) , skDPKE = skTDP)Enc : Brea (0) (1)DPKE k m into two ℓm -bit r and r , , ⊕ P (1) (1)1(r ||y )x(2) ← O (r(2)), y(2) ← F (crs, x(2)) (3) (1) (2) (2)2 , r ← r ⊕ P2(r ||y )r(4) ← r(2) ⊕ P (3(r3))e = TDP(pk (3)TDP, r )Output c = (r(4), e)Note that a TDP with message length ℓm can be trivially extended to a TDP with message′ length ℓm > ℓ by simply applying the to the first ℓm bits, and then outputtinglast ℓ′m − ℓm bits in the clear. Thus, our construct can be adapted to securely encrypt anymessage size, and achieves zero ciphertext expansion as long as the message has size at least2ℓm.A Cryptographic Building BlocksBuilding Block: PKE. Ordinary probabilistic PKE, or simply PKE, is syntactically thesame as deterministic PKE, except that encryption is randomized. In terms of security, PKEdemands the following:Definition Π = (Gen, Enc, Dec) with message space M =(M )λ is A = (A0,A1), there exists afunction negl negl(λ), where W(λ) is the pro ′b bability b = 1the following game:(pk, sk)← Gen(1λ)(m , m 1, ,c← Enc(pk, mb)b′ ← A1(ProgTr, c)Building Block: TDP. A trapdoor permutation is as follows:TDP−1) and a –If (pk, sk)← Gen(1 ), then TDP(pk, ·) is a function from {0, 1}ℓm to {0, 1}ℓm(λ).– Correctness: There is a negligible function negl such that, for all λ and for all m ∈Mλ,Pr[m = TDP−1(sk, TDP(pk, m)) : (pk, sk)← Gen(1λ)] ≤ negl(λ).– Sec[urity: For all PPT A, there exists a negligible fuPrm← A(pk, TDP(pk, m)) : 1λ) ]nction negl such that for all λ,(pk,sk)←Gen(m←{0,1}ℓm(λ)≤ negl(λ)SYSTEM IMPLEMENTATIONSThe computerized implementation of the invention on a networked system comprises thefollowing components and steps:Data Block Splitting Module: The plaintext data block is received over the network andsplit into two equal halves, designated as Left (L) and Right (R), by the data block splittingmodule. The data block splitting module ensures that the plaintext is divided accurately andsecurely, maintaining the integrity of the data.Round Function Module: The round function module operates on one half of the datablock (typically the right half) in each round of the Feistel network. It takes the right half(R) and a round key as inputs and produces an output that is combined with the left half(L). The round function module can be implemented using cryptographic primitives such assubstitution boxes (S-boxes), permutations, and arithmetic operations, which are optimizedfor efficient execution on networked systems.Key Scheduling Module: The key scheduling module derives a series of round keys fromthe main encryption key provided over the network. It employs techniques such as bitwiseshifts, permutations, and mathematical transformations to generate subkeys securely. Thegenerated subkeys are securely distributed to the respective round function modules for usein each round of the Feistel network.XOR Operation Module: The XOR operation module combines the output of the roundfunction with the left half (L) using the XOR (exclusive OR) operation. The XOR operationmodule ensures that the combining of the round function output and the left half is performedaccurately and efficiently over the network.Swapping Module: The swapping module exchanges the left and right halves of the datablock after each round. It ensures that the original right half becomes the new left half,and the XOR result becomes the new right half, maintaining the symmetry of the Feistelstructure. Round Iteration Module: The round iteration module controls the execution of multiplerounds of the Feistel network. It coordinates the flow of data between the data block splittingmodule, round function module, XOR operation module, and swapping module. The numberof rounds is determined based on the specific block cipher design and can be adjusted toachieve the desired level of security.Final Permutation Module: After the last round, the final permutation module concate-nates the left and right halves to form the ciphertext block. It may apply an additionalpermutation step to the concatenated block to further diffuse the data and enhance security.The computerized implementation of the Feistel network on a networked system ensuressecure encryption and decryption of data. The modular design allows for efficient executionand scalability across multiple network nodes. The use of secure communication channelsand protocols guarantees the confidentiality and integrity of the data during transmission.The invention provides a robust and efficient solution for data encryption and decryptionin networked environments, suitable for various applications such as secure communication,data storage, and digital transactions. The implementation can be optimized for specifichardware architectures and can be easily integrated into existing network security frameworks.The invention may include specifically-configured modules and / or nodes.Encryption / Decryption Nodes: Deployed throughout the computerized network, thesenodes are responsible for performing encryption and decryption tasks, utilizing the modifiedFeistel network algorithm.Key Management System (KMS): A centralized or distributed system responsible forgenerating, distributing, and managing encryption keys in a secure manner.Configuration Manager: Determines the optimal settings for the encryption system,including the number of rounds and the complexity of the round functions, based on currentnetwork conditions and security policies.In operation, the following routines may be executed:Initial Setup: The Configuration Manager assesses the network environment and securityrequirements, setting parameters such as the number of encryption rounds and specificattributes of the round functions.Key Generation and Distribution: The KMS generates a master key, from which roundkeys are derived using an adaptive algorithm. These keys are securely distributed to theEncryption / Decryption Nodes.Data Encryption: Data blocks are split into two halves. For each round, the right halfis processed through a dynamic round function that utilizes a combination of substitution,permutation, and mixing with the round key. The output is then XORed with the lefthalf. The roles of the halves are swapped, except in the final round. The process repeatsfor a predetermined number of rounds. The final output is the encrypted data, ready fortransmission or storage.Data Decryption: The process is identical to encryption but uses the round keys in reverseorder. Dynamic Round Functions: The algorithm for the round function can change based onnetwork conditions, security requirements, and specific application needs, adding an additionallayer of security.Adaptive Key Schedule: The system adapts the complexity of the key schedule and thederivation of round keys based on the overall security posture, ensuring that the encryptionremains resilient against attacks.Automatic Configuration: The system can automatically adjust its parameters (e.g.,number of rounds, round function complexity) in response to changing network conditions orthreats, maintaining optimal security and performance.Security Experiment OverviewFIG. 1 illustrates a security experiment diagram 100. The security experiment diagram 100depicts a comprehensive framework for evaluating the security properties of the encryptionsystem described herein. The diagram showcases the interactions between various componentsand the flow of information within the security experiment.In the security experiment diagram 100, the left block represents the cryptographicoperations, while the right block contains components A0 and S. The left block performsseveral key operations, including key generation, encryption, and security evaluation.The key generation process is denoted by (pk, sk) ← Gen(1λ), where pk represents thepublic key and sk represents the secret key. The security parameter λ determines the level ofsecurity for the cryptographic system.Following key generation, the diagram illustrates the process of generating auxiliaryinformation, messages, and patterns. This operation is represented by (aux, m, P ) ← D(),where aux denotes auxiliary information, m represents the message, and P denotes thepattern. The encryption process is depicted by ci ← Enc(pk, mi), where ci represents the ciphertextcorresponding to the message mi. This operation utilizes the public key pk generated earlier.A boolean value b is computed , which compares the original message m with the encrypted message may be used to verify the correctness ofthe encryption process.The diagram also shows the generation of a value w through the operation w ← P (inf),where P represents a pattern function and inf denotes some form of information input.On the right side of the security experiment diagram 100, component A0 receives the publickey pk and returns D ∈ Rλ, where Rλ may represent a set of possible outputs dependent onthe security parameter λ.Component S receives multiple inputs including aux and EqPat(m). The diagram depictsa bidirectional connection between S and the left block, showing the exchange of m, i, and bvalues. This interaction may represent a challenge-response mechanism or an iterative securityevaluation process.The flow of information in the security experiment diagram 100 is indicated by arrowsbetween components. These arrows show the transmission of values including pk, D, aux,EqPat(m), m, i, b, inf , and w. The final output w is shown exiting the system at the bottomof the left block, potentially representing the result of the security experiment.In some cases, the security experiment diagram 100 may enable private set intersectionoperations on encrypted data. The interaction between components A0 and S, along with theencrypted message processing, may allow for secure comparison and matching of encrypted setswithout revealing the underlying plaintext information. This capability may be particularlyuseful in scenarios where multiple parties need to find common elements in their respectivedatasets without compromising the privacy of non-shared data.Encryption System ArchitectureFIG. 2 illustrates a block diagram of an encryption system architecture. The systemprocesses an input message through multiple rounds of data transformation to produce anencrypted output ciphertext.The encryption process begins with an initial data block r(0). This initial data block r(0)may be split into two portions, with a first round data r(1) representing one portion and theinitial data block r(0) representing the other portion.The system incorporates a first oracle function O1 and a second oracle function O2, whichprocess data in separate paths. The first oracle function O1 may receive input from thefirst round data r(1), while the second oracle function O2 may receive input derived fromoperations on the initial data block r(0) and a second round data r(2).In some cases, the oracle functions may incorporate resource-hard functions to increasecomputational complexity. These resource-hard functions may be designed to require signifi-cant computational resources, such as memory or processing power, to evaluate. The inclusionof resource-hard functions may enhance the security of the encryption system by making itmore resistant to certain types of attacks.The system also implements a first permutation function P1, a second permutation functionP2, and a third permutation function P3. In some implementations, these permutationfunctions may be realized as trapdoor permutations. Trapdoor permutations are functionsthat are easy to compute in one direction but computationally infeasible to invert withoutknowledge of a secret trapdoor.The data flow through the encryption system proceeds as follows:1. Data from the first round data r(1) passes through the first oracle function O1, thenthrough a function F(crs,·), and finally through the first permutation function P1.2. Data from the second round data r(2) passes through the second oracle function O2,then through the function F(crs,·), and finally through the second permutation function P2.3. Data from a third round data r(3) passes through the third permutation function P3and a trapdoor permutation function TDP(pkTDP,·).The system combines these processed data streams using addition operations, representedby circled plus symbols (⊕) in FIG. 2. This combination of multiple rounds and mixingoperations contributes to the security and complexity of the encryption process.A notable feature of this encryption method is that it may produce zero ciphertextexpansion. This means that the size of the encrypted output (ciphertext) is the same asthe size of the input message (plaintext). Zero ciphertext expansion can be advantageous inscenarios where bandwidth or storage efficiency is a concern.The final output of the encryption process produces two portions: an encrypted portion eand a final round data r(4), which together form the ciphertext c. This structure, where theinitial data block r(0) is encrypted using a Feistel network structure with multiple rounds,allows for efficient encryption and decryption operations while maintaining a high level ofsecurity. The use of multiple rounds, oracle functions, permutation functions, and resource-hardfunctions in this encryption system architecture creates a complex and secure encryptionprocess. This design may provide resistance against various cryptographic attacks whilemaintaining efficiency in terms of ciphertext size and computational requirements.Encryption ProcessFIG. 3 illustrates a method 300 for processing and encrypting plaintext messages. Themethod 300 may be implemented on hardware architectures with cryptographic accelerationcapabilities, enabling efficient execution of complex encryption operations.In step 302, a setup routine may be executed. This setup routine may involve initializingcryptographic parameters, generating keys, and preparing the system for subsequent encryp-tion operations. The setup may include configuring hardware components such as dedicatedcryptographic accelerators or specialized processing units optimized for encryption tasks.Step 304 involves receiving an input plaintext message. This message may be any form ofdata that requires secure transmission or storage. The input plaintext message may be receivedthrough various interfaces, depending on the specific implementation of the encryption system.In step 306, the input plaintext message may be split into segments. This segmentationprocess may divide the message into blocks of a predetermined size, suitable for processingthrough the subsequent encryption stages. The size of these segments may be determinedbased on factors such as the block size of the chosen encryption algorithm or the architectureof the hardware accelerators being utilized.Step 308 involves processing the segments in a Feistel network. A Feistel network is asymmetric structure used in the construction of block ciphers.The Feistel network operations may be parallelized using GPU / FPGA clusters, allowingfor simultaneous processing of multiple data blocks and significantly improving encryptionspeed. This parallelization may be particularly effective for large volumes of data or inscenarios requiring real-time encryption.In step 310, a trapdoor permutation may be applied to the result of the Feistel networkprocessing. A trapdoor permutation is a bijective function that is easy to compute in onedirection but computationally infeasible to invert without special knowledge (the trapdoor).The application of the trapdoor permutation enhances the security of the encryption processby introducing an additional layer of computational complexity for potential attackers.Step 312 involves combining the ciphertext portions. This step may merge the outputs fromthe Feistel network and trapdoor permutation operations to form the complete ciphertext.The combination process may involve concatenation, interleaving, or other methods of joiningthe encrypted segments.Finally, in step 314, the ciphertext message may be transmitted. This transmission mayoccur over various communication channels, depending on the specific application and securityrequirements. The encrypted message may now be securely sent to its intended recipient,who possesses the necessary decryption keys and algorithms to reverse the encryption processand recover the original plaintext.The encryption process described in method 300 leverages both the diffusion propertiesof the Feistel network and the one-way nature of trapdoor permutations to create a robustencryption scheme. By implementing this method on hardware with cryptographic accelerationcapabilities and utilizing parallel processing techniques, the encryption system may achieveboth high security and efficient performance.Decryption ProcessFIG. 4 illustrates a method 400 for decrypting ciphertext messages. The method 400 maybe implemented in confidential computing environments using trusted execution environmentsto ensure the security and integrity of the decryption process.In step 402, the method 400 applies an inverse of a trapdoor permutation to the receivedciphertext. Following this operation, step 404 involves combining the decrypted portion withthe remaining ciphertext. The method 400 proceeds to step 406, where the result is splitinto two segments. In step 408, these segments are processed in a reverse Feistel network.The method 400 concludes with step 410, where the result is stored as a decrypted plaintextmessage. In some cases, the trusted execution environment may provide hardware-based isolation forthe decryption process, ensuring that sensitive operations such as key handling and plaintextrecovery are protected from potential attacks or unauthorized access. The confidentialcomputing environment may utilize technologies such as Intel SGX or AMD SEV to createsecure enclaves for executing the decryption method 400.The inverse trapdoor permutation applied in step 402 may be based on various crypto-graphic primitives, such as RSA or elliptic curve cryptography. The choice of the specifictrapdoor permutation may depend on factors such as security requirements, performanceconsiderations, and compatibility with existing cryptographic infrastructure.The reverse Feistel network processing in step 408 may involve multiple rounds of decryp-tion, with each round reversing the operations performed during the encryption process. Thenumber of rounds and the specific permutation and oracle functions used in each round maybe determined based on the desired level of security and computational efficiency.In some implementations, the method 400 may incorporate additional security measures,such as integrity checks or authenticated decryption, to detect any tampering or unauthorizedmodifications to the ciphertext during transmission or storage. These additional measuresmay enhance the overall security of the decryption process and provide assurance of theauthenticity and integrity of the decrypted plaintext.Client Computing ArchitectureFIG. 5 illustrates a client computing architecture 1100 that may be utilized to implementthe encryption and decryption processes described herein. The client computing architecture1100 comprises multiple subsystems interconnected via a system bus 1195, enabling efficientdata transfer and communication between components.A processing subsystem 1105 forms the core of the client computing architecture 1100.The processing subsystem 1105 includes a central processing unit 1110, which may executeinstructions for implementing the encryption and decryption algorithms. In some cases, thecentral processing unit 1110 may utilize specialized cryptographic instructions to accelerateoperations such as AES rounds or modular arithmetic.Connected to the central processing unit 1110 are several auxiliary processing components.A memory management unit 1115 may handle virtual memory operations, ensuring secureisolation between encrypted and unencrypted data regions. Cache memory 1120 may storefrequently accessed encryption keys or lookup tables, reducing latency for repetitive operationsin the Feistel network rounds.For computationally intensive tasks, a graphics processing unit 1125 may be employedto parallelize operations such as matrix multiplications in trapdoor permutations. In someimplementations, an AI / ML processing unit 1130 may optimize parameter selection forresource-hard functions or perform anomaly detection on encrypted data streams.The memory subsystem 1135 provides storage for active data and instructions. Systemmemory (RAM) 1140 may hold plaintext messages, ciphertext, and intermediate resultsduring encryption and decryption processes. Non-volatile memory 1145 may store long-termkeys and cryptographic parameters.For persistent storage, the storage subsystem 1150 includes a storage controller 1155managing both solid state storage 1160 and hard disk storage 1165. The solid state storage1160 may offer faster access times for frequently used encryption libraries, while the harddisk storage 1165 provides larger capacity for archiving encrypted data.The client I / O subsystem 1170 facilitates interaction with external devices and networks.An I / O controller 1175 coordinates data flow between various interfaces. A network interfacecontroller 1180 may handle secure communication protocols for transmitting encryptedmessages. A display interface 1185 may render visualizations of encryption processes orsecurity metrics. User input devices 1190 allow for manual entry of plaintext or cryptographicparameters. The system bus 1195 serves as the central nervous system of the client computingarchitecture 1100, enabling high-speed data transfer between subsystems. This interconnectionis crucial for maintaining performance in multi-round encryption schemes where data mustflow rapidly between processing, memory, and storage components.In some cases, the method may be deployed in edge and IoT platforms using micro-controllers with hardware security modules. These resource-constrained environments mayutilize simplified versions of the client computing architecture 1100, optimized for low powerconsumption and minimal footprint. For example, a microcontroller may integrate a reducedinstruction set central processing unit 1110 with on-chip cache memory 1120 and systemmemory 1140, while leveraging a hardware security module for key storage and cryptographicacceleration. The modular nature of the client computing architecture 1100 allows for flexible imple-mentation of the encryption and decryption processes across a wide range of devices, fromhigh-performance workstations to embedded systems. By leveraging specialized hardwarecomponents and efficient inter-subsystem communication, the architecture supports the com-putational demands of advanced cryptographic operations while maintaining the adaptabilityrequired for diverse deployment scenarios.Server-Client Network ArchitectureFIG. 6 illustrates a server-client network architecture 1200 that may support securecommunication and data processing. The architecture 1200 comprises multiple interconnectedcomponents, including client systems, network infrastructure, server systems, cloud services,and data flow services.In some cases, the client systems may include a mobile client 1210, a desktop client 1215,a web browser client 1220, and an IoT / edge client 1225. These clients may represent variousdevices or applications that interact with the network infrastructure 1230 to access servicesand resources.The network infrastructure 1230 may include a local area network 1240 and a wide areanetwork / internet 1245. In some implementations, a content delivery network 1250 may beconnected to the wide area network / internet 1245 to optimize content delivery to end-users.The server systems 1255 may comprise multiple server types, including an applicationserver 1260, a web server 1265, a database server 1270, and a file / storage server 1275. Theseservers may work in conjunction to process requests, manage data, and provide services tothe client systems.The cloud services 1280 section of the architecture may include a load balancer 1285that distributes incoming network traffic across multiple servers or computing resources. Thecloud compute 1290 component may encompass various computing paradigms, such as virtualmachines 1295, container services 1300, and serverless functions 1305.An API gateway 1310 may serve as an entry point for client requests, routing them toappropriate backend services. The cloud services 1280 may also include cloud storage 1315and database as a service 1320 components for data management and persistence.The data flow services 1325 may facilitate the movement and processing of data withinthe architecture. This may include a message queue 1330 for asynchronous communication,stream processing 1335 for real-time data analysis, batch processing 1340 for handling largevolumes of data, and an ETL (Extract, Transform, Load) pipeline 1345 for data integrationand transformation.In some implementations, the server-client network architecture 1200 may incorporate post-quantum cryptographic elements to enhance security against potential quantum computingattacks. For example, the encryption methods used for communication between clients andservers may utilize lattice-based cryptography or hash-based digital signatures, which arebelieved to be resistant to quantum attacks.The encryption method may be integrated into blockchain platforms and smart contractsystems within the architecture. For instance, the cloud compute 1290 component may hosta blockchain network where transactions are encrypted using the method described earlier.The encryption process may be represented as:C = E(K, M)Where C is the ciphertext, E is the encryption function, K is the encryption key, and Mis the plaintext message.In the context of smart contracts, the encryption method may be used to protect sensitivedata within the contract logic. For example, a smart contract function that processes encrypteddata may be represented as:result = f(D(K, C))Where f is the smart contract function, D is the decryption function, K is the decryptionkey, and C is the encrypted input data.The integration of this encryption method into the blockchain and smart contract systemsmay enhance the confidentiality and integrity of data processed within the server-clientnetwork architecture 1200, providing a robust foundation for secure distributed applicationsand data processing workflows.Blockchain and Decentralized ApplicationsThe deterministic encryption system described herein offers significant potential forenhancing privacy and security in blockchain and decentralized applications. By leveragingspecialized hardware architectures, the system can be optimized for specific use cases withinthis domain.For private set intersection (PSI) operations in blockchain networks, the encryption methodcan be implemented on FPGA clusters such as AWS F1 Instances or Azure NP-Series. Thesereconfigurable computing platforms allow for efficient parallelization of the Feistel networkrounds and trapdoor permutations central to the encryption scheme. This architecture enablesscalable private set matching, which has practical applications in supply chain verification.For instance, competing manufacturers could confidentially compare their supplier lists toidentify common high-risk vendors without exposing their full supplier networks, therebymaintaining competitive advantages while collaboratively mitigating supply chain risks.In cryptocurrency systems, the encryption method can be integrated into application-specific integrated circuits (ASICs) optimized for blockchain operations. Custom ASICsdesigned for zero-knowledge Succinct Non-interactive ARguments of Knowledge (zk-SNARKs)can incorporate the deterministic encryption into their proof circuits, enabling privatetransactions on public blockchains. The combination of delay functions with multiple Feistellayers in the encryption process provides an additional layer of security against potentialASIC-based attacks, which is crucial for maintaining the integrity of privacy features incryptocurrencies. This approach allows for enhanced transaction privacy while still enablingnecessary compliance checks, striking a balance between user anonymity and regulatoryrequirements. For non-fungible token (NFT) platforms, the encryption method can be deployed onLayer 2 scaling solutions for smart contract platforms like Ethereum, such as Arbitrum orzkSync. These Layer 2 solutions offer improved transaction throughput and reduced costscompared to the base layer, making them ideal for NFT operations. The zero ciphertextexpansion property of the encryption scheme is particularly advantageous in this context,as it allows NFT owners to prove ownership of underlying digital assets without revealingsensitive metadata. This capability enhances privacy in NFT transactions while maintainingthe verifiability essential for digital ownership. It could enable new use cases for NFTs inindustries where asset ownership needs to be proven without disclosing specific details, suchas in intellectual property rights management or exclusive access control systems.The versatility of the deterministic encryption system across these blockchain and de-centralized application scenarios demonstrates its potential to address key challenges indata privacy, secure computation, and verifiable transactions in decentralized networks. Bytailoring the implementation to specific hardware architectures and blockchain protocols, thesystem can provide robust security guarantees while enabling novel functionalities in therapidly evolving landscape of distributed ledger technologies.Healthcare and Biomedical ResearchIn genomic research applications, the encryption method can be implemented on high-performance computing (HPC) clusters utilizing vectorized processing capabilities, such asIntel Xeon Scalable Processors with AVX-512 instructions. These processors, capable ofperforming 512-bit vector operations, can significantly accelerate the multi-round Feisteloperations central to the encryption scheme. This architecture enables researchers to queryencrypted genomic databases for allele frequencies without accessing individual patient data,providing a powerful tool for population-level genetic studies while maintaining strict privacycontrols. The ability to perform real-time encrypted searches on large-scale genomic datasetscould revolutionize the speed and scope of genetic research, potentially leading to fasterdiscoveries in areas such as personalized medicine and disease risk assessment.For clinical trial matching, the encryption system can be deployed on edge computingplatforms with integrated hardware security modules (HSMs), such as ESP32-S3 or RaspberryPi Pico W microcontrollers. These low-power devices, equipped with AES-256 acceleratorsand secure boot capabilities, allow hospitals to confidentially match trial criteria againstpatient records using Feistel-based encrypted indexes. By performing these operations at thenetwork edge, healthcare providers can maintain data security and reduce latency in thematching process. This approach could significantly streamline the recruitment process forclinical trials, potentially accelerating the development of new treatments while ensuringpatient privacy is protected at every step.In medical device security applications, the encryption method can be implemented onquantum-resistant hybrid systems. These systems combine lattice-based trapdoor permuta-tions, such as NTRU (N-th degree Truncated polynomial Ring Units), with classical Feistelnetworks to provide forward-secure storage for medical records. This hybrid approach offersprotection against both current cryptographic threats and potential future quantum comput-ing attacks. Implantable medical devices utilizing this architecture can transmit encryptedbiometric data that remains searchable for anomaly detection, enabling real-time monitoringand early warning systems for patient health. The quantum-resistant nature of the encryptionensures long-term security for sensitive medical data, which is crucial given the extendedlifespan of many implantable devices and the potential for future advancements in quantumcomputing technology.Financial ServicesFor transaction monitoring in banking systems, the encryption method can be implementedon confidential computing environments such as Intel Software Guard Extensions (SGX) orAMD Secure Encrypted Virtualization (SEV). These trusted execution environments (TEEs)create isolated enclaves within the processor, protecting sensitive data and computations fromunauthorized access, even in the presence of compromised operating systems or hypervisors.This architecture allows banks to search encrypted transaction logs for money launderingpatterns without decrypting customer data, maintaining compliance with data protection reg-ulations while enabling effective financial crime detection. The stateful encryption capabilitiesof the system can be particularly advantageous in cross-border financial compliance scenarios,where adaptive security measures are crucial to address varying regulatory requirementsacross jurisdictions.In high-frequency trading applications, the encryption system can be deployed on modernx86 / ARM processors equipped with cryptographic extensions, such as Intel Ice Lake orAMD Ryzen CPUs featuring Advanced Encryption Standard New Instructions (AES-NI).These hardware-accelerated cryptographic operations significantly reduce the computationaloverhead of encryption and decryption processes, crucial for maintaining the ultra-low latencyrequired in high-frequency trading environments. This architecture enables the implementationof encrypted order books, allowing for sophisticated pattern analysis in market data feedswithout exposing proprietary trading strategies or sensitive client information. The zerociphertext expansion property of the encryption scheme is particularly valuable in this context,as it maintains the ciphertext length efficiency essential for minimizing data transmissiontimes and storage requirements in high-speed trading systems.For dark pool operations in financial markets, which require utmost confidentiality andsecurity, the encryption method can utilize secure coprocessors such as IBM 4764 / 4765 orAWS Nitro Enclaves. These isolated hardware modules provide a secure environment for keymanagement and execution of cryptographic operations, including the trapdoor permutationfunctions central to the encryption scheme. This architecture enables the matching of largeorders via encrypted private set intersection protocols, allowing dark pool operators tofacilitate trades between parties without revealing order details to unauthorized entities. Thedeterministic nature of the encryption allows for efficient matching of encrypted orders whilepreventing information leakage that could lead to front-running or other market manipulationtactics in these sensitive trading environments.Further Example Use Cases and EmbodimentsThe zero ciphertext expansion property of the encryption system may be particularlyadvantageous in bandwidth-constrained IoT networks. In some cases, the method may beimplemented on microcontrollers with hardware security modules, such as ESP32-S3 devices,enabling adoption in 5G / 6G IoT deployments where minimizing data transmission overheadis crucial.For applications requiring resistance against distributed denial-of-service (DDoS) attacks,the resource-hard function integration in the encryption method may be leveraged. In someaspects, FPGA-based implementations in API gateways may utilize proof-of-work variantsof the encryption scheme to deter malicious traffic while maintaining legitimate serviceavailability. In password database security scenarios, the encryption system’s memory-hard functionsmay be implemented on specialized hardware designed for key derivation, such as dedicatedASIC or FPGA modules. This approach may provide enhanced protection against GPU-basedcracking attempts on stored password hashes.For time-lock encryption applications, such as secure will disclosures, the delay functionsincorporated in the encryption method may be deployed on custom hardware implementationsdesigned to enforce specific time delays in decryption processes. This may enable the creationof time-bound access controls for sensitive documents or data releases.In blockchain state proof systems, the deterministic properties of the encryption methodmay be utilized to create verifiable encrypted historical states. Implementations on blockchain-specific hardware, such as custom ASICs or FPGAs optimized for cryptographic operations,may enable efficient verification of past blockchain states without compromising the privacyof the encrypted data.For encrypted database join operations across multiple organizations, the encryptionsystem may be deployed on secure multi-party computation (MPC) platforms. This architec-ture may leverage the deterministic nature of the encryption to enable data matching andaggregation across encrypted datasets from different entities without revealing the underlyingplaintext information.Throughout this disclosure, various terms and phrases are used to describe features of thedisclosed technology. It is to be understood that these terms and phrases may encompass avariety of meanings and definitions, as is common in the field of technology and patent law.The definitions of these terms may vary depending on the context in which they are used,the specific embodiment being described, or the interpretation of the technology by thoseskilled in the art.In various embodiments, certain variable names, symbols, or labels may be used in theclaims to represent various elements, components, or steps of the described methods, systems,and apparatuses. These variable names, symbols, or labels are provided for convenience andclarity in describing the claimed subject matter. However, it should be understood thatthe use of such variable names, symbols, or labels in the claims does not necessarily limitthese elements, components, or steps to being the same specific entities described in thespecification or in other parts of the disclosure. The variable names, symbols, or labels usedin the claims should be interpreted broadly and may encompass various implementations,variations, or equivalents of the described elements, components, or steps, unless explicitlystated otherwise or clearly limited by the context of the claim. As such, the scope of theclaims is not confined to the specific examples or embodiments described in the specification,but rather extends to the full breadth of the inventive concepts disclosed herein.For instance, terms such as "computing device," "processor," "memory," and "network"may refer to a wide range of devices, components, systems, and configurations known in theart, and their specific definitions may differ based on the implementation or design of thesystem. Similarly, phrases like "securely storing," "computing a vector," and "generating amessage" may involve various methods, techniques, and processes that achieve the same orsimilar outcomes but may be executed in different manners.It is also to be understood that the use of terms in the singular or plural form is notintended to limit the scope of the claims. For example, the mention of "a computing device"does not preclude the presence of multiple computing devices within a system. Likewise,references to "a network" may include various interconnected networks or a single networkcomprising multiple segments or layers.Furthermore, the use of the term "may" in relation to an action or feature indicates thatthe action or feature is possible, but not necessarily mandatory. This term is used to describeoptional or alternative aspects of the disclosed technology that provide flexibility in how thetechnology may be implemented or utilized.The definitions provided herein are intended to serve as examples and are not exhaustive.Those skilled in the art may ascribe different meanings to these terms based on the context,the specific technology being described, or the advancements in the field. Therefore, thedefinitions of the terms and phrases used in this disclosure and the claims are to be interpretedbroadly and in a manner consistent with the understanding of those skilled in the relevantart. The use of the word "a" or "an" when used in conjunction with the claims herein is to beinterpreted as including one or more than one of the element it introduces. Similarly, theuse of the term "or" is intended to be inclusive, such that the phrase "A or B" is intended toinclude A, B, or both A and B, unless explicitly stated otherwise.Reference throughout the specification to "one embodiment," "another embodiment," "anembodiment," and so forth, means that a particular feature, structure, or characteristicdescribed in connection with the embodiment is included in at least one embodiment of thepresent disclosure, and may not necessarily be present in all embodiments. Furthermore, theparticular features, structures, or characteristics may be combined in any suitable manner inone or more embodiments without limitation.The use of the terms "first," "second," and the like does not imply any order or sequence,but are used to distinguish one element from another, and the terms "top," "bottom," "front,""back," "leading," "trailing," and the like are used for descriptive purposes and are notnecessarily to be construed as limiting.As used herein, the term "processor" refers to any computing entity capable of executinginstructions to perform a specific set of operations, whether implemented in hardware,firmware, software, or any combination thereof. This definition includes a broad range ofprocessing technologies and architectures. The term encompasses general-purpose processorssuch as Central Processing Units (CPUs), specialized processors such as Graphics ProcessingUnits (GPUs), as well as highly specialized hardware accelerators such as Neural ProcessingUnits (NPUs) for artificial intelligence applications and Tensor Processing Units (TPUs) formachine learning workloads.The term also encompasses reconfigurable computing architectures such as Field-ProgrammableGate Arrays (FPGAs) for applications requiring specialized processing configurations, Application-Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Systolic Array Pro-cessors, and emerging computing paradigms such as Quantum Processors that leverageprinciples of quantum mechanics. System on Chip (SoC) designs, heterogeneous computingsystems, Edge Computing Processors for distributed network applications, cloud-based anddistributed processors, multi-core and parallel processors, and Neuromorphic processorsthat draw inspiration from biological neural architectures are all encompassed within thisdefinition. The term "processor" also encompasses the associated memory hierarchies, includingprimary memory (such as RAM), secondary storage (such as hard drives and SSDs), andcache memory, which work in conjunction with the processor to store and retrieve datanecessary for executing instructions. In this patent application, any reference to a "processor"should be interpreted broadly to include any type of processing unit capable of performingthe described functions, regardless of its specific implementation, architecture, or physicalform. As used herein, the term "messages" may refer to any form of data or information thatcan be processed, transmitted, or stored in a digital format. Messages may include arbitrary-length plaintext messages, pre-hashed messages, concatenated messages, binary data, networkprotocol messages, database records, and time-stamped messages. Messages may be composedof characters, symbols, or binary data and may represent various forms of content such astext, numbers, multimedia, executable code, or any other data that can be digitally encoded.Messages may be used as input for cryptographic functions, such as keyed hash functions,where they are transformed into a fixed-size hash value influenced by a secret cryptographickey. The term "messages" encompasses a wide range of data types and structures, from simpletext strings to complex structured data, and may include metadata, headers, footers, or otherinformation that facilitates the processing, transmission, or interpretation of the content.Messages may be generated by users, systems, or processes and may be intended for variouspurposes, including communication, authentication, verification, logging, or any other functionthat involves the use of digital data.Messages may also include data formats specific to artificial intelligence and machine learn-ing applications, such as tensors, feature vectors, embeddings, model parameters, activationmaps, training examples, and inference requests. In distributed and edge computing contexts,the term "messages" further extends to include event streams, state updates, service requests,synchronization messages, and smart contract transactions used in blockchain platforms.As used herein, the terms "store," "storing," "storage," or variants thereof refer to anymeans, methods, systems, or processes for recording, retaining, or preserving data in aretrievable format. This terminology encompasses a broad spectrum of technologies andmechanisms that may be employed to maintain information for future access or reference.The term includes traditional electronic storage technologies such as magnetic storage(including hard disk drives, magnetic tape, and floppy disks), optical storage (including opticaldiscs, holographic storage, and optical tape), and solid-state storage (including solid-statedrives, flash memory, static random-access memory, dynamic random-access memory, andread-only memory). It also encompasses emerging storage technologies such as DNA storage,molecular storage, quantum storage, and photonic storage.Storage terminology may refer to various architectural organizations and hierarchies ofdata repositories. This includes primary storage (main memory, cache memory) designedfor rapid access during processing operations; secondary storage providing non-volatileretention of larger data volumes; and tertiary storage for archival purposes. The terminologyextends to distributed storage architectures such as network-attached storage (NAS), storagearea networks (SAN), direct-attached storage (DAS), and object storage systems. It alsoincludes cloud-based storage configurations, including public, private, and hybrid cloudstorage implementations; edge storage systems located at network peripheries; and fog storagesystems distributed between centralized and edge locations.The definition encompasses storage virtualization technologies that abstract physicalstorage resources and present them as logical storage units, including virtual disks, software-defined storage, and storage hypervisors. It also includes storage orchestration systems thatmanage data placement, replication, and migration across distributed infrastructures.The terminology extends to various data organization and management paradigms. Thisincludes file systems that organize data into files and directories; block storage systems thatmanage data as fixed-sized blocks; object storage systems that handle data as discrete objectswith metadata; and content-addressable storage systems that retrieve data based on contentrather than location. It also includes specialized storage structures such as databases, datalakes, data warehouses, and knowledge repositories.Storage terminology encompasses various operational characteristics and capabilitiesof storage systems. This includes persistent storage that maintains data integrity acrosspower cycles; volatile storage that requires continuous power to retain data; and non-volatilestorage that preserves data without power. It also includes immutable storage that preventsmodification of stored data; append-only storage that allows additions but not modifications;and version-controlled storage that maintains historical states of data. The term furtherencompasses encrypted storage that protects data confidentiality; redundant storage thatduplicates data to prevent loss; and resilient storage that maintains availability despitecomponent failures.In specialized computing contexts, storage terminology may refer to domain-specificstorage mechanisms. For blockchain and distributed ledger technologies, this includes on-chain storage within the blockchain itself and off-chain storage that maintains references toexternally stored data. For neural networks and artificial intelligence systems, it includesweight storage for maintaining learned parameters and activation storage for intermediatecomputational results. For quantum computing systems, it refers to quantum state storagethat preserves quantum information, while for edge computing, it includes transient storagefor temporary data processing at network boundaries.The term "storage" also encompasses the protocols, interfaces, and access methods usedto interact with stored data. This includes file access protocols (such as NFS, SMB, andHDFS), block access protocols (such as iSCSI, Fibre Channel, and ATA), and object accessprotocols (such as S3, Swift, and CDMI). It also includes direct memory access mechanisms,memory-mapped file interfaces, and storage controller interfaces.The term "database" should be construed to mean a blockchain, distributed ledgertechnology, key-value store, document-oriented database, graph database, time-series database,in-memory database, columnar database, object-oriented database, hierarchical database,network database, or any other structured data storage system capable of storing andretrieving information. This may include traditional relational database management systems(RDBMS), NoSQL databases, NewSQL databases, or hybrid database systems that combinemultiple database paradigms. The database may be centralized, distributed, or decentralized,and may employ various data models, indexing strategies, and query languages to organizeand access the stored information. It may also incorporate features such as ACID (Atomicity,Consistency, Isolation, Durability) compliance, eventual consistency, sharding, replication,or partitioning to ensure data integrity, availability, and scalability. The database may behosted on-premises, in the cloud, or in a hybrid environment, and may support various accessmethods including direct queries, API calls, or event-driven architectures.The term "database" further encompasses specialized data storage and managementsystems designed for particular domains or use cases. This includes blockchain and distributedledger technologies used for secure, decentralized transaction records, edge databases optimizedfor resource-constrained environments, vector databases for high-dimensional data, time-seriesdatabases for temporal data management, knowledge graphs for representing interconnectedinformation, federated databases for integrating autonomous systems, and emerging paradigmssuch as quantum databases that leverage quantum computing principles.The terms "connected," "coupled," or any variant thereof, mean any direct or indirectconnection or coupling between two or more elements, and may encompass the presence ofone or more intermediate elements between the two elements that are connected or coupledto each other.In the context of modern computing architectures and network topologies, these terms mayalso refer to various connection modalities. This includes physical connections through wiredor wireless interfaces, logical connections operating independently of the physical layer, APIconnections allowing software components to communicate, and microservice connections indistributed architectures. The terminology extends to edge-to-cloud connections for distributedprocessing environments, blockchain connections for distributed ledger systems, quantumconnections for secure communication, and neural network connections for artificial intelligencesystems.nyu As used herein, the term "display" or "displaying" refers to any means, method, apparatus,or process for visually presenting or otherwise conveying information to a user. This termi-nology encompasses a broad spectrum of technologies and presentation modalities that maybe employed to render content perceivable by a user. The term includes traditional displaytechnologies such as cathode ray tubes (CRTs), liquid crystal displays (LCDs), light-emittingdiode (LED) displays, organic light-emitting diode (OLED) displays, micro-LED displays, andelectronic paper displays. It also encompasses specialized display types such as transparentdisplays, flexible displays, foldable displays, stretchable displays, and holographic displays.The term "display" may also refer to projection systems, including traditional projectors,laser projectors, pico projectors, and holographic projection systems. It further includesimmersive display technologies such as head-mounted displays (HMDs), virtual reality (VR)headsets, augmented reality (AR) glasses, mixed reality (MR) systems, and smart contactlenses. The terminology extends to ambient display methods that integrate visual informationinto the environment, such as smart mirrors, interactive surfaces, projection mapping systems,and volumetric displays.The definition also encompasses non-visual display modalities that may complement orsubstitute for visual displays. This includes auditory displays such as speech output systems,sonification interfaces, and spatial audio; haptic displays that communicate through tactilefeedback, vibration patterns, or force feedback; and other sensory output mechanisms such asolfactory displays and thermotactile interfaces. Multimodal displays that combine multiplesensory channels for information presentation are also included within this terminology.The term "display" further encompasses the software and computational componentsinvolved in rendering information. This includes rendering engines, graphics processingpipelines, display servers, and compositing systems. It also includes specialized displayrendering techniques such as rasterization, ray tracing, vector graphics, procedural generation,and neural rendering. The term extends to user interface paradigms such as graphical userinterfaces (GUIs), natural user interfaces (NUIs), voice user interfaces (VUIs), brain-computerinterfaces (BCIs), and ambient intelligence systems.In the context of accessibility, the term "display" includes assistive technologies andalternative display methods designed to accommodate diverse user needs. This encompassesscreen readers, braille displays, audio descriptions, high-contrast modes, color-shifted pre-sentations, and other adaptive display mechanisms. The terminology also includes displaypersonalization techniques such as adaptive interfaces, contextual displays, and user-specificrendering optimizations.The description of the embodiments of the present disclosure is intended to be illustrative,and not to limit the scope of the claims. Many alternatives, modifications, and variations willbe apparent to those skilled in the art. A number of implementations have been described.Nevertheless, it will be understood that various modifications may be made without departingfrom the spirit and scope of the disclosure. Accordingly, other implementations are withinthe scope of the following claims.

Claims

CLAIMS1. A method for secure message encryption in a computerized system, the method comprising:(a) executing, by a processor, a setup routine, the setup routine comprising:(i) selecting one or more resource hard functions to be used for encryption;(ii) establishing a trapdoor permutation;(iii) generating a public key and secret key pair;(b) receiving, by the processor, an input plaintext message over a network interface;(c) splitting, by the processor, the input plaintext message into a first segment and a secondsegment; (d) processing, by the processor, the first segment and the second segment in a Feistelnetwork, the network executing at least three rounds, wherein(i) each round of the Feistel network further comprises at least one hash function;(ii) the Feistel network further comprises execution of a first secure resource hardfunction and a second secure resource hard function, wherein the first and secondfunctions are executed in separate rounds;(e) applying, by the processor, the trapdoor permutation to at least a portion of the Feistelnetwork result to generate a first ciphertext portion;(f) combining, by the processor, the first ciphertext portion with a remaining portion ofthe Feistel network result to generate a ciphertext message, wherein the ciphertextmessage has the same length as the input plaintext message; and(g) transmitting, by the processor, the ciphertext message over the network interface.

2. The method of claim 1, further comprising:(a) receiving, by the processor, the ciphertext message over the network interface;(b) applying, by the processor, an inverse of the trapdoor permutation to the first ciphertextportion to generate a decrypted portion;(c) combining, by the processor, the decrypted portion with the remaining portion of theciphertext message, and splitting the result into two segments;(d) processing, by the processor, the two segments in the Feistel network, the networkexecuting at least three rounds in reverse order; and(e) storing, by the processor, the result of the Feistel network as a decrypted plaintextmessage in a memory.

3. The method of claim 1, wherein the first and second secure resource hard functions arethe same function.

4. The method of claim 1, wherein the first and second secure resource hard functions arenot the same function, but are considered hard in the same dimension, where the dimensionis one of parallel computation time, sequential computation time, or computational depth.

5. The method of claim 1, wherein all the hash functions in the Feistel network are identicalfunctions.

6. The method of claim 1, wherein the resource hard functions are selected from the groupconsisting of: deterministic proofs of work taking significant parallel computation time toexecute, memory-hard functions taking significant storage to execute, and delay functionstaking significant sequential computation time to execute.

7. The method of claim 1, wherein the Feistel network comprises:(a) applying a first oracle function to the second segment;(b) applying the first secure resource hard function to the result of the first oracle function;(c) applying a first permutation function to the second segment and the result of the firstsecure resource hard function;(d) combining the result of the first permutation function with the first segment using anXOR operation to produce a third segment;(e) applying a second oracle function to the third segment;(f) applying the second secure resource hard function to the result of the second oraclefunction; and(g) applying a second permutation function to the third segment and the result of thesecond secure resource hard function.

8. The method of claim 1, wherein the ciphertext message is stored in a database and indexedfor later retrieval without requiring decryption, thereby enabling searching over encrypteddata.

9. A system for secure message encryption, the system comprising:(a) a network interface configured to receive and transmit data;(b) a memory storing instructions; and(c) a processor coupled to the network interface and the memory, the processor configuredto execute the instructions to perform operations comprising:(i) executing a setup routine, the setup routine comprising:(1) selecting one or more resource hard functions to be used for encryption;(2) establishing a trapdoor permutation;(3) generating a public key and secret key pair;(ii) receiving an input plaintext message over the network interface;(iii) splitting the input plaintext message into a first segment and a second segment;(iv) processing the first segment and the second segment in a Feistel network, thenetwork executing at least three rounds, wherein:(1) each round of the Feistel network further comprises at least one hashfunction;(2) the Feistel network further comprises execution of a first secure resourcehard function and a second secure resource hard function, wherein the firstand second functions are executed in separate rounds;(v) applying the trapdoor permutation to at least a portion of the Feistel networkresult to generate a first ciphertext portion;(vi) combining the first ciphertext portion with a remaining portion of the Feistelnetwork result to generate a ciphertext message, wherein the ciphertext messagehas the same length as the input plaintext message; and(vii) transmitting the ciphertext message over the network interface.

10. The system of claim 9, wherein the processor is further configured to execute theinstructions to perform operations comprising:(a) receiving the ciphertext message over the network interface;(b) applying an inverse of the trapdoor permutation to the first ciphertext portion togenerate a decrypted portion;(c) combining the decrypted portion with the remaining portion of the ciphertext message,and splitting the result into two segments;(d) processing the two segments in the Feistel network, the network executing at least threerounds in reverse order; and(e) storing the result of the Feistel network as a decrypted plaintext message in the memory.

11. The system of claim 9, wherein the first and second secure resource hard functions arethe same function.

12. The system of claim 9, wherein the first and second secure resource hard functions arenot the same function, but are considered hard in the same dimension, where the dimensionis one of parallel computation time, sequential computation time, or computational depth.

13. The system of claim 9, wherein all the hash functions in the Feistel network are identicalfunctions.

14. The system of claim 9, wherein the resource hard functions are selected from the groupconsisting of: deterministic proofs of work taking significant parallel computation time toexecute, memory-hard functions taking significant storage to execute, and delay functionstaking significant sequential computation time to execute.

15. The system of claim 9, wherein the system further comprises a database configured tostore the ciphertext message and index it for later retrieval without requiring decryption,thereby enabling searching over encrypted data.

16. The system of claim 9, wherein the system is configured to operate as a security appliancein a network, receiving plaintext messages from client devices and transmitting ciphertextmessages to recipient devices.

17. A non-transitory processor-readable medium storing code representing instructions tobe executed by a processor at a computing device for secure message encryption, the codecomprising instructions to:(a) execute a setup routine, the setup routine comprising:(i) selecting one or more resource hard functions to be used for encryption;(ii) establishing a trapdoor permutation;(iii) generating a public key and secret key pair;(b) receive an input plaintext message over a network interface;(c) split the input plaintext message into a first segment and a second segment;(d) process the first segment and the second segment in a Feistel network, the networkexecuting at least three rounds, wherein(i) each round of the Feistel network further comprises at least one hash function;(ii) the Feistel network further comprises execution of a first secure resource hardfunction and a second secure resource hard function, wherein the first and secondfunctions are executed in separate rounds;(e) apply the trapdoor permutation to at least a portion of the Feistel network result togenerate a first ciphertext portion;(f) combine the first ciphertext portion with a remaining portion of the Feistel networkresult to generate a ciphertext message, wherein the ciphertext message has the samelength as the input plaintext message; and(g) transmit the ciphertext message over the network interface.

18. The non-transitory processor-readable medium of claim 17, further comprising instructionsto: (a) receive the ciphertext message over the network interface;(b) apply an inverse of the trapdoor permutation to the first ciphertext portion to generatea decrypted portion;(c) combine the decrypted portion with the remaining portion of the ciphertext message,and split the result into two segments;(d) process the two segments in the Feistel network, the network executing at least threerounds in reverse order; and(e) store the result of the Feistel network as a decrypted plaintext message in a memory.

19. The non-transitory processor-readable medium of claim 17, wherein the first and secondsecure resource hard functions are selected from the group consisting of: deterministic proofsof work taking significant parallel computation time to execute, memory-hard functions takingsignificant storage to execute, and delay functions taking significant sequential computationtime to execute.

20. The non-transitory processor-readable medium of claim 17, wherein the Feistel networkcomprises:(a) applying a first oracle function to the second segment;(b) applying the first secure resource hard function to the result of the first oracle function;(c) applying a first permutation function to the second segment and the result of the firstsecure resource hard function;(d) combining the result of the first permutation function with the first segment using anXOR operation to produce a third segment;(e) applying a second oracle function to the third segment;(f) applying the second secure resource hard function to the result of the second oraclefunction; and(g) applying a second permutation function to the third segment and the result of thesecond secure resource hard function.

Images