Artificial intelligence (AL) based encryption for data access control and transcryption

Abstract

Methods, apparatus, devices, systems, and software for probability based synchronized state machine encryption and decryption. A probability-based state machine makes up part of an Al based agent that is driven by the shared configuration between agents. The Al based agents generate an infinite number of encryptions through a combination of semi-private secret updating and data seeding. One or more agents can then synchronize such that they can all encrypt / decrypt data such that any other synchronized Al based agent can encrypt or decrypt.

Description

[0001] ARTIFICIAL INTELLIGENCE (Al) BASED ENCRYPTION FOR DATA ACCESS CONTROL AND TRANSCRYPTION

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims priority to and benefit of U.S. Provisional Patent Application Serial No. 63 / 527,934 filed July 20, 2023, which is fully incorporated by reference and made a part hereof.

[0004] FIELD

[0005] The field of this disclosure is cryptology in how to encrypt data in an efficient quantum proof way as well as better secure system topologies. Another embodiment demonstrates transcryption, the ability of converting between secret encrypt algorithms without exposing the original protected material to protect both data at rest and data in motion such as data streaming. As used herein, transcryption, and its variants, means a method of converting obfuscated data of one type into a second obfuscated data type without exposing the underlying obfuscated original data in memory or storage medium. This includes CPU Memory, GPU Memory, local / connected storage of temporary files, etc. Systems and / or devices used for performing transcryption are also included within the scope of this definition. A higher-level embodiment relates to the access control of data files accessible from a computer operating system such as Linux based, Windows, Mac, iOS, or Android. This access can be in the form of transmitted data from between systems, remote access such as FTP, or attached / local storage such as hard-drives of SAN / NAS devises.

[0006] BACKGROUND

[0007] With quantum computers off in the not so distance future, there is a need to harden encryption to be more than quantum resistant but to be quantum proof. Disclosed herein is a novel approach to quantum proof encryption using artificial intelligence (Al) based agents. Embedded in these agents is the concept of Classical Entanglement which is the digital equivalent of Quantum Entanglement. This allows Al based agents to forgo the need to transmit a key to a receiver thus reducing bandwidth and potential interception of the key. Due to this savings, encryption keys and masks can be as long as the transmitted data. In the preferred embodiment, masks for encryption of OTP (One Time Pad) and other quantum proof approaches are many multiples the size of the transmitted data with no need to transmit or expose the mask.

[0008] The disclosed embodiments also lay out a better topology for protecting data at rest. The solutions proposed demonstrate ways to separate pure encrypted data from meta data and any secrets needed to recover that data. These solutions are directly targeted at preventing ransomware attacks upon systems as they scrape all content from a file system. The disclosed embodiments significantly reduce the possibility of a data breach. Furthermore, the disclosed techniques can be applied to computer operating systems for better security.

[0009] Computer operating systems control files by permissions. These permissions might involve Read / Write / Execute access for the owner, a predefined group, and others in the case of Linux based operating system. Windows file access has a similar approach to Linux and tries to accomplish the same Access Control List type of function. The goal is to keep some files private to the user, or allow access to a group, or permit public access to a file. To access a user’s files, one only needs to assume that user’s ID or group ID, as specified by the file. This can be done by social engineering of either the user themselves or by an elevated permissions account such as root / administrator.

[0010] In most of these architectures, having root / administrative access to the operating system gives complete access to all private files on a system. That means there are no secrets from the root or administrator of a computer system. In most cases, IT functions are being outsourced and generally at a minimum have no right to review confidential files of the President and C-Suite of a company let alone any other employee within the organization they manage. Outsourcing is particularly troublesome as IT professionals can snoop through “high value” user accounts in attempts to learn things about future company actions or company trade secrets and designs. This level of access makes it easy for hackers and malware groups to collect and ransom data that would be considered highly sensitive and damaging to a company.

[0011] One embodiment within this specification poses a new means to control file access as well as thwart hackers and ransomware groups from attacking systems protected with this novel approach. This will leverage an Al based encryption method such as the one disclosed in PCT application PCT / US2023 / 083388, international publication number WO2024129596 filed December 11, 2023, which is fully incorporated by reference and made a part hereof, which discloses converting user and group files to Quantum Proof encrypted content. This will eliminate the value of scraping files from a computer system, file vault, or in-flight data. The content will now be encrypted such that even root / administrator access no longer provides usable access to the content.

[0012] Leveraging the need to protect and share files and network streams, there is a need to be able to convert from a first user file / data encryption directly to a second users encrypted format. This transcryption prevents the need for the first user to disclose their secret encryption mechanism leaving the content quantum proof but such that the second user can access the file / data without knowing the first user’s secret encryption. In this process it is important to not expose the unencrypted data in memory or temporary files as they might be obtained by hackers to recover the encrypted file / data.

[0013] Therefore, systems, methods, devices and computer program products are desired that overcome challenges in the art, some of which are described above.

[0014] SUMMARY

[0015] Disclosed herein are systems, methods, and computer-program products to implement asymmetrical encryption based upon a symmetrical cipher. A probability-based state machine makes up part of an Al based agent that is driven by the shared configuration between agents. The Al based agents generate an infinite number of encryptions through a combination of semi-private secret updating and data seeding. One or more agents can then synchronize such that they can all encrypt / decrypt data such that any other synchronized Al based agent can encrypt or decrypt. It would not be uncommon for data at rest to configure a single Al agent to both encrypt and decrypt content, eliminating the exposure of secrets which could expose / compromise the protected data. A good example would be in the case of reading / writing encrypted files at rest accessible by an operating system.

[0016] By combining multiple configurations within a single Al based agent creates a means to securely convert between two different encryptions algorithms. Any number of Al agents can be chained together as needed for proper security and end application needs. For example, a first Al based agent and a second Al based agent with a different configuration can be joined such that a file encrypted by the first Al based agent can be directly converted into encrypted data directly readable / decryptable by the second Al agent by computing the difference between first agent and second agent encryption algorithms. This allows an original content encrypted with format A to be converted to a new encryption with format B without exposing the original content. For cases where Al based agent B doesn’t wish to disclose to Al based agent A its secrets, a third encrypted format C can be used which would be known to both A and B, but A doesn’t know about B and B doesn’t know about A. So, A converts to C and then B converts from C.

[0017] Safe time of encrypted data is dependent upon the difficulty to solve the hard encryption math puzzle or by brute force search of the problem space. Embodiments disclosed herein assume there will be an eavesdropper monitoring the encrypted data and any hints or secrets passed. No keys are used in the encrypting or decrypting process meaning there is no hard math puzzle to be solved, defeating quantum computer algorithms from attacking and exposing the encrypted data. What is left is a brute force attack to simulate the exact operations performed by the encryption algorithm and then rolling that process backwards to recover original data white-text. Due to the endless size as well as no need to distribute the mask / key with classical entanglement, each individual object is encrypted independently of any other. This means that each individual object needs to be decrypted in a data set. Unlike an AES256 with a 256 bit key, once the 256 bits are discovered, the entire data set is recoverable. Given a one-megabyte file, the mask needed to recover the file taught in this invention would be a multiple of one-megabyte as more than one operation could be performed on the data. With AES256, the 256-bit key or 32 bytes is all that is required to be discovered. Brute force is far more feasible with AES256 than with the Al based agent encryption. With AES256, once the key is discovered the entire contents are revealed so it is easy to detect in a brute force situation that the contents have been recovered by looking at the decrypt attempts to see if they match the expected formats; plain text, word document, excel spreadsheet, binary executable, etc. For the Al based agent, each byte has its own pad / mask meaning each byte needs to be decrypted individually which gives no hint as to what the next byte should be making brute force useless to attempt.

[0018] The premise of the disclosed embodiments is based upon the digital analog of quantum entangled particles. The use of highly complex and configurable state machines driven by a probability-based system makes up the end-points or Al based agents. The complexity of the Al based agent can be scaled based upon the computing power available to the application and the associated threat due to loss of the privacy of the data. The Al based agent is deployed at both the encryption and decryption sites which could be the same location for some applications. Additionally, the ability to pass meta data in-band with the encrypted data stream will also be demonstrated.

[0019] The Al based agent accepts data to encrypt. It breaks the input into subdivisions of data that can be either fixed length or variable length. Invertible operations as well as random noise generators configured with a statistical probability are performed upon that data. Each pail of the data stream is encrypted independently of earlier data in the stream so discovering the first object in the stream does not help decrypt the second object. The data is then be passed as output. For decryption, all operations are reversed or inverted.

[0020] For real-time connections such as TCP / IP, a novel mechanism can be used to change the state or configuration of the Al based agent during encryption and distribute this change to all endpoints for each subsequent connection. Further, setting up a communication channel can automatically force a configuration change for each reconnection forcing an entirely new encryption algorithm preventing a repeat of any algorithm. This avoids any type of interruption hack of the connection to force retransmission and inadvertently disclosing some information which can be used to determine information about the encryption algorithm in use. The hacker will need to start all over again trying to figure out what the algorithm is for the next configuration. Also, random data can be streamed from the Al based agent while there is no live data to process. Providing dummy data on the output terminal requires any observer to capture all data in the hopes of decrypting at some future point but there is no hint as to the start / end of a valid data segment. This further contributes to the problem space of a third- party eavesdropper of the state machines. The amount of storage requirements will escalate as well due to the noise stream which can’t be rejected until such time the algorithm is decoded.

[0021] The need for a deterministic pseudorandom number generator (DPRNG) or secret sequence of data is needed to keep the endpoint in sync. There are several options that can be used as a DPRNG.

[0022] Other systems, methods, features and / or advantages will be or may become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features and / or advantages be included within this description and be protected by the accompanying claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The components in the drawings are not necessarily to scale relative to each other. Like reference numerals designate corresponding parts throughout the several views.

[0024] FIG. 1 illustrates a block diagram of an exemplary Al based agent;

[0025] FIG. 2 illustrates a block diagram of an exemplary Al based agent with transcryption capabilities;

[0026] FIG. 3 is a block diagram illustrating agent actions of an exemplary Al based agent;

[0027] FIG. 4 A is a block diagram of an exemplary conventional encryption process;

[0028] FIG. 4B is a block diagram of an exemplary Conventional Decryption process;

[0029] FIG. 4C is a block diagram of exemplary Al based agent encryption;

[0030] FIG. 4D is a block diagram of exemplary Al based agent decryption;

[0031] FIG. 5 is a block diagram of exemplary Al based transcryption;

[0032] FIG. 6 is a block diagram of exemplary Al based transcryption indirect;

[0033] FIG. 7 is a block diagram of exemplary isolated solution direct;

[0034] FIG. 8 is a block diagram of exemplary isolated solution indirect;

