Communication method and apparatus, method and system for folding data, and computer

Abstract

A communication method and apparatus, a method and system for folding data, and a computer are provided. A method of communicating via a network, comprising: processing a message using a method for folding data, including processing at least one input data object using a plurality of logical operations to produce at least one output data object, wherein data folding encapsulates at least one output data in at least one data field of a data structure with at least one essence of the plurality of logical operations performed in discrete steps on a same one of the at least one input data object, the at least one essence of the plurality of logical operations performed in discrete steps being encapsulated in at least one command field of the data structure; wherein the at least one output data object is configured to produce the same one of the at least one input data object using the encapsulated at least one essence of the plurality of logical operations performed in discrete steps.

Description

[0001] This application is a divisional application of the invention patent application filed on August 31, 2017, with application number 201780053634.5 (PCT / US2017 / 049661) and entitled "Encrypted User Data Transmission and Storage". Cross-references to related applications

[0002] This application is based on and derived from priority of U.S. Provisional Patent Application No. 62 / 395,084, filed September 15, 2016, the entire contents of which are incorporated herein by reference. Summary of the Invention

[0003] The data center model in computer software design prioritizes user data over applications. Data center software design allows data to be stored at a fixed point. Data containerization is one embodiment of data center design. To demonstrate how various concepts can be implemented within this disclosure, a series of diagrams from different perspectives highlight the specific concepts explored, and the overall diagrams show how several of these programs and structures can work together.

[0004] Data containerization can be presented in a layered approach, and preferably, each layer can be built on or work in conjunction with a previous layer, either partially or entirely. The concepts, methods, apparatuses, embodiments, and / or specifications described herein for the first layer can be collectively referred to as Structured Data Folding Utilizing Transformations or SDFT. The concepts, methods, apparatuses, embodiments, and / or specifications described herein for the second layer (which may contain the first layer) can be collectively referred to as Encrypted User Data Transmission and Storage or NUTS. Any combination of layers can be deployed partially or entirely to construct a data container called Nut, and layers can be deployed partially or entirely in isolation. The interaction and / or interweaving of these two layers can be significant and / or complex and can pose challenges to the clear demarcation of such layers. Therefore, these layers are presented together in this specification. The Nut container can then be infused with various data center characteristics that allow logical operations on the data contained therein. Various embodiments can be described based on the storage unit called Nut to demonstrate how certain common data-oriented logical operations can be redefined and restructured to provide users with privacy, security, convenience, and / or capabilities. Attached Figure Description

[0005] Various embodiments are disclosed in the following detailed description and accompanying drawings: Figure 1 Display a symbol table used to represent different cryptographic key types.

[0006] Figure 2 This section presents a set of simplified flowcharts illustrating data input, data output, and logical operations that can typically be performed using different cryptographic methods.

[0007] Figure 3 A diagram illustrating a general network layout in which embodiments of the present disclosure can be performed.

[0008] Figure 4 An illustration of a computing device in which embodiments of the present disclosure can be run.

[0009] Figure 5 A diagram illustrating the transition in a positive mode or normal operation.

[0010] Figure 6 A table showing common data operations and their transformation categories.

[0011] Figure 7 A diagram illustrating the transition in the reverse mode.

[0012] Figure 8 A diagram illustrating irreversible changes.

[0013] Figure 9 A diagram illustrating conditionally reversible transitions.

[0014] Figure 10 A table showing common data operations and functions grouped by conversion type.

[0015] Figure 11 Displays the encoding / decoding tables defined in Python v3.

[0016] Figure 12 Display a table listing the additional transformation definitions.

[0017] Figure 13 Demonstrate a transformation invertibility matrix.

[0018] Figure 14 Display a transition modal action matrix.

[0019] Figure 15 Show a detailed example of serialization transformation.

[0020] Figure 16 This section presents a detailed example of a summary transformation.

[0021] Figure 17 This section presents a detailed example of a summary transformation (also known as a test) in a reverse pattern.

[0022] Figure 18 A diagram illustrating the transformation of a scipher.

[0023] Figure 19 A diagram illustrating the transformation of salsa20 (scipher).

[0024] Figure 20This section presents a detailed example of the salsa20 (scipher) transformation.

[0025] Figure 21 This document presents a command specification table for serialization and compression conversion, along with a set of sample conversion commands demonstrating their applications.

[0026] Figure 22 This document presents a command specification table for encoding transformation and a set of sample transformation commands demonstrating its use.

[0027] Figure 23 This document presents a summary of the command specifications for transformations and a set of sample transformation commands demonstrating their usage.

[0028] Figure 24 This document presents a command specification table for the Acipher and Dign transformations, along with a set of sample transformation commands demonstrating their usage.

[0029] Figure 25 This document presents a command specification table for a derived transformation and a set of sample transformation commands demonstrating their usage.

[0030] Figure 26 The specification table 2602 shows a scipher transformation command and a set of sample transformation commands 2604 showing its use.

[0031] Figure 27 This demonstrates the output structure format of the scipher output string in a two-step sequence, where step 1 illustrates the input format and step 2 illustrates the output format. The "header" is a variable-length UTF-8 encoded parameter string of the scipher transition in the output message.

[0032] Figure 28 This table displays the header string parameters, keywords, and specifications in the output structure format of a Scipher transformation.

[0033] Figure 29 This diagram illustrates the iterative embedded message encapsulation of the AEAD mode scipher transition.

[0034] Figure 30 The specification table 3002 shows a lock transition command and a set of sample transition commands 3010 showing its use.

[0035] Figure 31 The specifications for various transformation structures are presented in tabular format.

[0036] Figure 32This document presents a command specification table for Mobius transformations. Its uses are shown, and a graphical representation illustrates the structural changes it can make to various structures. A matrix illustrates the effective operations of Mobius transformations on its structure type / mode.

[0037] Figure 33 Specification tables 3302 and 3304 for commands to press (data preparation), clean (data cleanup), and key (key) transformation, and a set of sample transformation commands 3310 to demonstrate their uses.

[0038] Figure 34 A table showing the Key Exchange Specification Structure or KISS.

[0039] Figure 35 Table 3502 shows the KISS operation mode, matrix 3504 shows the key type / field generation mapping, and key type definition 3506.

[0040] Figure 36 This demonstrates the structure of a TAR and provides an example of a TAR definition.

[0041] Figure 37 Display a diagram showing where the transformation-related attributes are temporarily located, and a table listing the types and locations of the attributes.

[0042] Figure 38 A diagram illustrating the SDFT operation of piecing together and disassembling (or the reverse of piecing together).

[0043] Figure 39 A flowchart showing the SDFT splicing operation.

[0044] Figure 40 A flowchart illustrating the SDFT disassembly process.

[0045] Figure 41 This demonstrates how to perform a reverse TAR on a fellow TAR.

[0046] Figure 42 This demonstrates an example of reverse TAR.

[0047] Figure 43 Show a transformation table that is mapped to a key type template that can be generated or required during TAR processing.

[0048] Figure 44 Show TAR instances and the key templates generated from each instance.

[0049] Figure 45 Displays TAR instances and the key templates generated by each instance, as well as the expected list of KISS structures to be input (put) or generated (generated). The KISS list is also known as the key stack.

[0050] Figure 46 This demonstrates three modes of key stack operations within the SDFT TAR process: generation, input, and mixed.

[0051] Figure 47 A diagram illustrating how to generate and use a key stack in the data lifecycle and its TAR.

[0052] Figure 48 A diagram illustrating the operations that can occur on data stored in an NSstr structure.

[0053] Figure 49 A flowchart illustrating the use of SDFT in iteratively folding data.

[0054] Figure 50 A flowchart illustrating the use of SDFT in iteratively unfolding data.

[0055] Figure 51 A diagram illustrating the SDFT API / library and the various types of TAR definition files that it can access.

[0056] Figure 52 This demonstrates an example Python script that performs manual data folding.

[0057] Figure 53 This demonstrates an SDFT instance defined by TAR and its use in a Python script.

[0058] Figure 54 A block diagram illustrating dynamic TAR switching within a single communication session.

[0059] Figure 55 A flowchart illustrating an exemplary process for generating Nut IDs is provided.

[0060] Figure 56 The diagram shows where Nut IDs and lock IDs can be used within Nut.

[0061] Figure 57 This demonstrates an exemplary relationship between Nut ID, path name, and payload data.

[0062] Figure 58 A block diagram illustrating an embodiment of a Nut or lock diagram, including a logic segment Nut lock and a Nut portion.

[0063] Figure 59 A block diagram illustrating an alternative embodiment of the Nut lock in a Nut that includes three keyhole lock nodes.

[0064] Figure 60A block diagram showing the internal data structure of the lock node.

[0065] Figure 61 Shown Figure 60 The diagram shows the internal data structure of the input section of the lock node.

[0066] Figure 62 This diagram illustrates the data flow when a valid primary key can be inserted into the keyhole. Figure 61 The diagram shows the relationship of the internal data structure of the first-level keyhole in the input section.

[0067] Figure 63 The flowchart shows the key insertion procedure for any lock node and any cryptographic key.

[0068] Figure 64 This demonstrates three instances where the first-level key can be inserted into the first-level keyhole.

[0069] Figure 65 Show your freedom Figure 64 The example shown in the diagram continues the data flow of a variable lock decryption operation.

[0070] Figure 66 Show your freedom Figure 64 The example shown in the diagram continues the data flow of variable lock encryption operations.

[0071] Figure 67 A table showing the variable lock types and their properties that can be used in any lock node.

[0072] Figure 68 This diagram illustrates the data flow of the ORLOCK decryption operation.

[0073] Figure 69 This diagram illustrates the data flow of the ORLOCK encryption operation performed by the Nut owner.

[0074] Figure 70 This section presents a data flow diagram illustrating the MATLOCK decryption operation.

[0075] Figure 71 This diagram illustrates the data flow of the MATLOCK encryption operation performed by the Nut owner.

[0076] Figure 72 This diagram illustrates the data flow of the XORLOCK decryption operation.

[0077] Figure 73 This diagram illustrates the data flow of the XORLOCK encryption operation performed by the Nut owner.

[0078] Figure 74This section displays a data flow diagram illustrating the HASHLOCK decryption operation.

[0079] Figure 75 This diagram illustrates the data flow of the HASHLOCK encryption operation performed by the Nut owner.

[0080] Figure 76 This diagram illustrates the data flow of the SSLOCK decryption operation.

[0081] Figure 77 This diagram illustrates the data flow of the SSLOCK encryption operation performed by the Nut owner.

[0082] Figure 78 A block diagram showing the Nut that highlights the hierarchical key.

[0083] Figure 79 A flowchart showing how hierarchical keys can be inserted into Nut.

[0084] Figure 80 Display a key-based permission table for two roles and four role players.

[0085] Figure 81 The table lists the various parts of a typical Nut, where each part can be represented by a lock node.

[0086] Figure 82 The table lists key-based access permissions for typical Nuts.

[0087] Figure 83 A block diagram showing how the initial group of Nut access control access keys (called the Access Attribute Key Group Unlock Key (AAKSUK)) can be inserted into the access key hole of each valid first-level key.

[0088] Figure 84 A diagram illustrating how NAC access attributes propagate from the outer lock node to the inner lock node.

[0089] Figure 85 A block diagram illustrating how NAC access attributes propagate from the external lock node to the internal lock node and how the output link key is inserted into the first-level keyhole of the linked lock node.

[0090] Figure 86 This diagram illustrates the process of inserting a key into the access keyhole.

[0091] Figure 87 A table for key-based authorization is shown for an alternative embodiment.

[0092] Figure 88 A data flow diagram showing the internal decryption data flow of the lock node.

[0093] Figure 89 Show the flowchart for unlocking Nut.

[0094] Figure 90 This document presents an embodiment of a NUTS-based system and a block diagram illustrating how files stored in Nut can be unlocked.

[0095] Figure 91 This diagram illustrates the common use of the terminology NUTS to refer to the payload of a Nut by holding its Nut ID. Here, the cryptographic key can be referred to by the Nut ID that holds its Nut.

[0096] Figure 92 A simplified example of a list of receiver-locked models.

[0097] Figure 93 A simplified embodiment of the ordered locking model is shown.

[0098] Figure 94 A simplified embodiment of an ordered locking model with a master key is presented.

[0099] Figure 95 A simplified embodiment of a locking model with a master key is shown.

[0100] Figure 96 A simplified embodiment of a locking model with a master key is shown.

[0101] Figure 97 A simplified embodiment of a secure safe deposit box locking model is shown.

[0102] Figure 98 A simplified embodiment of a secret-shared locking model with a master key is shown.

[0103] Figure 99 A simplified embodiment of the "PrivaTegrity" type locking model is shown.

[0104] Figure 100 A simplified example of a multi-Nut configuration is shown, in which multiple payloads can be stored within a single Nut.

[0105] Figure 101 A simplified example of a multi-Nut configuration is shown, in which multiple payloads can be stored within a single Nut.

[0106] Figure 102 A simplified embodiment of a direct-lock model with multiple payloads is shown.

[0107] Figure 103 This demonstrates a simplified example of an orderly message passing system designed to resist collusion.

[0108] Figure 104A block diagram showing typical components of modular I / O.

[0109] Figure 105 This diagram illustrates simple read and write operations using MIOR.

[0110] Figure 106 This demonstrates the data transformations and transfers involved in a typical MIO file read operation.

[0111] Figure 107 This illustrates how modular I / O can be used to promote backward compatibility of file formats.

[0112] Figure 108 This illustrates how modular I / O can be used to promote forward compatibility of file formats.

[0113] Figure 109 This illustrates how modular I / O can facilitate modular displays.

[0114] Figure 110 This illustrates how modular I / O can be used to facilitate modular applications.

[0115] Figure 111 The diagram illustrates the gradual changes in Nut's history across two edits and three points in time.

[0116] Figure 112 Plotting Nut logs from Figure 111 Gradual changes within the course of an event.

[0117] Figure 113 This demonstrates how relationship-based keys can be represented in Alice and Bob's contact cards.

[0118] Figure 114 A flowchart demonstrating how to detect SPAM using a well-known email address and / or RBK.

[0119] Figure 115 A flowchart illustrating how to detect SPAM using anonymous email addresses and / or RBKs.

[0120] Figure 116 Show the state matrix of the Alice-Bob RBK communication channel based on deterministic context.

[0121] Figure 117 Display the state matrix based on deterministic context for the Alice-vendor RBK communication channel.

[0122] Figure 118 Show the deterministic context-based state matrix of the vendor-Alice RBK communication channel.

[0123] Figure 119Plot the isolation of RBK relations in a restricted system for Bob.

[0124] Figure 120 A diagram showing the pre-packaged data Nut.

[0125] Figure 121 Plot a graph of the event sequence in an automated registry using RBK.

[0126] Figure 122 Plot a diagram of the sequence of events in an automated registration process that uses RBK and anonymous email addresses.

[0127] Figure 123 A table listing the core NUTS applications and their descriptions is displayed.

[0128] Figure 124 A block diagram showing the NUTS core applications running on a computer device.

[0129] Figure 125 A block diagram showing a NUTS server running on a user device.

[0130] Figure 126 A block diagram showing the internal components of the NUT server and its functional connections to the user device's environment.

[0131] Figure 127 Demonstrating the use of NoSQL databases as a cache mechanism in Figure 126 The alternative embodiment of the NUT server shown in the figure.

[0132] Figure 128 A block diagram showing the MIOR server network layout.

[0133] Figure 129 A diagram showing the layout of the MIOR server application.

[0134] Figure 130 This diagram illustrates the process of extracting the MIO module from the MIOR server. Figure 131 A diagram illustrating the MIOR cache is displayed.

[0135] Figure 132 A diagram showing the NUT browser application in the user's device environment.

[0136] Figure 133 A block diagram illustrating the NUT book application in a user device environment.

[0137] Figure 134 A block diagram illustrating the NUT processing application architecture in a user device environment.

[0138] Figure 135 The diagram shows the internal components of the NUT book.

[0139] Figure 136 The illustrations are from Figure 135 A diagram illustrating the internal organization of the NUT book directory cache.

[0140] Figure 137 A diagram showing the organization that displays hierarchical access codes is displayed.

[0141] Figure 138 Show how the main access code is displayed according to Figure 137 Use the access code to open personal files.

[0142] Figure 139 Show how the main access code is displayed according to Figure 137 Hierarchical access codes and Figure 138 Open your personal file in the file manager.

[0143] Figure 140 How to display the main and work access codes according to Figure 137 Use the hierarchical access code to open the working file.

[0144] Figure 141 Show how the main access code is displayed according to Figure 137 Hierarchical access codes and Figure 140 Open the working file in the file.

[0145] Figure 142 The illustrations are from Figure 135 A block diagram of the internal organization of the NUT book key cache.

[0146] Figure 143 A flowchart showing how to view the card catalog in a NUT book.

[0147] Figure 144 A table displaying NUTS-based services.

[0148] Figure 145 A diagram illustrating the network layout of NUTS-based services.

[0149] Figure 146 A diagram illustrating the network layout of the NUT mail server.

[0150] Figure 147 Plot a sequence of events in an automated registration process for anonymous email services (such as NUT Mail) using RBK.

[0151] Figure 148 A graph showing the sequence of events when a communication channel is added to the NUT mail server.

[0152] Figure 149 Draw a diagram of the sequence of events when Alice and Bob send emails via NUT Mail.

[0153] Figure 150 A diagram showing the network layout of the NUT chat server.

[0154] Figure 151 This section presents a data flow diagram of three chat sessions hosted by the NUT chat server.

[0155] Figure 152 This diagram illustrates the data flow for chat history persistence and replication across NUT servers.

[0156] Figure 153 This section presents a data flow diagram of three separate chat sessions using different chat IDs or chat services.

[0157] Figure 154 The display is provided by the user from Figure 153 The data flow diagram of the path-agnostic dialogue managed by the NUT chat client with three different chat paths.

[0158] Figure 155 A diagram illustrating the network layout of the NUT cloud server.

[0159] Figure 156 A diagram illustrating the network layout of the NUT network server.

[0160] Figure 157 A diagram showing the network layout of a NUT hub server for NUTS networking (IoN).

[0161] Figure 158 A diagram illustrating the topology of a direct IoN network.

[0162] Figure 159 A diagram illustrating the topology of an indirect IoN network.

[0163] Figure 160 Showing from Figure 159 A diagram illustrating the NUT server hub and its connections to the NUT hub and IoN devices.

[0164] Figure 161 Showing from Figure 160 A block diagram of the NUT hub / IoN interface in a NUT server hub.

[0165] Figure 162 Showing from Figure 160 A block diagram of the NUT hub / NUT server / IoT interface in an IoN device.

[0166] Figure 163A flowchart illustrating the registration and configuration process for IoN / IoT devices.

[0167] Figure 164 Demonstrate how remote control interfaces can handle data from... Figure 161 and Figure 162 The flowchart of Nuts commands.

[0168] Figure 165 A diagram showing the network layout of a NUTS-certified server.

[0169] Figure 166 The display highlights the source Figure 165 A block diagram of the functionality of the NUTS certified server.

[0170] Figure 167 A diagram illustrating the network layout of a NUTS-based WiFi / Ethernet router.

[0171] Figure 168 The display can be found from Figure 167 A flowchart illustrating how messages are processed in a NUTS-based WiFi / Ethernet router.

[0172] Figure 169 A table showing the device classification of NUTS-based WiFi / Ethernet routers.

[0173] Figure 170 A table showing the classification attributes of exemplary devices on NUTS-based WiFi / Ethernet routers.

[0174] Figure 171 A diagram illustrating how application packaging can automate device backup and replication.

[0175] Figure 172 A block diagram showing the Event Processing Service (EPS) in two devices.

[0176] Figure 173 A diagram illustrating a typical provider network setup that uses tracking cookies and session history stored on a big data server.

[0177] Figure 174 The demonstration uses App Nut to record locally and store data from external sources. Figure 173 A diagram showing the vendor network settings for replicating session history on a big data server.

[0178] Figure 175 The display can use from Figure 173 and Figure 174 A diagram showing the context calculations performed by App Nut on the local device.

[0179] Figure 176 A diagram illustrating the topology of a personal home network, including IoT devices and service providers.

[0180] Figure 177 A diagram illustrating a personal home network that includes two IoN devices in an indirect IoN network topology and their respective service providers to control the data flow output to the provider.

[0181] Figure 178 Demonstrating how context analysis apps can automatically filter output IoN messages to protect against incoming messages. Figure 177 A diagram illustrating user privacy in a NUT server. Detailed Implementation

[0182] Table of contents ● Symbols and abbreviations ●Cryptography and one-way hashing ●Network Diagram ●Diagram of the device ●Transformation ●Transformation Type ●Structural Transformation ●Transformation of Audit Records (TAR) ● Utilizing Transformed Structured Data Folding (SDFT) ●Nut ID ● Locked graph and locked nodes ○ Keyhole ○ Variable Lock ○ Level Nut Access Control (NAC) ○ Lock node traversal ● Modular I / O ○ Read and Write ○ Backward compatibility ○ Forward compatibility ○ Monitor ○Application ●Nut History ●Nut Log ● Relationship-based key (RBK) ●Anonymous relationship ●NUTS Core Applications ○NUT Server ○MIOR Server ○NUT Browser / NUT Shell ○NUT book ● NUTS-based services ○NUT email ○NUT Chat ○NUT Cloud ○NUT Network ○NUT Hub ○NUTS certified server ● NUTS-based WiFi / Ethernet routers ●Application Packaging ● Incident handling service ●Contextual computation ●Conclusion and Philosophical Insights Symbols and abbreviations The following symbols and abbreviations may be used throughout the description and accompanying drawings. Symbols marked with (*) may be unique to NUTS:

[0183] Figure 1 A table showing the types of cryptographic keys and their respective symbols used throughout the description and drawings of this invention is provided. Symbol 102 may represent a passcode or codeword based on variable-length text. Symbol 104 represents a key for a symmetric or alternative cryptosystem including AES-256. Symbol 106 represents a key pair for asymmetric or alternative cryptosystem including RSA-2048. The public portion of an asymmetric key pair 106 may be depicted as symbol 108, and the private portion may be shown as symbol 110. Those skilled in the art will readily recognize that such cryptosystems can be well-known and well-tested algorithms, and that other suitable methods can be substituted where specified in this disclosure are applicable when standards change or alternatives are desired.

[0184] Cryptography and One-Way Hash Figure 2 This describes the basic operations that can be performed by various types of cryptography. In encryption mode, symmetric cipher 208 accepts symmetric key 202 and data 204 to produce encrypted data 206 or ciphertext. In decryption mode, symmetric cipher 208 accepts the same symmetric key 202 and ciphertext 206 to produce the original data 204. In implementations of symmetric cryptography, the encryption and decryption methods can be two separately named function calls or a single call with a mode parameter as part of the input. A characteristic of symmetric cryptography is that both the encryption and decryption processes can utilize the same secret key 202.

[0185] In encryption mode, asymmetric key 214 accepts the public portion of asymmetric key pair 210 and data 204 to produce encrypted data 212 or ciphertext. In decryption mode, asymmetric key 214 accepts the private portion of asymmetric key pair 216 and ciphertext 212 to produce the original data 204. In implementations of asymmetric keying, the encryption and decryption methods can be two separately named function calls or a single call with a mode parameter as part of the input. A characteristic of asymmetric keying is that the encryption and decryption processes can utilize different parts of the key pair. In implementations such as RSA-2048, a public key can be derived from the private key using mathematical relations; therefore, the RSA-2048 private key is synonymous with the key pair and the public key can be extracted from it.

[0186] In signing mode, digital signature method 222 accepts the private portion of asymmetric key pair 216 and ciphertext 218 to generate digital signature 220. In authentication mode, digital signature method 222 accepts the public portion of asymmetric key pair 210, digital signature 220, and ciphertext 218 to authenticate 224 whether the digital signature was generated using ciphertext 218 and the private portion of asymmetric key pair 216. In embodiments of the digital signature method, the signing and authentication methods can be two separately named function calls or a single call with a mode parameter as part of the input. A characteristic of the digital signature method is that the signing and authentication processes can utilize different portions of the key pair. In embodiments such as those based on RSA-2048 key pairs, a public key can be derived from a private key using mathematical relations; therefore, the RSA-2048 private key can be synonymous with the key pair and the public key can be extracted from it. For the sake of brevity and clarity, this document will use the term "dign" interchangeably for digital signature; "digning" interchangeably for the behavior of digitally signed data; and "digned" interchangeably for digitally signed data.

[0187] Digital signature methods can be of the type Message Authentication Code (MAC). A MAC can be generated using a one-way hash algorithm applied to the data. Hash methods such as SHA-512 can accept data content to produce a message digest of it, which can be up to 512 bits long. MAC authentication using methods such as SHA-512 requires recalculating the MAC on the data and comparing the provided MAC with the calculated MAC. A technique called Keyed Hash Message Authentication Code (HMAC) uses an additional input of a cryptographically compiled key along with the data content to generate an HMAC value.

[0188] Digital signature methods and / or hashing methods may be used in various parts of this disclosure to generate message digests that represent the respective data.

[0189] Network diagram Figure 3 A simplified network diagram is shown, in which various embodiments of this disclosure may be applied in part or in full. Wide Area Network (WAN) 302 may be represented as a network cloud, which may include numerous servers, routers, and switching systems working together at various telecommunications centers to provide a simplified view of the network cloud to a user or company. Cloud service 304 may also be graphically simplified as a cloud representing various business systems that provide network services such as cloud storage and cloud processing; these services may be implemented according to their own specifications but may include numerous examples of server farms, storage arrays, and routers. Personal router 306 may be connected to WAN 302, providing the user with internet access from among multiple network-connectable devices 308 to 318 that an individual user may have. The user may not be limited to the devices depicted in the diagram, but may use any device that can utilize a router to access other devices on the same network or other devices across the internet. Router 306 may be a dedicated routing device of an internet service provider or a combination of devices that provide routing and / or LAN and / or WLAN capabilities and may be referred to as a gateway. The company router 320 can be connected to WAN 302, which can provide organizational users with Internet access from among the multiple network-connectable devices 302 to 330 that the company may have. The company is not limited to the devices depicted in the diagram, but may use any device that can utilize a router to access other devices on the same network or other devices across the Internet. Router 320 may be a dedicated routing device for an Internet service provider, or it may be a set of interconnected and managed routers providing routing and / or LAN and / or WLAN capabilities and may be referred to as a gateway and / or internal network. The systems and methods described in the various embodiments herein can be used and applied to some or all of this network diagram.

[0190] Device diagram exist Figure 4 A general-purpose computing device 400 is depicted. A processing unit 404 is connectable to a system bus 402, which facilitates some or all of the internal communication and data transfer within the device. Several different types of system buses exist, but for illustrative purposes, they are collectively referred to as system bus 402. The processing unit may represent a single-core or multi-core processor and a processor array, such as the processor arrays present in various dedicated processing boards such as GPU boards and blade servers. Other components served by the system bus may include: a network adapter 412; an I / O interface 410; a display interface 414; a read-only memory (ROM) 406 that stores the BIOS program 408; volatile memory (RAM) 416 that temporarily stores the running operating system 418, running applications 420, and / or application data 422; and non-volatile memory 424, such as hard disk drives, SSDs, and flash drives 426, which collectively permanently store the installed operating system 428, application programs 430, and / or data files 432.

[0191] Enabling and operating some or all embodiments of this disclosure does not necessarily require all components of the depicted computing device. For example, the device may not have any physical display or I / O interfaces as found on some IoT devices; routers and gateways may have fewer physical hard drives. A necessary requirement for NUTS support and compatibility may be the ability to run NUTS-compatible software, which may include a processing unit, some form of storage, and a system bus.

[0192] change Transformation can be a preferred approach for organizations to explore the many known data manipulation operations found in computer programming. NUTS can designate this as the Transformation Organizational Principle or TOP. Furthermore, any system data manipulation operation can be analyzed using TOP and categorized as a transformation type. Transformation can then be categorized, normalized, structured, integrated, and / or adapted to work collaboratively within the framework of TOP; this can be termed Structured Data Folding Utilizing Transformation, or SDFT. TOP's profound perspective and / or the manipulation of data using SDFT allow for the implementation of better and / or complex data designs in a conceptually simpler and / or procedurally more efficient manner. TOP and SDFT can be preferred low-level implementation mechanisms for NUTS components.

[0193] Data transformation-based analyses, methods, and / or structures can demonstrate how these concepts can be layered, and designing their associated methods can define a set of implementable, integrated data structures and algorithms that allow for easy and systematic data transformation in a modular, portable, storable, and / or self-describing manner. Due to the layered and interwoven nature of these analyses, the description of the transformation can have forward and backward references and may require the reader to engage with different sections to gain a better understanding of certain characteristics. Structured Data Folding (SDFT) leveraging transformation builds upon the transformation of data structures and methods and helps achieve storability, transmissibility, modularity, portability, encapsulation, and / or time compatibility of the transformed data.