[0035] FIG. 9A is a block diagram of exemplary full asymmetrical encryption creation;

[0036] FIG. 9B - is a block diagram of exemplary asymmetrical encryption creation;

[0037] FIG. 10 is a block diagram of exemplary asymmetrical decryption and verification;

[0038] FIG. 11 is a block diagram of exemplary asymmetrical encryption reply;

[0039] FIG. 12A is a block diagram of exemplary asymmetrical private transcryption;

[0040] FIG. 12B is a block diagram of exemplary asymmetrical private transcryption with a different return channel;

[0041] FIG. 13A is a block diagram of exemplary asymmetrical private message decryption; FIG. 13B is a block diagram of exemplary asymmetrical private message decryption with a different return channel; and

[0042] FIG. 14 shows an example computing environment in which example embodiments and aspects may be implemented.

[0043] DETAILED DESCRIPTION

[0044] Before the present methods and systems are disclosed and described, it is to be understood that the methods and systems are not limited to specific synthetic methods, specific components, or to particular compositions. It is also to be understood that the terminology used in this entire application is for the purpose of describing particular embodiments only and is not intended to be limiting.

[0045] As used in the specification and the appended claims, the singular forms “a,” “an” and “the” include plural referents unless the context clearly dictates otherwise. Ranges may be expressed herein as from “about” one particular’ value, to “about” another particular’ value, or from “about” one value to “about” another value. When such a range is expressed, another embodiment includes from the one particular value, to the other particular value, or from the one particular value to the other particular value. Similarly, when values are expressed as approximations, by use of the antecedent “about,” it will be understood that the particular value forms another embodiment. It will be further understood that the endpoints of each of the ranges are significant both in relation to the other endpoint, and independently of the other endpoint.

[0046] “Optional” or “optionally” means that the subsequently described event or circumstance may or may not occur, and that the description includes instances where said event or circumstance occurs and instances where it does not.

[0047] Throughout the description and claims of this specification, the word “comprise” and variations of the word, such as “comprising” and “comprises,” means “including but not limited to,” and is not intended to exclude, for example, other additives, components, integers or steps. “Exemplary” means “an example of’ and is not intended to convey an indication of a preferred or ideal embodiment. “Such as” is not used in a restrictive sense, but for explanatory purposes.

[0048] Disclosed are components that can be used to perform the disclosed methods and systems. These and other components are disclosed herein, and it is understood that when combinations, subsets, interactions, groups, etc. of these components are disclosed that while specific reference of each various individual and collective combinations and permutation of these may not be explicitly disclosed, each is specifically contemplated and described herein, for all methods and systems. This applies to all aspects of this application including, but not limited to, steps in disclosed methods. Thus, if there are a variety of additional steps that can be performed it is understood that each of these additional steps can be performed with any specific embodiment or combination of embodiments of the disclosed methods.

[0049] As will be appreciated by one skilled in the art, the methods and systems may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the methods and systems may take the form of a computer program product on a computer-readable storage medium having computer-readable program instructions (e.g., computer software) embodied in the storage medium. More particularly, the present methods and systems may take the form of web-implemented computer software. Any suitable computer-readable storage medium may be utilized including hard disks, CD-ROMs, DVD- ROMs, optical storage devices, or magnetic storage devices.

[0050] Embodiments of the methods and systems are described below with reference to block diagrams and flowchart illustrations of methods, systems, apparatuses and computer program products. It will be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, respectively, can be implemented by computer program instructions. These computer program instructions may be loaded onto a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create a means for implementing the functions specified in the flowchart block or blocks.

[0051] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including computer-readable instructions for implementing the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions that execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

[0052] Accordingly, blocks of the block diagrams and flowchart illustrations support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, can be implemented by special purpose hardware-based computer systems that perform the specified functions or steps, or combinations of special purpose hardware and computer instructions.

[0053] The present methods and systems may be understood more readily by reference to the following detailed description of preferred embodiments and the Examples included therein and to the Figures and their previous and following description. Systems, devices, methods and computer program products are described herein for Al based agent encryption, which provides a novel approach to data security as well as data production. The focus of this description will stay on the Encryption capabilities, but as shown in FIG. 1 - the disclosed Al based agent introduces a very powerful probability driven Al based data manipulation capability which can apply to almost any data processing needs outside of cryptograph such as compression or transcoding data. The disclosed aspects include an ability to produce a quantum proof encrypted data output based upon input. Another is the capability of producing a near infinite number of encryption / decryption algorithms without the need to transfer any key or mask along with the encrypted data like in the case of the current quantum proof One Time Pad (OTP) implementations. This encryption / decryption can apply equally to different data type applications which include data in flight (streaming) or data at rest (storage). This is accomplished by a classical entanglement between one or more Al based agents. This is the digital equivalent of quantum entanglement providing the ability to know what each agent is doing at the same time without communicating that activity. Much like all Al based agents have a priori knowledge of what the other similar configured agents will do. Another novel feature includes the ability to transcrypt data from one encryption algorithm to a second algorithm without first decrypting the original encrypted data. As described herein, this allows the distribution of a highly secure data set to other trusted and untrusted sources securely without ever exposing the original / master encryption algorithm or decryption to “white text” (original unencrypted content). Finally, the Al based agent is configurable such that it can scale the encryption up / down based upon available compute and memory on bare metal or virtualized platform. This makes it usable within some of the most basic intemet-of-things (IOT) devices including use with supercomputers.

[0054] To clarify the purpose and novelty of classical entanglement, this allows for the transmission and storage of encrypted message / data without the need to store the mask / pad. Due to the entanglement of the Al Based encryption & decryption, secret pad / mask data as well as other Al Decision data is generated locally and doesn’t need to be transmitted. For example, the approach described in this specification in one embodiment for One Time Pad (OTP) encryption, among other more complex algorithms, to be utilized with no transmission of the mask to decrypt the message. Current OTP technology requires the transmission of not only the encrypted message but also some secret way of transmitting the mask data to the decryptor to restore the original message. This has many drawbacks including twice the bandwidth requirement, public exposure of the mask, which is a security risk, as well as limited manipulation that can be done to the original message / data to ensure security. Furthermore, this entanglement method allows for any level of complex operations to be performed at a first location and have the reverse preformed at the same or multiple other locations without the need to retain such a mask or instructions to recover the original message / data.

[0055] FIG. 1 - Al based agent shows eight elements. Note that other supporting elements can be added as well as some can be removed based upon the final need for the Al based agent as stated above to cover scalability and functions outside of encryption / decry ption. The core of the disclosed Al based agent is Agent Action Determination 700, which is discussed later in detail. It maintains the coordination of the overall agent based upon the Al Agent Configuration Data 400 to give the initial setup / state / probabilities, State Machine 600 to maintain system state while the agent works, and the Encryption Generator and Decoder 300 to drive the agent actions for proper encryption / decryption. These portions of the disclosed Al based agent determine the actions and initial configuration with the ability to encrypt or decrypt input data if applicable. “If applicable” here is referenced here due to the capabilities of the Al based agent to generate data, it doesn’t need to ingest data to produce data. Also note, the disclosed Al based agent can ingest data and not produce output data. The simplest example use case of this generation without ingesting is to produce a channel / stream of digital network noise. A sending agent might create a noise stream with no input data to fill a silent network channel with noise while the receiving agent would ingest this noise and discard it so as to not burden the systems connected on both ends of the channel. If needed, these agents can inject valid data across the channel such that the receiving agent would discard noise and recover only the valid data.

[0056] The Al based agent internal intelligence depends upon both the Deterministic Pseudo Random Number Generator 100 that creates one or more deterministic random number streams and the Probability Converter 200 used to generate a deterministic percent value which connects with 100 to specifically provide probabilities upon request of the Agent Action Determination 700 to drive the current Al based encryption algorithm using a multitude of functions, test, calculations, meta data, configuration changes, system state changes, and other actions. Another way to think of this Al based agent is that of a genetic algorithm where it mutates over time and is probability based. One exemplary embodiment of 100 comprises initializing with a pre-amble, a block of random data, to define a new random sequence based upon the pre-amble. During the encryption, a pre-amble is generated after initial configuration, then added to the initialization changing the overall random data stream dependent upon the supplied pre-amble data. Upon inverting the process, the pre-amble is read from the previously output stream and then used to re-initialize the random number data stream. The size of the pre-amble can be pre-configured or dynamically determined from the supplied configuration prior to applying the pre-amble data. It is worth noting that in some applications, Random Number Generator 100 may also provide non-deterministic random numbers if needed by 700.

[0057] The Al based agent can ingest data via the Dynamic Buffered Inputs 500 to access any input 10 functions such as static files, Network Ports, Network Protocols, data acquisition hardware, serial input, hardware-based input (USB for example), keyboard, WIFI, Bluetooth device, IOT device, audio capture, video capture, IR detectors, GPS data, Satellite downlink, streaming input, dynamic input, etc. The Al based agent can also generate / produce output at the Dynamic Buffered Outputs 800. Much like the list that can ingest, the output can include similar things such as static files, Network Ports, Network Protocols, data acquisition hardware controls, serial output, hardware-based output (USB for example), WIFI, Bluetooth device, IOT device, audio output, video display, LEDs, Satellite uplink, streaming output, dynamic output, etc. There can be more than one input and / or type as well as more than one output and / or type. For 500 and 800, dynamic is important here as well, although most applications would use a static connection, the Al based agent could dynamically select a new input / output based upon probability of obtaining new input or output, most likely used to dynamically update the state of the system, increase the security, or assure private access to data only available for short periods of time. Both inputs and outputs may be buffered to facilitate functions that reach backwards / forward in the data stream. This allows for more complex invertible functions which further mutate the data stream based upon prior or past data within the stream.

[0058] Another aspect of the Al based agent is its ability to manage pre / post processing of the data at 500 and 800. For example, a customer may wish to have their data encrypted with a OTP, but also wrapped in another form of encryption such as, but not limited to, AES256. Depending upon the Al agent Configuration Data 400, data pulled into 500 may first be wrapped by an AES256 with a key memorized by the Al based agent. Then during a decrypt cycle, 800 can then unwrap the encrypted data on last time by decrypting the AES256 encryption with the memorized key. Having the Al based agent memorize the key is the general approach, but alternative methods can be employed as the key can be encrypted in the output stream for use by the decrypt cycle.

[0059] The same Al based agent in FIG. 1 is given the capability of transcryption (directly converting from encryption A to encryption B) by the addition of Al agent Mx Configuration Data 410 as show in FIG. 2 - Al based agent with Transcryption capabilities. Generally, transcryption addresses a need to convert data encrypted with one algorithm into another format without exposing the original plaintext. The goal is to achieve this conversion while maintaining security and without revealing the unencrypted data. As a non-limiting example, consider the following; Starting with an initial common encryption step (e.g., XOR) that both formats share; Instead of applying the PRNG data directly to decrypt the data, store it; For the second format, calculate the XOR stage PRNG data without applying it; Combine the XOR mask data from both formats to create a Transcryption Mask; Apply this Transcryption Mask to the encrypted data from the first format (XOR stage) to produce the XOR stage of the second format; Additional encryption steps can follow as needed.

[0060] This process allows translating Encryption A to Encryption B without exposing the plaintext data. Transcryption can be applied to various encryption algorithms, including AES256, by adapting the code to perform the specific cipher transcryption.

[0061] Referring back to FIGS. 1 and 2, one or more configuration files can be added. One embodiment would be to add a single additional configuration data set of the secondary encryption the Al based agent can use for transcryption. This allows the Al based agent to maintain a child Al based agent internally to facilitate the direct conversion between Encryption A and Encryption B. For the sake of brevity, the description of blocks already covered in FIG. 1 is not repeated here, other than Encryption Generator and Decoder 300 which would now need to be able to compute a combination of encryption / decryption functions between the two or more compatible encryption algorithms. For operations to be compatible, the operations performed in sequence individually must produce the same result as the operation of the combined operations. That is to say C being the combined result of operation fl + f2 must be equal to some new combined operation f3 which replaced the combined fl and f2 operations; C = fl + f2 = 1'3.

[0062] One way to think of this computation would be the difference between the fractional decryption of A and fractional encryption of B. Fractional since more than one invertible function may be statistically applied and all invertible function need to be applied to the data stream in a reverse sequence and more than one function can be applied to the same data. So, where an OTP hypothetical mask_A and mask_B are the associate XOR values to decrypt A and encrypt B, internally the A XOR mask_A which decrypts A and then the result XOR mask_B to encrypt to B is never performed. Rather the mask_DIF is computed as mask_A XOR mask_B, then B is generated by A XOR mask_DIF. This is similar for other functions such as ADD. If add_A and add_B respectively are needed to add to A to decrypt and added to B to encrypt, a similar dif function can be calculated to make a one-step operation. In this case, add_DIF = add_A + add_B. So, for example, if A was encrypted with ADD 10, and B is encrypted with ADD 10, then A would be fractionally decrypted at this point with ADD -10 (using the inverse of subtraction). So, add_DIF = -10 + 10 = 0 meaning 0 would be added as the computed change to the data stream. Many function types can be used to create a valid DIF function like the above such as BIT ROTATE, BUFFER ROTATE, NOISE, etc. Any operation / function F that is both invertible and constant within the fractional step going from A to B would be DIF = F-1(A) + F(B). This is referred to as a difference due to the negative / reversing nature of the F'1decryption. Some functions that rely on data not yet determine are not eligible for use in a transcryption.

[0063] Functions / Operations / Calculations that make up one exemplary embodiment are shown in FIG. 3 Agent Actions. Data Access Control 705 handles all IO requests to and from Input / Output buffers. It would be responsible for opening static and temporary inputs / outputs as dictated by the agent. The Invertible Function Library 710 makes up all the functions / operations / calculations which need to be inverted. The inversion is required when and if the data flow is reversed such as a decryption. A simple way to think of these functions would be; x = F-1(F(x,pl,p2,...),pl,p2,...) where F1is the inverse function of F which returns the original input x parameter / object to F. The pl, p2, ... are extra parameters needed by F and provided by the Al based agent. An example would be the XOR function where F and F'1are both the XOR function. Another example would be F being the ADD function and F’1being SUB. Here again, the function parameter / objects can be of any type / size as determined by the application. The only requirement is that it must be invertible. Please note, some invertible functions may be lossy, but this has been considered as either a desired or acceptable invertible function. An example of an application where lossy might be either desired or acceptable would be in rounding errors when inverting a function for a binary WAV format audio file. Generally, in the case of audio, small changes to the waveform can be kept to an unperceived level, and in some cases can be used to water mark the destination of the audio for tracking purposes. Some invertible functions might not require “x” as an input such as for “noise”. Here x can be the “null” set or omitted, and a parameter pl might be the size of the noise data requested. The inverse here will simply return the “null” or zero data. Other invertible functions might include self-repairing algorithms such as Forward Error Correction (FEC) or Error-Correcting Code (ECC). These would take x, returning x with error correction data, the inverse would take the questionable data x’ which may have errors but include the correction codes and return x. Internally, null, error flag, or exception can be thrown to handle the fact that the data is corrupt. Similar for a CRC function as well which may use supplemental data in blocks or meta-data to carry CRC or similar check results. Forward would calculate the CRC, reverse would test CRC much like describe above for handling errors to detect corruption of the data stream.

[0064] Continuing on with FIG. 3, Block Size 715 is responsible for maintaining the proper block size used for block operations. Although many implementations may be a static block size, this disclosure contemplates including the ability to have a variable block size based upon a range and the probability of those values in the range. Another aspect of this portion of the agent actions is for the inverse block size calculations. Here, the forward or encryption function may have generated more (injection) or less data (compression) than the original input block size. It is desired that the Agent Actions to understand, a priori knowledge, of what the new encrypted block size might be as well as the final decrypted block size. Probability Tester 720 is used throughout the agent’s lifecycle to determine what Functions / Operation / Calculations need to be performed based upon configured probability. It might also be used to determine meta parameters over a probability range such as discussed above for block size. Keep in mind, one valid operation of the agent is to dynamically update the configuration thus changing the probability of said operation on the next iteration. Configuration Management 725 maintains the current Agent configuration. As discussed earlier, the configuration is not necessarily static over the agent lifecycle. Configuration management is responsible to tracking those changes and understand the initial configuration if the agent needs to be restarted.

[0065] Meta Data Processor 730 handles the generation, injection, extraction, actions, and update of meta data within the data stream. Since the underlying technology can bundle meta data within the output stream and read back meta data within the input streams, this processor is responsible to coordinating those activities. It is also responsible for triggering additional actions that may originate from the included meta data. An example here might be an included meta data which changes the system state such as a pin code for the remainder of the agent lifecycle.

[0066] To help implement the classical entanglement between Al based agents, State Process 735 maintains and reads the deterministic state within FIG. 1 and FIG. 2 State Machine 600 which helps to drive the Deterministic Pseudo Random Number Generator 100 maintaining synchronized random data between instances with identical configurations. This then synchronizes the Probability Converter 200, keeping the Agent Action Determination 700 making the same probability selections for everything configured within Al agent Configuration Data 400 which in turn drives the Encryption Generator and Decoder 300 maintaining a fully invertible data stream.

[0067] The FIG. 3 Data Output Processor 740 fills the output buffer(s) as determined by the configuration files, Block Size determination, and invertible functions. It is also responsible for injecting the metadata into the data stream output. Optionally, the FIG. 2 Config Difference Engine 745 is only required for Al based agents that perform transcryption. It is responsible for making sure the fractional DIF is calculated properly for successful transcryption. Child Agent(s) Management 750 would be required with the transcryption feature or any other complex operation requiring two or more configurations. For the transcryption case, it would be responsible for synchronizing the secondary configuration file with the state of the primary agent (parent agent) and sharing said state with the parent. This state will be used by the Config Difference Engine 745 to calculate the DIF to apply for the fractional data / configuration / state manipulation operations.

[0068] Next will be a look at conventional encryption so that it can be compared to the Al based agent Encryption. FIG. 4A Conventional Encryption shows the typical algorithm such as AES256. Some Unencrypted Data 901 is presented to the Encryption Algo 902 (AES256 for example) which requires unique Encryption Key 904 for each request to create Encrypted Data 903 the final output. The key is generally created publicly with a private key generation algorithm such as Diffie Hellman or Kyber. It is used to initialize the encryption and all subsequence encryption is based upon the previous data block. The key needs to be distributed to all end points and doesn’t tend to be very large, in this case it is 256 bits for AES256. If this key can be hacked, cracked, memorized, decoded, or otherwise obtained due to its public exposures, FIG. 4B which shows the same parts in reverse with Encryption Algo 902 set to decrypt. 256 bits will unlock this entire dataset and will return the original Unencrypted Data 901. Although brute force may take a long time with current system, it isn’t clear the safe time for 256 bits in the future. For security reasons, each dataset needs to be encrypted with a new Encryption Key 904. The encryption key is publicly exposed and has multiple attack points depending upon how it was implemented. Other attacks may be used upon the key such as Shor’s Algorithm to break the key with super computers and / or quantum computers in the future.

[0069] FIG. 4C Al based agent Encryption looks similar to FIG. 4A, but has a completely different topology for encryption. Using classical entanglement, Al based encryption A 950 (Shorthand representation for Al based agent configured with Encryption A) ingests the same Unencrypted Data 901, utilizing Config A 921 which dictates the main secrets, features, and probabilities for Encryption A, it produces Encrypted Data Config A 907. If requested in Config A 921, it is worth noting that multiple executions of Al based encryption A 950 will produce entirely different binary versions of Encrypted Data Config A 907. This is accomplished from the Al based agent’s probabilistic application of PINS, Encryption Family, Initialization Vector, Salt, Unix Time Stamp, Secret diversification, Dynamic parameter selection, and other techniques to create a near infinite number of encrypted outputs, all of which can be decrypted as shown in FIG. 4D Al based agent Decryption. Even though the input data Encrypted Data Config A 907 are completely different binary forms, the Al based encryption A 950 configured for decryption recovered the identical Unencrypted Data 901. The agent is able to produce a near infinite number of Encrypted Data Config A 907 with different binary forms, but all resolve to the original Unencrypted Data 901.

[0070] Unlike the small publicly created Encryption Key 904 shown in FIG. 4A and 4B, the Al based encryption A 950 has no publicly generated Encryption Key 904. There is nothing pushed or broadcast from a sending location to a receiving location. This is accomplished through the classical entanglement so that all similarly configured 950 have private knowledge of Config A 921 leading to a common understanding of encryption / decryption techniques and an infinite number of families of encryption algorithms without the need to change to a different configuration for continued security.

[0071] To clarify the purpose and novelty of the synchronized Al based agents (entanglement), this allows for the transmission and storage of encrypted message / data without the need to store or transmit the mask / pad. For example, the approach described in this specification in one embodiment for One Time Pad (OTP) encryption, among other more complex algorithms, to be utilized with no transmission of the mask to decrypt the message. Current OTP technology requires the transmission of not only the encrypted message but also some secret way to transmitting the mask data to the decryptor to restore the original message. This has many drawbacks include twice the bandwidth requirement, public exposure of mask, which is a security risk, as well as limited manipulation that can be done to the original message / data to ensure security. Furthermore, this entanglement method allows for any level of complex operations to be performed at a first location and have the reverse preformed at the same or multiple other locations without the need to retain such a mask or instructions to recover the original message / data.