[0194] Within the NUTS design, SDFT is a set of low-order operations and can be viewed as a fundamental building block for more easily constructing Nuts. However, SDFT can be used alone, partially, or entirely to simplify certain verbose and / or repetitive data transitions within an application. SDFT enables computer communication protocols to dynamically switch transition sequences and / or transition parameter changes within the same session between two different applications. Currently, this single-session dynamic switching can be a significant procedural exercise. SDFT is not mandatory for building Nuts, but its features facilitate easier, clearer, and more flexible Nut construction. SDFT can be further described as a data state transition method that allows for an infinite variety of transition events with well-defined behavior regarding the reversibility of state transition sequences and provides an iterative encapsulation technique to temporarily retain necessary attributes and data in a simple, context-sensitive manner. SDFT accepts and incorporates the messy conditions of everyday programming problems and presents a set of practical organizing principles, where theoretical evidence can be subordinate to experimental evidence.

[0195] Figure 5 The transformation organization principle demonstrates how any data operation can be viewed as a data transformation 510, which may require input data source 502 and attributes 504 and output transformed data 512 and associated attributes 514. Any well-defined manipulation, operation, transformation, and / or alteration of data can be categorized as a transformation type 510. TOP allows us to systematically construct a consistent set of methods for transforming data in a modular, portable, and / or self-describing manner.

[0196] Figure 6 The table below illustrates a set of simple, common data operations and how to categorize them using TOP. Transformations can encompass categories of basic data operations that may have been traditionally separated in perception and practice. This is similar to how, when programmers discuss cryptography and data compression, these two data operation categories can generally be viewed as two very separate and distinct operations on data. Aside from the algorithmic differences between the operations, from a TOP perspective, these operations can be viewed as types of cryptographic and compression transformations. In the table, "JSON serialization" can be categorized as a "serialization" transformation using the "json" operation, so the executable transformation command can be stated as "serialize json". A call to AES symmetric encryption of data can be categorized as a "scipher" transformation using the "aes" operation, so the executable transformation command can be stated as "scipher aes". Those skilled in the art will readily recognize all other data operation types listed in the table and follow the organizational structure of transformation and operation categories.

[0197] Figure 7 This diagram illustrates the transition in a reverse mode or reverse operation. This diagram is identical to... Figure 5Except that the data flow arrows flow in opposite directions. Transformation 510 can have a well-defined reversible algorithm, as illustrated by block 710. Reversible transformation 710 may require the transformed data source 712 and attribute 714 as input and can output the original data 702 and associated attribute 704. So-called reversible computation may exist in the field of computing, exhibiting concepts similar to reversible transformations. There may be some differences in the goals of various organizational principles. Reversible computation can infer the existence of a general reversible computation language whose operations can be implemented down to the silicon layer to achieve the possible energy efficiency of general computation. Reversible transformation can be committed to the specific implementation of TOP to obtain benefits such as, but not limited to, minimizing write codes, minimizing programming errors, facilitating key management, simplifying key generation, structuring portable self-describing data, normalizing data manipulation concepts, introducing programming language-independent methods for performing transformations, and / or simplifying the creation of complex cryptographically compiled data structures.

[0198] Figure 8 This demonstrates a graphical representation of an irreversible transformation. In forward mode, transformation 810 performs a transformation on data 802 and attribute 804, resulting in transformed data 812 and attribute 814. However, the type of manipulation that can be performed on the inputs by these outputs, along with the transformation itself, can be irreversible. Such irreversible transformations can be exemplified by hashing, MAC, lossy data compression, and other one-way functions or data manipulations. TOP can incorporate analytical techniques that can externally enhance the characteristics of such irreversible transformations and generate operations that can limit their reverse transformation characteristics.

[0199] Figure 9 A block diagram of a conditionally reversible transformation is shown. This transformation 910 may have a well-defined reversible algorithm but may require additional input and / or attributes 914 for the reverse operation to succeed. A conventional reversible transformation 910 may require the transformed data source 912 and / or attributes 914 as input and may output the original data 902 and / or associated attributes 904 if and only when the required condition 916 is met; otherwise, it may fail under error condition 920. Cryptography that requires a key can be classified as a conventional reversible transformation because the absence of the correct key (attribute) can prevent the decryption of the ciphertext.

[0200] Figure 10This is a table listing common data operations and functions and their respective transformation categories. Those skilled in the art will recognize some or all of the data operations and / or functions listed in the table. For illustrative purposes, the material presented in this document may refer to the programming language known as Python version 3.6 and its syntax, concepts, functions, and / or methods. Many cryptographic compilation functions referred to in this disclosure can be found in the Python standard, pyCryptodome, secret sharing, and / or the pyCrypto library. Those skilled in the art can find equivalent syntax, concepts, functions, and / or methods in the most modern programming languages ​​and their respective libraries. It should be noted that "dign" is a transformation used for digital signatures; other mnemonics can be listed in the Symbols and Abbreviations section of this document. Figure 12 Further detailed descriptions of each transformation can be found in the table.

[0201] Figure 11 This is a list of encoding / decoding tables defined in Python v3.6. This list is incomplete due to the existence of multiple encoding / decoding tables, the proliferation of new encoding / decoding tables, and / or the limitations of the encoding / decoding tables defined in Python v3.6. "Encoding / decoding" is an abbreviation for encoding / decoding and is a mapping used in computation for character sets. A character is assigned an arbitrary but unique binary value within a single encoding / decoding table; therefore, a complete set of characters defines a single encoding / decoding table. Not all characters within a given encoding / decoding table are readable or printable by humans. A common use of encoding / decoding tables is for the appropriate representation of different character sets in different languages. "Encoding" transformations can perform any of these encoding / decoding operations on a given data string. Encoding / decoding tables with names beginning with "utf_" specify operations conforming to the Unicode Transformation Format (UTF), which is the organization principle for many Internet-based international character sets.

[0202] Figure 12This is a table listing the transformations discussed so far and their detailed descriptions. Additional transformations can be defined within the TOP architecture, as illustrated by the last six transformations in the table: key transformation, cleanup transformation, TAR group transformation, information collection, locking transformation, and mobius transformation. Some of these additional transformations may be specific to the Structured Data Folding (SDFT) library that utilizes transformations, some may be language-specific, and / or some may be operations related to NUTS. This demonstrates TOP's flexible nature by allowing the definition and categorization of new transformation types to expand its instruction list. This flexible expansion feature is designed to allow the SDFT library to adapt to new transformation operations in the future. The expansion feature also allows for the retrospective addition of older versions of transformation operations for backward compatibility. One benefit of this flexibility is that SDFT can achieve better time compatibility in processing data. Time compatibility of data can be defined as the ability to make stored data easily processed by the same or different applications at a future point in time. Time incompatibility may be caused by, but is not limited to, differences in application file format versions, different character encodings, expired application file formats, differences in data operation methods, differences in data operation sequence, and / or changes in specific data operation parameters.

[0203] Figure 13 This presents a transformation reversibility matrix. Transformations can be designated as reversible, irreversible, and / or conditionally reversible. The criteria used to make such designations can be based on the ideal intent of the transformation rather than its actual implementation and / or theoretical shortcomings. In other cases, the designation can be arbitrary. This can be illustrated by a digest operation called MD4, which produces a 128-bit hash of the source data. Compared to hash operations such as 512-bit SHA2, MD4 hashing can be considered a very weak hashing algorithm due to its sensitivity to collisions (which can be an undesirable characteristic in hashing algorithms). A TOP perspective can identify one of the original intents of MD4 as an irreversible unique hash and classify the hash in this way. This classification does not exclude this type of transformation, as will be shown in a later section, from well-defined engineering reversibility properties obtained through further TOP analysis. Compacted transformations can be categorized into both reversible and irreversible designations based on the specific compaction operation performed. Many image and / or audio compression techniques exhibit irreversibility due to their sampling nature; a 12 MB digital image can be compressed to 360 KB for efficient transmission via chat, but due to the nature of human visual perception, the overall impression of the image can still be adequately conveyed despite permanent data loss. This compression is due to the fact that a large amount of original data may have been irreversibly modified and discarded during the transformation.

[0204] A reversible compression transformation can be exemplified by gzip compression; it operates on the principle of identifying and reducing repeating bit patterns within binary data while maintaining sufficient information to allow the process to be reversed and the original data fully reproduced. A conditional reversible transformation can be exemplified by AES symmetric cryptography; it operates on the principle of using plaintext and a symmetric key to generate ciphertext. The decoding process uses the key and ciphertext to generate the original plaintext. Therefore, the correct presentation of the symmetric key for the ciphertext is a necessary condition for decrypting the ciphertext or reversing the encryption process.

[0205] TOP can define the transformation mode, which indicates the direction of a given transformation operation as forward or reverse. The forward transformation mode can perform its normal process and / or its engineered forward process. The reverse transformation mode can perform its inherent reverse process and / or its engineered reverse process. Figure 14 The table in the table shows a matrix indicating the types of operations that a transformation can inherently perform based on its transformation mode. For reference, the table lists commonly known operation names such as "serialization" and "deserialization" or "encryption" and "decryption." Note the reverse engineering processes of digests and digns: "digest" and "verification," "sign" and "authentication." For "clean" transformations, which can delete various internal data associated with their transformed data structure, it may be impossible to recover the deleted data without appropriate additional data and / or rerun the forward transformation process on the original data to reproduce the deleted temporary data. "Key" transformations can perform key generation and / or management operations associated with the transformation. Accordingly, due to the inherent randomness of key generation, it may be impossible to theoretically and / or algorithmically reverse this process in a deterministic manner within a finite time. The key management aspects of "key" transformations will be discussed in detail in a later section when we address how to make transformations work within the context of Structured Data Folding (SDF); the key management aspects of key transformations are difficult to design reversible copies due to the characteristic of setting appropriate key structures to achieve successful processing in the SDF context.

[0206] Figure 15A series of three diagrams are presented, each further detailing a serialization transformation 1504 instance, which can be specified as a reversible transformation. In computer programming, serialization and / or aggregation techniques can take internal data structures specific to complex languages ​​and can systematically deconstruct and / or organize their contents in a linear manner to produce equivalent data strings or groups of data strings (hereafter referred to as data strings). Data string form is more suitable for persistent storage, data transfer, and / or further transformation. Serialization as defined may require it to be logically fully reversible to reconstruct the original content in the original language or its equivalent. JSON operations 1514 can be used to transform a Python structure 1512 to produce an equivalent JSON string 1516, and the reverse process is feasible, as shown by the bidirectional process flow arrows. A simple tree data structure is shown in 1522, which can exemplify complex Python data structures. This serialization transformation 1524 can produce an equivalent string 1526 from 1522. This output string 1526 can now be stored, transferred, and / or transformed as a program process.

[0207] Figure 16 The diagram illustrates a series of three figures, each further detailing an instance of hash transformation 1606, which can be assigned an irreversible transformation. This instance demonstrates the SHA2 hash operation as hash transformation 1616, which requires data 1612 as input and hash length 1614 as attribute 1604. SHA2 hash hash transformation 1616 produces a hash 1618 of a specified length. Python data string 1622 and a desired hash length of 256 bits 1624 can be used as input to SHA2 hash transformation 1626 to produce a 256-bit hash string 1628.

[0208] Figure 17This section demonstrates a detailed example of a summary transformation (also known as a check) in the reverse mode. In TOP, this can be referred to as the engineering reverse of a transformation. Summary transformation 1710 accepts data D1 1702 and attribute A1 1704 as input to perform a forward mode summary transformation 1710, which produces a summary string DG1 1712 as output 1708. The reverse mode 1720 of this transformation accepts data D1 1722, attribute A1 1724, and summary string DG1 1728 as input 1736 to perform a reverse mode summary transformation 1720, which produces a flag and / or value indicating whether the summary string DG1 1728 has been checked 1732 or failed 1734 as output 1738. The check process 1740 produces a summary string DG2 1722 by performing a forward mode summary transformation 1720 on inputs D1 1722 and A1 1724. The output digest string DG2 1722 can then be compared with the input digest string DG1 1728 for equality 1730. The comparison result 1738 can be presented in some form to show whether the reverse digest transformation was successful. In this way, the reverse engineering of this digest may require reprocessing the forward pattern of the transformation and comparing the output, rather than relying on any workaround to find the logical reversibility of this operation (which may be difficult, time-consuming, and / or hard to achieve).

[0209] Figure 18 , Figure 19 and Figure 20 This section presents detailed examples of scipher transitions (also known as symmetric cryptography) in forward and reverse modes. In forward mode 1806, the scipher transition accepts plaintext 1802 and attribute 1804 as input to produce ciphertext 1810 and / or attribute 1812 as output. In reverse mode 1826, the scipher transition accepts ciphertext 1830 and attribute 1832 as input to produce plaintext 1822 and / or attribute 1824 as output. Figure 19This diagram illustrates how the salsa20 symmetric cipher can operate as a scipher transition. In forward mode 1906, the scipher salsa20 transition accepts plaintext 1902 and attribute 1904 as input to produce ciphertext 1910 as output. In forward mode, the attributes of this particular cipher may include a binary symmetric key, key length, and / or salt value. This forward (encryption) implementation of salsa20 can be a streaming cipher and may not produce additional output attributes during the encryption process, except for hidden attributes that can be embedded within its own output string. In reverse mode 1926, the scipher salsa20 transition accepts ciphertext 1930 and attribute 1932 as input to produce plaintext 1922 as output. In reverse mode, the attributes of this particular cipher may include a binary symmetric key, key length, and / or salt value. This reverse implementation of salsa20 (decryption) can be a streaming cipher and may not produce additional output attributes during the decryption process. Figure 20 This illustrates how the salsa20 symmetric cipher can be manipulated as a transformation of sample data, as can be represented within Python v3.6 and the PyCryptodome library functions. In forward mode 2006, the scipher salsa20 transformation accepts a data string 2002 and an attribute 2004 including a 256-bit symmetric secret key and a random number (such as salt) as input to produce ciphertext 2010 as output. In Python, the symmetric key can be represented as a string of "byte" data type, and therefore the key length attribute can be easily derived using the len() function on the key byte string. In reverse mode 2026, the scipher salsa20 transformation accepts ciphertext 2030 and an attribute 2032 including a 256-bit symmetric secret key and a random number as input to produce plaintext 2022 as output. In Python, the symmetric key can be represented as a string of "byte" data type, and therefore the key length attribute can be easily derived using the len() function on the key byte string. Attribute 2032 may need to be equivalent to attribute 2004 so that this conditional reversible transformation can properly process ciphertext 2030 in reverse mode (decryption) to recover the original plaintext 2002.

[0210] Transformation type The table below and Figures 21 to 35The examples presented here are not limited to the operations specified in this table; any suitable operation can be analyzed using TOP and then integrated into the architecture to extend the operational capabilities of a particular transformation. Python v3.6 syntax and constructs can be used to illustrate the examples in more detail. Those skilled in the art can find and substitute equivalent data types, structures, syntax, and / or methods in different programming languages. In some cases, key / value options may not be language- or library-specific and may be ignored or modified as needed, as long as the processing produces equivalent results.

[0211] Serialization / Compression Conversion Figure 21 Table 2102 shows the command specifications for serialization and compression transformations, and a set of sample transformation commands 2104 demonstrating their uses. Table 2102 lists the transformation names and the acceptable operation types for each transformation. Any column header with a trailing "=" indicates that the value presented below it can be presented in key / value format in the command syntax construct. The "Input" and "Output" columns specify the expected data type / structure for the transformation / operation in the Python v3.6 context. For example, the command "serialize jsonsortkeys=t" performs the following sequence of data manipulations: taking any Python data structure as input; executing json.dumps() on it, where the "sort_keys" flag is set to true; and then outputting a Python string with a serialized version of the data. The reverse mode of this command expects a JSON-formatted Python string as input, executing json.loads() on it, and then outputting a Python data structure. The "sort_keys" flag instructs the json.dumps() function to process the keys of any Python dictionary in ascending order. When processing keys, Python v3.6 may not guarantee a consistent processing order for dictionary structures. Therefore, the JSON strings obtained from multiple runs of this transformation on the same data structure may be inconsistent. Sorting the keys in a specific order within the serialization transformation can provide consistency in the process sequence, resulting in the same JSON string being the output of multiple runs on the same data structure. This can become crucial for determining whether two JSON strings are equivalent and thus represent two equivalent pre-serialized data structures.

[0212] The compression transformations in Table 2102 illustrate several different lossless or reversible compression operations. Any irreversible or lossy compression operation could expand this table of compression transformation instructions, but for the purpose of discussing reversible transformations, it would be neither interesting nor constructive to discuss one-way functions that might not provide cryptographic uses beyond data size reduction. From a top-down perspective, lossy compression can be analyzed and handled in the same way as digest transformations, as discussed in a later section. In the example in 2104, the command "compress bz2" performs bz2 compression on a binary string input and produces a binary string output, which may or may not be smaller than the input string. Some data can no longer be compressed using a particular compression scheme; one example of this could be reprocessing a bz2-compressed string without achieving further data size reduction.

[0213] Encoding Transformation Figure 22 A command specification table 2202 for encoding transformation is presented, along with a set of sample transformation commands 2204 demonstrating its use. Several encoding schemes may exist in computer science, and the references in this table do not represent all known encoding schemes. The encoding schemes listed below the “Encoding=" column can be found in Python v3.6 and its associated standard library. Those skilled in the art will recognize the utility of access to all such types of encodings for solving problems related to applications that can manipulate data. “Codecs (98)” refers to those used at the time of writing and previously in… Figure 11 The table below lists the encodings and decoders supported in Python v3.6. The transformation command "encode strbin utf_8" takes a Python string as input, performs utf_8 Unicode encoding on it, and outputs a Python byte string. The transformation command "encode utf utf_16" takes a Python string as input, performs utf_16 Unicode encoding on it, and outputs a Python string. The transformation command "encode binascii hex" takes a Python byte string as input, performs hexadecimal encoding on it, and outputs a Python string. The transformation command "encode base 64" takes a Python byte string as input, performs base64 binary encoding on it, and outputs a Python string. The transformation command "encode utf_8" is equivalent to "encode utf utf_8". These descriptions illustrate the consistency and permutation types allowed in the encoding transformation command syntax.

[0214] Abstract Transformation Figure 23Table 2302 shows a command specification for digest transformation and a set of sample transformation commands 2304 demonstrating their uses. As shown in Table 2302, the digest transformations are limited to three operation types, but not limited to: hashing, HMAC, and / or CMAC. The transformation command “digest hash md5 128” takes a source data string as input, performs an MD5 hash function on it, and produces a 128-bit output digest byte string. It should be noted that the input source data string is not modified or overwritten during the digest transformation call; the output digest byte string can be additional data generated from the digest transformation call and can be provided with separate memory space. The transformation command “digest hash sha2 512” takes a source data string as input, performs a SHA2 hash function on it, and produces a 512-bit output digest byte string. The transformation command “digest hash shake 256 digestlen=332” takes a source data string as input, performs a SHAKE256 hash function on it, and produces a 332-bit output digest byte string. The transformation command "digest hmac sha2 256" takes a source data string as input, performs an HMAC function on it using SHA2 hashing, and produces a 256-bit output digest byte string. The transformation command "digest cmac aes 256" takes a source data string and a 256-bit symmetric key as input, performs a CMAC function on it using AES256 cryptography, and produces a 128-bit output digest byte string. All these digest transformation examples and types can be found in standard Python libraries and / or the PyCryptodome library and do not represent all the various operations, types, digest lengths, key lengths, and / or other parameters that exist theoretically and / or practically outside these sample libraries. Any additional variations can be appropriately analyzed using TOP and integrated into a transformation form. Such integration of any transformation form may require the reconstruction and retesting of existing transformation operations.

[0215] Acipher / Dign Transformation Figure 24This document presents command specification tables 2402, 2404, and 2406 for acipher and digne transformations, along with a set of sample transformation commands 2410 demonstrating their usage. The transformation command “acipher pkcs1_oaep 2048” takes a byte string and a 2048-bit RSA asymmetric public key as input, performs an RSA PKCS#1 OAEP cryptographic operation on it using a 512-bit SHA2 hash, and outputs a 2048-bit encrypted byte string. The transformation command “acipher pkcs1_v1_5 3072” takes a byte string and a 3072-bit RSA asymmetric public key as input, performs an RSA PKCS#1 v1.5 cryptographic operation on it, and outputs a 3072-bit encrypted byte string. The reverse modes of these acipher transformations may require combining the ciphertext in byte string form with the private portion of the appropriate RSA key to produce the original plaintext.

[0216] The transformation command “dign pkcs1_v1_5 2048” takes a byte source string and a 2048-bit long RSA asymmetric private key as input, performs an RSA PKCS#1 v1.5 digital signature operation on it using a 512-bit SHA2 hash, and produces a 2048-bit long digest byte string as output. Note that the terms “digest byte string” and “digital signature byte string” can be used interchangeably, as TOP can consider these outputs as providing similar functionality and therefore storing such byte strings referred to by the variable name “digest”. The transformation command “dign dss 1024 hashtyp=sha2” takes a byte source string and a 1024-bit long DSA asymmetric private key as input, performs a DSS digital signature operation on it using a 512-bit SHA2 hash in FIPS-186-3 mode, and produces a 1024-bit long digest byte string as output. The transformation command "dign dss 256" takes a source byte string and a 256-bit long ECC asymmetric private key as input. In FIPS-186-3 mode, it performs a DSS digital signature operation using a 512-bit SHA2 hash, producing a 256-bit digest byte string as output. The reverse mode of these dign transformations may require the digest byte string (digital signature), the source byte string, and the public portion of an appropriate asymmetric key as input for authentication.

[0217] Derivative transformation Figure 25The document presents command specification tables 2502, 2504, and 2506 for derivation transformations, and a set of sample transformation commands 2510 demonstrating their uses. The sample operations pbkdf2, hkdf, and scrypt can also be referred to as key derivation functions and / or key expansion functions. The basic function of derivation transformations is to derive a symmetric key or several keys of a desired length from a user-known binary or character data string; a common use of key derivation functions is to derive one (or several) appropriately formed symmetric cryptographic keys from a passcode or passphrase. The transformation command “derive pbkdf2 keylen=256 iterations=100000” takes a character data string (passcode or passphrase) as input, performs a PBKDF2 operation on it using a SHA2 512-bit hash function, a randomly generated 512-bit initialization vector as salt, and an iteration count parameter set to 100,000, and produces a corresponding symmetric key, which is a 256-bit long byte data string. The transformation command "derive hkdf keylen=256numkeys=4" takes a byte data string as input, performs an HKDF operation on it using a SHA2 512-bit hash function and a randomly generated 512-bit initialization vector as salt, and generates a set of four corresponding symmetric keys, each a 256-bit byte data string. The transformation command "derive scrypt keylen=128 mode=login" takes a data string as input, performs a login mode SCRYPT operation on it using a randomly generated 512-bit initialization vector as salt, and generates a corresponding symmetric key, which can be a 256-bit byte data string. The login mode for the derived scrypt transformation can be set by setting the three parameters n, r, and p to abbreviations of the values ​​indicated in Table 2506. These parameter values ​​are suggested by the authors of the SCRYPT algorithm.

[0218] The TOP method for derived transformations can suggest dual-mode operation. Data Mode: If the transformation is not coupled with a key stack (discussed in detail in a later section) and is only coupled with a data source string of a certain type, then it can transform this input data source string and replace it with a transformation output that can be presented as one (or more) symmetric keys. Key Mode: If the transformation can be coupled with a key stack and a data source of a certain type, then it can transform and replace the corresponding key source material existing in the key stack, thereby deriving one (or more) cryptographically usable symmetric keys and placing them in the key stack. These terms can be further clarified in a later section when discussing key stacks and key management within the context of transformation audit logs or TARs and dependent transformations.

[0219] Scipher Transformation In the context of TOP, symmetric cryptographic operations can be categorized as scipher transformations, and as a group, these transformations can exhibit a set of associated properties, which can be extensive in number and / or variety. The following three figures illustrate how TOP can systematically normalize and encapsulate individual scipher transformations possessing all their properties into a common output string. This type of property embedding technique can be found in various functions and libraries used for many operation types. However, there may be very few widely accepted standards for such embedding techniques. TOP can propose a consistent approach that can be applied to all scipher transformations for disparate purposes, such as supporting features known as structured data folding or SDFT that utilizes transformations. Whether this approach can become a widely used standard may be beyond the scope of this document, but the reader can appreciate the potential benefits of its use within the TOP architecture, especially as we discuss TAR and SDFT constructions and methods later.

[0220] Figure 26 Table 2602 shows a command specification for scipher transformations and a set of sample transformation commands 2604 demonstrating their uses. The table shows three types of scipher operations: aes, chacha20, and salsa20. This is not a complete list of known symmetric ciphers, but it presents various relevant symmetric ciphers to illustrate how TOP can organize them and propose their uses. Symmetric ciphers may have more or less the following associated attributes: key length (keylen), mode of operation (mode), salt type (salttyp), salt length (saltlen), block size (Block), type of cipher operation (type), and / or padding (pad). Key length specifies the length of the secret symmetric key that can be used in the cipher to generate ciphertext from plaintext. For AES ciphers, there may be at least ten different modes of operation, as shown in the table. Most symmetric ciphers may require a salt (random value) input of a specific type (iv or nonce) and a specific salt length (whose use can promote better semantic security). Symmetric ciphers can provide at least three different types of operations: block, stream, and / or AEAD ciphers. Newer patterns can be proposed, and they can be integrated into another variant using TOP. Block pattern cryptography can make additional attributes, including padding method, padding location, padding type, and / or padding length, necessary.

[0221] In some instances of 2604, the transformation command "scipher aes 256 mode=ofb" can take a byte data string and a 256-bit symmetric key as input, encrypt the input data string using an AES-256 OFB mode stream cipher with the presented key and a randomly generated 128-bit initialization vector, and produce an output string, which can be embedded in the process as shown in... Figure 27The output byte string, formatted in the consistent key / value format specified in the standard, consists of the ciphertext in the header and all associated attributes (discussed in a later section). The transformation command "scipher aes 128 mode=gcm" takes a byte data string and a 128-bit symmetric key as input, encrypts the input string using an AES-256 GCM mode AEAD stream cipher with the presented key and a 128-bit nonce, and produces an output byte string, which can be embedded as described in the process. Figure 27 The output string, formatted in a consistent key / value format as specified in the code, consists of the ciphertext in the header and all associated attributes. AEAD is an acronym for authenticated encryption with associated data and can be a normalized or well-known method for embedding an authentication function along with the encryption capabilities of a symmetric cipher within a single function call. The transformation command "scipher chacha20256" takes a byte data string and a 256-bit symmetric key as input, encrypts the input string using a CHACHA20 stream cipher with the presented key and a 64-bit nonce, and produces an output string, which can be embedded as required during the process, such as in... Figure 27 The output string, formatted in the consistent key / value format specified in the standard, consists of the ciphertext in the header and all associated attributes. The transformation command "scipher salsa20 128" takes a byte data string and a 128-bit symmetric key as input, encrypts the input string using a SALSA20 stream cipher with the presented key and a 64-bit nonce, and produces an output string, which can be composed of embeddings involved in the process, such as in... Figure 27 The output byte string, formatted according to the consistent key / value format specified in the standard, consists of the ciphertext in the header and all associated attributes.

[0222] Figure 27This section illustrates the output structure format of the scipher output string in a two-step sequence, with step 1 illustrating the input format and step 2 illustrating the output format. The "header" is a variable-length UTF-8 encoded parameter string representing the key value of the scipher transformation of the output message. In step 1, the scipher accepts a variable-length message byte string, "Message," as input, with optional padding of a certain length typically placed at the end of the message as needed. The message may have a pre-considered salt value, as recommended by the selected cipher. Padding may be a requirement of block-mode symmetric ciphers. If the programmer has not specified a particular padding method, a default padding method may be used and appended to the end of the message. This message and padding can be referred to as plaintext. The selected cipher now processes the input plaintext and produces and outputs items called encrypted messages, as shown in step 2. The selected scipher transformation now transforms the embedded header into printable key / value pairs in character string format, where the key represents the parameter type and the value represents its respective setting. Details of the key / value pairs will be discussed in the next section. Once a header string is generated, the transformation can calculate the length of this header string, called the header size, which can be formatted as a two-byte unsigned big-endian integer. The two bytes can have values ​​from 0 to 2. 16The value range (65,536) is sufficient to describe all the properties of any predictable symmetric cipher in this specific format. Next, step 2 can continue to generate a packet message including the header size, header, and encrypted message. This packet message can be the actual output string from the scipher transformation, and therefore can be considered successfully encapsulated and embedding all the properties associated with the transformed data. The data stream of the reverse scipher transformation follows this procedure in reverse: the transformation command specifies the exact scipher transformation to perform a matching symmetric key, and the packet message can be provided as input. The scipher transformation then unpacks the packet message, reads and stores all the properties found in the header, and then prepares to decrypt the encrypted message. Symmetric ciphers may not have a deterministic method to convey successful decryption. Verification methods can be used in the above manner to determine such results. An example of a basic method could be to extract a pre-considered salt value from the encrypted message and compare it with the stored salt value from the header. A matching salt value indicates successful decryption but does not guarantee successful decryption. AEAD mode symmetric cryptography addresses this problem to a better extent by embedding the MAC (CMAC, HASH, or HMAC) of the data string into the encrypted message (before or after encryption) and performing a comparison. More complex methods may require using different keys to authenticate the hash of a digital signature of a message. As will be shown in a later section, the use of SDFT and TAR allows for this complexity in a procedurally simple and logical manner. Of all these hash-based methods, determinism cannot fully describe the conditions of a decryption attempt, due to inherent weaknesses in hash schemes that universally and uniquely identify data. A deterministic approach could be to compare the encrypted message with the original message for equality, but this may involve efficiency trade-offs due to verbose messages.

[0223] Figure 28 This table displays the parameter keywords and specifications for the header string in the output structure format of a scipher transformation. The keywords selected for this attribute table are sufficient for self-description and / or self-explanation by those skilled in the art. Examples of attribute values ​​are shown in the right-hand pane. The first listed attribute header size can be a unique attribute that can be represented as a 16-bit binary unsigned high-order integer value and can be the first field in the header. This header size can indicate the number of bytes, followed by a description of the attributes of this particular scipher transformation in a printable format. The attribute format can be selected to be printable to allow for variability in the range and length of attribute values. All attribute values ​​that naturally exist as binary strings including the salt value (salt_val) and the MAC string (mac_val) in the running program can be encoded as base64 to meet printable character preferences.

[0224] In this way, the output string of a scipher transformation can include one or more wrapper layers of attributes, depending on the details of the selected scipher. Figure 29 This diagram illustrates the iterative embedded message encapsulation of the AEAD mode scipher transition. The AEAD mode AES cipher can output the following layers from inner to outer. Message preparation layer 2910 may include a plaintext message 2914, which is encrypted with an appropriate salt value 2912. This prepared message 2910 can be encrypted using a selected AEAD cipher, which can then generate an additional MAC value and additional data 2922 as part of the cipher process, and this combined message can be referred to as the AEAD cipher output 2920. This AEAD cipher output 2920 can also be referred to as the encrypted message 2934. The encrypted message 2934 may have associated attributes from the scipher process, which can use attributes from... Figure 28 The keyword / value header method is parameterized to produce header 2932, and this combination can be referred to as scipher packet message 2930. This scipher packet message 2930 can be the output of the selected scipher transition, which can be stored in an obj pointer or variable 2944 of an NSstr structure 2940 that can be associated with a TAR called the scipher transition. The NSstr structure will be discussed more fully in a later section. Other attributes 2942 can also be stored in this data storage unit called the NSstr structure, including the TAR, key stack, digest, and / or status flags. The obj pointer or variable 2944 in the NSstr structure 2940 can be the starting point of the plaintext message 2914, so an iterative path 2950 can be feasible and can exist for object 2944, as it can handle as many nested encapsulations as required by the TAR, and it can itself be stored in attribute 2942 of the NSstr structure 2940.

[0225] In header 2932 of scipher packet message 2930, it can be found that... Figure 28 The keywords listed provide a complete and precise description of the symmetric cryptography, its patterns, and the parameters of the attribute values ​​used. In this respect, the TOP method relies solely on the theoretical and implementation security of the cryptography used for the transformation, without relying on non-cryptographic compilation processes or obfuscation and concealment of procedures used to fix the data. This may not seem significant at first glance, but its simplicity, which can later demonstrate the associated details of data transformation embedded in the output of the transformation itself, ultimately leads to novel methods and designs that rely more on self-describing data than on hard-wired procedures that process it. This approach can help develop one of the fundamental sources in data center design and data center modeling for some of the lowest-level operations of data storage science. NUTS can rely heavily on data center design and modeling, as will be shown in a later section.

[0226] Figure 30 This document presents a command specification table 3002 for locking transitions and a set of sample transition commands 3010 demonstrating their usage. Locking transitions are... Figure 12 The table lists another transformation, which may be an embodiment of a variable lock from NUTS, as will be... Figures 65 to 77The details are described below. Variable locks can present several different methods for cryptographically locking secret messages, including sslock, orlock, matlock, xorlock, and hashlock. A characteristic of variable locks is that they allow the input and use of several cryptographically compiled keys during the encryption of secret messages in a normalized, systematic, and ordered manner. The TOP method allows for a compact approach to implementing this locking technique in a simple and convenient way. In some 3010 instances, the transformation command “lockorlock 128 numkeys=10 scipherkeylen= 128” can take a byte data string and up to ten identical 128-bit symmetric keys as input, encrypt the input string using the transformation command “scipher aes 128 mode=eax”, and produce an output string that includes the ciphertext and associated embedded attributes. The transformation command “lock matlock 256 numkeys=5” can take a byte data string and five 256-bit symmetric keys as input, and uses the transformation command “scipher aes 256 mode=eax” to iteratively encrypt the input string for each key, producing an output string including ciphertext and associated embedding attributes. The transformation command “lock sslock 256 numkeys=4 threshold=2” can take a byte data string and at least two 256-bit tines256 secret shared keys as input, and uses an implementation of the Shamir secret sharing method with the provided secret sharing to encrypt the input string, producing an output string including ciphertext and associated embedding attributes. The transformation command “locksslock_b 256 numkeys=6 threshold=3” can take a byte data string and at least three 256-bit tinesidx128 secret shared keys as input, and uses an implementation of the Shamir secret sharing method with the provided secret sharing to encrypt the input string, producing an output string including ciphertext and associated embedding attributes. The transformation command "lock xorlock 128 numkeys=6" takes a byte data string and six 128-bit symmetric keys as input. It derives a computed key by iteratively performing XOR operations on the supplied keys. The "scipher aes 128 mode=eax" transformation command is used to encrypt the input string, producing an output string including ciphertext and associated embedding attributes. The transformation command "lock hashlock 192 numkeys=7" takes a byte data string and seven 192-bit symmetric keys as input. It derives a computed key by performing a hash operation on an ordered concatenation of the supplied keys. The "scipher aes 192 mode=eax" transformation command is used to encrypt the input string, producing an output string including ciphertext and associated embedding attributes.

[0227] Descriptions and operating modes of each variable lock type can be found at the beginning of Figure 60 The subsequent section on the variable lock reveals that TOP analysis and methods allow for the implementation of complex iterative lock variations potentially utilizing multiple cryptographic keys in a concise logical manner and allow for easy extension to different types of future lock algorithms. Furthermore, the key management of SDFT, as demonstrated later, allows programmers to generate and manage these multiple cryptographic keys relatively easily and conveniently.

[0228] As in Figure 12 , Figure 13 and Figure 14 The TOP analysis and methods presented here allow those skilled in the art to perform a given data manipulation function and determine its applicability to normalization into transformation operations and types. Figure 12 The tables in the table provide samples of well-known data manipulations and are generally considered sufficient for most developers. However, in cases where data manipulation functions cannot be found in this table, features can be analyzed and customized to operate within the SDFT architecture using the TOP method; features include, but are not limited to, lossy compression, bit scattering, message scattering, ECC (Eraser Code), and message-level RAID encoding and structuring. In most cases of these transformation extensions, it is not necessary to recode or rewrite the actual data manipulation functions. In fact, in most cases, doing so may be counterproductive and detrimental to the program. Libraries containing data manipulation functions are accessible through the transformation library, and the TOP method allows developers to provide regularized wrapper functions around specific data manipulation functions to perform well within the SDFT architecture.

[0229] Transform the structure, transform the audit record (TAR), and use the transformed structured data folding (SDFT). Figure 31The specifications of various transformation structures are presented in tabular form. Structure constraints rely on a nested key-based approach, similar to how structures are constrained in JavaScript; this can be a deliberate design choice, allowing its representation to be easily replicated across multiple programming languages ​​without relying on language-specific uniqueness. For example, Python v3.6 allows categorization, while some languages ​​such as JavaScript may not, thus enabling transformation data structures to be more widely applicable without relying on categorization. Transformation structures provide well-defined working memory areas for preparing, processing, and / or storing transformation inputs and outputs. The primary data storage unit or structure used in most, but not all, transformation operations is called the NSstr structure 3108. At least one instance of an NSstr may exist associated with a transformation call. All transformation structures may have a "typ" or structure type field specifying what structure it represents. NSstr structures may further constrain a "state" field specifying the state of the structure and / or its data. The "obj" or object field may hold a single value or may be a pointer to another memory area. The obj field may be the location where most of the transformation's input data can be found. Furthermore, the `obj` field can be the location where most of the output data of the transformation can be found. The `digest` field (if present) can store a digest of the data stored or referenced by the `obj` field. The digest may have been generated in a manner that depends on the specific transformation or digest transformation and the parameters and / or attributes supplied to the transformation command. The `key stack` (if present) can be a single instance of a KISS (Key Exchange Specification Structure, discussed in a later section) structure or a list of KISS structures in a predetermined order corresponding to their operation TAR. The key stack essentially holds various types of keys required for certain transformations. The `tar` field can point to an instance of an NStar structure 3106.

[0230] The NStar structure 3106 can specify a specific Transformation Audit Record (TAR) that can be applied to input data stored in the obj field of the NSstr structure. The TAR can be a logically ordered set of transformation commands, which may have been expertly ordered to process the data in the NSstr in an ordered and well-behaved manner to produce a single "fold" of the NSstr data. We can refer to this process of performing a TAR on the NSstr data structure as a "assemble" function call. Conversely, a "disassemble" function call can rely on the inherent properties of reversible transformations to "unfold" the folded data pieces within the NSstr structure using the same TAR. Therefore, the reversibility of transformations can be achieved by utilizing the central features in the structured data fold (SDFT) of transformations. The SDFT method can use TARs on the NSstr structure to iteratively transform objects as if they were within an assembly line operation on the data. Since the reversible behavior of each transformation command in the TAR can be analyzed, any TAR can be invoked in either the reverse mode or the disassemble function call. This topic can be discussed in more detail, as additional necessary components that make such operations possible will be presented in the following sections.

[0231] The NSbin structure 3102 can be used for specific functions that may or may not be relevant to Python v3.6. In Python v3.6, distinctions can be made based on how data strings are stored internally. They can be stored as "byte" strings or character strings. A byte string data type indicates that the information held in a variable is a series of binary bytes. A character string indicates that the information held in a variable is a series of bits representing a character encoded in a particular encoding scheme. Python v3.6 employs complex internal management schemes to optimally determine how to store specific character strings because different encodings may require different storage requirements for each "character". For example, UTF-8 may use 8-bit long encoding units to represent each character, while UTF-16 may use 16-bit long encoding units; such variations may be necessary for transmitting different international character sets, where the number of characters in a language may differ significantly from the English alphabet and therefore may not fit into an arrangement of 8 data bits. A better internal serialization method for Transform, TAR, and SDFT is JSON, which may not have native support for mapping Python "byte" data types to themselves. JSON function calls may fail abruptly if a conversion is attempted, with some indication that specific data types may not be supported. The NSbin structure is specifically designed for this situation and can replace any "byte" data string, thus making Python variables compatible with JSON. "Byte" strings can be encoded as base64 character strings and stored in the "b64" field of the NSbin structure. Byte string variables can now point to this NSbin structure, overwriting the original byte data. These can represent equivalent data, but they can be in different encodings and structures. However, the end result is that the NSbin structure is fully compatible with JSON, and JSON functions can now be used to safely serialize data without errors attributed to incompatible data types.

[0232] In the TOP method, the "byte" data used for NSbin structure conversion and replacement can be referred to as coming from Figure 12 and Figure 33 The "info collection" transformation. In Python v3.6, the info collection transformations listed in Table 3302 can take any valid Python structure or variable and iteratively transform each byte string into an equivalent NSbin structure, which can result in a Python structure missing any byte data type. Those skilled in the art can customize an appropriate info collection transformation for languages ​​other than Python v3.6 and their JSON function calls to remove this source of data serialization errors. The reverse pattern of "info collection" can be called "depress" and can iteratively undo transformations and replacements, making it possible to recover the data structure containing its original data type.

[0233] The NSjson structure 3104 is a particularly useful feature for retaining only data that is fully compatible with JSON. A quick look at the fields qualified for NSstr 3108 can alert us to potential problems with directly submitting the structure for JSON serialization, attributable to the digest field that potentially retains the digest value as a binary string or a byte data string from Python v3.6. We refer back to Figure 12 Furthermore, the "mobius" transformation is introduced to address this specific problem. It should be noted that prior to this point in the description, any reasonable definition of the mobius transformation might not be fully clear to the reader due to the intertwined nature of transformations and the TOP method. Figure 32 The mobius transformation in SDFT can transform a given structure from one form to another in a circular manner, but with slight distortions, like in a mobius band. Mobius transformations are a key implementer of structured data folding by systematically converting NSstr structures into JSON-serializable structures such as NSjson; the transformation process can be embedded in the TAR operations used on the NSstr as a whole, along with the transformed data, giving the resulting storable object a self-describing characteristic. Mobius transformations can be a convenient example of performing structured data folding within the SDFT library. Developers can choose to manually perform SDF using logical combinations of transformation commands other than the mobius command, but the mobius command adds at least one additional logical step that may require the developer to perform outside the SDFT library: the ability to serialize the NSstr data structure it is operating on into another structure, "such as NSjson". The mobius transformation can be the last transformation in the TAR. Due to its function, this may be the only logical place where a mobius transformation can be placed. When processing a mobius transformation, it can take the NSstr structure it is operating on and transform it into an NSjson structure. A TAR embedded in an NSstr structure may no longer exist in a useful or accessible form; therefore, a mobius transformation can be the final transformation command for a given TAR to be processed. Simply put, a mobius transformation can collect information from an NSstr structure, JSON serialize it, and then store it in an NSjson structure. The NSjson structure can be stored, transmitted, JSON serialized, collapsed, or subjected to any other valid data operations. A reverse pattern of a mobius transformation may exist, but viewing this transformation in another way can be described as a circular transformation: whether in a forward or reverse pattern, it performs a specific data transformation depending on the type of the input data structure. Table 3204 indicates NSx structures, whose NSjson can be a variable. If in the future, for any other than... Figure 31As the demand for transformation structures beyond those defined in the SDFT library increases and they may need to be accommodated in the mobius transformation, this table illustrates how the mobius transformation can behave for any transformation structure other than NSstr. This may not be entirely obvious without practical SDFT programming, but the mobius transformation logically implies that there cannot be TAR processing from a recovered NSjson structure unless the mobius transformation can be manipulated to convert it back to its original NSstr structure, which retains the TAR that can be collapsed. To initialize this mobius spin loop using the NSjson structure, a backflush start mobius (reverse) can be performed using the mobius function call from the SDFT library to produce the NSstr structure, access the embedded TAR, and reverse process the embedded TAR. This further implies that the mobius transformation command in the TAR (which, by definition, will be the first command to be processed in reverse mode) can be safely ignored during processing, as it may have already been executed via the backflush start function call, thus allowing the mobius function to be executed no more than once during this reverse process. In this sequence, it is impossible to ignore the potential for infinite oscillations in mobius calls that can occur in reverse mode, where NSstr is repeatedly converted to NSjson and vice versa. While this may seem like a roundabout way of expressing such operations, it produces a fairly compact bidirectional TAR, which can be systematically embedded in the output transformed data, thus giving the folded data a self-describing property. This property is novel because it can operate on data in a consistently reproducible manner, as if interpreted scripts but in either forward or reverse mode, across implementations that support SDFT libraries.

[0234] Figure 33The command specification tables 3302 and 3304 for information collection transitions, clear transitions, and key transitions are shown, along with a set of sample transition commands 3310 demonstrating their uses. A clear transition can be a service function that deletes temporary or transient fields from an NSstr structure. Some transitions may have a need for additional transient fields during processing and may create additional fields within the NSstr structure for storing and accessing them. The creation and use of such transient fields within the NSstr can be done in a deliberate manner after analyzing their coexistence within the TOP method and minimizing their interference with the proper operation of any other transition. A clear transition may not exist in a reverse mode due to its functionality, and therefore it can be safely ignored. This reverse implication can be considered when proposing a new transient field within the NSstr structure, which may not exist in the reverse mode processing of the transition, so the transition in the reverse mode can operate properly without its presence. An important function of a clear transition may be to delete an internal copy of the complete key stack used in the TAR processing; or it may delete only the keys within the key stack and convert the KISS structure into a keyhole. This could be one of the most critical shifts in SDFT TAR processing, because failure to properly clean the NSstr before it is prepared for storage could result in the storage of any and all cryptographic keys that could be used in a particular TAR process, and these keys could be unintentionally stored in plaintext and folded data. This situation could reveal the secret key and break some or all of the encrypted data within the folded data; this may not be the intended purpose of the encrypted data.

[0235] Table 3304 illustrates some operations using key transformations. This transformation can be part of the SDFT's key management functionality and primarily operates on the key stack fields by referring to the `tar` field of the `NSstr` structure. The key check transformation tests the stored TAR and generates a list of key templates. If a key stack is input, it can be compared to these key templates to determine if the correct key type, in the appropriate sequence, has been provided in the input key stack. For example, if a TAR requires two different 256-bit symmetric keys for two key transformations that may require keys, it can generate two key templates labeled "symmetric 256" in a list, indicating that the TAR expects the key stack to contain these keys (if they exist). Table 3504 lists some of the various key types. An empty key stack or a partially filled input key stack can also be appropriately processed. When a key stack is not required (where the TAR requires some keys), it can indicate a "key generation" transformation. SDFT can participate in key generation mode, whereby a key stack can be generated and assembled based on the appropriate key type from the derived key template for submission to the NSstr structure before TAR processing of the data stored in the obj field. Partial participation in the "key generation" mode is possible when a partially populated key stack can be input. Key checking and production transformation collaboratively determine whether the partial supply keys in the key stack are of the appropriate type and in the appropriate sequence. It can then proceed to generate appropriate keys for missing keys. This procedure can be referred to as a "toothless" case of SDFT key stack management. Very few instances of TARs with key transformation commands may exist, as they can be considered so fundamental to the appropriate operation of the SDFT library on the NSstr structure utilizing the TAR that they can be implicitly performed by pre-defined parameters in each call to concatenate / disassemble operations rather than requiring the programmer to place them in every TAR. It can be demonstrated that simply having the possibility of processing TARs (which may require cryptographically compiled keys) is sufficient to result in consistent, implicit, and / or automatic implicit checks on appropriate key stack management. The TAR reverse process can process the key stack in a suitable reverse order. The complexity is increased by the uniqueness of the derived transformations in the key stack pattern, which will be discussed in a later section regarding how SDFT handles such situations as TAR blocks used for dependent transformations.

[0236] Figure 34This table displays the Key Exchange Specification Structure (KISS). This structure can have at least two operating modes: Key or Keyhole. A key's attributes can be specified by some or all fields defined in the table, and additional fields can be added to extend the structure to support other key attributes as needed. The TOP method for ciphercomprehension operations can be a viewpoint specifying a matching keyhole that defines the exact key type required for each ciphercomprehension transformation. Attributes may include (but are not limited to) an actual unique ID for the key itself, a query or hint for a passphrase or passcode, a key description, etc. If a key value can exist in the KISS structure, it can simply be called a Key. If a key value can be missing in the KISS structure, it can be called a Keyhole. This can be indicated by the value in the "ima" field. The field name can be an abbreviation for "I am a" Key / Keyhole and can be read in this way for brevity. The column titled "In" indicates the required value used to generate an empty KISS structure and insert a key into it (for the purpose of placing it in the input key stack of the NSstr structure). The column titled "Gen" indicates fields that can be automatically generated and populated during key generation transitions from within the SDFT library. Throughout the SDFT discourse involving TARs, all key references can be synonymous with a KISS structure of appropriate type. It is evident that the key stack closely corresponds to the characteristics of the TAR being processed, and the stack transition commands and the stack itself represent a specific form of necessary cryptographically compiled keys and sequences. This approach allows for iterative processing of any input data through an infinite number of transition changes, transition parameter variations, and / or continuous data folding. At this point in the TOP description, we can begin to understand the interwoven nature of the various components of SDFT and reveal a complete understanding of any particular part in a non-linear manner.

[0237] Figure 35Table 3502 illustrates the KISS operation mode, matrix 3504 illustrates the key type / field generation mapping, and key type definition 3506. Table 3506 lists several key types identified by SDFT, but is not limited to these types, as new key types can be added and integrated as needed. At least three key types may require some explanation, as these can be structured specifically for the SDFT library using well-known basic key types. The key type "symmetriclist" can be an array or list of symmetric keys and can be stored as key values ​​within a single KISS structure. This key type can support (but is not limited to) transformations such as locking and derivation. Secret-sharing lock transformations called sslock and sslock_b can respectively represent two different implementations of the Shamir secret-sharing algorithm. The lock sslock transformation can be expected to be a secret-sharing in a specific format (including internal index numbers) and a key-sharing with a 256-bit long key. This can be referred to as the "tines256" key type within the SDFT library. The lock sslock_b transformation can be expected to present a secret share (including an internal index number) and a key share with a 256-bit long key. This can be referred to as the "tinesidx256" key type in the SDFT library.

[0238] Table 3502 is a matrix illustrating which features can be applied to a KISS structure in two possible modes: key (or transition) or keyhole. In the transition (key) mode, the KISS structure is expected to store the actual cryptographic key to produce a version of the ciphertext, which may include an encrypted digest and / or dign. Therefore, its storage is usable but requires further embedding using cryptographic features to permanently store it in a fixed manner. In the keyhole mode, the KISS structure is expected to have sufficient detail to accept the appropriate cryptographic key as its value to produce a version of the ciphertext, which may include an encrypted digest, dign, and / or derived key. Therefore, its storage is mandatory and does not require further fixation by any embedding method, as it may not contain a key value as a keyhole.

[0239] Table 3504 is a matrix showing which fields can be mandatory, correlated, input by key type, and / or generated. After testing this table, it becomes apparent that the KISS structure can maintain the salt for various cryptographic compilation operations. This discussion based on the scipher embedded header may seem redundant, but the salt discussion does not necessarily present the full picture of the salt. (As in...) Figure 37As shown, the persistence of properties 3704 and 3714 associated with the transformation can be distributed across several data storage areas 3732, 3734, 3736, and 3738. The TOP method has demonstrated that a salt can be embedded in certain cryptanalysis operations along with the resulting output data, as it does not reveal additional information about the generated ciphertext. However, when testing key derivation transformations processed in a key stack mode, we find that storing the associated salt value in a KISS structure is convenient and logical. A typical approach using key derivation functions is to accept a passphrase as input, combine it with a salt value, and produce a suitably shaped cryptanalysis key, such as (but not limited to) a symmetric key. In this case, the use of the salt can be for semantic security. Therefore, it is entirely possible that each keyhole accepting the same passphrase can have a different salt so that the resulting private cryptanalysis keys can be different from each other, regardless of any plausible reason. This derived key can be used temporarily and discarded after use, leaving only the keyhole as evidence of its existence. Since the products derived from the key cannot typically be permanently stored (as they can be used as secret keys), it can request: Where can we store them? TOP can store them in the corresponding keyhole and can prefer to store this keyhole along with the folded data using SDFT, thus allowing keyholes with the same common language to have their own instances stored for the salt value. Programmers can also store the KISS keyholes in a completely different, external manner. Figure 37 The simplified transformation diagram at the top (which is the same as) Figure 5 It becomes more like TOP and SDFT when various components can be introduced. Figure 37 The diagram at the bottom. Table 3720 summarizes the setting of attributes.

[0240] Much has been described previously regarding the analysis via TOP and SDFT and the available syntax and various transformation commands, but how does TAR actually look in practice? Figure 36This section demonstrates the structure of a TAR and lists several instances of TARs. Section 3602 specifies the general structure of a transformation audit log or TAR. The “tar label01” declaration indicates the name or label of the qualified TAR directly below it. All TAR commands follow the TAR label declaration, and a blank line indicates the end of the current TAR definition. Therefore, many TARs can be declared in a single text file. The TAR definition section can contain itself as an online TAR label or transformation command. This can be analogous to a macro-feature of a programming language compiler; it can be used as a convenient feature to combine familiar TAR constructs into a new TAR without actually copying the definition as the TAR itself. Transformation commands can be inserted into a specific sequence to process the target NSstr structure as desired. TAR “test_a01” can simply extract Python data object information into an equivalent structure lacking any Python byte data types; for other languages, it may or may not perform the same function, as “information extraction” can be language- and / or environment-specific. TAR “test_a02” performs information extraction transformations twice consecutively. The second cipher transformation may not complete a functional change to the data. This demonstrates the working TAR extension. TAR "test_a07" performs cipher transformation on the data, serializes it into a JSON string, and then converts it into a byte-type binary string using UTF-32 encoding. TAR "test_a17" shows what a terminated mobius transformation can look like. TAR "test_a20" performs cipher transformation on the data, serializes it into a JSON string, converts it into a UTF-8 encoded binary string, encrypts it using chacha20 with a 256-bit symmetric key, and then converts the resulting binary encrypted string into a base64 encoded character string. The symmetric key for the scipher transformation can be expected in a key stack containing an NSstr structure that holds the 256-bit symmetric key value. An alternative is to not provide a key stack and have the concatenation function continue to generate a valid key stack with an appropriately generated random 256-bit symmetric key, use it to perform the scipher transformation, and allow the programmer to extract a copy of the key stack (and therefore the key within it) after completion. The TAR “test_a42” demonstrates an example of TAR groups and dependent transformations: it collects information from data, serializes it into a JSON string, converts it to a binary string encoded in UTF-8, derives a 256-bit symmetric key from the common key provided in the key stack, and then performs chacha20 encryption on the data using the derived symmetric key. The last two transformations can have permanent dependencies because the cryptography relies on the derived key; therefore, this dependency can be grouped within the TAR into leading <labels> marked as such. In forward mode, there is no apparent effect on TAR groups within the TAR definition, except for visually highlighting these dependencies.However, TAR groups can play an important role when TAR reversal is involved. When preparing a TAR for the TAR reversal process, the TAR group can remain intact as a single unit and its components may not be reversed. Figure 41 and Figure 42 This diagram illustrates several instances of the reversed TAR. The TAR "test_a64" can perform five scipher transitions and one DSS dign transition. This TAR is expected to populate a key stack of six keys of various types and lengths in a specific order. Section 3610 illustrates a simplified representation of a key template corresponding to the TAR "test_a64". This key template can be used by implicit key checking and / or transition generation to verify any input key stack and / or generate a valid key stack for appropriate processing of the TAR.

[0241] Figure 38 This diagram illustrates the SDFT operations of splicing and disassembling (or the reverse of splicing). The two central operations in SDFT can be "splicing" and its reverse "disassembling". The splicing operation processes a given NSstr, which may include some or all of the following items: data, TAR, key stack, and / or other attributes. The splicing operation can "splice" or fold the source data within 3810 3802 according to the transformation sequence listed in the TAR within 3802, and can ultimately produce the output as a component within an NSstr structure 3804 or an NSjson structure 3806. The disassembling operation can "disassemble" or expand the source NSstr 3804 or NSjson 3806 structure according to the reverse transformation sequence listed in the embedded TAR, and can ultimately produce the output as an NSstr structure 3802. As will be shown, the symmetry of splicing / disassembling can be an interesting aspect of this design. Note the consistency in terminology and perspective used throughout TOP. The reverse splicing operation is equivalent to disassembling. This principle of reversibility not only simplifies the analysis of such functions, but also allows for the filtering of modular organization methods that can lead to higher-order concepts about data transformation.

[0242] Figure 39The flowchart illustrates the SDFT concatenation operation. Given an NSx structure, the concatenation function or method call can perform the following operations on the data within it using the parameters provided for the call and / or the TAR embedded within NSx, where "x" represents any transformation structure. Similar to key checking / generating transformations, mobius transformations can be considered so fundamental to this algorithm that they can be implicitly performed on any input data structure when condition 3906 is met. The concatenation can only properly perform its core operations on the NSstr structure; therefore, if an NSx structure instead of NSstr can be passed, it can attempt to transform the NSstr structure 3918. Failure to produce a valid NSstr 3924 can generate an appropriate error code 3978 and abruptly terminate the program 3984. There can be at least three different methods to concatenate or fold the data within it: First, a valid NSstr may contain a TAR indicating a sequence of transformations to be performed on the data within the NSstr structure; second, the name of the TAR tag can be passed as a parameter to the concatenation call, thereby indicating the optimal group transformation to be performed on the data within the NSstr structure; third, a customized list of TARs can be passed as a parameter along with its given name in the concatenation call, thereby indicating the optimal group transformation to be performed on the data within the NSstr structure. Preparation of TAR 3912 may include extending other TAR tags to involve / or appropriately sorting them for a traversal pattern that can be forward or reverse. Figure 41 and Figure 42 Several instances of TAR reversal are illustrated. Next, a key check transition can be performed on the TAR and NSstr structures. The components of the key check transition can be a list of key templates 3930 derived by testing the TAR. When using the TAR, the input key stack (which may be empty or partially occupied), and / or the key templates, the program can assemble a key stack for appropriate traversal of the TAR 3936. This may include generating missing keys of the correct type, ordering keys in the appropriate sequence, and / or checking input keys for the appropriate structure and type. Any mismatch in the input key type and the corresponding derived key template can generate an error condition 3942, which results in the generation of an appropriate error code 3978 and abrupt termination of the program 3984. The program can now iterate over the transition commands in the TAR in the appropriate sequence 3948 and perform the prescribed transition 3954 on the data contained in the NSstr. Any error 3960 encountered during the execution of the transition commands can generate an appropriate error code 3978 and abruptly terminate the program 3984. When the end of the 3948 TAR sequence is reached without errors, the subsequent splicing operation can be considered a success (3966) and the program can gracefully exit (3972).