[0072] The power of the entanglement is novel in that is provides a means for various systems to have a priori knowledge about each other’s behavior. Given the Al based agents can be used in any application which requires either the ingestion and / or non-ingestion of data and then the production and / or non-production of data, the technology can be used to bridge distances or time. Multiple entangled Al based agents can be setup at different endpoints to communication / transmit data in unique or confidential ways to cover distance such as across a public internet, WiFi connection, intranet, satellite uplink / downlink, serial connection, optical connection, audio, video, etc. This is commonly referred to as data in motion or transit. Where data at rest can be thought of as being transmitted over time. Data would be generated into a new format at time one, with the desire to retrieve that original data at some later time two. The time difference can be microseconds to decades depending on the application, and the length of time is irrelevant to the technology. The entanglement within this specification eliminates the need to store the required information to reverse the process to recover the original information.

[0073] Transcryption, as noted herein this term describes the process of converting from one encryption algorithm to a second (or more) algorithm without first converting back to the unencrypted “white text”. That is, if we have data X and we encrypt it with Algorithm A, we have A[X] representing the encrypted data X wrapped with Algorithm A. Let’s say the goal is to convert this A[X] into B[X] so that it can be sent to a third-party without disclosing Algorithm A, the master encryption, but re-encrypting it as Algorithm B. One could decrypt A[X] back to X and then apply Algorithm B to get B[X]. This has two flaws; decryption of original content which exposes the master data X to theft either from a file system or memory dump and it requires two steps (A[X] -> X, X -> B[X]) making it less efficient than the disclosed systems and methods. It is also worth noting with additions of operations within the Agent Action Determination 700 in FIG. 3, data specific operations can also be performed such as transcoding of video to other formats or resolutions. Unique meta data can be injected such as user account and or to add a water mark to the output of B[X] bit creating something closer to B[X’] before sending to the third-party. The third-party would only have Algorithm B information and able to take B[X] or B[X’] back to X or X’ as desired.

[0074] FIG. 5 Al Based Transcryption shows the blocks and flow of transcryption from end-end using encrypted data for clarity of data flow. This technique can be used for other conversions between an initial data format and a final data format where disclosure of the conversion is not desired. It starts with the same Unencrypted Data 901, which Al based encryption A and B 905 can ingest and store as Encrypted Data Config A 907 by using Config A 921. This encrypted master can then be loaded back into Al based encryption A and B 905 and transcrypted with the use of Al based agent with Transcryption plus Config A 921 and Config B 922. This produces Encrypted Data Config B 908 A in transit which is the same as Encrypted Data Config B 908 being an optional locally cached version. 908A is being passed to Al based encryption B 906 which only has access to Config B 922 to be able to decrypt the locally cached 908 or directly passed 908 A data back to Unencrypted Data 901. Again, the decrypted output from 906 might not be exactly the input Unencrypted Data 901 as 905 might have done additional processing to the data prior to Transcrypting into Config B 922. For example, a video watermark of the receiver can be added to protect the owners IP from theft. It has also been considered that Al based encryption B 906 can only be configured to decrypt, FIG. 3 Invertible Function Library 710 only contains the inverse functions, Config B 922 so it can’t be used to encrypt or forge content that isn’t owned by the third-party.

[0075] FIG. 6 Al Based Transcryption Indirect is a variation of FIG. 5 which protect not only the originators Algorithm A from disclosure, but also protects the receiving 3rdparties Algorithm B from disclosure to A. As in the last case in FIG. 5, the sender required both Config A 921, and Config B 922. In the case of the third-party not wishing to disclose their Algorithm B, a third shared or temporary Algorithm C can be used for the transport. Only the differences vs FIG. 5 are covered below for this indirect solution.

[0076] In FIG. 6, we change FIG. 5 905 to Al BASED Encryption A and C 910. 910 no longer has access to Config B 922, but gets access to Config C 923. Config C 923 has been considered as static between the sender and receiver, or it can be dynamically generated between the two parties for a single use and discarded. 910 will then transcrypt from A to C, producing Encrypted Data Config C 912. This is then received by Al based encryption C and B 911 which is now a Transcrypter itself having both Config C 923 and Config B 922. Depending on the applications need, the cached Encrypted Data Config B 908 is optional much like in FIG. 5 but requires the Transcryption from C to B. The output of 911 Unencrypted Data 901 can either be directly decrypted from 912 using Config C 923, or from 908 using Config B 922. Transcryption is only needed to go from C to B or to generate 908 from 912.

[0077] All approaches to better security of data in motion or at rest need to consider the system level solution and topology. The encryption / decryption algorithms, although critical to data security, are simply a tool. Applying that tool incorrectly might secure the data but may provide an easy means to attack the system in such that secrets might be easily acquired rendering the encrypted files insecure. A major weakness with conventional encryption / decryption algorithms is with the key distribution or generation for current ciphers. Accidental disclosure or failure to properly obfuscate the keys / masks render the encryption worthless as an eavesdropper can easily decrypt the secret message. Ultimately, keys, if transmitted, should have the same level of encryption as offered by the algorithm that uses them to assure the same level of protection as the desired encryption cipher. If not, the weaker algorithm makes up the strength of the cipher. This can be illustrated in an AES256 encryption system. AES 256 is considered a strong cipher, but if the key is distributed in white text, this renders AES256 encryption as white text because any eavesdropper can decrypt the secret message. Ideally, to maintain AES256 level encryption for a system using AES256, both the data and the key should be encrypted using AES256. This unfortunately generates an infinite series of problems where the key for one AES256 encryption needs a key to be encrypted, and then that new key now needs a key for AES256 encryption. This invention avoids this problem by simply not distributing the keys / mask so there is nothing to protect from an eavesdropper maintaining the strongest level of encryption.

[0078] To speak to the topology, FIG. 7 Isolated Solution Direct provides one such topology and an exemplary embodiment to significantly improve the security of the Data At Rest 1004 which is data storage either as files, database, distributed ledgers, cloud services, etc. The exemplary embodiment, by using separate instances of operating systems / services such as through Kubernetes, Virtual Machines (VM), or Docker Images, deep isolation between the different functions can be realized. For technologies that separate functional blocks but don’t provide an underlying isolated subnet such as VM or even multiple bare metal systems, using a private subnet for connecting the backend parts 1001, 1002, 1003, 1004 with the public / user connection at 1005 will replace the private networks provided by Docker and / or Kubernetes. This isolation for 1004 can also be realized through other topologies where there is no direct access to the data storage from the user / API access. This might be a single VM with a private link to a data store. This private link would not be “mounting” the data store to the VM, but rather through an API. This isolates any unauthorized access to the data store if the VM is compromised. It uses the same En / Decryption Service 1001 which is the Al based agent (with or without transcryption capabilities) as discussed earlier in FIG. 4C and elsewhere in this invention. The connection from 1001 to 1004 in the preferred embodiment would be a network protocol such as FTP or TCP / IP connection so that 1004 cannot be directly accessed from 1001 requiring an indirect connection. Although Network File System and other protocols to map 1001 to 1004 as “file storage” does work, it isn’t the preferred solution given the basic assumption of hackers gaining access to the different Virtual Machines, Nodes, Pods, or Services running. With the indirection, if a hacker managed to access 1001, they would not be able to bundle the files easily due to the FTP or TCP / IP requirement. Most hackers ZIP / TAR the file system files for later exploration or sale. This is possible if 1001 directly mounts the file storage location. Giving the possibility of obtaining not only the encryption / decryption capabilities, but the associated encrypted files. Whereas the hacker would need to hack both 1001 and 1004 to get said contents otherwise, making hacking more difficult and costly.

[0079] Within FIG. 7, the En / Decryption Service 1001 is buried deeper into the “private network” of the orchestrator. It relies upon Controller 1002 for instructions, configuration, secrets, semi secrets, pin codes, and file identifiers. The goal of 1004 is to look like a random dump of un-identified data which can include either files, database tables / BLOBS, distributed ledgers, sharded file storage such as Interplanetary File System, or other data storage means. If file names are used in 1004, they should only be randomized names so they contain no information other than a file ID which can be accessed. That is, names like “Company Take-Over Plan.doc” contains information for hackers to use and know what is contained within. They can assess the name of the file and focus effort where they think is the most valuable to crack. Another example might be “lim Smith SSN 123-45-6789 - Medical Record 5893923.TXT”. Here, personal identifiable information (PII) is disclosed simply by the name and is considered a breach. Data identifiers of file names should always be deidentified. A preferred file name would be “ab893c45012ffe9831.enc”. Contains no information about it content, the extension is optional, but here it is used to reinforce content is encrypted so stealing files might not be worth the trouble.

[0080] Meta Data Storage 1003 which is optional in some applications can support the Controller 1002 to help users find the needed data or store new data. This storage is again, a separate instance / pod / VM / etc. The connection here is likely to be via a TCP / IP port in the case of 1003 being an SQL database server. The Controller 1002 also has the option to use En / Decryption Service 1001 to encrypt Meta Data before being placed into 1003. This will protect the PII and Personal Health Information (PHI) from direct attack as well. The final part of FIG. 7 topology worth noting is API Layer 1005. Understand in an Orchestrated Solution, 1001, 1002, 1003, and 1004 are hidden from public or company intranets as they are only accessible via the Orchestrator’s private networking features. They are formed on a private network with no route from the “Ingress” of the orchestrator. 1005 would be the access for the Ingress to this topology. This means that a public or external IP address is created by the Orchestrator to route between API Layer 1005 and public / local intranet access. This pod / service / VM / instance would form the connectivity to the other parts of the system. User Authentication would be enforced here and carried through the rest of the topology. Such that USER1 is known through the lifecycle of a request to access or store data in 1004.

[0081] Due to the torturous nature of FIG. 7 and the fragmented services, hackers would need to penetrate deep into the system. Each node within the private network, namely 1001, 1002, 1003, 1004 once configured no longer need user / admin login information as there is never a need to login to that node or a means to access it directly. Additional, services and ports not needed for that particular node can be disabled only exposing the required ports / services for the minimal required functionality for that node. This significantly reduces the attack vectors and forces hackers to be more selective rather than being able to wholesale steal all protected data via social engineering and such to steal user access. The authenticated API Layer will slow down theft by not allowing bulk download of data, access monitors, access rules, and anomaly detection can be added to this layer as well. One rule might be that a user can only access 4 files an hour to prevent automated scripts from extracted the full system if an account is compromised outside of this topology. It also protects the Data At Rest 1004 from damage due to a bad actor by not allowing direct access to delete, encrypt, or over-write the existing data at rest. The other advantage of such a topology, if any node is somehow poisoned with a virus, backdoor, hack, or malware, the orchestrator can simply delete the contaminated instance and allow it to respawn from the master image for each subsequent access. This means that any hack that can get into the system is short lived and potentially deleted automatically.