[0243] Figure 40 This diagram illustrates the SDFT disassembly process. We can compare... Figure 39 and Figure 40The flowcharts in the diagram illustrate the symmetry of the transformation reversibility, rather than specifying the detailed disassembly procedure. The only difference between the two flowcharts is the TAR preparation steps 3912 and 4012. Since each transformation can be performed in a bidirectional manner and in a well-performing way using TOP analysis and structuring, the disassembly procedure does not need to be significantly different from the assembly procedure, except for how the TAR can be presented. It can be implemented as the same code but with a slight deviation when a reverse flag can be indicated and the appropriate reverse ordering of the TAR is performed when this is encountered. This call in Python v3.6 can take the form "obj.ravel(...,reverse=True)". Symmetry allows the actual implementation code to be smaller and / or the chance of presenting programming errors to be smaller. One conceptual benefit is the simplicity and clarity of thought when constructing new TARs for a specific purpose: the programmer can rely on a suitable TAR sequence that is fully reversible within its constraints and can do so without much consideration for that part of the application. One benefit is that the workload for programmers to generate a specific set of data transformations can be effectively reduced by at least half, as they no longer need to generate the reverse codes for such data manipulations. The establishment of complex encryption and locking mechanisms can require a huge number of data manipulations using a large number of cryptographic keys. The Transformation Organization Principle (TOP) approach helps achieve a more integrated and holistic approach to handling this complexity in a discrete, less error-prone manner; therefore, it allows for (but is not limited to) more consistent, reliable, secure, portable, understandable, broad, flexible, scalable, and / or complex encoding and / or data.

[0244] Figure 43A transformation table is shown, mapped to key type templates that can be generated or required during TAR processing. Referring back to the discussion of key management, one of the main operations of key management can be to analyze a given TAR and generate a corresponding list of key type templates, which can detail the types and specifications of each key necessary for the successful processing of a given TAR. Table 3506 lists at least nine types of key types defined within SDFT. Table 4300 shows the mapping of each transformation operation, which may require keys and their corresponding key types or "keytyp" required during the assembly / disassembly process. Key templates may have several attributes associated with each key type, such as, but not limited to, key length or "keylen". For simplicity and simplified illustration, a 256-bit long symmetric key can be indicated as a key template that can be represented as "symmetric keylen=256" or "symmetric 256", but in a practical implementation, any available data structure mechanism in a programming language can be used to store these values ​​in an organized manner. In Python v3.6, a possible structure for a key template can be represented by an array of dictionaries, where each dictionary entry stores a single key template with attributes corresponding to the dictionary key and attribute values ​​corresponding to the values ​​associated with that key in the dictionary. Within SDFT, all key templates can be temporary structures and can be repeatedly reproduced via key checking transformations, and it is not necessary to permanently store such key templates. In this way, SDFT can properly analyze any keys inserted into the key stack for processing before the cryptographic compilation transformation completely fails due to key type / structure incompatibility. A common theme in TOP and SDFT is that the obfuscation of data manipulation sequences is not a reliable component ensuring any sensitive payload but rather can be attributed to the strength and operational attributes and / or characteristics of the chosen cipher.

[0245] Figure 44 This table displays TAR instances and the key templates generated by each instance. The left column of Table 4402 lists TAR instance "A". The right column indicates the key type template generated for each transition command that may require a cryptographic key as an attribute input. In this instance, TAR "A" may require two cryptographic keys from the indicated sequence. The left column of Table 4404 lists TAR instance "B". The right column indicates the key type template generated for each transition command that requires a cryptographic key as input. In this instance, TAR "B" may require four cryptographic keys from the indicated sequence. This process can be considered as key template generation from a TAR.

[0246] Figure 45 This displays TAR instances and the key templates generated by each instance, along with a desired list of KISS structures to be input (put) or generated (generated). The KISS list is also known as the key stack. We can use... Figure 44 Two examples are presented, illustrating the next step in key management for a concatenation / disassembly call. A key stack can be anticipated or generated as a list of KISS structures corresponding to the key type templates shown in 4510. When the TAR “A” process receives the transition command “scipher salsa20256”, the process can expect to find an input 256-bit long symmetric key in the key stack as indicated by KISS A1. When the TAR “A” process receives the transition command “dign dss 1024 digestlen=512”, the process can expect to find an input 1024-bit dsa key in the key stack as indicated by KISS A2. The KISS list of TAR “B” can be read and understood in a similar manner. If the expected key cannot be found in the key stack, the TAR process can expect to find a generated key instead. This implicit key generation can be beneficial to programmers because the only requirement for generating any type of acceptable key for a given cryptographic transition is the ability to declare it within the TAR. Generating a specific key for a specific cryptographic function can be done without additional steps. Calling a concatenation with an empty key stack results in the output NSstr structure maintaining a fully compliant key stack with the appropriate generated key to match the TAR and be able to fold the data within it. It is strongly recommended that this key stack, consisting of KISS structures, be then securely stored separately from the folded data and / or may be further modified and folded again and secured with a TAR, thus further encrypted using a cryptographic transformation. Repeated encryption and encapsulation of the key stack can be useful when dealing with many cryptographic keys to be managed and protected. TAR "B" can generate a key stack of four KISSs, which can be easily stored securely in a key store; however, programmers may wish to encrypt the key stack of four keys using a single key for convenience. This can be accomplished by the following steps: generating a new NSstr; inserting the four-key key stack into the data obj field; picking up an appropriate cryptographic TAR; and performing a concatenation call on the NSstr structure. This series of steps produces a key stack with a single KISS structure containing the key locked to the folded NSstr structure that maintains the four-key key stack.

[0247] Figure 46This section illustrates three modes of key stack operations within the SDFT TAR process: generation, put, and mixed. Section 4600 depicts what might happen when key stack 4602 is empty during the processing of TAR instance "B". The concatenation process can take the key type template of TAR "B" 4508 and generate 4606 an appropriate number of randomly generated cryptographic keys of the same type and in the same order as found in the key type template shown in 4604. Section 4610 depicts what might happen when key stack 4612 is put 4616 during the processing of TAR instance "B". The concatenation process can take the key type template of TAR "B" 4508 and check the provided key stack 4612 to verify the number, type, and order of keys, and then allow it to be used during the processing of TAR "B" as shown in 4614. Section 4620 illustrates what might happen when key stack 4622 is presented to TAR instance "B", where only one key KISS B3 is provided, also known as a partially filled key stack or a "missing tooth" case. The splicing process can take the key type template of TAR "B" 4508 and check it against the provided key stack 4622 to verify the number, type, and order of keys. During the iterative verification of key stack entries for each key type template, any empty KISS structure can be considered a verification failure of a specific type and can be further interpreted as a change in the implicit key used for that key type template. The splicing process can then inject the newly generated key of the appropriate type into the empty position of the key stack at 4626 and continue the key verification iteration. After this step is completed, the mixed key stack (which may be referred to as a mixture of input and generated keys, a missing tooth case, or key injection) can be presented and used during the processing of TAR "B" as shown in 4624.

[0248] Figure 47This diagram illustrates how a key stack is generated and used in the lifecycle of data and its TAR. The use of the SDFT on data 4700 allows it to be iteratively transformed in an ordered manner according to a set of variable transformations, as defined by a specific TAR 4702. The TAR can be structured to allow for cryptographically compiled key types and thus generate a key template detailing the number and types of keys required for the TAR. The key template can then be referenced in the composition 4704 of the input key stack, regardless of whether all or some of the necessary keys are present or not. When a required cryptographically compiled key may be missing, the composition process can generate a new key for use. The TAR, data, and key stack can then be passed to the concatenation call 4706 to perform folding of the structured data according to the TAR. The folded data can then be stored 4708 by any method. The keys in the key stack can be stored 4710 in a separate secure location. When reference to folded data is needed, the application can retrieve the data from its storage location 4712, retrieve the key or key stack from its secure storage 4714, pass the folded data and key stack to a disassemble call 4716, and access the data in its original form from the disassembled output structure 4702. This can indicate a complete loop of folding structured data using transformation. Many other paths may exist for transforming and folding any data structure, but essentially, this loop of some form must be completed in order to fully retrieve the original data within the SDFT.

[0249] The storage of keys and / or key stacks 4710 may involve folding the key stack of a cryptographically compiled TAR to protect it using fewer keys (only one key and / or different keys). The folded key stack data can become part of another structure, which itself can eventually be folded. Data can be folded iteratively in a cascading manner to build an internal data structure, where precise progressive folding can lead to precise progressive encryption. This ability to guide the transformation of complex cryptographically compiled data in a precise, organized, and / or structured manner can lead to better and / or simpler designs for protecting sensitive data using more complex transformation schemes. The clarity and simplicity of the TAR can lead to a better understanding by others of the operations performed on the target data.

[0250] A key benefit of SDFT is its ability to provide a systematic approach to key management within the context of various cryptographic operations on a given data file, such as those in 4704 and 4714. Programmers can be largely freed from the insignificant details of generating individual keys and manually manipulating their storage and / or ordering during these processes. In cryptographic applications, these insignificant details can quickly accumulate into a large number of small details or attributes that the application (and therefore the programmer) must track, analyze, store, and / or use. The SDFT method allows a given application to track, analyze, store, and / or use fewer individual attributes of the cryptographic function because it allows these attributes to be embedded within the context of the data and / or key stack that has been manipulated and produced as output, thus providing paired coupling between folded data and the transformations that can be folded. Portability of data manipulation instructions from application to data allows for simpler applications and / or applications with more complex cryptographic uses. SDFT provides a superior alternative to the expressed Structured Cryptographic Compiler (SCP) approach, as will be discussed in the NUTS section.

[0251] Figure 48 This diagram illustrates the operations that can occur on data stored in an NSstr structure. An indicator suggests that any data involved in / or stored in a variable 4802 can be directly encapsulated 4812 into the NSstr structure using an instance method and / or method / function call 4804. The NSstr structure 4810 can then encapsulate a TAR 4814 and its associated attributes 4816 as needed. Attributes may include a key stack, digest, transformation parameters, and / or temporary variables. This provides the minimum complete information necessary to process the NSstr through SDFT splicing / desplicing operations to perform TAR on the data contained therein using the available attributes 4810. In TOP terminology, this can be referred to as data folding. The output of the SDFT can be returned as the same NSstr structure 4810 or an NSx structure (such as NSjson). This output can then be stored in a persistent and accessible manner 4820, transferred to another computing device using an inter-program communication (IPC) method 4840, and / or stored in another internal data structure 4830. The loop can be restarted at a subsequent point in the application for the stored data 4820 and 4830. For the transmitted data 4840, the loop can be initialized by receiving such data packet 4800.

[0252] Figure 49This is a flowchart illustrating the use of SDFT in iteratively folding data. This series of simplified diagrams demonstrates the systematic folding of data using SDFT splicing calls of N consecutive data folds. A splice 4900 containing at least data 4902 and TAR 4904 can be folded by calling splice 4906 to produce output data 4908. Output data 4908 can be modified and / or further encapsulated into an NSstr structure 4920 containing at least data 4922 and TAR 4924. A splice 4926 can be called to fold NSstr structure 4920 to produce output data 4928. Output data 4928 can be modified and / or further encapsulated into an NSstr structure 4940 containing at least data 4942 and TAR 4944. A splice 4946 can be called to fold NSstr structure 4940 to produce output data 4948. Output data 4948 can be modified and / or further encapsulated… This process can be iterated 4950 as needed. It should be noted that in this series of complex structured data folds, any TAR in any step can be modified separately from the application code by simply modifying the TAR instructions stored in a text file or its equivalent. An equivalent procedural expression of an SDFT that does not have such iterative encapsulation but has the possibility of transformation sequences and / or parameter variations in each step may be relatively long, error-prone, and / or difficult to understand.

[0253] Figure 50 This is a flowchart illustrating the use of SDFT in iteratively unfolding data. This series of simplified diagrams demonstrates a systematic unfolding of data called upon by SDFT decomposition using N consecutive data sets. It is... Figure 49 The exact reverse column of the flow and therefore can be understood as such. As previously stated in Figure 39 and Figure 40As shown, the disassembly call can be identical to the assembly call, except for the preparation of the TAR and the state of the data fed to it. It should be noted that in this series of complex structured data unfoldings, no additional reverse TAR is required to achieve the unfolding. All the necessary TARs required to disassemble each folded data can be found embedded within the folded structure. A more refined test of the NStar structure 3106 reveals an "expd" field, which is defined as a "list of TAR command extension forms." This is a key feature of reversibility in SDFT: the outputs of TAR preparation steps 3912 and 4012 can produce a complete set of operable transformation commands lacking labels indicating any other external references, and can be considered a complete description of the transformations that the transformed data can have undergone. This can be seen as a static snapshot of the TARs set for the folded data, thereby ensuring that proper unfolding of the folded data can be performed without any changes to the TAR definitions in external locations. This implies that a large number of TAR definitions can grow from a TAR definition file over time, but the storage of TAR definitions can be preserved through the SDFT procedure to maintain their reversibility regardless of changes to these external definition files (this may not be a recommended practice). This design facilitates a more efficient and time-compatible approach to handling stored data.

[0254] Figure 51This diagram illustrates the SDFT API / library and the various types of TAR definition files it can access. TAR definitions can exist in many forms, such as, but not limited to, text files, nuggets, encrypted files, databases, server programs, and / or running memory. A TAR can be defined by the programmer at any time as a custom TAR definition in a concatenated call and therefore can be a temporary TAR. For these TAR definitions that can be permanently stored, Figure 5100 may illustrate various forms of these definitions, but is not limited to those shown. A standard TAR 5102 can be a TAR definition that can be provided as a package along with an SDFT library installation for any OS / language pairing. A hidden TAR 5104 can be a TAR definition that can only exist in an access-restricted location and / or is a custom TAR definition with expressed permission. These may be a preferred method for TAR definitions within a private network or custom application installation. The use of hidden TARs can even remain hidden within the output of a concatenation, and the extended form of the TAR is not found embedded in this folded data but is only referred to by the TAR tag. Administrators of such groups may have an obligation to maintain hidden TARs because data folded using hidden TARs does not necessarily need to contain the transformation group required to unfold it. Hidden TARs can appear similar to an equivalent method of obfuscating data manipulation sequences within a program. Local user TAR 5106 can be a TAR definition, which can be a customized TAR definition accessible only under the user's or programmer's account permissions. These can be temporary or developmental TARs that programmers can create to be permanently added to the TAR definition storage form at a later time. Remote TAR 5108 can be a TAR definition that can be accessed with or without authorized access from a remote server or storage location. This topology may be necessary due to the restriction of local storage or due to a strategy of centralizing key TAR definitions in a central management area. This can also be a method for continuously checking whether standard TAR definitions are up-to-date. A protected TAR 5110 can be a TAR definition that can be located in any suitable accessible location but can be encrypted for authorized access only. Successful traversal of a separate authentication and / or authorization process may be required to gain access to the protected TAR. Another form of protected TAR can be stored within a Nut container, which may require one(s) appropriate keys to gain access to it. An embedded folded TAR 5112 can be an extended TAR definition that preserves folded data along with data from splicing calls.

[0255] Figure 52 This demonstrates an example Python script that performs manual data folding. Figure 53 This demonstrates an SDFT instance defined by TAR and its use in a Python script. Figure 52 and Figure 53These examples collectively demonstrate how SDFT can differ from a more straightforward programming approach using Python v3.6. These exemplary Python scripts illustrate the key differences in the basic call sequences of the tasks at hand. We can begin with a sample dataset 5210. Operations to be performed on the data can be specified in task 5220, expressed in plain language as shown in lines 02 to 06. Typically, for readability, these can be incorporated into the program itself as comment lines. Section 5250 shows the actual Python code for performing the task, and section 5260 shows the reverse processing of the task to recover the original data 5210.

[0256] When using SDFT, dataset 5310 is identical to 5210. Segment 5320 expresses task 5220 as a TAR definition labeled "test_a70". Segment 5350 concatenates the data and writes the folded data to a file. Segment 5360 reads the folded data from a file and disassembles it.

[0257] Figure 52 There are 18 lines of Python code and Figure 53 There are only 8 lines of code. It is obvious that any change in the type and amount of data transformation can affect both segments 5250 and 5260. Figure 52 The methods described in section 5260 require the programmer to maintain several variables, task sequences, and / or proper calls to functions or methods. The reverse programming in section 5260 requires the programmer to ensure that all operations are called in the correct reverse order and that parameters are fed correctly for each function or method call. Any change to a task in section 5220 may result in changes to the programming of sections 5250 and 5260. Any additional task in section 5220 may result in additional program execution in sections 5250 and 5260. More temporary variables may be generated and used as needed for these additions or changes to tasks.

[0258] exist Figure 53 In the SDFT method, any changes to the task can be directly reflected in TAR 5320. Therefore, any additional transformation modifications can only change the length of this section. The splicing and disassembling call lines 10 and 14 remain unchanged. The reverse procedure in TAR 5360 does not need to be specified beyond the original TAR definition in 5320. In fact, sections 5350 and 5360 can remain undisturbed for any selected TAR definition other than line 10, where the TAR definition label is specified in the splicing method call.

[0259] In terms of readability and comprehensibility of the tasks performed, readers may prefer TAR 5320 over the actual program code in sections 5250 and 5260. The tasks specified in 5220 are not coded and can generally be expressed as comments within Python code. Any changes to the program code in sections 5250 and 5260 must be manually coordinated with the comments by the programmer; otherwise, confusion can occur if another programmer attempts to understand the code with imprecise comments, and vice versa. TAR5320 can be viewed as a self-descriptive document in a clear and concise manner.

[0260] The data stored in lines 15 and 16 of segment 5250 does not have embedded metadata describing how it can be transformed. The transformation method is fixed as an actual code in segments 5250 and 5260. Any such data written in this manner can rely entirely on the existence of the same or similar encoding for its proper retrieval and recovery. These encoded segments or their equivalents must be permanently maintained so that their transformed data is permanently recoverable. This is equivalent to a hidden TAR method.

[0261] The data stored in line 11 of segment 5350 may contain an embedded extended TAR definition, which can transform the folded data. The transformation method may be paired with the folded data, thereby making it transportable. The recoverability of the folded data can be considered independent of the encodings 5350 and 5360 that generated it. Any encoding of the embedded TAR definition within the folded data can be appropriately processed to recover the original data. This type of functionality allows for better time compatibility as the transformation sequence changes over time, because older folded data is self-describing and therefore self-defining in terms of how it can be recovered.

[0262] Figure 54 This diagram illustrates dynamic TAR switching within a single communication session. In the TOP approach, higher-order communication protocols can be viewed as transferring transformed data from one computation process to another. Since transformations allow for many frequently used encryption functions, they can be used to generate secure messages for IPC. Theoretically, different TAR transformations and message folding can be used. Different TAR definitions can be considered as their own protocols through modern standards of protocol definition. Using SDFT, TARs can be dynamically switched between two applications based on each folded message, as in... Figure 54 The image is shown in the middle. It can be used as shown in... Figure 51Any mixture of TAR sources shown and described herein, provided that each application has access to these TAR-defined sources. This rich set of embedded folded metadata (such as, but not limited to, KISS structures, such as keyholes specifying an exact key identifier for each key required in an embedded cryptographic compilation transformation) allows SDFT-based communication protocols to provide security at a more complex and potentially more secure level.

[0263] A TOP analysis and method that can lead to an architecture known as SDFT allows stored data to contain its own portable instruction set that can generate it. This architecture can define a data folding and provide methods and / or embodiments for folding data using a conceptually and logically consistent reversible transformation processing method that can be expressed as a Transformation Audit Record (TAR) that can be embedded in an organized manner within the stored data. The resulting folded data can then be modified in some way and can then be folded repeatedly as needed to achieve the desired application or data form result. In addition to describing TAR as a programming language, it represents a set of collaborative data manipulations in a concise form, which can allow infinite variations in the transformation sequence and / or infinite variations in the transformation attributes within a given TAR and / or attribute. SDFT allows variable dataset categories to isolate local variables using category concepts and techniques in a manner similar to programming languages. Through TOP, protocol changes can be observed in a higher conceptual construct, which can result in data that is self-describing and accessible and readable from a variety of applications, whose methods can be accessed via available SDFT libraries adapted to their programming environments. Furthermore, these characteristics of immersion into folded data allow for dynamic switching of protocols within a single communication session or a single stored data object. The TOP method can serve as a fundamental building block of the NUTS ecosystem and is an integral part of Nut. NUTS can be fully implemented independently of SDFT, but this can be unwise.

[0264] NUT ID NUTS design enables data identifiability regardless of location. This could require a universally unique ID (UUID), but this cannot be guaranteed without some form of centralization. Therefore, we can choose a concept of a practically unique ID with sufficient length and entropy sensitivity to provide a low probability of ID collisions. Figure 55A flowchart illustrating an example of a program used to generate Nut ID 5500 is provided. Here, local device 5502 can run an application that can call a function to generate an actual unique ID from data, such as, but not limited to, user attribute 5504, environment attribute 5506, and / or random attribute 5508. User attribute 5504 may contain data items such as, but not limited to, user login information, group ID, company ID, user ID, and / or user passcode hash. Environment attribute 5506 may contain data items such as, but not limited to, MAC address, IP address, device information, system time, OS information, directory path and / or file, atomic clock synchronization time value, GPS synchronization time value, declared environment variables, thread ID, CPU runtime, IMEI number, phone number, application name, and / or program ID. Random attribute 5508 may contain data items such as, but not limited to, session counter, UUID, clock cycle count, randomly generated number, mouse movement, keyboard activity, file system state, partial or complete screen area hash, program uptime, OS uptime, and / or session duration. These data files can be collected and stored in an ID structure 5510, which can then be serialized using JSON or an alternative hashing technique. Next, a hash algorithm (such as SHA-512 (a family of hash algorithms from NIST published in FIPS PUB180-2 in 2001)) or an alternative hashing method (which utilizes the recommended minimum length of 512 bits to produce practical uniqueness and reduce the probability of ID collisions) can be used to generate the resulting binary string as hash 5520. For portability and readability, the binary hash can be encoded into a base64 (or alternative encoding scheme) text string 5514, which produces a text string of approximately 86 characters. The encoding scheme can include any method that results in a printable and human-readable text string that can be accepted by multiple programming languages ​​and software systems. Depending on the modality in which functions may have been called, duplicates of the resulting encoded hash string can be checked against any accessible Nut ID cache 5516. If ID value conflicts exist, the process can be repeated using a new random attribute 5508 until a non-conflicting ID can be generated; conflicts are expected to be rare events. The output string of this logical operation can be called Nut ID 5518.

[0265] This process can be implemented locally within a running application or within a server application residing locally or a remote server client application requesting a new Nut ID. A potential benefit of the server-based implementation is its ability to access a larger cache of existing Nut IDs for checking and to generate Nut IDs with a lower probability of collision. Nut ID duplication checks are not mandatory because the hash length in the ID structure 5510 and appropriately collected data components provide sufficient entropy. General partitioning concepts exist throughout some or all digital infrastructures, such as the Internet with IPv4 / IPv6 addresses, domains, directory hierarchies, and access control groups. Similarly, a Nut ID can be practically unique, but it can be used within a compartmentalized context constructed by external systems or relationships, and therefore the probability of collision can be orders of magnitude smaller than the mathematical probability provided by permutations within a given length of the Nut ID. In cases where a different length is desired, this can be accomplished by those skilled in the art by replacing the SHA-512 hash with an alternative hash algorithm in a modular, parameterized manner.

[0266] Considering the process by which a truly unique ID is generated as a Nut ID, what can it identify? In NUTS terminology, this is called a Nut ID stamp. At least two structures can exist within a NUTS that consistently stamp a Nut ID: a lock node and a Nut. A Nut ID assigned to a lock node is called a lock ID. A Nut ID assigned to a Nut is called a Nut ID. A lock node can establish a block within a Nut. A lock node can be a self-contained, independent locking mechanism that protects its payload, called a packet. A Nut can be a data structure consisting of one or more lock nodes. Therefore, a Nut can hold any one or more packets of data, either completely or partially. Nuts can be used throughout the NUTS environment to identify some or all associated software, data, and / or hardware represented in binary form in a truly unique way. The consequence of a Nut ID stamp is that each Nut can be uniquely identified, implying that every small data packet stored within a Nut can be uniquely identified by that Nut ID regardless of where the Nut can be physically located.

[0267] Figure 56A simplified diagram illustrating the Nut data structure. This diagram highlights the use and relative placement of lock IDs and Nut IDs within the Nut data structure. Specific lock IDs 5614 to 5622 can be assigned to this Nut, and they can be different values. Lock nodes 5604 to 5612 can be identified by lock IDs 5614 to 5622 respectively. In a typical Nut data structure (such as this example), Nut 5602 can be a group of lock nodes organized into a graphical data structure called a lock graph. A specific Nut 5602 can be identified by its Nut ID 5634, which can be stored in packet 5626 of lock node 5606, and the Nut ID can be considered the payload of this lock node, which may be different from the payload of Nuts that can be stored in one or more packets of other lock nodes. Each lock node 5604 to 5612 structure can contain payload areas called packets 5624 to 5632. This shows the relationship between Nut and its Nut ID, where we can find these items stored in a typical Nut container.

[0268] Figure 57 Examples illustrating the relationships between Nut IDs, path names, and / or payload data. Several lock nodes may exist within a Nut, which can be used to store the Nut's metadata, metadata about the Nut's payload, and / or the Nut's payload itself. The metadata portion may be stored in packets within various lock nodes within the Nut. Example 5702 shows a case where two distinct Nut payloads D1 and D2 may exist, each stored in a distinct Nut identified by NutIDs A3 and B1 respectively. Two-character Nut IDs are used for illustrative purposes, even though it may have been previously specified that Nut IDs can be base64 encoded 512-bit hashes that produce a text string up to 86 characters long. Nuts A3 and B1 also have distinct path names in the NTFS file system. Example 5704 shows two distinct Nuts with the same filename but different path names. Example 5706 shows two copies of the same Nut with the same filename in different directories. Example 5708 shows two copies of a Nut with different filenames in the same directory. This may not be an exhaustive list of some or all of these attributes, but it demonstrates the flexibility of having metadata items (such as Nut ID) permanently associated with each payload.

[0269] Embedding data within a Nut file that can be identified by its associated Nut ID introduces a novel feature to this method: the ability to automatically generate dynamic filenames based on parameterized rules in the metadata. The filename can represent a normal identifier string for the file, along with a defined summary of its other attributes, such as, but not limited to, modification date and time and / or the number of writes on that day. This provides a more accurate and convenient way to identify a file and its status in real time without delving into normal hidden attributes (such as the file nature in a directory browsing application). It also allows file and data attributes to be embedded in a container that retains the file rather than relying on the file system's attribute capture capabilities (which can vary between file systems). Example: A user can generate a Nut with Nut ID #234 that can store text files. The text file can always be identified by Nut ID #234, but the user can set a dynamic filename that includes a base name + last modified date + the number of writes on that day, such as "diary_20151115_1.txt". On the same day, when a user saves the file to disk after making slight modifications, the filename can be displayed as "diary_20151115_2.txt" and the old filename may no longer exist in the directory. This method can automatically generate a new filename that indicates some state information of the stored data. The nature of the NutID, which can be practically unique and can be specified separately from the path name + filename, allows this feature to be implemented without any external references. One benefit of this feature is that it is a common method for copying and saving the previous state of working files with datestamps. Authors can find directories filled with files they work on their documents every day. In the case of using the dynamic filename method, there may only be one Nut file in its directory containing the last written datestamp. The history (state) of the manual method can be preserved within the Nut itself using the Nut history feature presented in a later section. The Nut ID is the primary content identifier; this concept can then be used by the NUT server to perform copying and synchronization operations on distributed Nuts.

[0270] Lock graph and lock node NUTS technology addresses data storage, protection, and access control through a layered, integrated, modular, and / or iterative approach, which can be defined as a Structured Cryptographic Compiler (SCP). The overall design of a Nut's internal components can be described and defined, followed by a detailed description of each defined structure. Features can be described hierarchically, followed by an overall description demonstrating how individual features can work together. SDFT can be utilized throughout the NUTS design to improve the organization of complex cryptographic structures and the systematic embedding of properties associated with each folded data structure. Various embodiments demonstrate how SDFT enables the relatively easy implementation of SCP designs (compared to equivalent manual methods).

[0271] There are four different methods for controlling access to the Nut: keyhole, variable lock, hierarchical access control (SAC), and / or Nut access control (NAC). Some or all of these methods can be partially or completely layered and / or integrated within the Nut in a novel way, allowing the Nut to provide the full functionality of a reference monitoring system in an internalized and / or independent manner. These four layers can be represented in a complex data structure called a lock node, which can be designed to be modular, isolated, and / or chainable.

[0272] A keyhole can be a data structure that accepts any number of cryptographic keys, each of which may have an associated encrypted key map. Implementations are not limited to currently recognizable and acceptable types of cryptographic keys: common keys, symmetric keys, and asymmetric key pairs. Any simple or complex method or process that specifies a bit sequence as a secret key can be integrated into a keyhole. The encrypted key map may contain several sets of keys, each used for different layers of access control within the Nut: variable locks, SAC, and / or NAC.

[0273] Variable locks can provide different types of locking mechanisms within a normalized structure, protecting data in the lock node. These variable locks may include ORLOCK, MATLOCK, SSLOCK, XORLOCK, and HASHLOCK. This disclosure is not limited to these predefined lock types and may be extended or contracted to accommodate any suitable locking scheme that can be normalized to its structure.

[0274] Hierarchical access control modulates pervasive access to individual lock nodes in the lock graph. This feature can introduce a property in Nuts called gradient opacity, which allows various levels of metadata to be viewed given appropriate access attributes.

[0275] NUT access control or NAC can employ role-based cryptographic compilation access control (RBCAC) technology to provide fine-grained control over modifications and authentication of NUT internal components.

[0276] Structured cryptographic compilation programming enables the design of data structures that allow for easy and flexible interaction between different methods to express various access models. Security mechanisms can be fully embodied in encrypted data and its associated cryptography; therefore, there is no dependency on external applications (such as reference monitors) for access control of Nut. In some embodiments, lock nodes can be used individually to protect field-level data in any part of the payload. Internal components of the Nut container can potentially utilize multiple cryptographic keys to embody specific security models.

[0277] Nuts can be directed graph data structures called lock graphs, consisting of nodes called lock nodes. Each lock node can be identified by a lock ID, which can be generated by the same function used to generate Nut IDs, and therefore they can all have the same characteristics. Lock nodes can be stored in a hash array that can be referenced by their lock IDs. Each lock node can have pointers to other lock IDs or null pointers. A lock graph can be derived from the hash array of lock nodes using well-established graph extraction and traversal techniques. Lock nodes that do not have pointers to other lock nodes can be keyhole lock nodes (entry or external lock nodes). Lock nodes that can have null pointers can be terminal lock nodes of the lock graph and can store the Nut payload or a reference to the payload. A lock node can have multiple lock nodes linked to it. In most cases, a lock node does not link back to an earlier lock node in the lock graph or itself. Circular link references may be abnormal, but this can be accommodated through custom programming of custom Nuts while ensuring this structure.

[0278] Some (if not all) of the data structures that support Nut functionality described in this paper can be implemented using complex data structures within a chosen programming language. If the SDFT function library is available for a chosen programming language, it can be readily applied to fold and encapsulate any and all applicable complex data structures or sub-sections thereof to minimize data manipulation codes, clarify data manipulation methods, reduce the probability of coding errors, and utilize the implied SDFT features embedded in each folded data structure.

[0279] It should be noted that, due to the data center nature of this disclosure, most flow diagram types can be a hybrid of traditional flowchart components and data components, which may be referred to as data flow diagrams or data flow graphs. Furthermore, the interwoven nature of the lock node design layer may make it difficult to expose the logical operations of its components in a completely linear manner without positive reference statements; therefore, some rereading may be required for the reader's portion.

[0280] Figure 58 This is an embodiment of Nut or lock graph 5800, comprising two logical sections employing multiple purpose aspects of modular lock nodes: Nut lock 5802 and Nut portion 5804. The Nut lock 5802 section of the lock graph allows the construction of complex cryptographically compiled linked locks for a given Nut using one or more lock nodes. Currently, five types of lock nodes are defined within this disclosure, corresponding to five types of variable locks, referred to as: ORLOCK, MATLOCK, SSLOCK, XORLOCK, and HASHLOCK. Each lock node type may refer to the type of locking mechanism within the variable lock, which can be used at the center of a particular lock node to protect encryption keys to storage areas and other lock node metadata and parameters. Figure 30The lock transition disclosed herein can be an embodiment of a variable lock and can be used in the establishment of lock nodes. Successfully unlocking and traversing the Nut lock 5802 portion of the lock graph can lead to the Nut portion 5804 segment of the lock graph 5800. Several lock nodes may exist constituting the Nut portion 5804: hair 5820, tick 5822, seal 5824, vita 5826, bale 5828, and / or tale 5830. The Nut portion 5804 may contain the Nut payload 5830 and / or metadata 5820 to 5828. The number and type of Nut portions of the lock graph may vary depending on the data type that the Nut can be stored and / or the design of the Nut for some desired behavior and characteristics. In this example, unlocking the keyhole lock node 5806 (5816) can result in the appropriate cryptographic key being inserted into the first-level keyhole of the lock node 5820 connected to 5818. Unlocking lock node 5820 results in an appropriate cryptographic key, which can be inserted into the first-level keyhole of the connected lock node 5822. Unlocking lock node 5822 results in an appropriate cryptographic key, which can be inserted into the first-level keyhole of the connected lock node 5824. Unlocking lock node 5824 results in an appropriate cryptographic key, which can be inserted into the first-level keyhole of the connected lock node 5826. Unlocking lock node 5826 results in an appropriate cryptographic key, which can be inserted into the first-level keyhole of the connected lock node 5828. Unlocking lock node 5828 results in an appropriate cryptographic key, which can be inserted into the first-level keyhole of the connected lock node 5830. Lock node 5830 can be connected to a null index, and therefore it can be the terminal lock node or the innermost layer of this lock graph or Nut. Unlocking a lock node may include disassembling (unfolding) the folded data structure representing the lock node using the SDFT method. Each lock node can contain multiple collapsed data structures, where unlocking a lock node is equivalent to unfolding the applicable data structures.

[0281] Figure 59A simplified Nut diagram 5900 is shown, illustrating a lock diagram embodiment including a logical segment Nut lock 5902 and a Nut portion 5904. This example explores a Nut lock 5902 including four lock nodes 5908, 5910, 5912, and 5916. Lock nodes 5908 to 5912 can be keyhole lock nodes 5906 for this Nut, as some or all of them can be outward-facing nodes and accept an external cryptographic key called a first-level key. Users can have first-level keys associated with one or more of these keyhole lock nodes. The Nut ID, which stores the first-level key as its payload, can serve as a key ID, which can be automatically matched with the identifier that identifies the keyhole to which the keyhole lock node 5906 belongs. The passphrase key can be identified by a key ID or a text string, which may or may not retain a query as its identifier. Complex multi-layered passphrases can be constructed using appropriate keyhole identifiers and plaintext Nut metadata portions with appropriate query lists. The connection between lock nodes (such as 5914 and 5918) can be broken in a similar manner, where successfully unlocking a lock node produces one(s) output keys with identifiers. In this particular instance, unlocking any of the keyhole lock nodes reveals the appropriate cryptographic key, which can be inserted into the keyhole of lock node 5916 connected to 5914. From this point onward, unlocking of nodes including Nut section 5904 proceeds similarly to the procedure described for Nut section 5804. This Nut lock 5902 construction conveys the block-building nature of lock nodes and the flexibility of their combinations by demonstrating three distinct paths that can exist for the payload to unlock Nut 5900 (each path requiring different conditions to continue the unlocking process).

[0282] exist Figure 60 In this context, lock node 6000 may be a data structure including the following sections: parameters 6002, inputs 6006, key image 6008, variable lock 6012, derived key 6016, key group 6020, packet 6024, and / or output 6026. The parameter section 6002 may hold the lock node's metadata, the lock ID 6030, the encrypted string of the key image 6010, the derived key 6014, the key group 6018, the packet 6022, and the dign (which can be generated by the appropriate access role key of the lock node) of the encrypted string. Figure 83The discussion of component 8334 describes a forward reference. The design principle can be analogous to the process in a lock graph with unlocked segments, which can lead to a key that helps open the next segment, but then each component within the lock node provides specific functionality. A dign on the encrypted string can be used by the reader (an access role) to authenticate a specific segment before a decryption attempt. When a modification is possible, the writer of the specific segment (an access role) can use the encrypted string of the segment to generate a dign to retain or instruct an appropriate writer to access the key holder's generated dign. Furthermore, the aforementioned encrypted strings can be embodied using the SDFT method to utilize a data structure containing cryptographic transformations derived from TAR folds. The number and types of encrypted strings described in this section are given; the SDFT method can significantly reduce the burden on programmers managing cryptographically related properties during encoding.

[0283] Keyhole exist Figure 61 In the lock node, the input section 6006 provides two different keyholes: a first-level keyhole 6102 and an access keyhole 6104. Structurally, the first-level keyhole 6102 can accept any number of cryptographic keys, including four different key types: symmetric, asymmetric public, asymmetric private, and passphrase. The access keyhole 6104 can accept symmetric and / or passphrase key types. The first-level keyhole and access keyhole can be used internally, such as in... Figure 34 The data structure shown in the document is one or more KISS data structures, each of which operates in a keyhole pattern (ima="keyhole") to represent a keyhole for each unique key that it accepts.

[0284] Figure 62 A single cryptographic compilation key 6202 is shown, which may have an associated key ID, key type, and key attributes 6206, and may also be designated as a first-level key. The key ID can be any identifier string. The first-level key and any other keys mentioned in this disclosure may each be provided by, as in Figure 34The KISS data structure shown internally operates in a key mode (ima="key"), having a key->value field filled with the key and other matching attribute fields as needed. The first-level keyhole 6204 accepts a first-level key 6202 that can be decrypted via an encrypted key map 6208. The decrypted key map 6240 can be a structure comprising three sections: a primary key 6210, a hierarchical key 6212, and an access key set (AKS) 6214. The primary key structure 6210 may contain a symmetric key or tail (which may be referred to as the primary key), the expiration date / time of the first-level key 6202, a countdown timer for the first-level key, and / or an action command after the first-level key expires. The symmetric key or tail can be used by the variable lock of the lock node. For keyhole lock nodes, the key map structure may additionally hold the hierarchical key 6212 and / or the AKS 6214. The hierarchical key 6212 holds a set of keys to be inserted into a hierarchical lock node in the lock graph, which can be identified by its hierarchy. The AKS 6214 holds a set of keys in its own access keyhole 6104 to be inserted into a keyhole lock node. The encrypted key image 6208 can be an SDFT folded data structure, which may contain the main key 6210, the hierarchical key 6212, and the access key group (AKS) 6214 structure.

[0285] Figure 63 A flowchart illustrating the key insertion process for any lock node and any cryptographic key is provided. Step 6304 may be a search across some or all of the listed lock nodes in the Nuts of a given cryptographic key and its associated key ID. Once the cryptographic key is inserted into the appropriate keyhole 6304, step 6306 may attempt to decrypt and unfold the encrypted key image of that key. The decryption and unfolding of the encrypted key image is equivalent to the disassembly of an SDFT-folded encrypted key image in such embodiments.

[0286] After the successful unlocking and unfolding of an encrypted key image 6208 in a keyhole lock node, 1) a hierarchy key can be inserted into the first-level keyhole of each lock node to match the hierarchy specified in the parameter segment of each lock node, and 2) the access attribute key group unlock key (AAKSUK) of the access key group (AKS) can be inserted into the access keyhole of the lock node. Since so many first-level keys can be inserted into the lock node, this first-level key unlocking (or disassembly) can occur, after which we can have a set of decrypted (or unfolded) key images that together form a set of main keys that can be used by the variable lock of the lock node.

[0287] Figure 64An example is shown where three Level 1 keys 6402 to 6406 can be inserted into Level 1 keyhole 6400. Each key (→) can be matched with its identification key ID and can be inserted into a slot in a hash array or KISS keyhole structure. The key type can indicate a key type, such as, but not limited to, symmetric, asymmetric public, asymmetric private, and common key. In some embodiments of Nut, the user can specify any key type that can have a corresponding cryptographic method with appropriate modularity for NUTS integration. These key cryptographic methods can include fingerprint scanning, iris scanning, palm print, voiceprint, handwriting pattern, facial recognition, DNA characteristics, physical key devices, hardware security keys, software / hardware-based zero-knowledge protocol keys, and / or NFC keys. If an asymmetric private key (such as that used in RSA-2048) is inserted, it can represent a public portion and a private portion, the public portion of which can be extracted from the private portion and used to encrypt an encrypted key image of the Level 1 key; therefore, decryption operations may require presenting a private asymmetric key. As explicitly shown for a key (→) inserted into a keyhole 6402, its encrypted key image 6412 can be decrypted using a key-type cryptography method to reveal a key image structure 6430 that may contain three distinct sets of keys 6432, 6434, and 6436. This decryption step can be performed on each key 6404 and 6406 to produce corresponding key image sets 6440 and 6450. Each decryption step is also equivalent to disassembling the folded structure of the SDFT in these embodiments. For the linguistic key type, the key may be a linguistic key, and key attributes may indicate the linguistic derivation function used and appropriate parameters for that function, including the number of iterations performed to produce a symmetric key capable of decrypting the encrypted key image. For embodiments utilizing the SDFT, this linguistic attribute may also be matched with a corresponding TAR to access an appropriate derivation transformation with matching attributes. To place the instance in the view of the lock node graph 6000, the input segment 6006 may contain a first-level keyhole 6400, the encrypted key image 6010 may be represented by 6410, and the key image segment 6008 may be represented by 6420.

[0288] Variable lock The next part of the lock node can be as follows: Figure 60The variable lock is shown in component 6012. The variable lock can be a locking mechanism that helps protect the contents of the lock node stored in package 6024. The variable lock allows the lock node to utilize any of several different types of cryptographic locking techniques familiar to those skilled in the art. For example, these different lock types may include ORLOCK, MATLOCK, XORLOCK, HASHLOCK, and / or SSLOCK. This can be accomplished by normalizing the inputs and / or outputs of each locking method to fit to a common data flow model, thus allowing seamless replacement of each locking method. Similarly, the first-level keyhole and key mapping structure can act as a data normalizer for the number and type of keys flowing into a variable lock. The lock node may be imprinted with a set of parameters 6002 indicating the variable lock type 6030 it can implement. Once this value is set, the lock node can rarely change this setting, although it may be re-encrypted and / or reset by the RAT (the owner of Nut). The SDFT library is described as follows. Figure 30 The variable lock and its accompanying specifications listed herein (which may be used in this section for convenience) are one embodiment, but the use of lock transformation is not a necessary requirement for realizing this function of a lock node.

[0289] continue Figure 64 The traversal of the lock nodes, ending with the three primary keys 6432, 6442, and 6452. We can... Figure 65 The text explores how the variable lock can operate. The variable lock 6502 protects a derived key (DK) 6506 by encrypting it into an encrypted derived key (eDK) 6504. Some or all of the primary keys 6432, 6442, and 6452 can be symmetric or tail key types and can be fed into the variable lock 6502. Depending on the variable lock type specified in the lock node parameter sections 6002 and 6030, appropriate variable lock functions can be called to perform encryption / decryption operations on the DK or eDK. Figure 65 This demonstrates a decryption operation that uses a variable lock 6502, which can be used with the main keys 6432, 6442, and 6452, to decrypt eDK 6504 into DK 6506. Figure 66 This demonstrates an encryption operation that encrypts DK 6506 into eDK 6504 using a variable lock 6502 with primary keys 6432, 6442, and 6452. In embodiments using SDFT, DK may be data protected by a TAR, which employs a lock transformation through data folding; therefore, unfolding this structure reveals the derived keys contained therein.

[0290] Figure 67 The table summarizes some key characteristics mentioned in the mutable lock. As the term mutable lock may imply, any locking technique that can be normalized to this model can be added as another mutable lock type. Alternatively, any locking technique can be excluded. Figure 30 The table in can correspond to Figure 67 The table shows how SDFT can embody the variable lock design during its locking transition.

[0291] The metadata segment 6030 of the lock node can be a common component that may be involved in some or all variable locks. Various digns (digital signatures) may exist within the lock node segment, which may have been generated by an appropriate Access Role Key (ARK) (such as 6040 to 6048 (forward references)). Some of all these digns may be generated by the Nut owner, who may be any one who maintains an Access Layer (RAT) access role key (specifically, a RAT private key) through their AKS. The owner with a valid Level 1 key may have a RAT public key, which allows them to authenticate various RAT digns through the lock node to ensure that the Nut component has not been compromised. In the diagram, the RAT public key may sometimes be referred to as the RAT reader key and the private key as the RAT writer key. Further discussion of the Nut access control layer will explore, define, and / or clarify these characteristics later in this document. As previously mentioned in the section on SDFT and TAR, the dign of encrypted data can be part of the TAR specification of a folded data structure, which allows the protected data, its dign, and the TAR that generated it to be embedded. This explicitly implies that a systematic use of SDFT within a lock node can be advantageous for programmer workloads.

[0292] Figure 68 The ORLOCK (also known as the OR key) in the configuration is a variable lock that accepts any number of symmetric cryptographic keys called the primary key 6808 and can systematically attempt to decrypt 6814 eDK 6806 using symmetric cryptographic compilation ciphers (such as AES-256 or substitution ciphers). Parameter section 6002 can indicate the cryptographic method used for this logical operation or the preferred TAR when using the SDFT method. The first successful decryption of the eDK produces a derived key (DK) 6816 and results in the successful unlocking of the ORLOCK. Before any decryption attempt in the variable lock, a flag of the eDK 6804 can be authenticated using the eDK 6806 and the RAT reader key 6802. If authentication is successful 6810, the decryption process can continue; otherwise, an error 6830 is generated and the attempt stops. The primary key 6808 can be the same key, such as, but not limited to, a symmetric 256-bit key. In this arrangement, the nature of the OR lock can be isolated and normalized to a keyhole and variable lock structure to make it modular. In a folded structure, the identification process can be part of the TAR and can be implicitly attempted through the act of disassembly.

[0293] Figure 69The encryption operation of ORLOCK is described from the perspective of the RAT writer or Nut owner. It can use any primary key 6902 and an appropriate cipher to perform encryption operation 6920 on DK 6906 to produce eDK 6908. Then, using its RAT writer key 6904, eDK 6908, and an appropriate digning algorithm 6922, it can produce the dign of eDK 6910, which can be stored in the lock node parameter segment 6044. The SDFT method can fold many of these attributes along with the eDK into a single data object in a compact manner for storage in the parameter segment. The encryption process for non-RAT components of a lock node can be simple; they can erase the lock node's application memory contents because they do not produce a true dign for anything that implies they cannot successfully modify its contents and dign, or they can use a decrypted DK 6908 and encrypt the lock node's related contents but leave the eDK 6910 unaffected because the contents associated with the eDK dign are not changed. This demonstrates that only the RAT writer can replace or re-encrypt the value of DK 6906. When using the SDFT method, the non-RAT components of the lock node can optionally leave the original folded data containing the eDK in the parameter section and erase to preserve the unfolded structure of the DK.

[0294] Figure 70 The MATLOCK (also known as a matroyshka lock, cascade lock, or AND lock) is a variable lock that accepts a fixed number of symmetric cryptographic keys called primary keys 7006 and can be decrypted sequentially in ascending order using an appropriate cryptographic compilation key 7014 (such as AES-256 or a substitution key) using each primary key 7008. The parameter section indicates the exact cryptography used for this logical operation and the number of primary keys required, or a preferred TAR when using the SDFT method. Successful ordered iterative decryption of eDK 7022 produces DK 7024 and leads to the successful unlocking of MATLOCK. Before any decryption attempt in a variable lock, the dign of eDK 7004 can be authenticated using eDK 7022 and the RAT reader key 7002. If authentication is successful 7010, the decryption process can continue; otherwise, an error 7030 is generated and the attempt stops. In this arrangement, the essence of the Matroyshka lock can be isolated and normalized into a keyhole and variable lock structure to make it modular. In the folded structure, the authentication process can be part of the TAR and can be implicitly attempted by the act of disassembly.

[0295] Figure 71The cryptographic operations of MATLOCK are described from the perspective of the RAT writer or Nut owner. It may employ some or all of the presented primary keys 7102 and may sort them in descending order 7110. Then, it may iteratively perform cryptographic operations 7112 on the DK 7120 using an appropriate cipher to produce an eDK 7122. Then, using its RAT writer key 7124, eDK 7122, and an appropriate digning algorithm 7118, it may produce the dign of eDK 7126, which may be stored in the lock node parameter segment 6044. The SDFT method may fold many of these attributes along with the eDK into a single data object in a compact manner for storage in the parameter segment. The encryption process for non-RAT components of a lock node can be simple; they can erase the lock node's application memory contents because they do not produce a true dign for anything that implies they cannot successfully modify its contents and dign, or they can use a decrypted DK 7120 and encrypt the lock node's related contents but leave the eDK 7126 unaffected because the contents associated with the eDK dign are not changed. This demonstrates that only the RAT writer can replace or re-encrypt the value of the DK 7120. When using the SDFT method, the non-RAT components of the lock node can optionally leave the original folded data containing the eDK in the parameter section and erase to preserve the unfolded structure of the DK.

[0296] Figure 72 The XORLOCK (also known as the XOR lock) in the code is a variable lock that accepts a fixed number (>1) of symmetric cryptographic keys called primary keys 7206 and generates a computed key by applying XOR operations 7224 sequentially to each primary key 7208 in ascending order 7222. It can then attempt to decrypt 7228 eDK 7210 using the computed key from 7224 with an appropriate cipher (such as AES-256 or a substitution cipher). Parameter section 6030 can indicate the exact cipher used for this logical operation and the number of primary keys required (which can be no less than two keys) or a preferred TAR when using the SDFT method. Successful decryption of eDK 7210 produces DK 7212 and leads to successful unlocking of XORLOCK. Before any decryption attempt in the variable lock, the dign of eDK 7204 can be authenticated using eDK 7210 and the RAT reader key 7202. If authentication is successful (7220), the decryption process can continue; otherwise, an error (7230) will be generated and the attempt will stop. In this arrangement, the nature of the XOR lock can be isolated and normalized into a keyhole and variable lock structure to make it modular. In the folded structure, the authentication step can be part of the TAR and can be implicitly attempted by the action of disassembly.

[0297] Figure 73The encryption operation of XORLOCK is described from the perspective of the RAT writer or Nut owner. It can take some or all of the presented primary keys 7302 and sort them in ascending order 7320. Then, it can iteratively perform an XOR operation 7322 on the primary keys 7304 to produce a computed key, which can be used to encrypt 7326 DK 7306 to produce eDK 7308. The RAT writer key 7310, eDK 7308, and a suitable labeling algorithm 7328 can be used to produce the label of eDK 7312, which can be stored in the lock node parameter segment 6044. The SDFT method can fold many of these attributes along with the eDK into a single data object in a compact manner for storage in the parameter segment. The encryption process for non-RAT components of a lock node can be simple; they can erase the lock node's application memory contents because they do not generate a true dign for anything that implies they cannot successfully modify its contents, or they can use a decrypted DK 7306 and encrypt the lock node's related contents but leave the eDK 7312 unaffected because the contents associated with the eDK dign are not changed. This demonstrates that only the RAT writer may be able to re-encrypt the DK 7306. When using the SDFT method, the non-RAT components of the lock node can optionally leave the original folded data containing the eDK in the parameter section and erase to preserve the unfolded structure of the DK.

[0298] Figure 74 The HASHLOCK (also known as a hash lock) in the context is a variable lock that accepts a fixed number of symmetric cryptographic keys called primary keys 7406. It generates a computed key by concatenating some or all of the primary keys presented by 7424 in a specific order 7422, and then applies a hash algorithm 7426 to the string. It then attempts to decrypt 7428 eDK 7410 using the computed key with an appropriate cryptographic compilation cipher (such as AES-256 or a substitution cipher). Parameter section 6030 indicates the exact cipher and hash used for these logical operations, the required number of primary keys, and / or the order of the primary keys, or the preferred TAR when using the SDFT method. Successful decryption of eDK 7410 produces DK 7412 and leads to the successful unlocking of HASHLOCK. Before any decryption attempt in the variable lock, the dign of eDK 7404 can be authenticated using eDK 7410 and the RAT reader key 7402. If authentication is successful (7420), the decryption process can continue; otherwise, an error (7430) will be generated and the attempt will stop. In this arrangement, the nature of the hash lock can be isolated and normalized into a keyhole and variable lock structure to make it modular. In the folded structure, the authentication step can be part of the TAR and can be implicitly attempted by the action of disassembly.

[0299] Figure 75 The cryptographic operation of HASHLOCK is described from the perspective of the RAT writer or Nut owner. It can take the presented master key 7502 and sort them in ascending order 7520, then concatenate them 7522, and then generate a computed key by performing a hash operation 7524 on them. This computed key can be used to decrypt 7526 DK 7506 and generate eDK 7510. The RAT writer key 7508, eDK 7510, and a suitable dign algorithm 7528 can be used to generate the dign of eDK 7512, which can be stored in the lock node parameter segment 6044. The SDFT method can fold many of these attributes along with the eDK into a single data object in a compact manner for storage in the parameter segment. The encryption process for non-RAT components of a lock node can be simple; they can erase the lock node's application memory contents because they do not generate a true dign for anything that implies they cannot successfully modify its contents, or they can use a decrypted DK 7506 and encrypt the lock node's related contents but leave the eDK 7512 unaffected because the contents associated with the eDK dign are not changed. This demonstrates that only the RAT writer may be able to re-encrypt the DK 7506. When using the SDFT method, the non-RAT components of the lock node can choose to leave the original folded data containing the eDK in the parameter section and erase to preserve the unfolded structure of the DK.

[0300] Figure 76The SSLOCK (also known as the secret-share lock or Shamir secret-share scheme) is a variable lock that accepts k parts of n master keys 7606, each of which can be a distinct tail or secret-share portion, where 1>p+1≤k≤n and p+1 can be the minimum number of keys required (called the threshold). To recover the secret key, some or all of the tails from the decrypted key image 7606 can be provided to the appropriate secret-share cipher 7622, ​​such as the Shamir secret-share scheme or an alternative cipher. If some or all of the tails are valid and a sufficient number of tails exist, the recovery can be successful. It can then attempt to decrypt 7624 eDK 7608 using the recovered secret key with an appropriate cryptographic compilation cipher (such as AES-256 or an alternative cipher). Parameter section 6030 can indicate the exact cipher used for secret sharing and encryption operations, as well as the number of copies (n) and threshold count (p+1) of the secret-share cipher, and / or the preferred TAR when using the SDFT method. Successful decryption of eDK 7608 produces DK 7610 and leads to successful unlocking of SSLOCK. Before any decryption attempt in a variable lock, the dign of eDK 7604 can be authenticated using eDK 7608 and RAT reader key 7602. If authentication is successful 7620, the decryption process can continue; otherwise, an error 7630 is generated and the attempt stops. In this arrangement, the nature of the secret-shared lock can be isolated and normalized to a keyhole and variable lock structure to make it modular. In the folded structure, the authentication step can be part of the TAR and can be implicitly attempted by the action of disassembly.

[0301] Figure 77The encryption operation of SSLOCK is described from the perspective of the RAT writer or Nut owner (who can initially encrypt the lock node or can do so during the re-encryption of the variable lock). A new private key K (7720) can be generated, and then the desired number of copies (tails) can be generated from K using a suitable secret-sharing method specified in parameter 6030. These tails can then be stored as the master key (7702). In step 7724, key K can encrypt DK (7704) to generate eDK (7706). The RAT writer key (7708), eDK (7706), and a suitable dign algorithm (7726) can be used to generate the dign of eDK (7710), which can be stored in the lock node parameter section (6044). The SDFT method can fold many of these attributes along with eDK into a single data object in a compact manner for storage in the parameter section. The encryption process for non-RAT components of a lock node can be simple; they can erase the lock node's application memory contents because they do not generate a true dign for anything that implies they cannot successfully modify its contents, or they can use a decrypted DK 7704 and encrypt the lock node's related contents but leave the eDK 7706 unaffected because the contents associated with the eDK dign are not changed. This demonstrates that only the RAT writer may be able to re-encrypt the DK 7704. When using the SDFT method, the non-RAT components of the lock node can choose to leave the original folded data containing the eDK in the parameter section and erase to preserve the unfolded structure of the DK.