[0082] FIG. 8 Orchestrated Solution Indirect is very similar to FIG. 7, it has all the same features of FIG. 7. The different is that Data At Rest 1004 is connected to Controller 1002 rather than directly to En / Decrypt Service 1001. There may be times when this is a better topology, but the drawback is one more data hop so latency gets a little longer as Controller 1002 also acts as a data relay between 1004 and 1001 where in FIG. 7, 1001 can directly access 1004.

[0083] These approaches can be thought of as Encryption as a Service (EaaS) and can be paired with Applications, SaaS, Data Vault, Microsoft Graph, Cloud Storage, Machine Learn Inferences, Operating system and simply through user authentication. These services would integrate with the API Layer 1005 to store and recover data for use in the application or pair system. Access would be obtained through an authenticated connection of the API Layer 1005.

[0084] File system access (access control) could be changed entirely to protect against file scraping; Zipping or a Tar of the user files. This protection will even cover a hacked ROOT or ADMIN level account. The paradigm shift here is not to use access controls exclusively to protect access. In the case of root or admin, these controls would be defeated, granting access to all system files. Access control would be both the file level and encryption. A preferred embodiment would be using an EaaS like FIG. 7. Reconfiguring file access drivers such that user level protections need to be enforced, but also, the user needs to be authenticated upon the EaaS system and data is routed transparently through that encryption / decryption system prior to access or prior to storage on the system file structure. Please note, the type of storage does not matter. As file access abstraction can be spread across any devices such as physical media, virtual media, USB devices, VM Mounts, cloud storage, etc. The issue is more of what a hacker would get direct access to by a ransomware attack. The preferred embodiment here would be similar to FIG. 7, but Data At Rest 1004 is locally available on the file system. The data is transparently encrypted or decrypted as needed based upon the current user. Note that if a hacker is accessing the system through root or admin access, they no longer have access to the decryption of user’s files. In this case, a hacker would ZIP / TAR up all the files on the file system like any other random ware or theft, but they would get encrypted content for any user other that ROOT. This topology enforces private files by users to actually be private. This is good for corporations where private files should not be accessed such as at the C-Suite level. So as an admin of the system, they would be able to see the files stored, but not be able to decrypt them to snoop on what is happening at the C-Suite level. This goes for other groups and financial data.

[0085] This isolation of stored data on a file system can be extended. For illustration, let’s consider a LINUX file system. Users’ login, there may also be Groups and publicly accessible files. There are also files that arc executable as part of the operating for services and features of that system. The above structure can be implemented and extend in such a way that any executable file on the system is encrypted by root or appropriate user account (usually a non-human account with no login). A service on the operating system can be started during boot up / boot strap, or external to the server as an EaaS. Drivers in the file access control would know that executable files need to be decrypted prior to execution by the operating system. This service would be preferred to only be able to decrypt. This would stop rogue or spoofed files from being put onto the system since they are not properly encrypted. Updates to files can be fully controlled and logged, rogue files will not decrypt properly causing the application to fail to execute. This will help prevent malware from being installed and executed. Depending upon the operating systems security need and use, this can provide an enormous increase in executable file system integrity by using a EaaS or embedded version that only decrypts executable files.

[0086] The user file read / write features would be the same as described above, but group files could use the transcryption described earlier and shown in FIG. 5 or FIG. 6 as appropriate to the end security needs. So, any group access to a file owned by USER1 would be transcrypted to the USER2 that is part of the same group level access GR0UP1. This doesn’t disclose USER1 but provides access to USER2 through GR0UP1 access controls. Any write access can perform the reverse transcryption back to USER1 if desire, or change ownership to USER2 so that USER1 can access the files through transcryption between USER2 to USER1. There arc many other scenarios with different access controls that can be played out in a similar manner. Versions of the file can be stored as well to preserve USERl ’s original file, but allow for USER2 to update the file for review or to supersede USERl ’s file, but being able to roll back changes to USER1 and earlier versions. Newer LINUX access control and file drivers would need to be developed.

[0087] For the final set of access control of public, PUBLIC can be considered unique group type and follow the same access above. This would have the added benefits of requiring public access to be a member of that system. So, for example, an anonymous user over a network file share would not have a valid user id for proper transcryption, so access would fail. But if a user on the system such as USER3 which isn’t the owner and is not part of the files group access can be allowed access to the file by transcryption between the owner and requesting PUBLIC users. Alternatively, the public files can simply be left unencrypted if the security of that file is not a concern. For example, a free ebook might not need any security as the goal is to give it away as marketing material.

[0088] A simpler approach to file security can be explored as well, which might be well suited on private desktop systems. Consider a single user on a single desktop computer. The user can save files into their Documents folder and access them locally, but they wish the contents to be encrypted. Another embodiment would allow for a “Encrypt” and “Decrypt” directory. These two directories would be the only two the user could write files. If a user wrote a file to the “Encrypt” directory, it would be picked- up by a daemon or service detecting the file change in that directory. It would then be encrypted with the users encryption and stored in the Documents folder but adding a file suffix such as “.encrypted”. The original “white text” file will be deleted from the Encrypt directory after encrypted and moved to the Documents folder. Later, a file in the Documents folder of interest to the user can copy the file into the “Decrypt” directory. The system would detect this file, see the “.encrypted” extension and then decrypt the file removing the “.encrypted” extension in the process. The user can now access that file as “white text” again. Additional protections on the “Decrypt” directory may include the maximum time a file will stay there without being auto deleted as well as the maximum number of files to exist in that directory. Both of these features will remove the “white text” after a period of time so it is no longer exposed. It would also prevent a hacker from copying all files in the Document directory to this folder prior to trying to steal all the files as decrypted. This mechanism can be connected with any EaaS option as well, moving the files off the desktop and into an encrypted cloud location such as 1004. Additional combinations and rules have been considered.

[0089] As part of this invention, the newer access control topologies discussed can utilize any means to automate the process of moving from a “white text” exposure of data within application such as Word Processing, spread sheet, Presentation, CADD, Video Editing, etc. to a data storage layer with the contents encrypted. The goal of this invention and the topology presented here is to separate the file / data access from the decryption / encryption feature such that scraping files on said system yield nothing more than encrypted content to the bad actor. Current encryption of storage media is generally only useful when the system / device is shut-off and the storage media is removed with an attempt to access it contents with a different operating system or hardware setup. That is due to the operating system transparently decrypting the encrypted content if you are logged into that system and authorized. Additional security can be realized by incorporating some of the teachings of FIG. 7 or FIG. 8 in using an Orchestration to bury private secrets and encryption / decryption features.

[0090] With the novel technology demonstrated above, transcryption, shown in FIG. 2, can be used to re-invent solutions to some current security issues. The most notable is the concept of Asymmetric encryption / decryption using a symmetrical cipher. The fundamentals of performing Asymmetric encryption with a symmetric cipher are shown and described in FIG. 5 and 6 depending upon the need and use case. Generally, symmetrical ciphers are not used to produce an asymmetrical equivalent due to the ability of a receiver to fake a message that looks like it comes from the sender. This is due to the inability to hide the keys used to encrypt from the decryptor as in a symmetrical cipher, the same key used to encrypt the data is then used to decrypt the data. This means the decryptor has the access to the same key and can impersonate the sender. This impersonation can be in the form of a faked signature, contract, document, data, etc. Eliminating this leak of the key to the receiver can enable the use of a symmetrical cipher which can be accomplished using transcryption. As demonstrated below, this technique is used to encrypt and deliver to one or more additional parties and if needed to the public.

[0091] Leveraging transcryption, this problem can be broken down into simpler parts and then pieced together as needed for the desired security / application. Generally, there are 4 major parts that can be separated and implemented based upon the security / application requirements. The parts include the following and yield the same result as the sender encrypting a document with their asymmetric key (such as RSA) for public access / verification; sender initiation, sender asymmetrical conversion, receiver to verify sender, receiver decryption. The equivalent of encrypting with the public key to send a private response back to the sender can be broken down into the following using transcryption; Reply Initiated, reply transmitted to sender, sender verify replier, sender decryption. What follows is a description of the preferred embodiment of the invention but using different groupings and separations of these features will result in the same result. These changes might be required for optimization to the specific problem or changes in security need or implementation platform. These can be thought of as building blocks for the asymmetrical analogy with symmetrical ciphers. A sender would have the ability to encrypt a document / meta-data into encryption A. If X is the plain text of the document with its meta-data, then A[X] is the encapsulation or encryption of X in the format of A. A[X] can only be created by the owner making this document private and signed by that sender. Due to security concerns, A can be different than other encryption(s) that the sender could use, another encryption, Z for example, could be used to protect documents from public signing which will be demonstrated below. A[X] would be the senders signed document and Z[X] would be the senders archived private document.

[0092] To initial a message as a sender, the message as well as optional meta data is collected for initiation. The meta data can include ways to verify the sender; name, address, security PIN code, secret phrase, contract number, invoice number, User ID (Driver’s license, VISA, employee ID for example), company name, title, email address, phone numbers, private hashes, reference to another document / contract, verification service to use, etc. The meta data can also include financial or exportable data about the contract or document such as options, price, value, bill of materials, etc. that would be useful to the receiving party. Given the document X, this is FIG. 9A the Unencrypted Data 901 being fed into the Al based encryption A 950 with any optional Unencrypted Meta Data 960. 950 uses Config A 921 to encrypt 901 and optionally 960 to yield Encrypted Data Config A 907. 907 can optionally be stored for later use as the Signed document A[X] and use FIG. 9B to complete the Asymmetrical Encryption Creation or continue along in FIG. 9A as one process. The following processes apply to both FIG. 9A and 9B depending upon the desired application / implementation. 907 is then processed by Al based encryption A and B 905. This uses Config A 921 as the root transcryption and Config B 922 as the resulting output. This yields Encrypted Data Config B 908, or B[X]. B[X] contains all the same content originally passed but transcrypted into B and is the Asymmetrically encrypted version of A[X]. B[X] cannot be created by anything other than 905 transcryption. For this process to succeed, A[X] needs to be valid or ultimately a valid signature from the sender. Any other use of 905 with anything other than 907 (data encrypted in Config A) will simply fail, not producing a 908 B[X], This makes B[X] a one-way encrypted document from the sender’s A[X] signed document. B[X] is now an encrypted document, unlike current signed document technology which are white text containing a CRC or similar to validate the document hasn’t been altered. B[X] cannot be altered as it will fail to decrypt / valid when attempted. Now completely private, B[X] can then be transported / transferred to intended recipient(s) by any desired means; email, ftp, tcp / ip, udp, streamed, portable drive, cloud based, wirelessly, uploaded, messenger application, etc. Optionally, the meta data can include some secret that is stripped out of the response, but compared within the verification system. If there is no match, the verification fails. Generally this isn’t needed as the verification will fail a B[X] can only be created by A[X] which can only be created by the sender.