[0302] The description of the variable lock and the diagram of its various logical operations illustrate how a lock node can use the first-level keyhole 6102 in input segment 6006, the encrypted key image 6010, key image 6008, variable lock 6012, encrypted derived key 6014, and / or derived key 6016 to generate a robust data structure. This data structure allows for the normalization and modularization of different locking techniques, such that replacing one locking technique with another may require some parameter 6030 to be changed and / or re-encrypted. The normalization of different locking methods ensures that the user's first-level key for the Nut remains unaffected and that a single user's first-level key can be used in many different locking techniques in different Nuts unknown to the user, and that such locking techniques can be considered suitable for protecting the payload of a specific Nut. The SDFT method is highlighted as an advantageous segment in some embodiments of such complex data structures. Some examples are provided. ORLOCK allows multiple users to gain packet access to the lock node: this can be in the form of group access or a key that may represent a master key. MATLOCK, XORLOCK, or HASHLOCK ensure that a specific number of keys exist to decrypt the packet: sensitive corporate secrets may require two specific senior executives to supply their respective secret keys to view the contents. SSLOCK requires a minimum number of secret keys to gain access to the packet: a corporate payment system may be accessed by a minimum number of authorized persons, but they do not need to operate independently.

[0303] Each first-level keyhole is partitioned using a corresponding key image. The key image may contain attributes of the first-level key, such as, but not limited to, expiration date / time, countdown timer, and / or expiration action. If any of the expiration attributes has begun, the corresponding expiration action can be set to execute after the first-level key expires. For example, a typical expiration action might be to delete the key image of the first-level key. The deletion of a key image can be attributed to its partitioning design without interfering with any other registered first-level keys on the keyhole lock node. Re-inserting an expired first-level key may no longer be recognized as a valid key because there may be no matching key image. Of course, such first-level key deletions should be carefully performed with regard to the type of variable lock used: ORLOCK and some SSLOCKs accept deletion, but MATLOCK, XORLOCK, and HASHLOCK do not, as they can create a locking condition for the lock node.

[0304] The interplay of complex data structures (which may utilize multiple cryptographic techniques for the purpose of protecting their contents in various ways and layers) can be attributed to the exceptionally large number of variable attributes required and / or generated by each cryptographic operation, posing significant challenges in implementation details. In this context, the utility and elegance of SDFT become apparent, providing convenient organizational methods and structures to help overcome these implementation challenges. For example, a single authenticated encryption of data may require storing the following attributes somewhere: key type, key length, cipher type, cipher mode, initialization vector, key ID, padding, padding type, padding length, block length, digital signature or encrypted MAC string (digest), matching key ID of the digest, digest length, digest key length, and digest method. Multiplying this by the various cryptographic operations described in the lock node specifications presented so far (lock nodes have several more components discussed in later sections) results in a continuously traversable number of attributes. In many instances, application designers and architects can recognize these predicaments and challenges and choose to simplify the coding process by selecting a small number of cryptographic methods and associated attribute values ​​and using them globally throughout their implementation. Such simplification can lead to undesirable consequences, such as, but not limited to, less security, less flexibility, fewer features, more incompatibility, and computer code that is more difficult to maintain or modify.

[0305] hierarchy Figure 78 A block diagram (lock diagram) 7800 illustrates the purpose of hierarchical keys in the Nut. Each lock node in the Nut section 7804 can be assigned a hierarchical ID. Lock nodes 7820 to 7824 are hierarchical ID "A", lock node 7826 is hierarchical ID "B", lock node 7828 is hierarchical ID "C", and lock node 7830 is hierarchical ID "D". The hierarchical designation can be arbitrary but can follow a grouping pattern in terms of privacy sensitivity, along with the various Nut sections: the deeper the hierarchy, the more sensitive the data contained in the lock node can be. Through the precise use of hierarchical access control (SAC), we can implement gradient opacity in the Nut. For illustrative purposes, Figure 78 The hierarchical IDs described are simple letters, but can actually be any identifiable string group, such as, but not limited to, numeric IDs (as in the example from...). Figure 55 (In the actual unique ID).

[0306] Any lock node, including the Nut lock 7802, can be assigned a level. When the keyhole lock node of the Nut 7806 is properly unlocked or disassembled, it can reveal a key image 7840 (similar to) that may include up to three key groups 7842. Figure 62This section can focus on level keys 7850 (6212) and how they can operate within the lock graph. In this example, we can find four level keys 7852, 7854, 7856, and 7858, which can correspond to levels "A, B, C, and D" respectively. Each level key can be stored in the level key 7850 section with an associated level ID. We can follow... Figure 79 The flowchart presented in the diagram illustrates how the keys at each level can be used. Once some or all level keys have been inserted into the first-level keyhole of their matching lock node, the process is complete and we can wait for the traversal of the lock graph to continue beyond Nut lock segment 7802.

[0307] Level keys can be used in conjunction with MATLOCK variable locks, as shown in some or all of the lock nodes in section 7804 of the Nut part. When using the SDFT method, MATLOCK can be indicated by the "lockmatlock" transition in the preferred TAR of the section involved. Each level key can be a lock node under discussion ( Figure 79 The *) in the MATLOCK is the mandatory key. If the lock node output connection key or hierarchy key is missing, a specific lock node may not be unlocked according to the definition of MATLOCK. Therefore, it may be impossible to open some or all deeper levels beyond this level. By controlling which hierarchy keys can be stored in the key image 7840 of the first-level key, the Nut owner can explicitly control how far someone can penetrate the lock graph 7860. The hierarchy access control layer can work independently of the Nut access control layer and can work in conjunction with variable lock methods.

[0308] The methods that SAC and keyholes can perform suggest that if multiple keys can be presented to a keyhole lock node (such as 7806), then multiple key images 7840 can be displayed and possibly multiple hierarchical key groups 7850 can be inserted into various lock nodes. The hierarchical key for a single hierarchical ID can be the same key; therefore, inserting the same key into a lock node that can utilize MATLOCK results in a key being inserted below that ID, essentially allowing the same key to be overwritten multiple times in the keyhole. This can be considered an additional access attribute property of hierarchical keys.

[0309] Both hierarchical keys and Nut access control (discussed in the next section) can exhibit an additional access attribute property or characteristic. Inserting first-level keys with different access levels into the first-level keyholes of a lock graph results in an access level of the lock graph, which can represent the combination or union of the access levels of all validly inserted first-level keys. A powerful use of this property is to distribute the keys of a given lock graph in a segmented manner, where combinations of first-level keys may be needed to obtain a very specific access level for the lock graph. This can be the opposite of an operational mode where the first-level keys can represent a complete picture of a given access for the key holder.

[0310] Nut Access Control Nut access control, or NAC, is an access control method that uses cryptographically compiled data structures that can operate independently of mutable locks and hierarchical access control. NAC can use a combination of role-based access control (RBAC) and cryptographically compiled access control (CAC), which we may refer to as role-based cryptographically compiled access control (RBCAC) or key-based authorization (KBP). NAC attribute key sets can be localized as internal components of a single lock node; however, a mechanism can exist within a lock node to propagate NAC attributes along the rest of the lock graph, allowing key holders to have a consistent level of access across associated lock nodes. These NAC attributes can be found in a keyhole lock node where a first-level key can be inserted from an external source for unlocking or dismantling. Similar to hierarchical keys, NAC keys can exhibit an additional access attribute property.

[0311] KBP can be deployed using well-known properties of public-key cryptography, such as generating digital signatures (dign) and asymmetrically authenticating them on a data string using an algorithm (such as RSASA-PSS (with an appendix based on the parasitic signature scheme originally invented by Bellare and Rogaway) or an alternative algorithm). The basic premise of KBP is that a private / public key pair is provided, the private key holder (writer) can use the writer's private key to generate a digital signature (dign) on a data packet, and then the public key holder (reader) can use the writer's public key, which is possessed by the reader, to authenticate the dign generated by the writer on the data packet. If authentication fails, something, such as the public key, the data packet, or the dign, or some or all of them, can be compromised. The writer is responsible for generating an updated dign on the target data packet after each modification, and the reader is responsible for authenticating the dign and the target data packet before "reading" or decrypting the data packet. This process reasonably ensures to the reader that they can read something that has been created or modified by someone (the writer) who possesses the corresponding private key. In Role-Based Cryptographic Compilation Access Control (RBCAC), each defined access role can have an asymmetric key pair, and the "writer" of the role has access to the private portion of the key while the "reader" of the role has access to the corresponding public portion of the key. By separating datasets by function and dignifying each functional dataset using different key pairs, access roles can be precisely defined and can be assigned to each key holder by distributing appropriate portions of the key. NUTS' RBCAC allows one or more symmetric keys to be coupled with the asymmetric key pair of the defined role to provide an additional layer of control over the target dataset. The holder of the coupled symmetric key can decode and read the target dataset for that role. This coupled symmetric key can encrypt the target dataset on top of the encryption using the symmetric key revealed by the unlocking of a variable lock in the eKS and subsequent keys. Alternatively, the presence of the coupled symmetric key can replace the use of the encryption key revealed from the eKS and can be the unique key for symmetrically encrypting the target dataset. This alternative may be better for larger target datasets because they will be encrypted no more than once. The coupled symmetric key can be used to control read access to a target dataset.

[0312] In NAC implementations, the use of SDFT can significantly simplify coding. Encryption and dign can be embedded into a logically cohesive TAR suitable for the functions to be performed, and the SDFT decomposition process can automate much of the detailed processing of such operations. Any localization attributes associated with a TAR can be folded together with the target data or further folded with another TAR to simplify its protection and storage.

[0313] Figure 80The table illustrates how key-based permission can work with three defined roles (readers, writers, and verifiers) and five role players (A, B, V, X, and Y). All role players possessing the coupled symmetric key S have the ability to encrypt or decrypt data using symmetric key S. Writer classes (COW) X and Y have the ability to generate a dign on encrypted data using an asymmetric private key R. When using an asymmetric public key U, reader classes (COR) A and B have the ability to verify the corresponding digital signature generated on encrypted data by someone from the writer class, and they also have the ability to decrypt the data using symmetric key S. Therefore, the ability to generate a valid dign implies that you have the ability to modify data, and all other readers can verify that a dign was generated by a valid writer. The number of defined roles depends on the granularity of access control desired by the owner, but some or all of the defined roles can utilize... Figure 80 The method described herein. A role player possessing only the asymmetric public key U can be called a verifier; a verifier may have the ability to traverse the entire Nut but may not be able to decrypt the target data corresponding to the role category. For example, a COR verifier may only authenticate that the Nut's payload has been appropriately modified using a COW public key on dign by an appropriate COW role player, but it cannot decrypt the payload because it does not have a copy of the decryption key S.

[0314] NAC can precisely influence and control visible and modifiable content, thereby locking the content of nodes and the content of Nuts. Figure 81 The table shown lists some parts of Nut, but may contain more or fewer parts than expected: hair, tick, seal, vita, face, tale, and / or bale. Positive references to Nut logs and Nut history may exist in the table, which will be detailed in subsequent documents. Each column can represent a lock node and specifies that the data for the Nut portion can be kept in the packet of that lock node. The column titled "Packet Opacity" displays the ciphertext pattern of the packet of the lock node, which can be controlled by the lock node's metadata. Packets can be encrypted or not (explicitly) based on metadata settings known as packet opacity. Figure 81If some or all of the Nut portions in the table exist in a given Nut, then the Nut portions, which can be represented by lock nodes, can be linked sequentially from top to bottom using lock node link pointers and link keys. The process of traversing the columns of this table downwards relative to the packet opacity of each Nut portion is called the gradient opacity of the Nut. The holder of the appropriate external first-level key can gain access to the Nut by eventually unlocking the variable lock of the lock node. Depending on the SAC settings of the first-level keys, key holders can be limited to how far they can traverse into the Nut. NAC can affect which first-level keys are allowed to read, modify, and / or authenticate each Nut portion through careful placement of coupled symmetric cryptographic keys, precise use of asymmetric key pairs, and the use of digital signature methods.

[0315] Figure 82This table lists the key-based permitted access roles defined for and used with a typical Nut. Access roles are not limited to this list, as more or fewer access roles may exist depending on the needs of the Nut owner. The table lists four segments of the Nut, which can be identified, but are not limited to: Bale, Vita, Tale, and All. The All segment can refer to anything not explicitly covered by another access role. This may require some or all of the lock node's internal work, such as, but not limited to, dign, eDK, and / or encrypted packets not specified by key pairs representing a separate access role. For this discussion, key pairs may include asymmetric key pairs and coupled symmetric keys. The presence of coupled symmetric data may depend on the presence of the access category verifier role. The holder of the All private key may be referred to as the RAT (Root Access Layer) or the Nut owner. Each Level 1 key may have a key image, which may contain a copy of the RAT reader's public key for authentication purposes. Bale may be maintained in a packet (such as a file) of the lock node that holds the Nut's payload. This key pair is specifically named the Writer Class (COW) and Reader Class (COR) due to its frequent use. This key pair controls which first-level key has the ability to modify the Nut's payload. Similarly, the Nut log can be maintained in a packet within the Vita portion of the Nut and can be controlled by a logger / log reader key pair. The Nut history can be maintained in a packet within the Tale portion of the Nut and can be controlled by a history recorder / history reader key pair. The authenticator role for each access role category can have access to at least one public key associated with that role to authenticate the associated dign. An authenticator role may imply the existence of coupled symmetric keys associated with access role categories it does not have access to. The maintenance process can be given access to a defined combination of authenticator roles within the Nut to check the validity, consistency, and / or authenticity of the Nut portion but cannot read the contents of protected data. Key pairs are not limited to these settings and can be expanded or reduced based on requirements. Any encrypted and / or unencrypted string on a lock node may have a dign generated on it by its own specific key pair, and all lock nodes in the lock graph may adopt this level of specificity, which may result in an extreme level of access control granularity; however, this extreme level of access control granularity may weaken the effectiveness of access control over this Nut.

[0316] The parameter section of the lock node specifies the applied digital signature algorithm and the length of the asymmetric key (defaulting to a minimum of 2,048 bits for RSA-2048). Alternatively, SDFT usage allows specific TAR representations to have these preferences, and the TAR tag can be stored alternatively in the parameter section. The encrypted packet of the lock node, which can retain the payload of Nut, can be digitally signed not by the RAT writer using the RAT writer key, but by a key holder (which may include the RAT writer) with COW access. A first-level key holder can be granted access to the RAT reader key via their access key setting and corresponding access attribute propagation key (AAPK) in their key image of the keyhole lock node; this RAT reader key allows any legitimate first-level key holder to authenticate any dign within the lock node in the RAT-authorized domain (exemplified by a first-level key holder with access to the RAT writer key). Any failure to authenticate any RAT dign may indicate that the corresponding string or folded data has been compromised, or that the RAT reader key may be invalid, or that the first-level key may no longer be valid, or some or all of the aforementioned reasons. This application may display this warning and may not continue the process because the integrity of the nut may have been compromised and further decryption attempts may fail or result in the exposure of compromised data.

[0317] Figure 83 This demonstrates how Nut obtains its initial NAC access key set. Starting at keyhole lock node 8300, a first-level key 8304 can be inserted into a first-level keyhole 8306 and can decrypt or unfold an encrypted key image, which can display a key image structure 8310. An access key set (AKS) 8312 can exist, which may contain a set of keys consisting of a symmetric access attribute key set unlock key (AAKSUK) 8314. Each individual AAKSUK symmetric key can correspond to, as shown in... Figure 82The table shows the access roles. Each AAKSUK in the AKS can then be inserted into the access keyhole 8320 in the same input segment 8302 of the same lock node 8300 as the initial first-level keyhole 8306; thus, the key map 8310 can hold a set of keys in the AKS 8312 that can feed its own access keyhole 8320. This may be a special property of keyhole lock nodes (outward-facing lock nodes) and may not be applicable to internal lock nodes in most cases. In the access keyhole 8320, each appropriately inserted AAKSUK 8314 can be decrypted or expanded to reveal the corresponding Access Attribute Key Set (AAKS) 8330, which includes the access role description 8332, the access role key (ARK) 8334, and / or the access attribute propagation key (AAPK) 8336. The ARK 8334 can specify the key pair portion corresponding to the given role: public (reader) or private (writer). AAPK 8336 can be a symmetric key for AAKSUK that can serve as an access keyhole to the next linked lock node. A group of AAKSUKs can form a set of AAKS, which can define the NAC access attributes of the first-level keys and ultimately their access in the lock node. In this diagram, AAKS 8330 can define the access attributes of the Nut owner because it contains the RAT private key and the COW key. The additional attribute properties of AAKSUKs (and thus the additional attribute properties of NACs) can be illustrated in this diagram; each first-level key 8304 can exist in AKS 8312, which can be inserted into the first-level keyhole 8306, so each insertion of AAKSUK 8314 into the access keyhole 8320 can be additional. The same AAKSUK can be overwritten only through the access keyhole, which can result in the union of unique AAKS when some or all of the presented first-level keys have been processed. This can result in a cumulative access attribute effect when first-level keys with different access attributes can be inserted simultaneously.

[0318] Figure 84This diagram illustrates how AAPK can be used to propagate NAC attributes throughout the rest of the lock nodes in the lock graph. A keyhole lock node 8400 may have been properly unlocked and some or all of the AKS 8402 may have been inserted into the access keyhole 8404, resulting in AAKS 8420. The access attribute propagation key (AAPK) 8424 can then be inserted into the next connected lock node's access keyhole 8432. It should be noted that this is similar to how access keyholes of keyhole lock nodes that are already filled are obtained, but these keys come from a connected lock node rather than from an AKS that may or may not be found in its own first-level keyhole. The first-level keyhole (not shown) of an internal lock node 8430 may have an empty AKS in the key map, except for the RAT access level key. By following this propagation method, the access attributes of the first-level key can exist in every unlocked lock node in the lock graph. Lock nodes can isolate and localize some or all of their internal control mechanisms, such as having different sets of AAKS generated within the lock node for its own purposes, even if the access roles are the same (e.g., COW). Even the AAKSUK and AAPK symmetric keys can be different, as long as they can be properly mapped. This can be a prerequisite for a well-defined Nut to allocate a complete set of AAKS to the RAT for the entire lock node and for lock nodes that are properly propagated throughout its lock graph. For reference, there can exist a complete set of AAPK and ARK, which can be encrypted by the RAT public key and stored in the lock node's parameter section, so that only the RAT can reveal this set when another lock node needs to be encrypted.

[0319] Figure 85 The diagram illustrates the propagation of access attributes using AAPK from an external lock node 8500 to an internal lock node 8530. It shows where various keys can originate to feed through the first-level keyhole 8550 and access keyhole 8560 of the linked node. Output section 8510 can display a linked symmetric key 8512 for the first-level keyhole 8550 of the linked lock node 8530. AAPK 8522 can be inserted 8524 into the access keyhole 8560 of the linked lock node 8530.

[0320] Figure 86 The flowchart for inserting a key into an access key hole is shown, which can be described in detail using the examples in the previous section.

[0321] Figure 87 A key-based permission table is shown for use in an alternative embodiment. This table can be further defined by a written asymmetric key pair (U... W ,R W ) and a symmetric key S for encrypting each item's data n And expansion Figure 80 The table presented in the document. (Source: [Insert Source Here]) Figure 80The three keys can be alternatively represented as a dign asymmetric key pair (U D ,R D The key R is a pre-defined symmetric key for data encryption. Additionally, the key allows ARK to restrict access to a write-only role, which can write to a packet in a lock node but cannot read any other part of that packet. The write-only role can have access to the key R. D U D U W and S n The visit. When the only character wants to send message T n When saved to the lock node's packet, it can generate a singleton symmetric encryption key S. n Encrypting T n This generates an encrypted message E. n Next, the singleton symmetric encryption key S n It can be used with key U w Asymmetric cryptography is used to encrypt and generate the encrypted key K. n E n and K n Both can now be stored within the lock node's package. Only the write role can also use R. D The key generates a dign and stores it. Message authentication can be performed alternatively or separately by authenticating the appropriate SDFT TAR sequence, which can be embedded and automatically folded for compactness and organizational simplicity. Such TAR sequences allow for alternative message authentication methods using any cryptographic MAC transformation. Once a write-only actor has completed writing and may destroy the SDFT TAR sequence, the message authentication is lost. n In the memory instance, the role-player may no longer have access to the decrypted message E. n S n Access to the key is restricted because the write-only role may no longer possess the asymmetric private key R. W Only these individuals might possess the asymmetric private key R. W Access roles to the copy (such as reader and writer roles) can decrypt the encrypted key K. n To obtain S n And it can be used to process encrypted messages E n Perform the operation to obtain the original message T n The authentication method may additionally incorporate hashing or dign linking, similar to how Merkle trees work, for a more efficient authentication process involving payloads comprising several separate messages. Write-only access may not prevent unauthorized truncation or overwriting of previous messages on lock nodes operated by the local system; however, the NUTS ecosystem can help prevent or highlight such occurrences through various collaborative methods by combining its Nut history, replication, and synchronization features. This will be discussed later in the section on Nut servers and revision control modules.

[0322] Depend on Figure 87 The limited capabilities of the write-only and verifyer roles presented in the table can help mitigate some of the problems associated with the pervasive "god key" problem in computer system security. This can be a well-known problem category where, in one scenario, a system administrator can be granted a "god key" or all access authentication to a system or group of systems for maintaining, updating, repairing, installing, and / or troubleshooting one or more systems at hand. Industry tends to automatically associate technical capabilities with enhanced security investigations, attributing this to a relatively small number of highly capable and experienced system administrators with appropriate security investigation checks. This type of practice may fail to handle the dynamic nature of trust relationships, where the level of trust between two parties may change unilaterally over time, potentially undetectable to others or intentionally hidden from them. Through the careful use of write-only and verifyer access roles, payloads can be protected against unauthorized access to data in transit or idle. The application of these two access roles allows organizations to decouple the combined nature of technical capabilities and security investigations for more appropriate and independent full management of all aspects. The write-only role allows people and processes to add evidence of disposal to Nut's logging components but may not allow them to read the payload or edit the log. Additionally, the write-only role can have access to the flag key and can generate and verify the authentication string. The verifyer role allows people and processes to check Nut's internal consistency and authenticity but does not allow any access to the payload. Lock nodes can be systematically modified, adapted, and inserted into any database system (such as, but not limited to, NoSQL or RDBMS) to achieve this granularity of access control at the field, record, table, and / or database level. Compactness, flexibility, features, and / or independence allow lock nodes to exist in computerized devices, such as embedded access gateways within the device itself. This will be discussed in more detail in a subsequent section on the Internet of Nut.

[0323] NAC characteristics can encompass a complete set of actions that can be performed on a target payload. A simple cross-reference matrix of permitted actions, along with its NAC implementation, can be illustrated as follows:

[0324] Reader and writer roles may have the implicit ability to examine or authenticate digns contained in the lock node's packet.

[0325] Three protection methods for lock nodes are summarized: variable locks, hierarchical access control, and / or Nut access control. Variable locks primarily protect packets that can be used to carry data content within the lock node. Hierarchical access control limits how deep a user can penetrate into the lock layer hierarchy. Nut access control specifies which parts of the Nut can be modified, viewed, written to, and digitally signed by a user. Some or all of these layers can be controlled by embedded or folded key sets within the lock node's keyhole mechanism. The keyhole mechanism can be a flexible entry point, allowing the insertion and processing of multiple cryptographic keys for various functions. Some or all of these components can work together and / or separately to provide a rich set of access controls that can be customized on a per-Nut basis and modularly constructed to exhibit the locking behavior expected of the protected content. The modularity of lock nodes also provides simplicity in building many complex locking structures due to their iterative, compact, and modular design. While many different algorithms can be used to fully unlock and exploit Nut, the initialization mechanism information can be represented by a portion of encrypted data that can be fully stored within the lock node of Nut. Therefore, its access control mechanism can be portable and can operate independently of any external reference monitor along with its payload. These mechanisms can be further embodied by various SDFT methods and structures to help simplify implementation and better manage the complexity of internal coding and / or data details.

[0326] Nut's access control model can be a combination of mandatory access control (centralized), arbitrary access control (user-centric), and other access control methods. It can resemble an arbitrary access controller model, allowing it to store some or all of its access attributes internally and enabling the owner to directly set the access level for each Nut to promote transportability. It can also adapt to some or all arbitrary access control models and be integrated into some or all such environments, thanks to the flexibility provided by its keyholes, mutable locks, and other mechanisms. Furthermore, it can exhibit other features such as, but not limited to, gradient opacity, additional access attributes, and / or modular lock node connections (which may be novel to Nuts).

[0327] Lock node traversal Now we can traverse the entire lock node and see how things can be revealed along the path. Figure 88 This diagram depicts a simplified representation of the decrypted data flow within a lock node 8800. Components of other diagrams involved in this interwoven and integrated depiction of the lock node unlocking process can be referenced, such as... Figure 62 , Figure 78 , Figure 83 , Figure 84 , Figure 85 and Figure 88The same lock node segment may be referenced by different views of the same segment tested in a deep exploration type, numbered by different component symbols. The order of logical operations required during lock node unlocking can be further optimized for efficiency and / or other purposes. The process of unlocking the lock node, thus resulting in a lock graph or Nut, may involve steps that can be described in this example, such as, but not limited to: obtaining access to the lock node and a decryption key using a first-level key; authenticating the lock node; propagating access permissions throughout the lock graph; performing logical operations on the variable lock and / or decrypting the stored data; these steps may be expanded, reduced, or reordered as needed. Where appropriate, certain mechanisms within the lock graph and lock nodes may benefit from the proper application of the SDFT method.

[0328] First-level keys 8804 can be inserted into input segment 8806, and each first-level key can use its associated cryptographic method to attempt to decrypt its matching encrypted key map 8810 and expand it into a key image structure 8808. Each key image 6240 can generate a master key 6210, which can be used by the variable lock 8812. Within each key map 7840 (equivalent to 6240), there may be a set of hierarchical keys 7850, and each hierarchical key (such as 7852 to 7858) may be inserted into a matching hierarchical lock node (such as 7820 to 7830) of the lock map in the first-level keyhole 8306 of its respective input segment 8302 (in this example, hierarchical keys such as 7852 to 7858 may be equivalent to the first-level keys in 8304); the hierarchical specified lock node such as 7820 to 7830 may employ MATLOCK, which may require the minimum of two keys to open it: the hierarchical key such as 7852 and the output link key such as 8512 can be found in the output segment 8510 or 8826. For a keyhole lock node 8300, within each key map 8310, there can be a set of access attribute key group unlock keys (AAKSUK) 8314, referred to as access key group (AKS) 8312, and each AAKSUK key can be inserted into the access keyhole 8320 of the input segment 8302 of the current keyhole lock node 8300. Once a set of access attribute propagation keys (AAPK) 8336 can be obtained in this way, they 8522 (equivalent to 8336) can be inserted into the access keyhole 8560 of the next connected lock node 8540. Now we can have an access attribute key group (AAKS) 8332, which may contain access role keys (ARK) 8334. ARK can define the access role of the first-level key 8304 of the entire lock graph. Such ARK can be used to authenticate the dign of various lock node segments such as 8840 to 8848. The dign of lock ID and metadata 8840 can be authenticated using RAT public ARK 8344 (which can be the public portion of a RAT asymmetric key pair, as described in the NAC specification) and the authentication algorithm specified in segment 8830. For authentication, segment 8830, along with the corresponding dign 8840 and RAT public ARK 8344, can be submitted to the authentication algorithm. If authentication fails, segment 8830 may have been compromised, and the lock node unlocking process may produce an error and may be halted. If authentication is successful, each dign of the encrypted key map 8842 can be authenticated for each encrypted key map corresponding to a valid inserted first-level key. For authentication, each eKM 8810 string, along with the corresponding dign 8842 and RAT public ARK 8344, can be submitted to the authentication algorithm. If authentication fails, the eKM may have been compromised, and the lock node unlocking process may produce an error and may be halted. If all appropriate eKMs have been successfully authenticated, then each dign of the encrypted derived key 8844 can be authenticated.For authentication, each eDK 8814 can be submitted to the authentication algorithm along with its corresponding dign 8844 and RAT public ARK 8344. If authentication fails, the eDK may have been compromised, and the lock node unlocking process may generate an error and stop processing. If all appropriate eDKs have been successfully authenticated, each dign of the encrypted key group 8846 can be authenticated. For authentication, each eKS 8818 can be submitted to the authentication algorithm along with its corresponding dign 8846 and RAT public ARK 8344. If authentication fails, the eKS may have been compromised, and the lock node unlocking process may generate an error and stop processing. If all appropriate eKS have been successfully authenticated, each dign of the encrypted packet 8848 can be authenticated. For authentication, each eBag 8822 can be submitted to the authentication algorithm along with its corresponding dign 8848 and COR ARK 8348. If authentication fails, the eBag may have been compromised, and the lock node unlocking process may produce an error and halt processing. If all appropriate eBags have been successfully authenticated, the lock node can be considered fully authenticated. Note that the eBag can be authenticated using the Reader Class (COR) access role key 8348. This applies to lock nodes that hold the Nut payload, but for lock nodes that hold Nut metadata in their packets, the RAT exposed ARK can be used alternatively for authentication. Next, based on the variable lock type indicated in the lock node's parameter section 8830, an appropriate variable lock algorithm 8812 can be attempted for each encrypted derived key string (eDK) 8814 using the set of primary keys 7844 from key image 8808. Successfully unlocking the variable lock 8812 by decrypting the eDK 8814 can result in one or more derived keys (DKs) 8816. Each derived key can decrypt the corresponding encrypted key group string (eKS) 8818 stored in parameter 8802. Decrypting the eKS produces a corresponding key group 8820 structure, which holds the output section 8826 structure and the packet key. One or more output linking keys found in the key group 8820 structure can be stored in the input section 8826 and can function as keys that can be inserted into the first-level keyhole of the linked lock node 8530 (if present). The packet key can be decrypted using an appropriate cipher to the encrypted packet string (eBag) 8822 stored in the parameter section. The decrypted packet holds data such as, but not limited to, the payload of the Nut (lock graph), metadata about the payload, metadata of the Nut, metadata of the packet, and any combination of these and / or other data. The packet metadata can indicate whether the packet 8824 holds the Nut portion or the Nut payload. If the package retains a Nut section, it can indicate which Nut section it can represent, along with other appropriate Nut section metadata and / or other data.If the package holds the payload of Nut, it can indicate whether the stored data can be actual data or a reference to it, and if so, what reference type it can be, what kind of reference it can be, and / or where it can be located.

[0329] This series of steps can be repeated for each lock node in the lock graph in order to unlock the Nut. Figure 89 This section presents a general flowchart for unlocking Nut. Most steps have been detailed in previous examples, but some require further clarification. Step 8902 - Organize lock nodes into appropriate traversal levels: Since lock nodes can be stored in a list-type structure in a column-based manner, the actual topology of the lock graph can be extracted and constructed using the link information stored within each lock node. Once the graph is constructed, one or more additional passes can be performed to appropriately allocate graph levels so that lock nodes can be traversed in the appropriate sequence. Step 8908 - Hint some or all passphrase-based keyholes: During the processing of an input segment, if a passphrase-based keyhole encounters an empty key (passphrase), it can hint at the passphrase. This default behavior can be modified to call another function or bypass any empty passphrase keyhole. Any logical step or procedure in the flowchart may contain errors that can occur and cause the process to stop, and these are not specified in detail because this is a higher-order flowchart: for example, any procedure attempted to operate may fail and cause the algorithm to stop. The rest of the flowchart can follow the path of the previous instance.

[0330] Figure 90This diagram illustrates how a NUTS-based system can open files contained within a Nut. A positive reference is introduced: the Nutbook 9000 can be a data collection organization application that uses Nuts and can essentially act as a personal PKI when it comes to storing and organizing a collection of passcodes, password keys, and / or certificates. File symbols such as 9002 and 9004 can be used throughout this diagram to represent Nut files. A primary Nutbook access key, Nut 9002, can exist within the Nutbook system, which can be unlocked to obtain a minimum level of functionality from the application. The key can be stored within Nut 9002 and may be referred to as the primary Nutbook key, and the unlocking mechanism within Nut 9002 itself may include a passcode. A hierarchical key relationship can exist between the primary Nutbook key 9002 and the file access key 9004, such that access to any file that holds the Nut in this configuration may require a file access key. Therefore, the hierarchy can be configured to require the primary Nutbook key 9002 to open and access the file access key 9004. The Nut holding the file access key may have Nut ID #33 9016. Therefore, the key that can be stored in payload 9020 may be called Key ID #33: both the file access key and the Nut ID holding it can be referred to by the same ID, in this case #33. File 9040 may be stored in Nut 9030 with Nut ID #44 9036. Similarly, the file may be called file #44. When a user decides to open file #44, one of the keyholes in the first-level keyhole 9032 may specify that it may require Key ID #33 to open it. Nut #33 9004 may be requested from the NUT book and opened in order to open it; Nut 9004 may need to be opened. To open this Nut, Nut 9002 may need to be opened. It is assumed that the user may have initialized their NUT book using a passphrase for Nut 9002 and that the NUT book may have cached the main NUT book key in memory. Next, opening the Nut 9004 requires only a separate password for file-level access to the NUT book, and once it can be opened, a cascading unlocking process can occur to ultimately reveal the decrypted file #44 9050. The NUT book can cache file access keys for a limited amount of time to expedite file retrieval during a session, but certain events (such as inactivity, hibernation, screen lock, timeout, and / or explicit lockout) may require a password to re-enter file access. This section introduces the NUT book application and the concept of hierarchical passwords, which will be discussed further in a subsequent section. The series of steps required to open a single file can be numerous, but some or all of the logic employed can be based on lock nodes and their iteration procedures, and much of it can be hidden from the user. The end result is that data can be stored in the Nut 9030, and its security can be consistent in some or all environments.

[0331] Figure 91The diagram illustrates a common use of the terminology NUTS to refer to the payload of a Nut by maintaining its Nut ID. Here, we show how a keyhole 9124, labeled key #33, can actually locate a Nut 9110 with Nut ID #33 9112, and it can be expected that Nut #33 will remain a single key 9114 that can be inserted into keyhole 9124. It may be of interest to note that in many of these diagrams and examples, if the Nut can be stored in a file, then in most operations, the filename of a Nut file is rarely referred to.

[0332] The next set of figures illustrates various exemplary embodiments of lock graphs, highlighting the flexibility and expressiveness of lock node and lock graph models using variable locks and lock node connections.

[0333] Figure 92 A simplified embodiment of the receiver locking model is shown in the following list: any key 9210 can unlock ORLOCK lock node 9220, which leads to a lock node carrying a payload 9290 containing the Nut. It should be noted that, for simplicity, the lock node can be graphically represented as a padlock, but in reality, it is a fully functional lock node capable of storing some metadata about the Nut.

[0334] Figure 93 A simplified embodiment of the ordered locking model is shown: key 9310 may be presented first, followed by key 9320, which allows access to the payload 9390 of Nut. MATLOCK lock node 9312 may require a single key, while MATLOCK lock node 9322 may require both key 9320 and a connection key from lock node 9312.

[0335] Figure 94 A simplified embodiment of an ordered locking model with a master key is shown: key 9410 can be presented first, followed by key 9420, which allows access to the payload 9490 of Nut. Alternatively, master key 9430 can be presented directly to ORLOCK lock node 9432, which allows access to the payload 9490. ORLOCK lock node 9432 can allow either the chain key or the master key to unlock it.

[0336] Figure 95 A simplified embodiment of a locking model with a master key is shown: key 9510 or master key 9520 can be presented together or separately, which allows access to the payload 9590 of Nut.

[0337] Figure 96A simplified embodiment of a locking model with a master key is shown: key 9610 or master key 9620 can be presented together or separately, which allows access to the payload 9690 of the Nut. The MATLOCK bit in lock diagram 9632 can indicate that there may be some level of control at the location of this Nut, and it may be a Nut portion that stores some Nut metadata.

[0338] Figure 97 A simplified embodiment of the secure safe deposit box lock model is shown: key 9710 and bank key 9712 can be presented together, which allows access to the Nut payload 9790.

[0339] Figure 98 A simplified embodiment of a secret-sharing locking model with a master key is shown: From a set of keys 9810, several keys that satisfy or exceed the secret-sharing threshold can be collectively presented, which allows access to the payload 9890 of Nut. Alternatively, the master key 9820 can be directly presented to the ORLOCK lock node 9822, which allows access to the payload 9890. Key 9810 can be any combination of a passphrase, symmetric key, and / or asymmetric key, as the keyhole / key mapping structure can be hidden in the tail of the secret-sharing scheme utilized in the SSLOCK lock node 9812.

[0340] Figure 99 A simplified embodiment of a "PrivaTegrity" type locking model is shown: User key 9920 can be presented to ORLOCK 9922, which allows access to payload 9990. Alternatively, nine keys 9910 can be collectively presented to MATLOCK 9912, which allows access to Nut's payload 9990. The "PrivaTegrity" model may have been proposed by David Chaum in early 2016 for implementing text messaging systems that can securely transmit messages using keys known to their users, but may contain a collusion backdoor system that may involve up to nine different keys held by nine international jurisdictions to grant law enforcement access to a particular message if and only if all nine jurisdictions agree that the particular message is critical and legally authorizable.

[0341] Figure 100A simplified embodiment of a multi-Nut configuration is shown, where multiple payloads can be stored within a single Nut: user key 10010 or master key 10012 can access one or two payloads, depending on their hierarchical access control. Master key 10020 can be attributed to its traversal path through the lock graph and access only payload 10092. This lock graph demonstrates the flexibility of modular lock nodes and their collaborative access control layers. Separate data packets can be protected in different ways within some or all of this single Nut. If master keys 10012 and 10020 are the same, the key holder can be allowed to access two payloads.

[0342] Figure 101 A simplified example of a multi-Nut configuration is shown: any of user keys 10110 can access some or all three payloads, depending on their hierarchical access control. SSLOCK 10122's key 10120 can access only payload 10194, attributable to its lock node connection. This lock diagram illustrates the flexibility of modular lock nodes and their access control layers working together and / or individually. Separate data packets can be protected in different ways within this single Nut. The flexibility of this disclosure allows for virtually unlimited variations in lock configurations.

[0343] Figure 102 A simplified embodiment of a direct-lock model with multiple payloads is shown: this lock graph can represent a flat topology of Nut rather than the usual linear one. ORLOCK 10212 can be the node of interest because there are several ways to implement the multiple connection keys required to connect it to five different lock nodes. In one embodiment, the output segment of ORLOCK node 10212 can contain five output keys. In another embodiment, the output connection keys map to key images that can be embedded in keyholes and then propagated to the output segment. Furthermore, hierarchical keys can also play a role in determining which keys can access various nodes.

[0344] Figure 103A simplified embodiment of an ordered messaging example is shown: it can be designed to resist collusion using Nuts and relationship-based keys (RBK.-forward reference). Mr. Data 10310 can have relationships with Alice, Bob, Charlie, and Danny. Some or all participants can know each other. Their relationships can be synchronized by having relationship-based keys with each person. Mr. Data may wish to send a set of secret instructions to each person, but it may wish to read messages in a certain sequence without being able to snoop beforehand through collusion among the participants. Therefore, Mr. Data can construct specific content in each of these four Nuts. Nuts sent to Alice 10320 can be opened only by Alice because they can use the RBK grouplock between Alice and Mr. Data. 10320 can contain messages for Alice and a key K for Bob. Bob She can read her messages and can use the key K Bob Send to Bob. The Nut sent to Bob 10330 can be opened using MATLOCK, which can only be opened with two keys at a time: Bob's RBK key between Bob and Mr. Data, and the key K from Alice. Bob Internally, 10330 can contain messages for Bob and a key K for Charlie. Charlie He can read the message and can access the key K. Charlie Send to Charlie. Nut sent to Charlie 10340 can be opened using MATLOCK, which can only be opened with two keys simultaneously: Charlie's RBK key between Charlie and Mr. Data, and the key K from Bob. Charlie 10340 internally contains messages for Charlie and the key K for Danny. Danny He can read the message and can access the key K. Danny Send to Danny. Nuts sent to Danny10350 can be opened using MATLOCK, which can only be opened with two keys at a time: Danny's RBK key between Danny and Mr. Data, and the key K from Charilie. Danny The 10350 internal configuration can contain messages for Danny. He can read messages and Mr. Data's schedule to sort messages that may have been processed.

[0345] In the field of cybersecurity, the term "backdoor" can carry negative connotations in various conversations surrounding the topic. Traditionally, backdoor mechanisms may be implemented at the application level, which may have allowed free access to data processed by that application. This type of application-level access may have been constructed as a serious compromise to the security of the data processed by that application, depending on which party gains access to the backdoor entry point. The perception of compromise in such situations can be well-founded due to the prevalence of these applications primarily processing unencrypted data within their own application memory, thereby potentially authorizing access to plaintext data to the backdoor user. In NUTS, and particularly in Nut's locking model, some may observe the use of the master key as a type of backdoor to Nut; however, technically it can be quite different, as in all Nut locking models, all doors (keyholes) are front doors and require a properly cryptographically encoded key to gain access to Nut. The NUTS API or any NUTS-related application implementation may not have the intended backdoor designed at the application level. There may be several legitimate reasons for having a master key entry point that can be used with Nuts, but all such entries can be limited by a single secret key and can be directly noticed by a rough test of the input segment of any lock node. Therefore, any application attempting to install backdoor-like functionality within a Nut-related application can only do so after first gaining access to the master key of the target group of Nuts, and it can only be applied to Nuts where that master key is valid. This illustrates the flexibility, partitioning, protection, and / or resilience of the data center approach to Nut security.

[0346] In some or all access control methods in NUTS, there may be a pattern that hides a cryptographic key within an encapsulated data structure, the unfolding of which may reveal other keys that allow access to a target dataset. In the embodiments illustrated in this disclosure, most of these key hiding methods may use data encapsulation and / or data folding methods. Methods for hiding access keys may be a preference formed by the implementer or may be parameterized within each nut. These methods may include data folding, data encapsulation, attribute-based encryption, function encryption, authorization tokens from a reference monitor, or any other method that may selectively reveal a subsequent access key when the access material has a cryptographic mechanism to decrypt or unlock it. The illustrative embodiments in this disclosure may have been chosen because of their simple and straightforward mechanisms and their well-known characteristics. Other equivalent mechanisms may streamline or make certain aspects of the embodiments more efficient but may still essentially provide the same functionality, controlling access to a target dataset that can be authorized and based on access attributes independent of any reference monitor by default. Any equivalent access attributes of the display method may be replaced by methods that provide the same level of protection to the content illustrated so far as to be a nut.

[0347] This allows for inferences about the segments of the Nut container and its internal workings. The internal mechanisms can be directly embodied or embodied through the use of the SDFT method, which is easily coded and managed in this embodiment. The Nut's payload can be anything that the Nut can ultimately protect, which can be any digital data that can be stored, such as, but not limited to, text files, binary applications, image files, access keys for remote systems, executable scripts, authentication for secure computer-to-computer connections, entire databases, operating systems, links to other Nuts, streaming data, and / or text messages. Due to the Nut's ability to describe what it can hold through its rich, configurable metadata, a standard list of common file types far exceeds its holding capacity. Lock node architecture allows payloads across Nuts, thus enabling an unlimited logical container size. If solid-state Nuts-compatible chips or circuitry are available, it may be possible to transform a physical device into the Nut itself, thus allowing the device to be accessed only by the key holder. A series of such devices can constitute an entire network and internal network that can only operate with proper authentication. The flexibility of the modular lock node design allows for an unlimited variation in the locking configuration of the Nut. The following sections may describe various systems and / or methods that use Nut as the basis for secure storage to demonstrate how common services and methods can be extended, improved, and redesigned to provide capabilities that may appear to exceed the average user's capabilities.

[0348] Modular I / O Programmers may expend considerable effort ensuring that data is properly fed into a program, transformed, computed, and / or edited in its runtime memory space, and then properly and permanently stored. A negative side effect of this application development model may be the eventual degradation of file formats and their various versions. Having, owning, and controlling our own data may be a useful and desirable goal, but its purpose is whether you can properly read it. The ability to read formats, write formats, act on read data, and / or display read data constitutes some of the basic components of a typical program. Modular I / O (MIO) can be a system and / or method for modularizing this logical operation into a library of modular components that can be used by any party with access to it. A side effect of MIO can be the ability to create file format conversion modules that allow users to access past versions of file read and write routines, making older data readable. This can be called backward compatibility. A concept of forward compatibility can also be provided, but the effectiveness of this feature depends on the skill of the programmer designing the application modules. A preferred embodiment of the MIO system may have some or all modules encapsulated in Nut, thus allowing for authentication, protection, and / or access control of each module by default. Figure 104This demonstrates typical components in modular I / O. Component 10450 may be a modular I / O repository (MIOR), which may be a server program capable of storing and organizing MIO components. The MIOR may be embodied as a local and / or remote server-type application that can act as a smart cache for such modules. In other embodiments, the MIOR may have a local cache on the local device, thus better facilitating shared requests from MIO modules. A typical application 10402 capable of reading and / or writing to a file 10404 may be conceptually and programmatically divided into modules for reading the file 10406 ​​and writing to the file 10408. The file 10404 may be formatted in a specific format "A" that may be unique to application 10402. Similarly, this diagram illustrates two other applications 10410 and 10418 with corresponding data files 10412 and 10420 and their respective read and write modules 10414, 10422, 10416, and 10424, which can be stored in the MIOR 10450 in a specific format (which can be "B" and "C"). The MIOR may contain other modules that can execute different tasks or programs of the applications. Modules 10426 to 10432 are depicted as file conversion modules that can perform conversions from one file format to another as specified by their respective labels: module Convert_A_B 10426 can read data from file format "A" into the memory of an application via file read module 10406, and then it can convert the memory structure into a similar memory structure that can be generated by read module File_Read_B 10414.

[0349] Modular I / O: Read and Write Figure 105This demonstrates a simple read and write operation using the MIOR 10500. Application 10502, capable of handling files stored as file format "A", can read a file F_A 10504 formatted as "A" by requesting a file reading module File_Read_A 10506 from the MIOR 10500. Module 10506 (if found) can be transferred 10510 to App_A 10502, at which point App_A 10502 can install and execute the file reading module File_Read_A 10506 on file F_A 10504. Module File_Read_A 10506 can perform file reading on file F_A 10504 and construct an internal memory structure representing the contents of file F_A 10504. This memory structure representing the contents of file F_A 10504 can then be transferred to the calling application App_A 10502. Once the transfer is successful, App_A 10502 can continue to perform its functions using the contents of file F_A 10504, which may reside in its runtime memory space. In other embodiments, once the file contents may have been read by file reading module File_Read_A 10506 (if a facility is available), it is not necessary to transfer the memory structure to App_A 10502, thereby allowing file reading module 10506 and application module 10502 to share the same memory space.

[0350] When application App_A 10502 is ready to save the modified contents of file F_A 10504 back to file format, it can access the MIOR and request a file writing module (referred to as File_Write_A 10508) of file format "A". Upon receiving module 10508, App_A can install and use a method execution module for transferring application memory structures, identical to the reading procedure. The writing module 10508 can perform a write operation for permanent storage, resulting in a modified file F_A 10520. Requests to read and write modules 10506 and 10508's MIOR can be completed in any sequence deemed appropriate by the application developer. In one embodiment, the application may pre-request some or all relevant I / O modules before starting to ensure that some or all necessary I / O operations can be performed by the application, preventing any subsequent unexpected failures. In another embodiment, a local cache MIOR may exist via a previously fetched module of a previously run application, which can be maintained to expedite the request and fetching process.

[0351] Numerous methods exist for transferring and / or sharing memory structures between two or more logical programs with those skilled in the art, such as, but not limited to, shared memory segments, memory image files, databases, inter-program messages, binary memory dump files, and / or converted memory dumps. A preferred method for application memory transfer in MIO systems is to use converted memory dumps between programs. JSON read and write functions can be modified to recognize binary data and can automatically convert it to base64 encoding and from base64 encoding to other binary-to-text encoding schemes. Figure 106 This demonstrates the data transformation and transfer involved in a typical MIO file read operation. The MIO read module File_Read_A 10604 can read 10620 a file named F_A 10602 in format "A" into its runtime memory 10606. Therefore, the contents of file 10602 can be represented in application memory structure 10630. Application memory can be stored in JSON-compatible data structure 10606 and aggregated into text form 10610 using JSON write function calls. JSON output can be embedded in Nut container 10608 for added security, depending on the situation. Therefore, application memory 10606 can be converted and stored 10608 outside of read module 10604. Nut 10608 can then be opened and read into memory by App_A 10612, and JSON read can be performed on the data packet 10610. Therefore, the data is reconstructed into runtime memory of App_A 10614. Data transmission methods 10622 and 10624 may include, but are not limited to, command line arguments, inter-program messages, and / or (a number of) data files. The reading application and / or data processing application may be separate processes on different machines, the same machine, separate threads, or separate cores; or the application may be a single logical process on a local or remote machine with the dynamic ability to modify its runtime code in real time.

[0352] Modular I / O: Backward Compatibility Applications can undergo gradual changes over time by releasing enhanced versioning changes throughout their lifespan. Many of these versioning changes can include format changes to the stored files used to preserve user work. Historically, this has led to two problems: bloat and degradation. Bloat can become cumbersome with each version that adds backward compatibility capabilities to the production line as a result of every formatting change throughout the software's lifespan. This can involve a large number of formatting versioning changes. Furthermore, if there are other third-party or open formats that the application may wish to handle, it can lead to even greater software bloat. Figure 105 The drawing application can utilize any version of any format; if modular read and write modules are available in MIOR, files can be read and processed without any excessive bloat. Furthermore, Figure 105The diagram illustrates how newer read and write modules can be added individually to MIOR, and each application that can communicate with MIOR can now have access to additional formatting modules without any program modifications. These newer modules may be capable of reading different versions of file formats from the same application production line, or they may be compatible modules for reading and writing third-party file formats written by any party (including application developers).

[0353] Figure 107This demonstrates a backward compatibility example where the application App_B 10702 is a newer version and can use a corresponding newer format version "B" of the data file, but the user may expect to read and write an older version "A" of file format 10704. Data conversion modules such as 10708 and 10710 can be generated and stored in the MIOR 10700 for such situations. The conversion modules can be responsible for reading one format and generating another: in this example, conversion module 10708 can read an "A" formatted file and convert it to a "B" formatted file; conversion module 10710 can read a "B" formatted file and convert it to an "A" formatted file. File F_A 10704 can be presented to App_B 10702, where it can be determined that the file may be presented in an incompatible format from the metadata and the MIOR 10700 can be requested to obtain the sequence of read modules required to read "A" and generate a "B" file. The MIOR 10700 can respond to App_B 10702 by sending the following modules: File_Read_A 10706, File_Write_A 10712, Convert_A_B 10708, and Convert_B_A 10710. App_B 10702 can call File_Read_A 10706 on file F_A 10704. File_Read_A 10706 can then call Convert_A_B 10708 and transfer its memory structure in the form of "A" to module 10708. Module 10708 can then convert the received data into the form of "B" and transfer it to App_B 10702. When App_B is ready to save the modified data back to file F_A in format "A", it can then call Convert_B_A 10710 and transfer its memory structure in format "B" to module 10710. Convert_B_A 10710 can then convert its memory structure to format "A" and call File_Write_A 10712, transferring its memory structure in format "A". File_Write_A 10712 can then overwrite file F_A 10714 with its modified content in format "A" and format the file as "A". More complex examples could involve sequentially calling several conversion modules to perform iterative conversions to appropriate older format versions, or developers could add frequently used version change converter modules (such as Convert_B_F and Convert_F_B) to streamline these requests.

[0354] A simple computational diagram can illustrate software bloat: Suppose a popular application has likely undergone five major revisions, with three formatted versions across three operating systems, each with major version changes within the last 10 years. It is also assumed that each of these changes may have required different versions of the application's I / O routines. This could potentially lead to most current versions of the application carrying up to 135 versions of its I / O functionality within itself. Assuming this is an extreme case, we can understand the resulting proliferation of program code to maintain backward compatibility within an application over time. This characteristic can be called the cumbersome nature of software.

[0355] A properly maintained MIOR 10700 with a consistently updated module added to its repository can act as a historical I / O format library, allowing users to access older versions of their data files at any future time: this solves the problem of software and data format degradation. When an application is no longer produced, sold, and / or maintained, its lifespan can be drastically shortened because newer versions that allow it to run on newer operating system versions may not be forthcoming. When an application no longer runs on modern computers due to incompatibility, the data files formatted by the application can become difficult to access. Savvy users and developers have found various solutions to these problems, but these often require considerable effort and / or expertise. Using MIOR requires at least one developer who can maintain modules that can be associated with non-existent applications and who can periodically add newer versions of modules compatible with newer versions of various operating systems. This type of routine maintenance can be automated in a timely manner using automated unit testing tools and self-generated OS-type and version-appropriate modules. An updated module that can be inserted into a MIOR and has access to the MIOR can benefit from the developer's work; if a particular MIOR is accessible to everyone on the Internet, some or all users on the Internet can automatically benefit from it without the users having knowledge of lower-level problems and programs that can be invoked to automatically solve them. Software backward and forward compatibility issues can be referred to as the degenerate nature of software.

[0356] Modular I / O: Forward Compatibility Users may sometimes find themselves in a situation where they acquired, installed, and / or used an application many years ago, but haven't purchased subsequent updates to it during those years. However, the user can still run the application, but can only read and write file formats compatible with older versions of the application. The latest version of the application may have introduced a newer file format with different features at some point in the past. This situation presents two problems for the user: 1) their application version cannot read files formatted to the latest format; and 2) other programs that can read the latest format from this application cannot access their older formatted data. The solution to the first problem can be called a forward-compatible read operation, whereby the older application can directly load a set of modules from a MIOR that performs progressive data conversion, allowing the user to read files formatted to a newer version using their older program. The solution to the second problem can be called a forward-compatible write operation, whereby the older application can directly load a set of modules from a MIOR that performs progressive data conversion, allowing the user to write files formatted to a newer version using their older program. Programs built with forward compatibility in mind can use MIORs with minimal or no functional loss, making this type of transition easier and seamless. Newer features for newer format versions can be optimally mapped to less complex application constructs or simply replaced with the original data, allowing users to modify it at a later time. Figure 108 Use examples to illustrate these two different logical operations.

[0357] Forward compatibility read operation: App_A 10802 is compatible with files formatted as version "A" but the user may wish to read a newer file format "C". This request can be passed to MIOR 10800, which can respond with a sequence of modules capable of performing this regression conversion: File_Read_C 10806, Convert_C_B 10808, and Convert_B_A 10810. Module File_Read_C 10806 can read a file F_C 10804 that can be formatted as version "C". Module 10806 can then call the regression conversion function Convert_C_B 10808 and pass its memory structure to the function. Module Convert_C_B 10808 performs a conversion on the data in memory and produces a memory structure compatible with format "B" (a previous file format version applied). Module 10808 can then call the regression conversion function Convert_B_A 10810 and pass its memory structure to that function. Module Convert_B_A 10810 performs a conversion on the data in memory and produces a memory structure compatible with format "A" (the desired file format version compatible with the older application App_A). Module 10810 can then pass its memory structure in format "A" to the calling application App_A 10802, and App_A can process it. Therefore, a newer version of the file format can be read from an older version of the application without modifying the application.

[0358] Forward compatibility write operation: App_A 10840 is compatible with files formatted as version "A", but the user may wish to write to a newer file format "C" that exceeds its original capabilities. This request can be passed to MIOR 10800, which can respond with a sequence of modules capable of performing such progressive conversions: File_Write_C 10816, Convert_B_C 10814, and Convert_A_B 10812. App_A 10840 can call Convert_A_B 10812 and pass its memory structure to the function. The module Convert_A_B 10812 can perform conversions on the data in memory and produce a memory structure compatible with format "B". Module 10812 can then call the progressive conversion function Convert_B_C 10814 and pass its memory structure to the function. The module Convert_B_C 10814 performs conversions on data in memory and produces a memory structure compatible with format "C". Module 10814 can then call the file write function File_Write_C 10816 and pass its memory structure to that function. Module File_Write_C 10816 can write a file F_C 10818 that can be formatted as version "C" (the desired file format version). Therefore, a newer version of a file format can be written from an older version of the application without modifying the application.

[0359] This disclosure is not limited to the two examples shown. The conversion module may be generated to access some or all file format versions of applications on any operating system. The conversion module may not be limited to conversions within its application production line but may be written to perform conversions across different application production lines. The conversion module may include data to different formats, such as, but not limited to, file to database, database to file, file to data stream, data stream to file, file to web page, web page to file, file to cloud storage, cloud storage to file, and / or others.

[0360] Modular I / O: Display Figure 109The diagram illustrates the MIOR display module in operation. Once application App_A 10902 has successfully read data from file F_A 10904 into its memory, it can continue to use the functionality of module Display_A 10908 to display the contents of file F_A 10904 to the user. Within the display module, the functionality can vary considerably depending on the application, data content, and / or the developer's design. Some modules may be designed to use a shared memory approach, allowing the display module to directly access data in the application's memory; other modules may transfer data to the display module, which then allows it to display the data. Other embodiments of the display module may include screen formatting instructions and / or templates for displaying and potentially editing data types. This modularity of display functionality allows for the creation of customized display modules for various hardware and OS platforms, while allowing the calling program to remain relatively unchanged.

[0361] The collection directory architecture discussed later in the NUT Book section leverages the lightweight aspects of modular display. Instead of building larger monolithic applications to handle, display, and / or edit different dataset collections, the NUT Book can take full advantage of the MIOR architecture, which allows the NUT Book to be customized on a per-unit basis based on the payload type in the NUT being tested.