[0093] B[X], which is of the 908 format, is in the hands of the receiver. FIG. 10 demonstration one option for the receiver to verify and decrypt B[X], B[X] is sent to the sender’s verification service in any way required for the application. Some examples might be a TCP / IP port, FTP, Email to decrypt email address (eg decrypt@user.mycompany.com), uploaded to web portal, online service, etc. This service Al based encryption B 906 uses Config B 922 and is only configured to decrypt B[X]. The user would then get X as Unecrypted Data 901 and any optional Unencrypted Meta Data 960. These are shown as two distinct items for clarity, but they can be combined into an application specific response such as a JSON, ZIP File, fixed data formats, etc. Any attempt to validate anything other than B[X] will fail proving it wasn’t initiated by the sender through an A[X] signature. It is important to understand that X can be any digital asset such as a contract, image, video, document, or even a stream. The only change in the above would be the initiate stream X would use FIG. 9A connected to FIG. 10 at 908 to allow for a real-time stream. Additional layers of transcryption could be implemented due to application needs for different custody models such as passing an asset to an escrow (or similar concept such as a store for sale) service where the Sender cannot modify their asset, only recall it from escrow service if it hasn’t been sold. The difference here would be the addition of more layers. To keep all entities private, the escrow / store service would have another configuration for example E. The sender / seller would take their asset X convert it to B[X] by send it through the asymmetrical encryption FIG. 9 A from X -> A[X] -> B[X], B would be registered with the escrow / store as the sellers signed asset, which would then be used to transcrypt into E. So the escrow / store would use something similar to FIG. 9B, but Al based encryption B and E to convert from B[X] to E[X]. E[X] is private to that escrow / store and can no longer be access / tampered with by the sender. That service can then have numerous assets that are private until a trigger / purchase occurs. For simplicity, the sender might request the asset back. The service can then convert back to the requesters registered interim format B [ X | and then the asset can be converted back to A[X] and then back to X. Different users / customers could be used to distribute the asset through the transcryption process. In this case an interim format B was used to isolate the private encryptions A and E. Depending on trust and application need, more jumps or less can be configured, for example, E[X] -> A[X] could have been performed to save the interim step of B[X] which might be appropriate in some cases. In other cases the service might register another configuration, for example F, with the receivers. So transcryption from the service E[X] would transcrypt to F|X], the receiver might transform (in the case of the original sender) from F[XJ to B|X] and then to A[X], There could be a completely different return channel which will be described below where the sender has two service configurations, A for signing, and encrypted as A’ for receiving to prevent the ability to take A’ and send it back as A. This is since A’[X] doesn’t equal A[X] so any attempt to push A’[X] from the return into FIG. 9B as 907 will fail. The current RSA type asymmetrical encryption allows for users to encrypt data with a public key so that the owner of the public key is the only one able to recover a document. This is good in the form of a reply to the original sender. The preferred embodiment is stated above which would be the Asymmetrical encryption demonstrated in FIG. 9A, 9B, and 10. There may be cases where there might not be the ability to act like this sender. For example, a public message for a Class Action lawsuit for example might go to millions of class members. It might be cost and technically prohibitive to onboard the entire set of class members. In this case, the firm managing the class action can contact class members via the asymmetrical encryption described above requesting details about each individual claimant. Each claimant could fill out a form and send it back confidentially from the firm’ s public service.

[0094] For cohesiveness of the description above, the same situation will be described and how this additional means of working with the asymmetrical encryption can work. In this case, the sender(s) (original receivers) are not fully trusted by the intended recipient of the documentation / data, the law firm. In the document would be meta data and / or instructions to the recipients (class members) of how to return the document to the law firm. The sender(s) would fill-out documentation containing personally identifiable information (PII) or personal health information (PHI) intended to verify the class action claim. This information is sensitive and should remain confidential. The sender(s) would follow the instructions provided on how to return the document which will feed FIG. 11 Unencrypted Data 961 and any additional meta data like costs, expenses, injuries, etc. as Unencrypted Meta Data 962 which could expedite the law firms data collection and award payout.

[0095] The supplied data would then be encrypted as C[X] where X here is the supplied 961 and 962 through Al based encryption C 951 using Config C 923 to produce the Encrypted Data Config C 912 C[X]. Based upon the law firms security stance, 912 would be passed to continue on through FIG. 12A or 12B. The difference between these two figures is the return channel for the encrypted data X. FIG. 12 A with take the C[X] 912 through Al based encryption C and A 951 using Config C 923 as the primary encryption method of the incoming data and Transcrypting it into Config A 921 format, which is the outbound encryption of the law firm, yielding A[X] for the Law firm to decrypt and process the claim. This A[X] can be processed as shown in FIG. 13A by the law firm to recover the 961 and 962 sent by the individual senders in the class action. FIG. 13A shows the familial- process of decryption of Encrypted Data Config A 907 passed into the Al based encryption A 950 using Config A 921 to yield Unencrypted Data 961 and optionally Unencrypted Meta Data 962.

[0096] In the case of this public to private asymmetrical type of data return, the preferred embodiment would be shown in FIG. 12B which is similar to 12A but with a different return channel. 912 is fed into Al based encryption C and D 952, again using Config C 923 as the primary encryption input type and Config D 924 as the resulting transcrypted data type Encrypted Data Config D 965 or D[X]. FIG. 13B shows how the law firm can process and decrypt the claimants response Encrypted Dat Config D 965, D[X], by decrypting through Al based encryption D 953 using Config D 924 to recover the senders data Unencrypted Data 961 and Unencrypted Meta Data 962 if supplied.

[0097] An optimization of FIG. 1 and 2 Deterministic Pseudo Random Number Generator can be used in place of a streams basic on demand generator. This will utilize the Al logic and observations of the Al system as well as the configuration files used. Since the configuration of 100 and Probability Converter 200 might require varied amounts of DPRNs for any one encryption / decryption, a fixed value might not be able to be predetermined for each iteration of the Al based agent. Since operation is probabilistic in some configurations, note that this is an optional configuration to increase obfuscation and not required, it is difficult to know as encryption / decryption starts the amount of data needed for each iteration. There are configurations where the amount of DPRNs can easily be precalculated, but this will focus on the uncertain case as it works in both situations. In the case of precalcuating for the initial Al based agent iterations, if there is a fixed block size, that can be used based upon the stream type to determine the DPRN that will be consumed with each iteration. For example, if the fixed block size which is handled per iteration is 100 bytes, block_size, and the DPRN generates 16 bytes, DPRN_size on demand then the number of calls to the DPRN required is; DPRN_iterations = Ceiling(block_size I PPRN_size). Ceiling function returns the smallest integer that is larger than the resulting division floating point number. In this example, DPRN_iterations = Ceiling( 100 / 16 ) = Ceiling( 6.25 ) = 7. For this stream, 7 calls to the DPRN are required to fulfill the 100 bytes, the extra will be discarded.

[0098] Once the encryption / decryption process starts, the Al based agent can also automatically optimize these DPRN_iterations for each stream. This is accomplished by initializing at the initial run a stream global MaxCounter to zero and an internal stream counter to zero. The internal stream counter will be reset to zero each time the Al based agent starts a new iteration. For each call to the DPRN for data, the internal stream count is incremented. If the value exceeds the global MaxCounter, the MaxCounter is updated to reflect the new maximum amount of calls per iteration. As data is processed through the Al based agent after multiple iterations, this MaxCounter will converge upon the maximum amount of data per iteration required. Alternately, if the precalcuation is performed above, the MaxCounter can be set to DPRN_iterations rather than zero which is a better estimate of the maximum amount of DPRN required earlier in the encryption / decryption process.

[0099] Once the MaxCounter is determined for a DPRN stream(s), this information can be used to pre-request the DPRN that will be required in the future for the associated DPRN streams. This can be accomplished in any number of ways such parallel process threads, multiple cores in a Central Processing Unit (CPU), Accelerated Processing Unit (APU), Data Processing Unit (DPU), specialized hardware components, Graphical Processing Unit (GPU), external compute services such as cloud computing, or other type of parallel / accelerated approach. Depending upon the hardware the application is being implemented upon will determine how many iterations into the future can be precalculated as a something like an APU or GPU might allow hundreds or even thousands of iterations to be calculated into the future, a parallel thread or multicore CPU might only allow a “Just- in-time” level of approach. That is, the parallel thread or CPU core might finish the next PRNG request just prior to being requested by the Al based agent. In slower systems or complex PRNG complications, it is possible the Al based agent needs to wait for the precalculation to complete before continuing. Tn this wait case, the performance of the overall Al based agent will still be increased as in the basic single thread approach, the Al based agent needs to place a request only to pause to start the calculation of the required PRNG. If there is any parallel computation with the PRNG precomputation and the running of the Al based agent, this is all saved time, accelerating the Al based agent processing time on its tasks.

[0100] With this PRNG precomputed, the Al based agent can worry about the processing of data and the implementation of its functions than the creation of the PRNG. The PRNG can ultimately be outsourced to another process or service if desired. This PRNG is cached and ready to be supplied to the Agent immediately upon demand. In the case of a cache miss which could happen before final convergence of MaxCounter, the Al based agent would simply wait until the missing data can be calculated but will initiate a new request for more PRNG data with a larger MaxCounter so the cache miss doesn’t happen again. Data not used will simply be discarded. The same for cases where there is not more input data for encryption / decryption, the cached data will be discarded. If the length of the input data stream can be determined a prior, this information can be used to figure out the number of iterations to precalculate for the PRNG cache.

[0101] Computing Environment