[0362] Modular I / O: Applications exist Figure 110In this context, the MIOR 11000 can store modular application modules such as 11022. The NUT browser 11020 (forward reference) can be an application that resembles most file and directory browsers in appearance and behavior, but it can recognize Nuts and act upon them by viewing their extensive metadata. Within Nut 11030, metadata 11002 can contain information about the types of payloads it can protect and store. When a user selects a Nut from the NUT browser 11020 and double-clicks to open it, the NUT browser can open the Nut and read the metadata to indicate which modules are needed to open the file. The metadata may contain data such as, but not limited to, application version, file format version, and / or display version. The NUT browser can then request MIOR 11004 to find applications App_A 11022, File_Read_A 11024, and Display_A 11026. The MIOR 11000 can return some or all of the modules and can be invoked by the NUT browser 11020 to the application App_A 11022. Once App_A is running, it can call File_Read_A 11024 to read the contents of the Nut payload F_A 11028, which can be stored in the Nut 11030. After transferring the memory structure from 11024 to the calling module App_A 11022, it can call the display module Display_A 11026 to display the data F_A 11028 to the user.

[0363] Modular I / O application modules can vary greatly in their maintainability and functionality: in some embodiments, they may be complex logic computation modules; in another embodiment, they may store an entire software installation package; in yet another embodiment, they may contain some or all of I / O, display, and / or application functionalities; in yet another embodiment, they may contain information including a Genesis Nut that can remotely backflush and restart the user's environment. The functionality of modular I / O application modules is not limited to these examples.

[0364] Modular I / O features (such as read, write, display, and / or applications) can be overlaid with access control mechanisms at the MIOR or container level, allowing only appropriately authorized users to access them. These access control mechanisms may include, but are not limited to, access control policies, ownership requirements, and / or DRM mechanisms for enumeration purposes. Most access controls may stem from the nature of the Nut container in which modules can be stored. As the invention is discussed in further detail, the mechanisms that can derive such MIOR requests will become clear. When a data file or its contents can be encapsulated within a secure Nut container, numerous available metadata levels can exist regarding the Nut content. This metadata can specify details of the data format, such as, but not limited to, the application version that produced it, the display version, the file format version, the size, the creation time, the last modification time, the author, the file type, and / or a summary. Environmental attributes, such as, but not limited to, the OS version, the application version, the hardware manufacturer, and / or the version, can be provided by the application opening the Nut. Given this information about the environment, the data content, and / or the requested operation, the MIOR can locate the appropriate modules and a set of modules that can satisfy the operation, or an error message as a response. These modular I / O modules can run as a single or separate program in other modes, such as on the same machine, across different machines, across different chips or cores, across networks, and running one or more logical programs on a computing device. Through these modules, problems of degradation, redundancy, adaptability, compatibility, and / or flexibility can be partially or completely resolved.

[0365] NUT History Nut containers can be constructed to store the history of a payload. The history can take the form of periodic snapshots, incremental updates, complete event sequences, or any combination of these three or any other storage methods. The form of the history can vary depending on the data type stored and the application and / or data preferences and design. The NUTS ecosystem can include methods and systems that support these data history storage modes. These three storage methods are well-established practices known to those skilled in the art. The physical location of the Nut history can be in a Nut section called the Tale (…). Figure 81 Furthermore, its opacity can be controlled by Nut RAT.

[0366] Figure 111This diagram illustrates a simplified Nut, showing the progressive changes to its history structure over three points in time across two editing sessions covering a file. At time T1, Nut 11102 retains data D1 11110, and its history can be empty at 11112. At time T2, the user can edit data D1 11110 at 11126, creating a new version D2 11114. The application can use a snapshot method, storing the original version of data D1 11110 as a snapshot in the Nut's history segment 11116 at time T1 11118. Subsequently, the user can edit data D2 11114 at time T3, creating a new version D3 11120. The application can also use a snapshot method, storing an older version of data D2 11114 as a snapshot in the Nut's history segment 11122 at time T2 11124. At time T3, history segment 11122 now holds two distinct snapshots, 11118 and 11124, of the previous version of data D3 11120. Users can freely browse and extract Nut's history 11122 at any time using a simple history extraction method, allowing for restoration or the creation of entirely new files from it. Nut metadata parameters can exist, controlling the type, frequency, and / or lifespan of history segments to set a reasonable historical growth for the data at hand. For some text files, it may be practical to permanently save some or all changes, as their size can be relatively small when using an incremental save method. This allows Nut to generate some or all saved versions of the file at any subsequent time. Binary files can be saved as snapshots or incrementally, depending on the application. Some event-driven applications can archive complete sets of event sequences as their history. It should be noted that Nut history can be saved within Nut itself and can be independent of external programs and / or storage systems. Any payload can be historically archived in this way, provided that an archiving method for the payload type available in the Nuts environment exists.

[0367] NUT Log Nut containers can be constructed to store the event log of Nuts. Because computer processes can read, manipulate, and / or write to Nuts, they can generate and leave an audit record of the logical operations performed on the Nuts within the Nuts themselves. This audit record can essentially exist on a per-object basis from the perspective of the object. Therefore, between the Nut history and the Nut log, an event chronology from the beginning of the data object can be stored in a single container for further review at later times. The accuracy, content, and / or granularity of the Nut archive can depend on the rigor and methodological purpose of these characteristics by the developers of the applications that operate on the Nuts. The physical location of the Nut log can be in a Nut section called a Vita ( Figure 81 Furthermore, its opacity can be controlled by Nut RAT.

[0368] Figure 112 This example presents a simplified diagram of a Nut, illustrating the progressive changes to its event log structure over three time points corresponding to two events occurring on the Nut. This example can be applied to Nut history continuing from... Figure 111 Example: At time T1, Nut 11102 can hold data D1 11110, and its log 11212 can hold a log entry 11218 indicating that event E1 was generated at time T1 for Nut 11102. The user can edit data D1 at time T2, which can generate a new version D2 11114 in Nut 11104. The editing application can record an event log entry to Nut log 11216 at T2, as indicated by component 11222. Subsequently, the user can edit data D2 11114 at time T3, which can generate a new version D3 11120. The editing application can record an event log entry to Nut log 11230 at T3, as indicated by component 11224. At time T3, log segment 11230 can now hold three distinct event log entries: 11218, 11222, and 11224. Users can freely browse and extract Nut's log 11230 at any time using a simple log extraction method, which allows for auditing on Nut. Nut metadata parameters can exist to control the type, frequency, and / or lifespan of log segments to set reasonable and appropriate log growth for Nut.

[0369] System administrators and application developers can understand the effort and resources involved in tracking errors on their systems when modifying data objects that may involve more than one application. This is because they may have to sift through the event logs of some or all the involved applications (if they have access to all of them), filter out event log entries for the problematic object, and then manually reconstruct those events in the sequence in which they could have occurred on the object. With Nut logs, this collection, filtering, and reconstruction of event logs can be done at the object level from the object's perspective. Furthermore, Nut's metadata can specify the granularity of the event log messages to the level of detail that the object owner can expect. This granularity can range from a concise debugging level to a detailed debugging level to allow for tracing various lines of investigation. Sensitive, top-secret payloads may require the highest granularity of event log details to perform an audit of their access history. In short, this provides a consistent and customized approach to controlling the auditable past of an object at every level of granularity required by any application. The term "consistent" can refer to the consistent design and operation of available log features, while the term "customized" can refer to the design adaptable to each object's preferences.

[0370] Relation-based key (RBK) The description of how to establish a relationship-based key (RBK) should be familiar to anyone who can manually use encryption tools: Bob and Alice may wish to communicate privately and therefore they can exchange randomly generated asymmetric cryptographic keys (only partially public) or use keys in tools such as PGP or its equivalents to exchange encrypted messages and files. Bob and Alice's protection and management of the key pairs may depend entirely on them. This can lead to the deliberate and difficult task of properly establishing, maintaining, and utilizing the relationships, which may require Alice and Bob to have basic knowledge of cryptography, its proper use, and / or key protection. This type of key exchange can occur when Bob or Alice does not have an established public key certificate via a centralized directory or a trusted website. It can also occur when participants feel that creating a completely private communication channel may require an additional layer of privacy.

[0371] If RBK is Alice and Bob's default communication method, what might happen? What could the consequences be, and what would be needed to make it happen painlessly? The establishment, maintenance, and / or use of RBK in a system can be automated. Constructively, it is helpful to explore some properties and consequences of the consistent application of RBK before delving into the details of how to systematically implement RBK.

[0372] Properties of relation-based keys ● The level of trust between two parties can be a dynamically adjustable parameter. This can be observed in any real-life relationship between two parties: trust can be relative. It can rise and fall over time based on events and communication.

[0373] ● Unilateral adjustment of trust level. Either party in a relationship may unilaterally change the trust level of the relationship with or without notifying the other party.

[0374] ● The health of the relationship channel can be determined from the message context. Either party can crack the system and key at any time. The default purpose of RBK is to allow either party to test the communication content and determine the possibility that the other party's system or key has been cracked. In the simplest case, a message from Bob without RBK encryption may be a sign of being cracked.

[0375] ● The true nature of the relationship can be assessed over time. If an abnormal message is transmitted via RBK and the sender's key may not have been cracked, the sender may have altered the nature of the relationship.

[0376] ● The loss of a relationship can be permanent, and some or all of the relationship's history may lose commercial and / or meaningful value. Unilaterally, either party can terminate the relationship by blocking its messages or erasing its RBK group. This logical operation of the relationship channel provides each user with a deterministic unilateral message blocking capability.

[0377] ● Each party may strictly adhere to the fundamental principle of mutual obedience or bear the risk of damaging the relationship—fundamental principles can change over time. Numerically speaking, a violation of implicit fundamental principles can lead to a permanent, unilateral break in the relationship.

[0378] ● It allows for a closer expression of real-world relationships in the form of digital cryptography. Public-key cryptography, in its most widely used form, can be a centralized model that contrasts with how people form relationships. RBK can be distributed and can be used in a private manner with public-key cryptography.

[0379] ● Destruction Isolation. RBK destruction on Bob's environment is isolated from Bob and the RBK channels he may have established with his contacts (i.e., Alice). Damage to Alice's environment is isolated from her and Bob's channels and their mutual history bulletins. Some or all of Alice's relationship channels are secure and cannot be compromised by hackers who destroy Bob's environment.

[0380] Personal Information Manager (PIM) is a well-known application concept in computer software. It can be broadly defined as a mixture of various functions that provide productivity and organizational tools for personal use. PIM can provide tools such as, but not limited to, calendars, address books, contact management, passcode holders, notes, email managers, chat functions, project management, key managers, calculators, task lists, and / or activity loggers. PIM can be a combination of any of these functions or may provide only a single function. PIM can be designed to operate locally in an isolated manner or only within a PIM website server or in any combination thereof. In the preceding discussion, reference to such functions of PIM (such as an address book, chat, or email manager) can be understood as the PIM providing any of these functions as its offering or as its sole function.

[0381] Figure 113This demonstrates how digital address book entries between Alice and Bob can be structured to consistently support RBK for some or all relationships within the address book. Alice's address book 11310 (which can be a feature provided by her PIM) can have two entries: one for herself 11320 and one for Bob's information 11330. In Alice's own entry 11320, she can list her basic contact data 11322 and some personal information 11324. Alice's address book entry 11320 can be stored and can be embedded as a payload in the Nut file on Alice's system. On Bob's contact card 11330, Alice can have some of Bob's contact information 11332, such as his name and email address. Bob's address book entry 11330 can be stored and can be embedded as a payload in the Nut file on Alice's system. Bob's address book 11350 (a function provided by his PIM) can have two entries: one for himself 11360 and one for Alice's information 11370. In Bob's own entry 11360, he can list his basic contact data 11352 and some personal information 11354. Bob's address book entry 11360 can be stored and embedded as a payload in the Nut file on Bob's system. On Alice's contact card 11370, Bob can have some of Alice's contact information 11372, such as her name and email address. Alice's address book entry 11370 can be stored and embedded as a payload in the Nut file on Bob's system. When Alice and Bob decide to establish an RBK with each other, they can decide to establish a private two-way communication channel between them. Alice can begin the process by generating an asymmetric key pair 11334 and 11336, storing them under Bob's address card 11330, and transmitting the public portion of key 11334 to Bob. The transmission process 11344 can be completed by a secure nut, a written message, a phone call to Bob, a message using Bob's public key known to outsiders, or any version of a secure key exchange protocol well known to those skilled in the art. When Bob receives this message containing key 11334, he can store the message in Alice's address card entry 11370 as a key 11334 to privately send the message to Alice. Bob can then generate an asymmetric key pair 11374 and 11376, store them under Alice's address card 11370, and transmit the public portion of key 11374 to Alice using the public key 11334 sent to him by Alice to encrypt the message.When Alice receives this message, she can decrypt it using her private key 11336 for Bob's messages. She can extract the internal key 11374, which she can store in Bob's address card entry 11330 as the key 11374 for privately sending messages to Bob. She can generate an acknowledgment message for Bob encrypted using the key 11374 from card 11330 and can send the message to Bob via any working communication medium. Bob can receive the message, then decrypt it using the key 11376 from card 11370 and mark his RBK group as created and interact with Alice.

[0382] The steps in establishing this RBK between Alice and Bob can be automated and initialized using a single action button or command. This forms the operational basis for how the NUT book manages its contact set, and will be discussed later in the NUT book section of this document. Bob or Alice can repeat this process individually for some or all of the contact cards in their respective address books within their PIM. Finally, each person can establish an RBK channel for each of their contacts, which can be considered a private communication channel for each person in their relationship. If Cathy is a mutual friend of Alice and Bob, then Cathy's RBK relationship with Bob can differ from Cathy's RBK relationship with Alice, and the RBK configuration can reflect this reality.

[0383] Now that we have defined the context of RBK and its systemic use, what can it do for Alice or Bob? Consistent use of RBK in sending messages between the two entities allows for monitoring of the health of their communication channels. One practical example of use is spam email reduction. It can be estimated that spam emails of both malicious and / or commercial types can consume a significant amount of global internet bandwidth and data storage capacity. We can risk assuming that not many people welcome this spam capacity. Some common methods of spam reduction include using filtering techniques based on content pattern recognition, domain exceptions, address exceptions, and / or, in practice, law enforcement to shut down rich spam servers. In a mode where RBK encryption can be the default communication method, spam can be detected more deterministically.

[0384] One of the major obstacles to automating processes such as RBK is the significant lack of user-friendly, user-accessible, and / or user-controllable personal public key infrastructure (PKI) applications. NUT books, along with the use of Nut, can attempt to fill this PKI gap. They provide a flexible, secure, and / or user-controllable method for storing, manipulating, and accessing this information in a seamless manner.

[0385] Figure 114This diagram illustrates a flowchart to reduce SPAM between Alice and Bob, who may have already established an RBK communication channel. This could be their default communication method, and they could use well-known public email addresses. If an email is sent via RBK encryption between Alice and Bob, it could be a valid email from Alice to Bob or vice versa (11414). If either person receives an email from the other that is not encrypted using RBK encryption, that email is likely SPAM and can be filtered out and stored in the SPAM frequency (11412).

[0386] Figure 115 This example illustrates a flowchart reducing the potential SPAM between Alice and Bob, who may have already established an RBK communication channel. This could be their default communication method, and it could use undisclosed private email addresses – anonymous email addresses. If an email is sent via RBK encryption between Alice and Bob, it could be a valid email from Alice to Bob or vice versa

[11514] . If either person receives an email from the other that is not encrypted using RBK, that email is likely a SPAM and can be filtered out and stored in the SPAM frequency

[11512] . This example can be assumed that this set of private email addresses can only be used between Alice and Bob to send RBK-encrypted messages to each other, thus extending the RBK channel concept to the email address level. We can limit this type of communication channel-directed email address to anonymous email addresses.

[0387] The communication channel between Alice and Bob, which consistently uses RBK via anonymous email addresses, can reveal certain characteristics that can be analyzed to determine the health of the relationship itself. We have removed some or all unencrypted SPAM messages from the channel by default, as is possible... Figure 115 As described in the text. Now we can test the context of appropriate RBK encrypted messages. Figure 116 The table lists the state matrix of the Alice-Bob communication channel based on a deterministic context. This may require a deterministic evaluation of the content by Alice to indicate what might be happening in their relationship. This also shows a unilateral action matrix for Alice, which can be based on Bob's behavior, as can be confirmed by messages Bob sends to Alice.

[0388] Figure 116 The last signs listed could create an interesting case if Bob's role could be replaced by a website vendor (i.e., Alice may have established an anonymous RBK communication channel with a vendor). Figure 117The table in the table presents a deterministic context-based state matrix of the health of Alice's communication channels with suppliers. Alice now has the ability to track whether a supplier may have sold their information to spammers through anonymous email addresses and RBK groups that are identifiable through the channel. It provides a level of transparency to the internal operations of supplier marketing departments with a clear audit trail. This type of supplier accountability can be made more systematically detailed by general users than ever before. The consequences of a supplier breaching Alice's trust can be dire, as the supplier may permanently lose the means to contact them. In effect, the appropriate and consistent use of anonymous email addresses and / or RBKs allows Alice's digital equivalent to leave the store and never return; this can act as a deterrent against suppliers abusing their clients' personal information.

[0389] Figure 118 This presents a state matrix based on a deterministic context, showcasing the health of the Alice-supplier communication channel from the supplier's perspective. Channel characteristics allow suppliers to take similar types of unilateral actions to protect their business and potentially their clients. A supplier's use of this approach may enhance its reputation for privacy and data security. It can also implicitly suggest that the supplier can operate without engaging in the wholesale, unrestricted resale of client data.

[0390] Figure 119This demonstrates how the use of RBKs can help isolate the breach of sensitive data on a user's system. Bob 11900 may have RBK channels with Alice 11910 and Dave 11920. Bob may have clicked on a Trojan horse website and become infected with a key logger or equivalent malware, and subsequently, a hacker may have been able to compromise his RBK's secure data storage (such as his NUT book). Therefore, Bob's RBK group, which contains some or all of his contacts 11900, may have been compromised. Bob may contact some or all of his friends and notify them of this breach, or some of his friends may have inferred from the SPAM messages sent to him using his private channel with Bob that Bob or his system is compromised. If we look at Alice's NUT book 11910 (where she may store some or all of her RBK groups), she may mark her RBK group with Bob 11912 as compromised, and a new RBK group may be created when Bob works together to remove the virus from his system. This allows for the extent of damage to Alice without it spreading to other RBK relationships Alice has established. This is especially true if she also consistently uses anonymous email addresses with her contacts. Alice can receive SPAM from the hacker, but SPAM can be automatically ignored when she marks the channel as compromised or deleted. When Bob is ready, Alice can generate a new set of RBKs and a new anonymous email channel, allowing her to continue her digital conversations privately. Dave's procedure is identical to his RBK storage 11920.

[0391] Anonymous relationship The digital relationship topologies and conventions that have enhanced and strengthened the internet over the past few decades can be unnatural and unreal. Anonymity can be a powerful relationship construct and a level of relationship from which we can enjoy most of our casual interactions on an everyday basis, such as, but not limited to, buying personal products at a pharmacy, buying food at a restaurant, and / or hailing a taxi for a drive. In contrast to this physical reality, almost every vendor on the internet might want to know who Alice really is, including some or all of the personal information they can obtain from her. Many vendors themselves can maintain relative anonymity by not publishing direct phone numbers and can provide services to customers through email, transaction systems, and / or remote outsourced customer service representatives at remote customer service centers. The most common use of anonymity is for people who wish to remain hidden, such as hackers. Currently, there are dummy persona generation websites for people who wish to remain anonymous on the internet, but they may have to maintain anonymity in a very difficult way and may have to make careful decisions with a dual purpose. The use of RBK and anonymous email addresses can bring a certain equality to the anonymity imbalance on the Internet to ordinary users and authorize them to have more meaningful two-way relationships with suppliers and each other without relying on fake people and accidental double nature.

[0392] Figure 120 This is a simplified illustration of a pre-packaged Nut profile. A Nut can store detailed personal information about an individual (12000). It can automate the pre-packaging of different subgroups of this personal information for various purposes. 12010 can be a simple Nut profile, which may only contain a name and email address. An anonymous Nut profile (12020) may only display an alternative email address. A shopping Nut profile (12030) may contain information fields typically required for purchasing items on shopping websites. Protection of this subset of data from the main information (12000) can be accomplished through simple rules and filters and can be generated as needed during a registration process on the Internet. Regardless of whether the supplier or service accepts the Nut profile, the information can be used to insert into the correct fields if needed by other methods. If a user utilizes an anonymous email service (positive reference), a Nut profile like 12020 can dynamically provide an anonymous email address generated for a specific relationship established.

[0393] Figure 121A diagram is drawn showing the sequence of events in an automated registration process that can use a Nut. A provider on the Internet can use and accept personal Nuts and can allow automated RBK channels to be established with its customers. Users can access the provider's website and may wish to register 12100. Users can begin the process by automatically registering to the provider's website by instructing their Nut book and entering the URL of the registration website. The Nut book can query the provider to retrieve the information required for registration 12102. The Nut book can be composed of a subgroup of user personal information that the provider can request and can display a preview to the user. The user can decide that the requested registration information is acceptable and that the Nut book has collected the relevant information and can continue the process 12104. The Nut book can retrieve and generate a pre-packaged Nut containing preview information and can send it to the provider's website. The provider can accept the registration request and can send an inquiry to the user's email address specified in the pre-packaged Nut 12106. Users may receive emails from suppliers requesting proof that they are not website bots (which may be performing tedious registrations) by directing them to a specific URL to enter a verification code 12108 or other possible verification methods. Once the verification code is successfully entered, the supplier can be assured that the request originated from a single person and can proceed to establish an automatically generated login authentication, login key, and / or RBK group with the user. The user's NUT book can automatically generate a login card for the supplier, its associated website information, login authentication, login key, and / or RBK group 12112. The registration process can be completed through user interaction at several points within the program: initialization, personal data encapsulation, viewing / editing, and / or human verification. Choosing a login name, password, entering personal information, and / or generating a password holder for the supplier can be done automatically and without prompting. When the user's NUT book is activated, they have seamless, real-time access to the supplier in a fully authenticated mode, as the NUT book automatically records this information when requested. It should be noted that this program can be completed using any supplier employing this method that may benefit both the user and the supplier. Fewer hassles for users and suppliers can be achieved by obtaining more accurate information from users' databases and potentially more transactions between them.

[0394] Figure 122A diagram is drawn illustrating the sequence of events in an automated registration process using a Nut and an anonymous email address. A vendor on the Internet can and accept Nuts and allows the use of anonymous email addresses to automatically establish RBK channels with its customers. Users can access the vendor's website and may wish to register 12200. Users can begin the process by instructing their Nut book to automatically register on the vendor's website and entering the URL of the registration website. Th...

Claims

1. A method for communicating via a network, the method comprising: Messages are processed by at least one processor of one of a plurality of computers communicating with each other via the network using a folded data method. The folded data method comprises: processing at least one input data object using a plurality of logical operations to produce at least one output data object, wherein data folding encapsulates the at least one output data object within at least one data field of a data structure by utilizing at least one essence of a sequence of multiple logical operations performed discretely on the same input data object within the at least one input data object; the at least one essence of the sequence of multiple logical operations is encapsulated within at least one command field of the data structure. The at least one output data object from the at least one data field of the data structure is configured to generate the same input data object from the at least one input data object using at least one encapsulated essence of a plurality of logical operations of the entire sequence from the at least one command field of the data structure.

2. The method according to claim 1, further comprising: At least one second processor of the second computer among the plurality of computers processes at least one output data object from at least one data field of the data structure using at least one encapsulated essence of a plurality of logical operations of the entire sequence of at least one command field of the data structure to produce the same input data object among the at least one input data object.

3. The method of claim 1, further comprising processing the message by the at least one processor using at least one second essence of an encapsulated plurality of second logical operations of at least one second command field of the second data structure received from one of the plurality of computers coupled via the network, to process at least one second output data object of at least one second data field of the second data structure to produce the same second input data object in at least one second input data object.

4. The method according to claim 1, wherein, The multiple logical operations include transformations.

5. The method according to claim 1, wherein, The at least one output data object can be stored in a computing environment.

6. The method according to claim 1, wherein, The at least one output data object can be transmitted to another computer process.

7. The method according to claim 1, wherein, At least one of the multiple logical operations in the entire sequence within the first message is different in nature from at least one of the multiple logical operations in the entire sequence within the second message.

8. A communication device for use between a plurality of computers coupled via a network, the communication device comprising: At least one processor; as well as At least one memory storing instructions that, when executed by the at least one processor, cause the at least one processor to process a message in such a way as to process at least one input data object using a plurality of logical operations to produce at least one output data object, wherein data folding encapsulates the at least one output data object in at least one data field of a data structure by utilizing at least one essence of a plurality of logical operations performed in discrete steps on the same input data object in the at least one input data object, wherein the at least one essence of the plurality of logical operations in the entire sequence is encapsulated in at least one command field of the data structure; wherein... The at least one output data object from the at least one data field of the data structure is configured to generate the same input data object from the at least one input data object using at least one encapsulated essence of a plurality of logical operations of the entire sequence from the at least one command field of the data structure.

9. The device according to claim 8, wherein, When executed by the at least one processor, the instructions also cause the at least one processor to process the message in such a way that it processes at least one second output data object from at least one second data field of the second data structure using at least one second essence of a plurality of second logical operations encapsulated from at least one second command field of the second data structure received from one of the plurality of computers coupled via the network, to produce the same second input data object in at least one second input data object.

10. The device according to claim 8, wherein, The multiple logical operations include transformations.

11. The device according to claim 8, wherein, The at least one output data object can be stored in a computing environment.

12. The device according to claim 8, wherein, The at least one output data object can be transmitted to another computer process.

13. The device according to claim 8, wherein, At least one of the multiple logical operations in the entire sequence within the first message is different in nature from at least one of the multiple logical operations in the entire sequence within the second message.

14. A system for data folding, the system comprising: At least one processor; At least one memory; as well as The data structure located in the at least one memory includes: At least one input data object, which is processed by the at least one processor using multiple logical operations to produce at least one output data object, wherein the data folding utilizes at least one essence of the multiple logical operations performed on the same input data object in a discrete sequence to encapsulate the at least one output data in at least one data field of the data structure, and the at least one essence of the multiple logical operations of the entire sequence is encapsulated in at least one command field of the data structure; wherein, At least one output data object from at least one data field of the data structure is configured to generate the same input data object from the at least one input data object using at least one encapsulated essence of a plurality of logical operations of the entire sequence of at least one command field of the data structure.

15. The system according to claim 14, wherein, The at least one processor is further configured to process the message in such a way that it processes at least one second output data object from at least one second data field of the second data structure using at least one second essence of a plurality of second logical operations encapsulated from at least one second command field of the second data structure, received from one of a plurality of computers coupled via a network, to produce the same second input data object in at least one second input data object.

16. The system according to claim 14, wherein, The multiple logical operations include transformations.

17. The system according to claim 14, wherein, The at least one output data object can be stored in a computing environment.

18. The system according to claim 14, wherein, The at least one output data object can be transmitted to another computer process.

19. A plurality of computers coupled via a network, each of the plurality of computers including at least one processor and at least one memory, the memory storing instructions that, when executed by the at least one processor, cause the at least one processor to process messages using the system of claim 14.

20. The system according to claim 19, wherein, At least one of the multiple logical operations in the entire sequence within the first message is different in nature from at least one of the multiple logical operations in the entire sequence within the second message.

21. A method for folding data, the method comprising: At least one processor uses multiple logical operations to process at least one input data object to produce at least one output data object, wherein data folding encapsulates the at least one output data object in at least one data field of a data structure by utilizing at least one essence of the multiple logical operations performed in a discrete sequence on the same input data object in the at least one input data object, the at least one essence of the multiple logical operations in the entire sequence being encapsulated in at least one command field of the data structure; and At least one processor uses at least one encapsulated essence of a plurality of logical operations from the entire sequence of the at least one command field of the data structure to process the at least one output data object from the at least one data field of the data structure to produce the same input data object in the at least one input data object.

22. The method according to claim 21, wherein, The multiple logical operations include transformations.

23. The method according to claim 21, wherein, The at least one output data object can be stored in a computing environment.

24. The method according to claim 21, wherein, The at least one output data object can be transmitted to another computer process.

25. A system for folding data, the system comprising: A memory configured to store data structures; as well as At least one processor, said processor being configured to: Multiple logical operations are used to process at least one input data object to produce at least one output data object, wherein data folding utilizes at least one essence of the multiple logical operations of the entire sequence of discrete steps performed on the same input data object in the at least one input data object to encapsulate the at least one output data in at least one data field of the data structure, and the at least one essence of the multiple logical operations of the entire sequence is encapsulated in at least one command field of the data structure. as well as At least one essence of a plurality of logical operations encapsulated from the entire sequence of at least one command field of the data structure is used to process the at least one output data object from the at least one data field of the data structure to produce the same input data object in the at least one input data object.

26. The system according to claim 25, wherein, The multiple logical operations include transformations.

27. The system according to claim 25, wherein, The at least one output data object can be stored in a computing environment.

28. The system according to claim 25, wherein, The at least one output data object can be transmitted to another computer system.

Images