[0102] FIG. 14 shows an example computing environment in which example embodiments and aspects may be implemented. The computing device environment is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality. The computing environment of FIG. 14 may be a computing device 1400 used by a controller 1002, and / or other hardware aspects of the disclosure, to implement aspects of the disclosure. For example, computing device 1400 may be a component of or comprise a cloud computing and storage system. Computing device 1400 may comprise all or a portion of a server or a controller. State machines, as described herein, may be implemented on one or more computing devices 1400. Each computing device may have one or more processors. In various implementations, computing devices 1400 used by the various parties may be interconnected with one another through various connections, including networks. Such networks may be wired (including fiber optic), wireless, or combinations thereof including parallel, RS-232 (all serial communication from point to point), Visual (Infra-Red), audible (modem for example). Other connections / communication standards can also be improved such as USB, PCI Express, Firewire, Fiber Channel, HDMI, I2C, SPI, etc. Some of these are important for applications such as wireless barcode readers, Credit Card Terminals, walkie-talkies, radios, video conferencing, etc.

[0103] Numerous other general purpose or special purpose computing devices environments or configurations may be used. Examples of well-known computing devices, environments, and / or configurations that may be suitable for use include, but are not limited to, personal computers, server computers, handheld or laptop devices, multiprocessor systems, cloud-based systems, microprocessorbased systems, network personal computers (PCs), minicomputers, mainframe computers, embedded systems, Internet of Things devices, network switches, network routers, network edge devices, Modulator-demodulators (modems), industrial control equipment, including distributed computing environments that include any of the above systems or devices, and the like. The computing environment may include a cloud-based computing environment. Computer-executable instructions, such as program modules, being executed by a computer may be used. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Distributed computing environments may be used where tasks are performed by remote processing devices that are linked through a communications network or other data transmission medium. In a distributed computing environment, program modules and other data may be located in both local and remote computer storage media including memory storage devices.

[0104] With reference to FIG. 14, an example system for implementing aspects described herein includes a computing device, such as computing device 1400. In its most basic configuration, computing device 1400 typically includes one or more processing units 1402 and one or more memory 1404. Depending on the exact configuration and type of computing device, memory 1404 may be volatile (such as random-access memory (RAM)), non-volatile (such as read-only memory (ROM), flash memory, etc.), or some combination of the two. This most basic configuration is illustrated in FIG. 14 by dashed line 1406.

[0105] Computing device 1400 may have additional features / functionality. For example, computing device 1400 may include additional storage (removable and / or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated in FIG. 14 by removable storage 1408 and non-removable storage 1410.

[0106] Computing device 1400 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by the device 1400 and includes both volatile and non-volatile media, removable and non-removable media.

[0107] Computer storage media include volatile and non-volatile, and removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Memory 1404, removable storage 1408, and non-removable storage 1410 are all examples of computer storage media. Computer storage media include, but are not limited to, RAM, ROM, electrically erasable program read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information, and which can be accessed by computing device 1400. Any such computer storage media may be part of computing device 1400.

[0108] Computing device 1400 may contain communication connection(s) 1412 that allow the device to communicate with other devices over networks. Such networks may be public or private, combinations thereof, and may include the internet. Computing device 1400 may also have input device(s) 1414 such as a keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s) 1416 such as a display, speakers, printer, etc. may also be included.

[0109] It should be understood that the various techniques described herein may be implemented in connection with hardware components or software components or, where appropriate, with a combination of both. Illustrative types of hardware components that can be used include Field- programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Applicationspecific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc. The methods and apparatus of the presently disclosed subject matter, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium where, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the presently disclosed subject matter. Although exemplary implementations may refer to utilizing aspects of the presently disclosed subject matter in the context of one or more stand-alone computer systems, the subject matter is not so limited, but rather may be implemented in connection with any computing environment, such as a network or distributed computing environment. Still further, aspects of the presently disclosed subject matter may be implemented in or across a plurality of processing chips or devices, and storage may similarly be effected across a plurality of devices. Such devices might include personal computers, network servers, and handheld devices, for example.

[0110] It is to be appreciated that the embodiments described herein have a wide potential for use, including data migration; interoperability; collaboration and sharing; privacy-preserving data processing; legacy system support; and the like.

[0111] Non-limiting examples of data migration include: transitioning from one encryption algorithm to another without exposing sensitive data. In another example, if an organization wants to switch from an older encryption standard to a more secure one, transcryption ensures data continuity.

[0112] Non-limiting examples of interoperability includes transcryption enabling communication between systems using distinct encryption methods by converting data from one format to another without compromising security.

[0113] Non-limiting examples of collaboration and sharing includes allowing two users employing different encryption mechanisms to share encrypted files without revealing plaintext content.

[0114] Non-limiting examples of privacy-preserving data processing includes in scenarios where data processing involves multiple parties, transcryption maintains privacy. For instance, a cloud service provider can perform computations on encrypted data without knowing the original content. Non-limiting examples of legacy system support includes where legacy systems may use outdated encryption methods, transcryption facilitates interaction with these systems while maintaining security.

[0115] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

CLAIMSWhat is claimed is:

1. A method of encrypting data comprising the steps of: a. initializing a system slatc^ b. acquiring a random data set; and c. changing the initialized system state based on the acquired random data set; d. processing meta data associated with the data to obtain an obfuscated meta data package; e. processing the data to produce encrypted data from at least a portion of the data, wherein said encrypted data is produced based upon a probabilistic state machine probabilities found through deterministic random data, where said processing comprises: i. determining a configured operation based upon a probability of the configured operation to be applied , ii. acquiring a block size of the data to ingest, iii. acquiring additional parameter data needed for the determined configured operation, iv. applying the configured operation to the ingested data to create encrypted data, v. updating the system state; and f. outputting the encrypted data and / or the obfuscated meta data package.

2. The method of claim 1, wherein initializing the system state further comprises generating an initial system state random data set, and obtaining a pre-amble size based upon a size of the initial system state random data set.

3. The method of claim 2, wherein the acquired random data set has a size equivalent to the size of the pre-amble.

4. The method of claim 3, further comprising outputting the random data set, wherein the output random data set has a size equivalent to the pre-amble size.

5. The method of any one of claims 1-4, wherein processing the meta data associated with the data to obtain an obfuscated meta data package comprises processing the meta data to produce encrypted meta data from at least a portion of the meta data, wherein said encrypted meta data is produced based upon a probabilistic state machine probabilities found through deterministic random data, where said processing comprises: i. collecting a meta data elements package, ii. adding an end of data element to the meta data elements package, iii. calculating a meta data elements package size, iv. acquiring deterministic random data, and v. obfuscating the meta data elements package with the deterministic random data to create an obfuscated meta data elements package6. The method of claim 5, wherein the acquired deterministic random data has a size equivalent to a size of the meta data elements package size.

7. The method of any one of claims 1-6, wherein the data comprises previously encrypted data.

8. The method of any one of claims 1-6, wherein the data comprises unencrypted data.

9. The method of any one of claims 1-8, wherein the meta data comprises previously encrypted meta data.

10. The method of any one of claims 1-8, wherein the meta data comprises unencrypted meta data.

11. The method of any one of claims 1-10, further comprising repeating steps d.-f. until the data is exhausted.

12. The method of claim 11, wherein outputting the encrypted data comprises outputting a stream of encrypted data after exhaustion of the data, wherein random data is injected into the stream of encrypted data to increase obfuscation of valid data.

13. The method of claim 11, wherein the data is exhausted when no additional output is required.

14. The method of any one of claims 1-13, wherein the data is from any one or more of a random data, deterministic random data, time stamp, IP address, computer internal state, probabilistic state machine internal state, external data acquisition, data file, memory, or a network port.

15. The method of any one of claims 1-14, wherein the block size of the data to ingest is dynamically determined.

16. The method of any one of claims 1-14, wherein the block size of the data to ingest is a configured block size.

17. The method of claim 16, wherein the data is a binary object of any length equal to or smaller than the configured block size.

18. The method of any one of claims 1-17, wherein the configured operation is an invertible function.

19. The method of any one of claims 1-17, wherein the configured operation comprises an injection of configured meta data.

20. The method of any one of claims 1-17, wherein the configured operation is an update to the system state and / or an operation on the ingested data.

21. The method of any one of claims 1-17, wherein the configured operation comprises an external location of updates to the system state.

22. The method of claim 21, wherein the external location comprises another IP address, a website, or a remote or local device.

23. The method of any one of claims 1-17, wherein the configured operation comprises an injection of random data.

24. The method of any one of claims 1-17, wherein the configured operation comprises operations changing the system state.

25. The method of any one of claims 1-17, wherein the configured operation comprises one of a system state, a bit, a binary object, or a block based operation.

26. The method of any one of claims 1-25, wherein the system state includes preconfigured metadata.

27. The method of any one of claims 1-25, wherein the system state includes preconfigured function probabilities.

28. The method of any one of claims 1-25, wherein the system state includes preconfigured constant data.

29. The method of any one of claims 1-25, wherein the system state includes preconfigured access to external metadata, and accesses a remote location to find such metadata.

30. The method of any one of claims 1-25, wherein the system state includes preconfigured access to external constant data, and accesses a remote location to find such constant data.

31. The method of any one of claims 1-30, wherein the method is used to encrypt an output of an existing data encryption, transformative, or protective algorithm.

32. The method of any one of claims 1-31, wherein a decryption mask or pad information is not required and is not transmitted with the encrypted data.

33. The method of claim 32, wherein the decryption mask or pad information is not stored.

34. A method of decrypting encrypted data comprising the steps of: a. initializing a system state, wherein the initialized system state matches a system state of an encrypting method used to encrypt the encrypted data; b. obtain a pre-amble size based upon the initial system state; c. ingest a data set, wherein the ingested data set has a size equivalent to the pre-amble size; d. update the system state with the ingested data set size; e. process encrypted meta data to produce an unencrypted meta data value from at least a portion of the encrypted meta data; f. update the system state with the unencrypted meta data value; g. repeat e. - f. until the encrypted meta data is exhausted; h. process the encrypted data to produce decrypted data from at least a portion of the encrypted data based upon a probabilistic state machine probabilities found through one or more deterministic random data generators, where said processing comprises:i. rendering percentages from deterministic random data, ii. determining one or more configured operation based upon a probability of the configured operation to be applied, iii. mimicking the encrypting method used to encrypt the encrypted data to calculate data length and parameters needed, iv. acquire encrypted data to ingest, v. acquire additional parameter data needed for the one or more configured operations, vi. apply inverse operations to the ingested encrypted data, vii. update system state; and i. outputting the decrypted data.

35. The method of claim 34, further comprising repeating steps e.-i. until the encrypted data is exhausted.

36. The method of claim 35, wherein outputting the decrypted data comprises outputting a stream of decrypted data after the exhaustion of the encrypted data, wherein random data is rejected from the stream of decrypted data.

37. The method of any one of claims 35-36, wherein the encrypted data is exhausted when no additional output is required.

38. The method of any one of claims 34-37, wherein the encrypted data to ingest is from a random data, deterministic random data, time stamp, IP address, computer internal state, probabilistic state machine internal state, external data acquisition, data file, memory, or a network port.

39. The method of any one of claims 34-38, wherein the one or more configured operations are an invertible function.

40. The method of any one of claims 34-38, wherein the one or more configured operations are an injection of configured meta-data.

41. The method of any one of claims 34-38, wherein the one or more configured operations are updates to the system state.

42. The method of any one of claims 34-38, wherein the one or more configured operations are external locations of updates to the system state.

43. The method of claim 42, wherein the external locations include another IP address, a website, or a remote or local device.

44. The method of any one of claims 34-38, wherein the one or more configured operations are an injection of random data.

45. The method of any one of claims 34-38, wherein the one or more configured operations are operations changing the system state.

46. The method of any one of claims 34-38, wherein the one or more configured operations arc internal state, bit, binary object, or block based.

47. The method of any one of claims 34-46, wherein the system state includes preconfigured metadata.

48. The method of any one of claims 34-46, wherein the system state includes preconfigured function probabilities.

49. The method of any one of claims 34-46, wherein the system state includes preconfigured constant data.

50. The method of any one of claims 34-46, wherein the system state includes preconfigured access to external metadata, and accesses a remote location to find such metadata.

51. The method of any one of claims 34-46, wherein the system state includes preconfigured access to external constant data, and accesses a remote location to find such constant data.

52. The method of any one of claims 34-51, wherein the decrypted data is processed by an existing data decryption, transformative, or protective algorithm.

53. The method of any one of claims 34-52, wherein a decryption mask or pad information is not required.

54. The method of claim 53, wherein the decryption mask or pad information has not been stored.

55. A method of transcrypting data comprising the steps of: a. initializing a system state, wherein the initialized system state matches a system state of an encrypting method used to encrypt a first encrypted data; b. processing the first encrypted data to produce a second encrypted data of a second type from at least a portion of the first encrypted data, wherein said processing comprises: i. acquiring first parameter data needed for primary operations, ii. acquiring second parameter data needed for secondary operations from subsystem, iii. combine primary parameter data and secondary operation data into a replacement operation for a compatible operation,iv. acquiring at least a portion of the first encrypted data to ingest, v. applying the replacement operations to the first ingested data, vi. updating the system states; and c. outputting the secondary encrypted data.

56. The method of claim 55, further comprising repeating steps b.-c. until the encrypted data is exhausted.

57. A method of re-encrypting encrypted data comprising the steps of: a. initializing a system state, wherein the initialized system state matches a system state of a primary encrypting method used to encrypt the encrypted data; b. initializing a system state of a subsystem with a second encryption configuration; c. processing primary encrypted data to produce secondary encrypted data of a second type from at least a portion of the primary encrypted data, wherein said primary and secondary encrypted data are produced based upon a probabilistic state machine probabilities found through deterministic random data, where said processing comprises: i. rendering percentages from deterministic random data, ii. rendering percentages from deterministic random data from the subsystem, iii. testing for one or more common configured operations probability that can be combined to be applied, iv. acquiring additional parameter data needed for primary operations,v. acquiring additional parameter data needed for secondary operations from subsystem, vi. combine first parameter data and secondary parameter data into a replacement operation, vii. acquire encrypted data to ingest, viii. applying the replacement operations to the ingested encrypted data, ix. updating the system states of the primary encrypting method and the subsystem; and d. outputting the secondary encrypted data.

58. The method of claim 57, further comprising repeating steps c.-d. until the encrypted data is exhausted.

59. A method of transforming data comprising the steps of: a. initializing a system state for primary data; b. initializing a system state of a subsystem with a second data configuration; c. processing the primary data to produce secondary data of a second type of data from at least a portion of the primary data, wherein said primary and secondary data are produced based upon a probabilistic state machine probabilities found through deterministic random data, where said processing comprises: i. rendering percentages from deterministic random data, ii. rendering percentages from deterministic random data from the subsystem,iii. testing for one or more common configured operations probability that can be combined to be applied, iv. acquiring additional parameter data needed for primary operations, v. acquiring additional parameter data needed for secondary operations from subsystem, vi. combine primary par ameter data and secondary parameter data into a replacement operation, vii. acquire primary data to ingest, viii. applying the replacement operations to the primary ingested data, ix. updating the system states for the primary data and the subsystem; and d. outputting the secondary data.

60. The method of claim 59, further comprising repeating steps c.-d. until the encrypted data is exhausted.

61. A method of isolating data comprising: a. initializing a data storage with only a private network access; b. configure a computing device to have authorized user access; c. provide users access to the computing device; d. configure the computing device to have access to the data storage on the private network; e. configure the computing device to manage user requests for retrieving encrypted data;f. allow the computing device to have access to the data storage at only an application level; g. configure the computing device to decrypt data requested from the data storage; h. provide the decrypted data to a user.

62. The method of claim 61 wherein one or more triggers can disable steps e.-h.

63. The method of claim 62 wherein the one or more triggers include time of day, firewall settings, increased failed authorizations, Al Based network attack alerts, and / or manual disable.

64. The method of claim 61 wherein the computing device comprises a plurality of computing devices wherein only one computing device gives user access.

65. The method of claim 64 where the additional computing devices further separate the computing device with user access from the data storage.

66. The method of claim 64 where the additional computing devices not providing user access are only accessible upon the private network.

67. The method of claim 64 where the user access is provided by a first computing device with access to a secondary computing device providing only indirect access to data storage through the secondary computing device.

68. A method of isolating data comprising the steps of: a. initializing a data storage with only a private network access; b. configure a computing device for authorized user access; c. provide one or more users access to the computing device;d. configure the computing device to also have access to the data storage on the private network; e. configure the computing device to manage user requests for storing decrypted data; f. configure the computing device to have access to data storage at only an application level; g. configure the computing device to accept user data for isolation; h. encrypt the supplied user data; i. move the encrypted user data to the data storage.

69. The method of claim 68 wherein one or more in triggers can disable steps e.-i.

70. The method of claim 69 wherein the one or more triggers include time of day, firewall settings, increased failed authorizations, Al Based network attack alerts, and / or manual disable.

71. The method of claim 68 wherein the computing device comprises a plurality of computing devices wherein only the one computing device gives user access.

72. The method of claim 71 wherein the additional computing devices further separate the computing device with user access from the data storage.

73. The method of claim 71 wherein the additional computing devices not providing user access are only accessible on the private network.

74. The method of claim 71 wherein the user access is provided by a first computing device with access to a secondary computing device providing only indirect access to data storage through the secondary device.

75. The method of claim 68 wherein the encrypted data moved to the data storage never overwrites existing data.

76. A method of accelerating a transforming of data comprising the steps of: a. configuring a computing device to transform the data; b. predetermining parameters and random data needed for transforming the data; c. configuring one or more compute threads to pre-generate required parameters and pseudo random data; d. caching the pre-generated required parameters and pseudo random data for the transformation; e. allowing access to the cached data for the transformation; f. ingesting data for transformation; g. obtaining the required parameters and pseudo random data from cached data; h. transforming the data based upon the cached data; i. outputting the transformed data.

77. The method of claim 76, further comprising repeating steps d.-i. until the ingested data is exhausted.

78. The method of any one of claims 76-77, wherein the transformation is encryption of the data.

79. The method of any one of claims 76-78, wherein the data is encrypted and the transformation is decryption of the data80. The method of any one of claims 76-79, wherein configuring the one or more compute threads comprises configuring one or more GPUs.

81. The method of any one of claims 76-80, wherein configuring the one or more compute threads comprises configuring one or more vGPUs.

82. The method of any one of claims 76-81, wherein configuring the one or more compute threads comprises configuring one or more APUs.

83. The method of any one of claims 76-82, wherein configuring the one or more compute threads comprises configuring one or more DPU.

84. The method of any one of claims 76-83, wherein configuring the one or more compute threads comprises configuring one or more external compute resources.

85. The method of any one of claims 76-84, wherein configuring the one or more compute threads comprises configuring one or more cloud service.

86. The method of any one of claims 76-85 wherein configuring the one or more compute threads comprises configuring a multicore CPU with two or more threads.

87. The method of claim 76 wherein configuring the one of more compute threads comprises configuring one or more compute threads or hardware as in claims 80-86 optimized by consumption speed.

88. The method of any one of claims 76-87, wherein caching pre-generated data comprises caching pre-generated data required in at a future time period.

89. The method of any one of claims 76-88, wherein caching the pre-generated data comprises caching pre-generated data required just in time.

90. The method of any one of claims 76-89, wherein caching the pre-generated data comprises cache pre-generated data required slower than or equal to a speed of encryption speed.

91. The method of any one of claims 76-90, wherein predetermining the parameters and random data needed for transforming the data is calculated based upon the configuration of the computing device.

92. The method of any one of claims 76-91, wherein predetermining the parameters and random data needed for transforming the data is calculated based upon a learned demand.

93. The method of any one of claims 76-92 where predetermining the parameters and random data needed for transforming the data is calculated based upon a supplied configuration and updated upon a learned demand.

94. A method of digitally signing data comprising the steps of: a. initializing a system state with a primary encryption configuration; b. ingesting data to be digitally signed; c. encrypting the ingested data with the primary encryption configuration; d. storing the encrypted data; c. initializing a system state with secondary encryption configuration; f. initializing a transcryption subsystem state with a secondary configuration; g. ingesting the stored data to be digitally signed; h. transcrypting the ingested data that has been encrypted with primary encryption; i. outputting transciypted data in the secondary configuration;95. The method of claim 94 wherein the ingested data comprises ingested data and meta data.

96. A method of validating digital signing data comprising the steps of:a. initializing a system state for decryption, wherein a configuration of the decryption is a same configuration as a secondary configuration of a digitally signed document; b. ingesting data to validate a digital signature of the digitally signed document; c. decrypting the ingested data; and d. outputting at least an indication if the digital signature is valid.

97. The method of claim 96 wherein the ingested data comprises ingested data with meta data.

98. A method of privately replying to signed data comprising the steps of: a. initializing a system state with a primary encryption configuration known to an intended recipient; b. ingesting data to be digitally signed; c. encrypting the ingested data with the primary encryption configuration; and d. outputting the encrypted ingested data.

99. The method of claim 98 wherein the ingested data comprises ingested data and meta data.

100. The method of claim 98 further comprising transcryption of the encrypted ingested data to secondary encryption: a. initializing a system state with the primary encryption configuration known to a replier; b. initializing a transcryption subsystem state with a secondary configuration known to the intended recipient; c. ingesting the encrypted ingested data;d. transcrypting the encrypted ingested data directly from its primary encryption to a secondary encryption configuration; and e. outputting the transcrypted data in its secondary encryption configuration.

Images