Nuts: encrypted userdata transit and storage

Abstract

A method of processing data includes: at least one processor accessing a data storage unit; the data storage unit providing at least one input data object; and executing at least one transformation command on the at least one input data object. The at least one transformation command operates on the at least one input data object in a forward mode to produce at least one output data object for storage in the data storage unit.

Description

Summary of the Invention

[0001] A data-centric model of computer software design allows user data to take precedence over application programs. A data-centric software design allows data to be fixed at a single storage point. Data containerization can be an example of a data-centric design. To illustrate how various concepts can be implemented within this disclosure, a series of diagrams from different perspectives highlight specific concepts being explored, and an overall diagram shows how several of these processes and structures can work together.

[0002] Data containerization can be presented in a layered approach, and where preferred, each layer can partially or completely build upon or work in conjunction with previous layers. The concepts, methods, apparatus, embodiments, and / or specifications described herein for a first layer may be collectively referred to as Structured Data Folding with Transformations, or SDFT. The concepts, methods, apparatus, embodiments, and / or specifications described herein for a second layer (which may include the first layer) may be collectively referred to as Encrypted User Data Transport and Storage, or NUTS. Any combination of layers may be deployed partially or completely to construct a data container, referred to as a NUTS, and each layer may be deployed partially or completely in isolation. The interaction and / or interweaving of these two layers can be significant and / or complex, and may pose challenges in clearly demarcating the layers. Therefore, these layers are presented together in this specification. The NUTS container can then be imbued with various data-centric properties that allow logical operations to be performed on the data contained therein. Based on a storage unit called a Nut, various embodiments may be described to show how certain common data-oriented logical operations may be redefined and restructured to provide privacy, security, convenience, and / or power to users. Simple diagram description

[0003] Various embodiments may be disclosed in the following detailed description and accompanying drawings: FIG. 1 shows a symbol table used to represent different cryptographic key types. FIG2 shows a set of simplified flow charts illustrating data input, data output, and logical operations that may typically be performed by different cryptographic methods. FIG3 shows a diagram of a general network topology in which embodiments of the present invention may operate. FIG4 shows a diagram of a computing device in which embodiments of the present invention may be run. FIG. 5 shows a diagram of a transition in a forward mode or normal operation. FIG6 shows a table of common data operations and their transformation categories. FIG. 7 shows a diagram of a transition in a reverse mode. FIG8 shows a diagram of an irreversible transformation. FIG9 shows a diagram of a conditionally reversible transformation. FIG10 shows a table of common data operations and functions grouped by transformation type. Figure 11 shows an encoding and decoding table defined in Python v3. FIG12 shows a table listing additional transition definitions. FIG13 shows a transition reversibility matrix. FIG14 shows a transition mode motion matrix. FIG15 shows a detailed example of a serialization transformation. FIG. 16 shows a detailed example of a summary transition. FIG. 17 shows a detailed example of a summary transition (also called a confirmation) in reverse mode. FIG18 shows a diagram of a scipher transformation. FIG. 19 shows a diagram of a salsa20 (scipher) transformation. FIG20 shows a detailed example of a salsa20 (scipher) transformation. FIG21 shows a command specification table for serialization and compression transformations and a set of sample transformation commands illustrating their use. FIG. 22 shows a command specification table for a coding conversion and a set of sample conversion commands illustrating its use. FIG. 23 shows a command specification table for a summary transformation and a set of sample transformation commands illustrating its use. FIG. 24 shows a command specification table for a cipher and flag conversion and a set of sample conversion commands illustrating their use. FIG. 25 shows a command specification table for a derived transformation and a set of sample transformation commands illustrating its use. FIG. 26 shows a command specification table 2602 for a scipher transformation and a set of sample transformation commands 2604 illustrating its use. Figure 27 shows the output structure format of a scipher output string in a two-step sequence, where step 1 shows the input format and step 2 shows the output format. The "header" is a variable-length utf8-encoded parameter string of the key value of the scipher transformation on the output message. FIG. 28 shows a table of parameter keywords and specifications for the header string in the output structure format of a scipher transformation. FIG. 29 shows a diagram of repeated embedded message encapsulation for an AEAD mode scipher transition. FIG30 shows a command specification table 3002 for a lock transition and a set of sample transition commands 3010 illustrating its use. FIG31 shows the specifications of various transition structures in a tabular format. Figure 32 shows a command specification table for a Mobius transformation. Its use is shown, and a graph shows the structural changes it can make to various structures. A matrix shows the types of structures / modes on which the Mobius transformation can operate effectively. FIG33 shows a command specification table 3302, 3304 for press, clean, and key transitions and a set of sample transition commands 3310 illustrating their use. Figure 34 shows a table of the Key Exchange Specification structure or KISS. FIG35 shows a table 3502 of KISS operation modes, a matrix 3504 showing key type / field generation mapping, and key type definitions 3506. FIG. 36 shows the structure of a TAR and an example of a TAR definition. FIG37 shows a block diagram illustrating where transition-related attributes reside and a table listing the type and location of the attributes. FIG38 shows a block diagram of the SDFT operations of concatenation and deconcatenation (or the reverse of concatenation). FIG39 shows a flow chart of an SDFT concatenation operation. FIG40 shows a flow chart of a SDFT disassembly operation. FIG. 41 shows how to perform a reverse TAR on a generic TAR. FIG42 shows an example of reverse TAR. FIG. 43 shows a translation table that is mapped to a key type template that may be generated or required during TAR processing. Figure 44 shows TAR instances and the key templates generated by each instance. Figure 45 shows a list of TAR instances and the key templates generated by each instance and the expected list of KISS structures to be put or generated. The KISS list is also called a key stack. Figure 46 shows the three modes of key stacking operations within the SDFT TAR process: generation (gen), input (put), and injection (mixed). Figure 47 shows a diagram of how a key stack is generated and used throughout the lifecycle of data and its TAR. Figure 48 shows a diagram of operations that can occur on data stored in an NSstr structure. FIG49 shows a flow chart of one use of SDFT to repeatedly fold data. FIG50 shows a flow chart of one use of SDFT to repeatedly expand data. Figure 51 shows a diagram of the SDFT API / library and the various types of TAR definition files it can access. FIG52 shows an exemplary Python descriptive language for performing manual data folding. Figure 53 shows an SDFT example of a TAR definition and its use in a Python descriptive language. Figure 54 shows a block diagram of dynamic TAR switching within a single communication session. FIG55 shows a flow chart of an exemplary process for generating a Nut ID. FIG. 56 shows a block diagram illustrating where Nut ID and Lock ID may be used within a Nut. FIG. 57 shows an exemplary relationship between Nut ID, path name, and payload data. 58 shows a block diagram of an embodiment of a Nut or lock diagram including logical segments Nut lock and Nut portions. FIG59 shows a block diagram of an alternative embodiment of a Nut lock comprising three keyhole locking nodes in a Nut. Figure 60 shows a block diagram of the internal data structure of a locked node. Figure 61 shows a block diagram of the internal data structure of an input segment of a locked node shown in Figure 60. 62 shows a data flow diagram showing the relationship of the internal data structure of a primary keyhole of an input section shown in FIG. 61 when a valid primary key may be inserted into the keyhole. Figure 63 shows a flow chart of the key insertion procedure for any locked node and for any cryptographic key. FIG. 64 shows an example in which three primary keys can be inserted into a primary keyhole. Figure 65 shows a data flow diagram of a variable lock decryption operation continuing from the example shown in Figure 64. Figure 66 shows a data flow diagram of a variable lock encryption operation continuing from the example shown in Figure 64. Figure 67 shows a table of variable lock types and their characteristics that can be used in any lock node. Figure 68 shows a data flow diagram of an ORLOCK decryption operation. Figure 69 shows a data flow diagram of an ORLOCK encryption operation performed by a Nut owner. Figure 70 shows a data flow diagram of a MATLOCK decryption operation. Figure 71 shows a data flow diagram of a MATLOCK encryption operation performed by a Nut owner. Figure 72 shows a data flow diagram of a XORLOCK decryption operation. Figure 73 shows a data flow diagram of a XORLOCK encryption operation performed by a Nut owner. FIG74 shows a data flow diagram of a HASHLOCK decryption operation. Figure 75 shows a data flow diagram of a HASHLOCK encryption operation performed by a Nut owner. Figure 76 shows a data flow diagram of an SSLOCK decryption operation. Figure 77 shows a data flow diagram of an SSLOCK encryption operation performed by a Nut owner. FIG78 shows a block diagram highlighting one of the hierarchical keys, Nut. Figure 79 shows a flow chart of how a level key can be inserted into a Nut. Figure 80 shows a table of key-based permissions for two roles and four role players. FIG81 shows a table listing the various Nut parts in an exemplary Nut, where each part can be represented by a locked node. FIG82 shows a table listing the key-based permission access roles defined for a typical Nut. Figure 83 shows that an initial set of Nut access control access keys, called Access Attribute Key Set Unlocking Key (AAKSUK), can be inserted into the access key hole of each valid primary key. FIG84 shows a block diagram of NAC access attributes propagating from an external lock node to an internal lock node. 85 shows a block diagram of NAC access attributes propagating from an outer lock node to an inner lock node and the output link key being inserted into the primary keyhole of the linked lock node. Figure 86 shows a flow chart for inserting a key into an access keyhole. Figure 87 shows a table of key-based permissions for an alternative embodiment. Figure 88 shows a data flow diagram of the internal decryption data flow of a locked node. FIG89 shows a flow chart for unlocking a Nut. Figure 90 shows an embodiment of a NUTS based system and a block diagram of how a file stored in a Nut can be unlocked. Figure 91 shows a diagram of the common usage in NUTS terminology to refer to a Nut payload by holding a Nut's Nut ID. Here, a cryptographic key can be referred to by the Nut ID of the Nut holding it. Figure 92 shows a simplified embodiment of a list of recipient locking models. Figure 93 shows a simplified embodiment of an ordered locking model. Figure 94 shows a simplified embodiment of an ordered locking model with a master key. Figure 95 shows a simplified embodiment of a locking model with a master key. Figure 96 shows a simplified embodiment of a locking model with a master key. Figure 97 shows a simplified embodiment of a safe deposit box locking model. Figure 98 shows a simplified embodiment of a secret sharing locking model with a master key. Figure 99 shows a simplified embodiment of a "PrivaTegrity" type locking model. Figure 100 shows a simplified embodiment of a multi-Nut configuration, where multiple payloads can be stored in a single Nut. Figure 101 shows a simplified embodiment of a multi-Nut configuration, where multiple payloads can be stored in a single Nut. FIG. 102 shows a simplified embodiment of a direct lock model with multiple payloads. FIG103 shows a simplified embodiment of an ordered message passing exhibiting a collusion-resistant design. Figure 104 shows a block diagram of a typical component of modular I / O. Figure 105 shows an illustration of a simple read and write operation using MIOR. Figure 106 shows the data conversion and transfer involved in a typical MIO file read operation. Figure 107 illustrates how modular I / O can be used to promote backward compatibility of file formats. Figure 108 illustrates how modular I / O can be used to promote forward compatibility of file formats. Figure 109 illustrates how modular I / O can be used to facilitate modular displays. Figure 110 illustrates how modular I / O can be used to facilitate modular applications. FIG111 shows the progressive changes of a Nut history during two edits and at three time points. FIG112 illustrates the progressive changes of a Nut log during the course of events from FIG111. Figure 113 shows how relationship-based keys can be represented in Alice and Bob's contact cards. FIG. 114 shows a flow chart of how well-known email addresses and / or RBKs may be used to detect SPAM. FIG. 115 shows a flow chart of how anonymous email addresses and / or RBKs may be used to detect SPAM. FIG116 shows a state matrix of an Alice-Bob RBK communication channel based on a deterministic context. FIG117 shows a state matrix based on a deterministic context for an Alice-Provider RBK communication channel. FIG118 shows a state matrix based on a deterministic context for a Provider-Alice RBK communication channel. Figure 119 illustrates the isolation of RBK relations in one of Bob's constrained systems. FIG120 shows a block diagram of the pre-packaged data Nut. Figure 121 is a diagram depicting the sequence of events in an automated registration process using RBK. Figure 122 is a diagram depicting the sequence of events in an automated registration process using RBK and an anonymous email address. Figure 123 shows a table listing the NUTS core applications and their descriptions. Figure 124 shows a block diagram of the NUTS core application running in a computer device. Figure 125 shows a block diagram of a NUTS server running in a user device. Figure 126 shows a block diagram of the internal components of a NUT server and its functional connections to the environment of the user device. FIG. 127 shows an alternative embodiment of the NUT server shown in FIG. 126 using a NoSQL database as a caching mechanism. Figure 128 shows a block diagram of a MIOR server network layout. Figure 129 shows a block diagram of a MIOR server application layout. FIG130 shows a flow chart for extracting MIO modules from a MIOR server. FIG. 131 shows a block diagram illustrating a MIOR cache. Figure 132 shows a block diagram of a NUTS browser application in a user device environment. Figure 133 shows a block diagram of a NUTS book application in a user device environment. Figure 134 shows a block diagram of a NUTS processing application architecture in a user device environment. Figure 135 shows a block diagram illustrating the internal components of a NUT book. Figure 136 shows a block diagram illustrating the internal organization of a NUT directory cache from Figure 135. Figure 137 shows a diagram of the organization of the display hierarchical pass code. Figure 138 shows how the main pass code opens a personal file according to the hierarchical pass code in Figure 137. Figure 139 shows how the main pass code opens a personal file according to the hierarchical pass code in Figure 137 and the file in Figure 138. Figure 140 shows how the main and work pass codes open a work file according to the hierarchical pass code in Figure 137. Figure 141 shows how the main pass code opens a working file according to the hierarchical pass code in Figure 137 and the file in Figure 140. Figure 142 shows a block diagram illustrating the internal organization of a NUT book key cache from Figure 135. Figure 143 shows a flow chart of how a NUT book can view a card directory. Figure 144 shows a table of NUTS-based services. Figure 145 shows a diagram of a network layout for NUTS-based services. Figure 146 shows a diagram of the network layout of a NUT mail server. Figure 147 diagrams the sequence of events in an automated registration process for an anonymous email service (such as NUT Mail) using RBK. Figure 148 is a diagram of the sequence of events when adding a communication channel in a NUT mail server. Figure 149 diagrams the sequence of events when Alice and Bob send an email via NUTmail. Figure 150 shows a diagram of the network layout of a NUT chat server. Figure 151 shows a data flow diagram of one of three chat sessions hosted by a NUT chat server. Figure 152 shows a data flow diagram of chat history persistence and replication across NUT servers. Figure 153 shows a data flow diagram of one of three separate chat sessions using different chat IDs or chat services. Figure 154 shows a data flow diagram of a path-agnostic conversation managed by a NUT chat client using one of the three different chat paths from Figure 153. Figure 155 shows a diagram of the network layout of a NUT cloud server. Figure 156 shows a diagram of the network layout of a NUT network server. Figure 157 shows a diagram of the network layout of a NUT hub server for the Internet of Networks (IoN) of NUTS. Figure 158 shows a diagram of a direct IoN network topology. Figure 159 shows a diagram of an indirect IoN network topology. FIG160 shows a diagram of a NUT server hub from FIG159 and its connections to the NUT hub and IoN devices. FIG161 shows a block diagram of the NUT Hub / IoN interface in a NUT Server Hub from FIG160. FIG162 shows a block diagram of the NUT Hub / NUT Server / IoT Interface in an IoN device from FIG160 . FIG163 shows a flow chart of a registration and configuration process for an IoN / IoT device. Figure 164 shows a flow chart of how the remote control interface can process the command Nuts from Figures 161 and 162. Figure 165 shows a diagram of the network layout of a NUTS certification server. Figure 166 shows a block diagram highlighting the functionality of a NUTS certification server from Figure 165. Figure 167 shows a diagram of a network layout of a NUTS-based WiFi / Ethernet router. Figure 168 shows a flow chart of how messages may be processed in a NUTS-based WiFi / Ethernet router from Figure 167. Figure 169 shows a table of device classification of NUTS-based WiFi / Ethernet routers. FIG. 170 shows a table of exemplary device classification attributes on a NUTS-based WiFi / Ethernet router. Figure 171 shows a block diagram of how the application wrapper implements device backup and replication in an automated manner. Figure 172 shows a block diagram of the Event Processing Service (EPS) in two devices. Figure 173 shows a block diagram of a typical provider network setup that may use tracking cookies and session history stored on a big data server. FIG174 shows a block diagram of a provider network setting that can use App Nut to record a copy of the session history locally and stored on the big data server from FIG173. FIG175 shows a block diagram of context calculations that can be performed locally using the App Nut from FIG173 and FIG174. Figure 176 shows a diagram of a personal home network topology including IoT devices and service providers. Figure 177 shows a diagram of a personal home network including two IoN devices in an indirect IoN network topology and their respective service providers to control the flow of data outgoing to the provider. Figure 178 is a block diagram showing how the context analysis app can automatically filter outgoing IoN messages to protect user privacy from the NUT server in Figure 177. Implementation Method

[0004] [Cross-reference to related applications] [] This application is based upon and benefits from priority from U.S. Provisional Patent Application No. 62 / 395,084, filed on September 15, 2016, the entire contents of which are incorporated herein by reference. [Table of contents] [] ●Symbols and abbreviations ● Password and one-way hash Network diagram ●Installation diagram Transformation Transformation type ●Transformation of structure Transition Audit Record (TAR) ●Structured Data Folding using Transformations (SDFT) Nut ID ●Lock graph and lock node ○Keyhole ○Variable Lock ○ Level Nut Access Control (NAC) ○ Lock node traversal ●Modular I / O ○Read and write ○Backward compatibility ○Forward compatibility ○Display ○App History of Nut Nut Log Relationship-based Key (RBK) Anonymous relationships NUTS core applications ○NUT Server ○MIOR server ○NUT Browser / NUT Shell ○NUT book ●NUTS-based services ○NUT Mail ○NUT Chat ○NUT Cloud ○NUT.com ○NUT Hub ○NUTS certification server ●NUTS-based WiFi / Ethernet router ●App packaging ●Event processing services Contextual computing ●Conclusion and philosophy [Symbols and abbreviations] []

[0005] The following symbols and abbreviations may be used throughout the description and drawings. Symbols marked with (*) may be unique to NUTS: AAKS *Access attribute key group ●AAKSUK * Access attribute key group unlock key AAPK * Accessor attribute propagation key ●acipher Asymmetric cryptography AEAD Authenticated encryption with associated data AES Advanced Encryption Standard; also known as Rijndael API Application Programming Interface AKS *Access key group ARK *Access role key BIOS Basic Input / Output System bz2 bzip2, Burrows-Wheeler compression algorithm ●CA Certificate Authority CAC Cryptographic access control ChaCha20 Bernstein's symmetric key-based stream cipher CLI Command Line Interface CMAC Password-based message authentication code CODEC COder / DECoder; encoding scheme for character data COM Component Object Model COR *Reader class; or reader CORBA Common Object Request Broker Architecture COW * Writer class; or writer CPU central processing unit CRC Cyclic redundancy check ●dign *(noun) A digital signature generated using an asymmetric private key ●dign *(verb) Use an asymmetric private key to generate a digital signature DK *Derived key DRM Digital Rights Management DVD Digital video disk DSA Digital signature algorithm ECC Elliptic Curve Cryptography eDK * Encrypted derived key EPS *Event handling services FIPS Federal Information Processing Standards HMAC Hash-based message authentication code GPS Global Positioning System GPU Graphics Processing Unit GUI Graphical User Interface GUID Globally unique identifier gzip GNU zip compression ●HKDF HMAC-based key derivation function ●ikm Initial key material IMEI International Mobile Station Equipment Identification IoN *Nut's Internet IoT Internet of Things IPC Inter-program communication IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 I / O Input / Output ●ima * Name of the KISS field abbreviated as "I am a" or "I'm a": Determine the KISS mode iv Initialization Vector: Random number for cryptographic compilation JSON JavaScript Object Notation KBP *Key-based licensing Keccak SHA3 hash series KISS *Key exchange specification structure LAN Local Area Network ●lock * Implement mutable locking as a transition class lzma Lempel-Ziv-Markov chain algorithm MAC Media Access Control (about Ethernet) MAC Message Authentication Code MD5 Rivest's Message Summary #5 MIO *Modular I / O MIOR *Modular storage MMS Multimedia messaging services NAC *Nut access control NCS *NUTS certification server NFC Near Field Communication NIST National Institute of Standards and Technology NoSQL Non-standard inquiry language; nor relevant standard inquiry language nonce Number used only once: random number for cryptographic compilation NTFS New Technology Archive System (Microsoft) NUTS *User data is transmitted and stored encrypted OAEP Bellare and Rogaway's optimal asymmetric encryption padding OS operating system PBKDF2 RSA (PKCS) passphrase-based key derivation function #2 PGP Better privacy PIM Personal Information Manager PKCS RSA Laboratories Public Key Cryptography Standard PKCS1_V1.5 PKCS #1 version 1.5 PKI Public Key Infrastructure PSS Probabilistic Signature Scheme PUID Actual unique ID QA Quality Assurance QUOPRI Quoted-Printable or QP encoding RAM Random Access Memory RATs *Root access layer, owner / creator of Nut; also RAT writer and owner RBAC Role-based access control RBCAC Role-based password-compiled access control RBK *Relationship-based keys ROM Read-only memory RSA Rivest-Shamir-Adleman public key cryptosystem SAC * Hierarchical access control Salsa20 Bernstein's symmetric key-based stream cipher salt Random numbers for cryptographic purposes scipher Symmetric ciphers SCP *Structured cryptographic programming SCRYPT Percival's passcode-based key derivation function SDF *Structured data folding SDFT *Use transformation structured data folding SHA Secure Hash Algorithm-Keccak Hash Variable Shake Keccak hash variable SMS Short Message Service SOAP Simple Object Access Protocol SPAM Unsolicited bulk email; also known as spam SSD Solid-state drive SSID Service Group Identifier SSO Single Sign-On ●tar Tape archiving: Unix commands for storing data on tape or disk TAR *Transform audit records TOP * Transform organizational principles ●tine *Shamir's secret sharing, like the tail on a fork TMX *change TOP * Transforming organizational principles URL Uniform Resource Locator UTF Unicode Transformation Format UTI Uniform Type Identifier UUID Universally Unique Identifier VPN Virtual Private Network WAN Wide Area Network WiFi WLAN Protocol WLAN Wireless LAN XML Extensible Markup Language Zlib zlib compression algorithm

[0006] FIG1 shows a table of cryptographic key types and their respective symbols that may be used throughout the description and diagrams of the present invention. Symbol 102 represents a variable-length text-based passcode or passphrase. Symbol 104 represents a key for a symmetric cipher or substitution cipher, including AES-256. Symbol 106 represents a key pair for an asymmetric cipher or substitution cipher, including RSA-2048. The public portion of an asymmetric key pair 106 is depicted as symbol 108, and the private portion is shown as symbol 110. Those skilled in the art will readily recognize that these ciphers may be well-known and well-tested algorithms, and that other suitable methods may be substituted where specified in the present invention if standards change or an alternative is desired. Passwords and one-way hashes

[0007] Figure 2 depicts the basic operations that can be performed by various types of ciphers. In an encryption mode, a symmetric cipher 208 can accept a symmetric key 202 and data 204 to produce encrypted data 206 (also known as "ciphertext"). In a decryption mode, a symmetric cipher 208 can accept the same symmetric key 202 and ciphertext 206 to produce the original data 204. In a symmetric cipher implementation, 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 a symmetric cipher can be that the same key 202 can be used for both encryption and decryption.

[0008] In an encryption mode, an asymmetric cipher 214 can accept the public portion of an asymmetric key pair 210 and data 204 to produce encrypted data 212 (also known as "ciphertext"). In a decryption mode, an asymmetric cipher 214 can accept the private portion of an asymmetric key pair 216 and ciphertext 212 to produce original data 204. In an asymmetric cipher implementation, 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 an asymmetric cipher is that encryption and decryption can utilize different parts of a key pair. In an implementation such as RSA-2048, a mathematical relationship can be used to derive a public key from a private key. Therefore, an RSA-2048 private key is synonymous with the key pair and the public key can be extracted from it.

[0009] In a signing mode, a digital signature method 222 can accept the private portion of an asymmetric key pair 216 and encrypted data 218 (also called "ciphertext") to generate a digital signature 220. In an authentication mode, digital signature method 222 can accept the public portion of an asymmetric key pair 210, digital signature 220, and ciphertext 218 to authenticate 224 whether to generate the digital signature using ciphertext 218 and the private portion of an asymmetric key pair 216. In an embodiment of a 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 a digital signature method can be that the signing and authentication procedures can utilize different parts of a key pair. In an implementation of a digital signature method, such as one based on an RSA-2048 key pair, a public key can be derived from a private key using a mathematical relationship. Thus, an RSA-2048 private key is synonymous with the key pair, and the public key can be extracted from it. For the sake of brevity and simplicity, this document refers to a digital signature interchangeably as a sign; the act of digitally signing a document interchangeably as a tag; and a document that has been digitally signed interchangeably as a tag.

[0010] A digital signature method can be a type of message authentication code (MAC). A MAC can be generated using a one-way hash algorithm applied to the data. A hashing method such as SHA-512 accepts the data content to generate a message digest thereof, which can be up to 512 bits long. MAC authentication using methods such as SHA-512 requires recalculating a MAC for the data piece and comparing the provided MAC with the calculated MAC for equality. A technique known as a keyed hash message authentication code (HMAC) uses an additional input, a cryptographic key, along with the data content to generate an HMAC value.

[0011] Digital signature methods and / or hashing methods may be used in various parts of the present invention to generate message digests that can represent respective data. Network Map

[0012] FIG3 illustrates a simplified network diagram in which various embodiments of the present invention may be partially or fully implemented. A wide area network (WAN) 302 may be represented as a network cloud, which may include numerous servers, routers, and switching systems at various telecommunications centers working together to provide a simplified network cloud view to a user or company. Cloud services 304 may also be graphically simplified to represent a cloud of various business systems that provide network services such as cloud storage and cloud processing; these services may be implemented in their own specifications but may include numerous instances of server farms, storage arrays, and routers. A personal router 306 may be connected to WAN 302, providing access to the internet from a plurality of network-connectable devices 308 to 318 that individual users may have. A user is not limited to the devices depicted and may use any device that can utilize a router to access other devices on the same network or across the internet. Router 306 may be a dedicated routing device for an ISP, or it may be a combined device that provides routing and / or LAN and / or WLAN capabilities and may be referred to as a gateway. A corporate router 320 may be connected to WAN 302, providing access to the internet for the organization's users among a plurality of network-connectable devices 302-330 that the company may possess. A company is not limited to the devices depicted in the diagram and may use any device that can utilize a router to access other devices on the same network or across the internet. Router 320 may be a dedicated routing device for an ISP, or it may be a group of interconnected and managed routers that provide routing and / or LAN and / or WLAN capabilities and may be referred to as a gateway and / or intranet. The systems and methods described in various embodiments herein may be used and applied to some or all portions of this network diagram. Installation view

[0013] FIG4 depicts a general-purpose computing device 400. A processing unit 404 may be connected to a system bus 402, which may facilitate some or all internal communications and data transfer within the device. There are several different types of system buses available, but for the sake of illustration, they may be collectively referred to as system bus 402. The processing unit may represent a single-core or multi-core processor, as well as processor arrays, such as those found in various specialized 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, which may store a BIOS program 408; a volatile memory (RAM) 416, which may temporarily store a running operating system 418, running applications 420, and / or application data 422; and non-volatile memory 424, such as a hard drive, SSD, and a USB drive 426, which may collectively permanently store an installed operating system 428, applications 430, and / or data files 432.

[0014] Not all components of the depicted computing devices are required for some or all embodiments of the present invention to be applicable and operational. For example, a 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. One essential 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. change

[0015] Transformations can be a preferred method for organizing the many known data manipulation operations found in computer programming. NUTS may designate this as the Transformation Organizing Principle, or TOP. Furthermore, any system data manipulation operation can be analyzed using TOP and categorized as a transformation type. Transformations can then be categorized, formalized, structured, integrated, and / or adapted to work together within the TOP framework, which may be referred to as Structured Data Folding with Transformations, or SDFT. The insight of TOP and / or the use of SDFT to manipulate data can allow for better and / or complex data designs to be implemented in a conceptually simpler and / or programmatically efficient manner. TOP and SDFT may be preferred low-level implementation mechanisms for NUTS components.

[0016] Data transformation-based analyses, methods, and / or structures demonstrate how these concepts can be layered and their associated methods can be designed to define a set of implementable integrated data structures and algorithmic methods 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 transformations may have forward and backward references and may require the reader to refer to different sections to gain a better understanding of certain characteristics. Structured Data Folding (SDFT) using transformations builds on transformations using data structures and methods and can help achieve storability, transportability, modularity, portability, encapsulation, and / or temporal consistency of transformed data.

[0017] Within NUTS design, SDFT is a set of low-level operations and can be considered a fundamental building block for more easily constructing a NUTS. However, SDFT can be used alone, partially, or completely to simplify certain lengthy and / or repetitive data transitions within an application. SDFT can implement computer communication protocols to dynamically switch transition sequences and / or transition parameter changes within the same session between two different applications. Currently, this dynamic switching of a single session can be a significant programming exercise. Using SDFT is not required to build a NUTS, but its features can help make building a NUTS more convenient, clear, and flexible. SDFT can be further described as a data state transition method that allows for an unlimited variety of transition events with well-defined behavior for state transition sequences and provides an iterative encapsulation technique for persisting necessary attributes and data in a simple, context-sensitive manner. SDFT accepts and encompasses the messiness of everyday programming problems and presents a set of practical organizing principles where theoretical evidence can be subservient to experimental evidence.

[0018] Figure 5 shows how the transformation organizing principle can view any data operation as a data transformation 510, which may require an input data source 502 and attributes 504 and may output transformed data 512 and associated attributes 514. Any well-defined manipulation, operation, conversion, and / or transformation of data can be classified as a transformation type 510. TOP can allow one to systematically construct a consistent set of methods for transforming data in a modular, portable, and / or self-describing manner.

[0019] The table in Figure 6 shows a set of simple, common data operations and how they are categorized using TOP. Transformations encompass a category of fundamental data operations that may have been traditionally separated in perception and practice. This is particularly true when programmers discuss cryptography and data compression, where these two data operation categories are often viewed as distinct and separate operations on data. Despite the algorithmic differences between each operation, through the lens of TOP, these operations can be viewed as types of cryptographic and compression transformations. In the table, a "JSON serialization" can be categorized as a "serialization" transformation using a "json" operation, so an executable transformation command can be described as "serialize json." An AES symmetric cipher encryption call can be categorized as a "scipher" transformation using an "aes" operation, so an executable transformation command can be described as "scipher aes." Those of ordinary skill can easily recognize all other data operation types listed in the table and follow the organizational pattern of transformation and operation categories.

[0020] Figure 7 shows a diagram of a transformation in reverse mode or reverse operation. This diagram is identical to Figure 5 , except that the data flow arrows flow in the opposite direction. A transformation 510 may have a well-defined reversible algorithm, as depicted by block 710 . A reversible transformation 710 may require a transformed data source 712 and attributes 714 as input and may output original data 702 and associated attributes 704 . A computing field known as reversible computing may exhibit concepts similar to a reversible transformation. There may be some differences in the goals of each organizing principle. Reversible computing may infer the existence of a universal reversible computing language whose operations can be implemented down to the silicon level to achieve energy efficiency for general computing. Reversible transformations may specifically address the benefits of TOP, such as (but not limited to) minimizing written code, minimizing programming errors, facilitating key management, simplifying key generation, structuring portable self-describing data, formalizing data manipulation concepts, introducing programming language-independent methods for performing transformations, and / or simplifying the creation of complex cryptographic data structures.

[0021] Figure 8 shows a graphical representation of an irreversible transformation. In the forward mode, a transformation 810 can perform a transformation on data 802 and attributes 804, which can produce transformed data 812 and attributes 814. However, these outputs, along with the types of manipulations the transformation can perform on the inputs, can be irreversible. Examples of such irreversible transformations include hashing, MAC, lossy data compression, and other one-way functions or data manipulations. TOP can introduce analytical techniques that can further characterize these irreversible transformations and generate operations that can define their reverse transformation characteristics.

[0022] FIG9 shows a block diagram of a conditionally reversible transformation. This transformation 910 may have a well-defined reversible algorithm but may require additional input and / or attributes 914 for the reversal operation to succeed. A conventional reversible transformation 910 may require a transformed data source 912 and / or attributes 914 as input and may output the original data 902 and / or associated attributes 904 if and when required conditions 916 are met; otherwise, it may fail with an error condition 920. Ciphers that may require a key may be classified as conventional reversible transformations because the lack of the correct key (an attribute) may prevent decryption of the ciphertext.

[0023] FIG10 sets forth a table categorizing common data operations and functions and their respective transformations. A person of ordinary skill 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 a programming language called Python version 3.6 and its syntax, concepts, functions, and / or methods. Many of the cryptographic functions referred to in this disclosure can be found in the Python standard, pyCryptodome, Secret Sharing, and / or pyCrypto libraries. A person of ordinary skill in the art will find equivalent syntax, concepts, functions, and / or methods in most modern programming languages and their respective libraries. It should be noted that a "flag" is used for a transformation of digital signatures; other mnemonics are listed in the Symbols and Abbreviations section of this document. A further detailed description of each transformation can be found in the table in FIG12.

[0024] Figure 11 is a table of codecs defined in Python v3.6. This list is incomplete due to the existence of several codecs, the addition of new codecs, and / or limitations of the codecs defined in Python v3.6. A "codec" is an abbreviation for codec / encoding and is a mapping of a character set in computing. A character is assigned an arbitrary but unique binary value within a single codec; therefore, a complete set of characters defines a single codec. Not all characters within a given codec are human-readable or printable. A common use of codecs is for the proper representation of different characters in different languages. An "encoding" transformation can perform any of these encoding operations on a given data string. Codecs whose names begin with "utf_" specify operations that conform to the Universal Code Transformation Format (UTF), the standard organizing principle for many international character sets based on the internet.

[0025] Figure 12 sets forth a table of the transformations discussed thus far, along with their detailed descriptions. Traditional transformations can be defined within a framework using TOP, as illustrated by the last six transformations in the table: key, clean, TAR group, press, lock, and Möbius. Some of these additional transformations may be unique to the Structured Data Folding (SDFT) library using transformations, some may be language-specific, and / or some may be operations on NUTS. This illustrates the flexible nature of TOP by allowing the definition and classification of new transformation types to extend its repertoire. This flexible extensibility is by design, enabling the SDFT library to accommodate new transformation operations in the future. This extensibility also allows for the retroactive addition of transformation operations from older versions for backward compatibility. One benefit of this flexibility is that SDFT enables better temporal consistency in data processing. Temporal consistency of data can be defined as a property that enables stored data to be easily processed by the same or a different application at a future point in time. Temporal incompatibilities may arise from, but are not limited to, differences in application file format versions, different character encodings, outdated application file formats, differences in data operation methods, differences in data operation sequencing, and / or changes in data operation specific parameters.

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

[0027] 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, yet retains sufficient information to allow the process to be reversed and fully reproduce the original data. A conditionally reversible transformation can be exemplified by the AES symmetric cipher; it operates on the principle of taking plaintext and a symmetric key and generating ciphertext. The decryption process can then use the key and ciphertext to generate the original plaintext. Therefore, the presence of the correct symmetric key for the ciphertext can be a necessary condition that must be met to decrypt the ciphertext or reverse the encryption process.

[0028] A TOP can define a transformation mode, which indicates the direction of a given transformation operation as forward or reverse. A transformation's forward mode can execute its normal process and / or its engineered forward process. A transformation's reverse mode can execute its inherent reverse process and / or its engineered reverse process. The table in Figure 14 shows a matrix indicating the types of operations a transformation can perform based on its internal transformation mode. For reference, the table lists commonly known operation names such as "serialization" and "deserialization" or "encryption" and "decryption." Note the reverse processes for digests and signs: "digest" and "validation," "sign" and "authentication." For "clean" transformations (which may delete various internal data associated with their transformed data structures), it may not be possible to recover this deleted data without appropriate additional data and / or rerunning 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 executing the transformation. Therefore, due to the inherent random nature of key generation, it may not be possible 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 subsequent section when we address how to make the transformation work within the context of structured data folding (SDF); the key management aspects of a key transformation are difficult to design a reversible counterpart due to its characteristic of setting the appropriate key structure to achieve a successful transaction in an SDF context.

[0029] FIG15 shows a series of three diagrams, each of which further details an example of a serialization transformation 1504, which can be assigned a reversible transformation. In computer programming, a serialization and / or marshaling technique can take a complex language-specific internal data structure and systematically deconstruct and / or organize its contents in a linear fashion to produce an equivalent data string or set of data strings (hereafter referred to as a data string). The data string form may be more suitable for persistent storage, data transmission, and / or further transformation. A serialization by definition may require that it be fully reversible in a logical manner to reconstruct the original content in the original language or its equivalent. A Python structure 1512 can be transformed using JSON operations 1514 to produce an equivalent JSON string 1516, and the reverse process is possible, as shown by the bidirectional program flow arrows. A simple tree data structure is shown at 1522, which can instantiate a complex Python data structure. Serialization transformation 1524 can produce an equivalent string 1526 from 1522. This output string 1526 can now be stored, transmitted and / or transformed as a program process.

[0030] FIG16 shows a series of three diagrams, each of which further details an example digest transformation 1606, which can be assigned an irreversible transformation. This example shows a SHA2 hash operation as digest transformation 1616, which can require data 1612 as input and a digest length 1614 as attribute 1604. SHA2 hash digest transformation 1616 can produce a hash 1618 of a specified length. A Python data string 1622 and a desired digest length 1624 of 256 bits can be input to SHA2 hash transformation 1626 to produce a 256-bit hash string 1628.

[0031] FIG17 shows a detailed example of a digest transformation (also called a validation) in reverse mode. In TOP, this can be referred to as engineering the reverse of a transformation. A digest transformation 1710 can accept data D1 1702 and attribute A1 1704 as input to perform a forward-mode digest transformation 1710, which can produce a digest string DG1 1712 as output 1708. The reverse mode 1720 of this transformation can accept data D1 1722, attribute A1 1724, and digest string DG1 1728 as input 1736 to perform a reverse-mode digest transformation 1720, which can produce a flag and / or value indicating whether digest string DG1 1728 is validated 1732 or failed validation 1734 as output 1738. Validation process 1740 can generate a digest string DG2 1722 by performing a forward-mode digest transformation 1720 on inputs D1 1722 and A1 1724. Output digest string DG2 1722 can then be compared 1730 with input digest string DG1 1728 for equality. The comparison result 1738 can be presented in some form to indicate whether the reverse digest transformation was successful. In this way, reverse engineering of the digest can require reprocessing the forward-mode transformation and comparing the outputs, rather than relying on any workarounds to find a logical reversibility of these operations (which can be difficult, time-consuming, and / or inaccessible).

[0032] Figures 18, 19, and 20 illustrate detailed examples of a Scipher transformation (also known as a symmetric cipher) in forward and reverse modes. In forward mode 1806, a Scipher transformation may accept plaintext 1802 and attributes 1804 as input to produce ciphertext 1810 and / or attributes 1812 as output. In reverse mode 1826, a Scipher transformation may accept ciphertext 1830 and attributes 1832 as input to produce plaintext 1822 and / or attributes 1824 as output. Figure 19 illustrates how the SALSA20 symmetric cipher may operate as a Scipher transformation. In forward mode 1906, a Scipher SALSA20 transformation may accept plaintext 1902 and attributes 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 a salt value. This forward (encryption) implementation of SALSA20 can be a stream cipher and, aside from hidden attributes that the function can embed within its own output string, can generate no additional output attributes during the encryption process. In reverse mode 1926, a cipher SALSA20 transformation can accept ciphertext 1930 and attributes 1932 as input to produce plaintext 1922 as output. In reverse mode, the attributes of this particular cipher can include a binary symmetric key, key length, and / or a salt value. This reverse (decryption) implementation of SALSA20 can be a stream cipher and can generate no additional output attributes during the decryption process. Figure 20 illustrates how the SALSA20 symmetric cipher can operate as a transformation on sample data, as represented within Python v3.6 and the PyCryptodome library. In forward mode 2006, a scipher salsa20 transformation can accept as input a data string 2002 and attributes 2004 including a 256-bit symmetric key and a random number (e.g., salt) to produce ciphertext 2010 as output. In Python, a symmetric key can be represented as a "byte" data type string, and thus a key length attribute can be easily derived from the len() function on the key byte string. In reverse mode 2026, a scipher salsa20 transformation can accept as input ciphertext 2030 and attributes 2032 including a 256-bit symmetric key and a random number to produce plaintext 2022 as output. In Python, a symmetric key can be represented as a "byte" data type string, and thus a key length attribute can be easily derived from the len() function on the key byte string. Property 2032 may need to be equivalent to property 2004 in order to make this condition reversible to properly process ciphertext 2030 in reverse mode (decryption) to recover original plaintext 2002. Transformation Type

[0033] In the examples presented in the following table and Figures 21 through 35 , each transformation is not limited to the operations specified in this table; any suitable operations can be analyzed by TOP and then integrated into the framework to expand the operational capabilities of a particular transformation. Python v3.6 syntax and constructs are used to illustrate the examples in more detail. Equivalent data types, structures, syntax, and / or methods can be found and substituted in different programming languages by one of ordinary skill. In some cases, a key / value option may not be associated with a specific language or library and can be ignored or modified as needed, as long as the processing produces equivalent results. Serialization / compression transformation

[0034] Figure 21 shows a command specification table 2102 for serialization and compression transformations and a set of sample transformation commands 2104 demonstrating their use. 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 can be presented in a key / value format within the command syntax construct. The "Input" and "Output" columns specify the expected data type / structure for the transformation / operation within the context of Python v3.6. For example, the command "serialize json sortkeys=t" performs the following data manipulation sequence: takes any Python data structure as input; executes json.dumps() on it with the "sort_keys" flag set to true; and then outputs a Python string containing the serialized version of the data. The reverse mode of this command would expect a JSON-formatted Python string as input, execute json.loads() on it, and then output a Python data structure. The "sort_keys" flag tells the json.dumps() function to process the keys of any Python dictionary in increasing order. Python v3.6 may not guarantee a consistent processing order for a dictionary structure when processing keys, so the resulting JSON string may not be consistent between multiple runs of this transformation on the same data structure. Sorting the keys in a specific order within the serialization transformation can provide consistency in the processing sequence, resulting in the same JSON string as output between multiple runs on the same data structure. This can be important for determining whether two JSON strings are equivalent and therefore represent two equivalent pre-serialized data structures.

[0035] The compression transformations in Table 2102 illustrate several different lossless or reversible compression operations. Any irreversible or lossy compression operation could extend the compression transformation repertoire, but for the purposes of discussing reversible transformations, discussing a one-way function that may not provide a cryptographic purpose beyond data size reduction is neither interesting nor constructive. From a TOP perspective, lossy compression can be analyzed and processed in the same manner as a digest transformation, as discussed in a subsequent section. In the example in 2104, the command "compress bz2" performs bz2 compression on a binary string input and produces a binary string output that may or may not be smaller than the input string. Some data may no longer be compressible using a particular compression scheme; an example of this would be processing a bz2-compressed string again and failing to achieve further data size reduction. Code Shift

[0036] FIG22 shows a command specification table 2202 for encoding conversion and a set of sample conversion commands 2204 illustrating its use. Numerous encoding schemes exist in computer science and the references in this table do not represent all known encoding schemes. The encoding schemes listed under the "Encoding" column are found in Python v3.6 and its associated standard library. One of ordinary skill in the art will recognize the utility of having access to all of these types of encodings for solving problems associated with an application that manipulates data. "Codecs(98)" refers to the list of supported encodings and decoders in Python v3.6 as written herein and previously listed in the table in FIG11. The conversion command "encode strbin utf_8" takes a Python string as input, performs a utf_8 Unicode encoding on it, and outputs the result as a Python byte string. The conversion command "encode utf utf_16" takes a Python string as input, performs a utf_16 Unicode encoding on it, and outputs the result as a Python string. The conversion command "encode binascii hex" takes a Python byte string as input, performs hexadecimal encoding on it, and outputs the result as a Python string. The conversion command "encode base 64" takes a Python byte string as input, performs base64 binary encoding on it, and outputs the result as a Python string. The conversion command "encode utf_8" is equivalent to "encode utf utf_8." These descriptions illustrate the consistency and arrangement types allowed in the encoding conversion command syntax. Abstract Transformation

[0037] Figure 23 shows a command specification table 2302 for a digest transformation and a set of sample transformation commands 2304 illustrating its use. A digest transformation, as shown in table 2302, defines three, but not limited to, operation types: hash, 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 generates an output digest byte string 128 bits long. Note that the input source data string is not modified or overwritten during a digest transformation call; the output digest byte string can be additional data generated from a digest transformation call and can be provided in 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 generates an output digest byte string 512 bits long. 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 digest byte string as output. The transformation command "digest hmac sha2 256" takes a source data string as input, performs an HMAC function on it using a SHA2 hash, and produces a 256-bit digest byte string as output. 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 the AES256 cipher, and produces a 128-bit digest byte string as output. All of these digest transformation example operations and types can be found in the standard Python library and / or the PyCryptodome library and may not represent all of the various operations, types, digest lengths, key lengths, and / or other parameters that exist in a theoretical and / or implementation sense outside of these sample libraries. Any additional changes can be appropriately analyzed and integrated into a transformation form by TOP. Such integration of any transformation form may require reconstruction and retesting of existing transformation operations. Acipher / Logo Shift

[0038] FIG24 shows command specification tables 2402, 2404, and 2406 for acipher and flag transformations, along with a sample transformation command 2410 illustrating their use. 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 them using a 512-bit SHA2 hash, and produces a 2048-bit encrypted byte string as output. 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 them, and produces a 3072-bit encrypted byte string as output. The reverse mode of these acipher transformations may require the ciphertext to be input as a byte string and the private part of the appropriate RSA key in order to produce the original plaintext.

[0039] The transformation command "dign pkcs1_v1_5 2048" takes a byte source string and a 2048-bit RSA asymmetric private key as input, performs an RSA PKCS#1 v1.5 digital signature operation on them using a 512-bit SHA2 hash, and produces a 2048-bit digest byte string as output. Note that the term "digest byte string" and "digital signature byte string" are used interchangeably, as TOP can treat these outputs as providing similar functionality and can therefore store this byte string under the variable name "digest." The transformation command "dign dss 1024 hashtyp=sha2" takes a one-byte source string and a 1024-bit DSA asymmetric private key as input, performs a DSS digital signature operation on them using a 512-bit SHA2 hash in FIPS-186-3 mode, and produces a 1024-bit digest byte string as output. The transformation command "dign dss 256" takes a one-byte source string and a 256-bit ECC asymmetric private key as input, performs a DSS digital signature operation on them using a 512-bit SHA2 hash in FIPS-186-3 mode, and produces a 256-bit digest byte string as output. The reverse modes of these flag transformations require the digest byte string (digital signature), the source byte string, and the public portion of the appropriate asymmetric key as input for authentication. Export Transformation

[0040] FIG25 shows a command specification table 2502, 2504, and 2506 for a derivation transformation and a set of sample transformation commands 2510 illustrating their use. The sample operations pbkdf2, hkdf, and scrypt may also be referred to as key derivation functions and / or key expansion functions. The basic functionality of a derivation transformation can be to derive a symmetric key or keys of a desired length from a binary or character data string known to the user. A common use of a key derivation function can be to derive one or more appropriately formed symmetric cryptographic keys from a passphrase or password. The transformation command "derive pbkdf2 keylen=256 iterations=100000" takes a single-byte data string (a passphrase or password) as input, performs a PBKDF2 operation on it using a SHA2 512-bit hash function, a randomly generated 512-bit initialization vector (e.g., salt), and an iteration count parameter set to 100,000, and generates a corresponding symmetric key, which is a 256-bit byte data string. The transformation command "derive hkdf keylen=256 numkeys=4" takes a single-byte data string as input, performs a HKDF operation on it using a SHA2 512-bit hash function, a randomly generated 512-bit initialization vector (e.g., salt), and generates a set of four corresponding symmetric keys, each of which is 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 (e.g., salt), and generates a corresponding symmetric key, which can be a 256-bit byte data string. A derive scrypt transformation in login mode can be a shortcut for setting the three parameters n, r, and p to the values indicated in Table 2506. These parameter values can be the settings recommended by the authors of the SCRYPT algorithm.

[0041] The TOP method for deriving transformations suggests a two-mode operation. Data mode: If a transformation is not coupled with a key stack (discussed in detail in a subsequent section) and is coupled only with a data source string of a certain type, it can transform the input data source string and replace it with a transformation output that can be in the form of one or more symmetric keys. Key mode: If a transformation can be coupled with a key stack and a data source of a certain type, it can transform the corresponding key source material present in the key stack and replace the key source material, thereby deriving one or more cryptographically usable symmetric keys and placing them in the key stack. These terms will be further clarified in a subsequent section when discussing key stacks and key management in the context of a transformation audit record or TAR and dependent transformations. Scipher Transformation

[0042] In the context of TOP, symmetric cryptographic operations can be categorized into scipher transformations, and as a group, these transformations can exhibit a set of related properties, which can be extensive in number and / or variety. The next three figures illustrate how TOP can systematically normalize and encapsulate scipher transformations with all their properties into the same output string. This type of attribute embedding technique can be found in various functions and libraries for many types of operations. However, there are very few widely accepted standards for these embedding techniques. TOP proposes a consistent method that can be applied to all scipher transformations for the diverse purposes of supporting a feature called Structured Data Folding with Transformations, or SDFT. Whether this method can become a widely used standard is beyond the scope of this document, but the reader will recognize the potential benefits of its use within the TOP framework, especially when we discuss TAR and SDFT constructions and methods later.

[0043] Figure 26 shows a command specification table 2602 for a Scipher transformation and a set of sample transformation commands 2604 illustrating its use. 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 related symmetric ciphers to illustrate how TOP can organize them and address their use. Symmetric ciphers may have the following properties associated with them to varying degrees: key length (keylen), operation mode (mode), salt type (salttyp), salt length (saltlen), block size (block), cryptographic operation type (type), and / or padding (pad). A key length specifies the length of the symmetric key used in the cipher to generate ciphertext from plaintext. For the AES cipher, it has at least ten different operation modes, as shown in the table. Most symmetric ciphers require input of a salt (random value) of a specific type (IV or nonce) and a specific salt length (the use of which can promote better semantic security). Symmetric ciphers offer at least three different types of operation: block, stream, and / or AEAD ciphers. Newer modes may be proposed and integrated into an additional transformation variant using TOP. Block mode ciphers may require additional properties including padding method, padding location, padding type, and / or padding length.

[0044] In the example in section 2604, a transform command "scipher aes 256 mode=ofb" may take a byte data string and a 256-bit symmetric key as input, encrypt the input data string using the AES-256 OFB mode stream cipher with the presented key and a randomly generated 128-bit initialization vector, and produce an output string that may consist of the ciphertext and all associated attributes involved in the procedure embedded in a header of the output byte string formatted in the consistent key / value format as specified in FIG. 27 (discussed in a subsequent section). A transform command "scipher aes 128 mode=gcm" may take a byte data string and a 128-bit symmetric key as input, encrypt the input string using the AES-256 GCM mode AEAD stream cipher with the presented key and a 128-bit nonce, and produce an output byte string consisting of the ciphertext and all associated attributes embedded in the header of the output string formatted in the consistent key / value format as specified in FIG27 . AEAD is an acronym for Authenticated Encryption with Associated Data and may be a standardized or well-known method of embedding authentication functionality along with the encryption power of a symmetric cipher into a single function call. A transformation command "scipher chacha20 256" may take a byte data string and a 256-bit symmetric key as input, encrypt the input string using the CHACHA20 stream cipher with the presented key and a 64-bit nonce, and produce an output string consisting of the ciphertext and all associated attributes embedded in the header of the output string formatted in the consistent key / value format as specified in FIG27. A transformation command "scipher salsa20 128" may take a byte data string and a 128-bit symmetric key as input, encrypt the input string using the SALSA20 stream cipher with the presented key and a 64-bit nonce, and produce an output string consisting of the ciphertext and all associated attributes embedded in the header of the output byte string formatted in the consistent key / value format as specified in FIG27.

[0045] Figure 27 shows the output structure format of a scipher output string in a two-step sequence, where step 1 illustrates the input format and step 2 illustrates the output format. "Header" is a variable-length UTF8-encoded parameter string of the key value of the scipher transformation on the output message. In step 1, a scipher accepts as input a variable-length message byte string "Message," where optional padding with a padding length is typically placed at the end of the message as needed. A message may be prepended with a salt value, as recommended by the selected cipher. Padding may be a requirement of a block-mode symmetric cipher. If the programmer does not specify a specific padding method, a default padding method may be used and appended to the end of the message. This message and padding are referred to as plaintext. The selected cipher can now process the input plaintext and generate and output an item called an encrypted message, as shown in step 2. The selected scipher transformation can now prepare the embedded header as a printable key / value pair in a string format, where the key represents the parameter type and the value represents their respective settings. The details of the key / value pairs will be discussed in the next section. Once a header string can be 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. Two bytes can have a value range from 0 to 2 ¹⁶ (65,536) and are sufficient to describe all properties of any symmetric cipher known to the future in this particular format. Next, step 2 can proceed to generate a packet message that includes the header size, the header, and the encrypted message. This packet message is the actual output string from the Scipher transformation, and therefore can be considered to have successfully encapsulated and embedded all attributes associated with the transformed data. The data flow for a reverse Scipher transformation can follow this process in reverse: the transformation command can specify the exact Scipher transformation to perform on a matching symmetric key, and the packet message can be provided as input. The Scipher transformation can then unpack the packet message, read and store all attributes found in the header, and then prepare to decrypt the encrypted message. A symmetric cipher may not have a deterministic method for conveying a successful decryption. A validation method can be used in an overlay to determine such results. One example of a basic method might be to extract a pre-determined salt value from the encrypted message and compare it to a stored salt value from the header. A matching salt value may indicate a successful decryption but does not guarantee it. AEAD mode symmetric ciphers can better address this issue by embedding a MAC (CMAC, HASH, or HMAC) of the data string within the encrypted message (before or after encryption) and performing a comparison. More complex methods may require digitally signing hashes that authenticate certain forms of the message using different keys. As will be shown in a subsequent section, the use of SDFT and TAR can allow for this complexity in a procedurally simple and logical manner.In all of these hash-based methods, it's impossible to fully describe the conditions for a decryption attempt due to inherent weaknesses in the hashing schemes used for universally unique identifiers. A deterministic method is to compare the encrypted message to the original message for equality, but this can compromise efficiency due to lengthy messages.

[0046] FIG28 shows a table of parameter keywords and specifications for the header string in the output structure format of a scipher transformation. The keywords selected for this attribute table should be sufficiently self-descriptive and / or self-explanatory to a person of ordinary skill. Example attribute values are shown in the right column. The first attribute header size listed may be representable as a 16-bit binary unsigned big-endian integer value and may be the only attribute present in the first field of the header. This header size may indicate the number of bytes, followed by a description of the attributes of this particular scipher transformation in a printable format. The attribute format may be selected as printable to allow for variability in attribute value range and length. All attribute values that may naturally exist as binary strings in the runtime, including the salt value (salt_val) and the MAC string (mac_val), may be encoded in base64 to accommodate the preference for printable characters.

[0047] In this way, the output string of a scipher transformation can include one or more encapsulated layers of attributes, depending on the details of the selected scipher. Figure 29 shows an illustration of the repeated embedded message encapsulation of an AEAD mode scipher transformation. An AEAD mode AES cipher can output the following layers, listed from inner to outer. A message preparation layer 2910 can include a plaintext message 2914, which is cryptographically combined with an appropriate salt value 2912. This prepared message can be encrypted using the selected AEAD cipher, which can then additionally generate a MAC value and additional data 2922 as part of the cryptographic process. This combined message can be referred to as AEAD cipher output 2920. This AEAD cipher output 2920 can also be referred to as an encrypted message 2934. Encrypted message 2934 can have associated attributes from the scipher process, which can be parameterized using the key / value header method from Figure 28 to generate a header 2932. This combination can be referred to as a scipher encapsulated message 2930. This scipher packet message 2930, which may be the output of the selected scipher transformation, may be stored in the obj pointer or variable 2944 of an NSstr structure 2940, which may be associated with the TAR of the scipher transformation. The NSstr structure will be discussed more fully in a subsequent section. Other attributes 2942 may 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 may already be the starting point of the plaintext message 2914, so an iterative path 2950 may be possible and may exist for the object 2944, as it can handle as many nested encapsulations as required by the TAR, which itself may be stored in the attributes 2942 of the NSstr structure 2940.

[0048] In header 2932 of scipher packet message 2930, parameters including the description of the symmetric cipher, its mode, and the attribute values used can be fully and accurately described by the keywords listed in FIG28 . In this respect, the TOP method does not rely on the obfuscation and hiding of non-cryptographic compilers and programs for fixing data, but rather relies solely on the theoretical and implementation security of the cipher used as a transformation. This may not seem significant at first glance, but it will be shown later that this simplicity of embedding the details of the data transformation within the output of the transformation itself can ultimately lead to novel methods and designs that rely more on self-describing data rather than releasing hard-wired formulas for processing it. This method can help formulate one of the fundamental primitives in data-centric design and data-centric modeling for some of the lowest-level operations in data storage science. NUTS can rely heavily on data-centric design and modeling, as will be shown in a subsequent section.

[0049] FIG30 shows a command specification table 3002 for a lock transition and a set of sample transition commands 3010 illustrating its use. A lock transition is one of the additional transitions listed in the table in FIG12 and may be an embodiment of a variable lock from NUTS, as described in detail in FIG65 through FIG77. Variable locks may present several different methods of cryptographically locking a secret message, including sslock, orlock, matlock, xorlock, and hashlock. A characteristic of variable locks may be the input and use of several cryptographic keys in the process of encrypting a secret message in a standardized, systematic, and orderly manner. The TOP method may allow for a compact method of implementing this locking technique in a simple and convenient manner. In the example of section 3010, a transformation command "lock or lock 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 a "scipher aes 128 mode=eax" transformation command, and generate an output string including ciphertext and associated embedded attributes. A transformation command "lock matlock 256 numkeys=5" can take a byte data string and five 256-bit symmetric keys as input, repeatedly encrypt the input string for each key using a "scipher aes 256 mode=eax" transformation command, and generate an output string including ciphertext and associated embedded attributes. A transformation command "lock sslock 256 numkeys=4 threshold=2" may take as input a byte data string and at least two 256-bit Tines256 secret sharing keys, encrypt the input string using an implementation of the Shamir secret sharing method with a provisioned secret share, and generate an output string including ciphertext and associated embedded properties. A transformation command "lock sslock_b 256 numkeys=6 threshold=3" may take as input a byte data string and at least three 256-bit Tinesidx128 secret sharing keys, encrypt the input string using an implementation of the Shamir secret sharing method with a provisioned secret share, and generate an output string including ciphertext and associated embedded properties. A transformation command "lock xorlock 128 numkeys=6" can take a byte data string and six 128-bit symmetric keys as input, derive a calculated key by repeatedly performing XOR operations on the supplied keys, encrypt the input string using a "scipher aes 128 mode=eax" transformation command, and produce an output string including ciphertext and associated embedded attributes.A transformation command "lock hashlock 192 numkeys=7" takes a byte data string and seven 192-bit symmetric keys as input, derives a calculated key by performing a hash on a sequential concatenation of the supplied keys, encrypts the input string using a "scipher aes 192 mode=eax" transformation command, and produces an output string that includes the ciphertext and associated embedded attributes.

[0050] Descriptions of each variable lock type and their modes of operation can be found in the following sections, beginning with the variable lock section in Figure 60. The TOP analysis and method allows complex, iterative lock variations that potentially utilize multiple cryptographic keys to be accomplished in a concise and logical manner, allowing for easy expansion of different types of future lock algorithms. It will be shown later that the key management aspects of SDFT allow a programmer to conveniently generate and manage these multiple cryptographic keys with relative ease.

[0051] As presented in Figures 12, 13, and 14, the TOP analysis and methodology allows one of ordinary skill to take a given data manipulation function and determine its suitability for normalization into a transformation operation and type. The table in Figure 12 shows a sampling of well-known data manipulations and can be considered sufficiently general for a broad audience of developers. However, in cases where a data manipulation function cannot be found in this table, it is possible to analyze and customize the function to operate within the SDFT framework using the TOP methodology; functions such as, but not limited to, lossy compression, bit scattering, message dispersion, erasure coding (ECC), and message-level RAID encoding and structuring are possible. In most cases of these transformation extensions, it is not necessary to recode or rewrite the actual data manipulation function. In fact, in most cases, doing so would be counterproductive and programmatically weak. Libraries containing data manipulation functions are available from the transformation library, and the TOP methodology allows a developer to provide a normalized wrapper around a specific data manipulation function that performs well within the SDFT framework. Transformation structure, Transformation Audit Record (TAR), and Structured Data Folding (SDFT) using Transformation

[0052] Figure 31 shows the specifications of various transformation structures in a tabular format. Structure definitions rely on a nested key-based approach, similar to how structures are defined in JavaScript; this may be an intentional design choice so that its representation can be easily replicated across multiple programming languages and does not rely on the unique characteristics of a particular language. For example, Python v3.6 allows for the definition of classes, while some languages, such as JavaScript, may not. Therefore, transformation data structures can be defined without relying on classes for wider applicability. A transformation structure provides a well-defined working memory area where the inputs and outputs of a transformation can be prepared, processed, and / or stored. The primary data storage unit or structure used in most, but not all, transformation operations is called the NSstr structure 3108. There can be at least one instance of NSstr associated with a transformation call. All transformation structures may have a "typ," or structure type, field that specifies what structure it represents. NSstr structures may further define a "status," field that specifies the state of the structure and / or its data. The "obj," or object, field may hold a single value or it may be a pointer to another memory area. The obj field can be where most of the input data for a transformation can be found. Furthermore, the obj field can be where most of the output data for a transformation can be found. The "digest" field (if present) can store a digest of the data stored or referenced by the obj field. The manner in which the digest can be generated can depend on the specific flag 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 Interchange Specification structure, discussed in a subsequent section) structure or it can be a list of KISS structures in a predetermined order corresponding to their operation TAR. A key stack essentially holds various types of keys that may be required for certain transformations. The "tar" field can point to an instance of an NStar structure 3106.

[0053] The NStar structure 3106 can specify a specific transformation audit record (TAR) that can be applied to the input data stored in the obj field of an NSstr structure. A TAR is a collection of transformation commands in a logical sequence that can be sensibly ordered to process the data in an NSstr in an orderly and well-behaved manner, producing a single "fold" of the NSstr data. We can refer to the process of executing a TAR on an NSstr data structure as a "patch" function call. Conversely, a "disassemble" function call can leverage the inherently reversible nature of transformations to "unfold" the folded data within the NSstr structure using the same TAR. Therefore, the reversibility of transformations can become a central feature of structured data folding (SDFT) using transformations. SDFT methods can use TARs on NSstr structures to repeatedly transform objects like an assembly line operation on data. Because the reversible behavior of each transformation command in a TAR can be analyzed, any TAR can be called in a reverse mode or disassemble function call. This topic may be discussed in greater depth as additional necessary components that make such operations feasible may be presented in the following sections.

[0054] NSbin structure 3102 may be used for a specific feature that may or may not be relevant only to Python v3.6. In Python v3.6, a distinction is made between how a data string is stored internally. It can be stored as a "byte" string or a character string. A byte string data type indicates that the information stored in the variable is a series of binary bytes. A character string indicates that the information stored in the variable is a series of bits representing characters encoded in a certain type of encoding scheme. Python v3.6 may employ a complex internal management scheme to optimally determine how to store a particular character string, as different encodings may require different storage requirements per "character." An example is that UTF-8 may use 8-bit code units to represent each character, while UTF-16 may use 16-bit code units. These variations may be necessary to transmit 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 8-bit arrangement. The preferred internal serialization method for transforms, TAR, and SDFT may be JSON, and JSON may not have native support for mapping Python "byte" data types to one of its own. If a conversion is attempted, JSON function calls may fail unexpectedly with some indication that a particular data type may not be supported. An NSbin structure can be designed specifically for this type of situation and can replace any "byte" data string, thus making Python variables compatible with JSON. A "byte" string can be encoded as a base64 character string and stored in the "b64" field of an NSbin structure. You can now make a byte string variable point to this NSbin structure, overwriting the original byte data. These may represent equivalent data, but they may be in different encodings and structures. However, the end result is that the NSbin structure is fully compatible with JSON and can now be safely serialized using JSON functions without errors due to incompatible data types.

[0055] In the TOP method, this "byte" data conversion and replacement of NSbin structures can be referred to as a "push" transformation from Figures 12 and 33. In Python v3.6, a push transformation, such as that listed in Table 3302, can take any valid Python structure or variable and repeatedly convert each bit string into an equivalent NSbin structure, which can result in a Python structure lacking any byte data type. One of ordinary skill in the art can customize an appropriate push transformation for languages other than Python v3.6 and their JSON function calls to remove these sources of data serialization errors. The reverse mode of "push" can be referred to as "undo push" and can repeatedly undo the conversion and replacement, allowing the data structure containing its original data type to be restored.

[0056] NSjson structure 3104 can be used to maintain only data that is fully compatible with JSON, a particularly useful feature. A quick glance at the fields defined for NSstr 3108 can alert us to a potential problem if we submit a structure directly for JSON serialization due to the digest field potentially holding a digest value of the source data in binary string form, or a byte string in Python v3.6. We refer back to Figure 12 and reintroduce the "Möbius" transformation for this specific issue. It should be noted that, prior to this point in this description, any reasonable definition of a Möbius transformation may not be fully clear to the reader due to the intertwined nature of transformations and the TOP method. The Möbius transformation in Figure 32 can transform a given structure from one form to another in a circular manner, but with a slight twist, as in a Möbius strip. Möbius transformations can be a key enabler of structured data folding using transformations by systematically converting an NSstr structure into a JSON-serializable structure (such as NSjson). The transformation routine can embed an operational TAR for the entire NSstr along with the transformed data, thereby making the resulting storable object self-describing. Möbius transformations can be a convenient implementation of the essence of structured data folding within the SDFT library. A developer can choose to manually implement SDF using a logical combination of transformation commands other than Möbius commands, but Möbius commands add at least one additional logical step that may require the developer to perform outside of the SDFT library: the ability to serialize the NSstr data structure it is operating on into another structure (such as NSjson). A Möbius transformation can be the last transformation in a TAR. Due to its functionality, this may be the only logical place to place a Möbius transformation. When processing a Möbius transformation, it can take the NSstr structure it is operating on and convert it into an NSjson structure. The TAR embedded in the NSstr structure may no longer exist in a useful or accessible form, so the Möbius transformation may be the last transformation command to be processed for a given TAR. Simply put, a Möbius transformation can compress an NSstr structure, JSON-serialize it, and then store it in an NSjson structure, which can be stored, transmitted, JSON-serialized, folded, or any other valid data operation that can be performed on these structures. There can be a reverse mode for a Möbius transformation, but another way to view this transformation is to state that it is a circular transformation: whether in a forward or reverse mode, it performs a specific data transformation depending on the input data structure type. Table 3204 indicates an NSx structure, for which NSjson can be a variable. If the need for additional transformation structures beyond those defined in Figure 31 arises in the future and they may need to be accommodated in a Möbius transformation, this table illustrates how the Möbius transformation might behave for any transformation structure other than NSstr.While this may not be entirely obvious without actually using SDFT programming, the Möbius transform logically implies that TAR processing from a recovered NSjson structure is impossible unless a Möbius transform can be performed on it to convert it to its original NSstr structure, which preserves the TAR that has been folded. To initialize this Möbius spin loop using an NSjson structure, a Möbius function call, RecoilStartAMobius(Reverse), from the SDFT library can be used to generate an NSstr structure, access the embedded TAR, and process the embedded TAR in reverse. This further implies that the Möbius transform 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 can already be executed via the RecoilStart function call, thereby executing the Möbius functionality no more than once during these reverse operations. In this sequence, the inability to ignore the Möbius transform in reverse mode can potentially create an infinite oscillation of Möbius calls, which can continuously convert NSstr to NSjson and back. This may seem like a roundabout way of expressing these operations, but it can produce quite compact bidirectional TARs that can be systematically embedded in the output transformed data, thereby giving the folded data a self-describing property. This property can be novel because it can act on data as if it were an interpreted descriptive language, but in forward or reverse mode, performing operations on the data in a consistently reproducible manner across any language and / or operating system that can support an implementation of an SDFT library.

[0057] Figure 33 shows command specification tables 3302 and 3304 for push, clean, and key transformation, along with a set of sample transformation commands 3310 demonstrating their use. A clean transformation can be a housekeeping function that deletes temporary or ephemeral fields from the NSstr structure. Certain transformations may require additional temporary fields during processing and may create additional fields within the NSstr structure to store and access them. The creation and use of these temporary fields within NSstr can be done in a deliberate manner, analyzing their coexistence within the TOP method and minimizing their interference with the proper operation of any other transformations. A clean transformation, due to its functionality, may not have a reverse mode, so it can be safely ignored. This reverse implication can be considered when introducing a new temporary field within the NSstr structure; the field may not exist in the reverse mode processing of the transformation, so the transformation in the reverse mode does not depend on its presence for proper operation. A key function of a clean transformation can be to delete an internal copy of the entire key stack used in TAR processing; or it can simply delete the keys within the key stack and convert the KISS structure into a keyhole. This can be one of the most critical changes in the SDFT TAR process, as failure to properly sanitize NSstr before preparing it for storage can result in the storage of any and all cryptographic keys that may have been used in a particular TAR process and may be inadvertently stored in the plaintext and folded data. This situation can reveal the key and crack some or all of the encrypted data within the folded data; this may not be the intended purpose of the encrypted data.

[0058] Table 3304 illustrates key transformations using some operations of a key transformation. This transformation can be part of the key management functionality of the SDFT and can primarily operate on the key stack field by referring to the tar field of an NSstr structure. A key check transformation tests the stored TAR and generates a list of key templates. If a key stack is input, it can be compared with these key templates to determine whether the correct key types in the appropriate sequence are 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 in a list of "Symmetric 256," indicating that the TAR expects the key stack to contain these keys (if available). Table 3504 lists some of the various key types. An empty key stack or a partially populated input key stack can also be handled appropriately. When a key stack is not input (where a TAR requires some keys), a "Key Generation" transformation can be indicated. SDFT can participate in a key generation mode, whereby appropriate key types based on a derived key template are generated and assembled into a key stack for submission to the NSstr structure before the data stored in the obj field is TARed. A partial "key generation" mode can be engaged when a partially populated key stack is available as input. Key checking and generation transformations can collaboratively determine whether the partially supplied keys in the key stack are of the appropriate type and in the appropriate sequence. They can then proceed to generate appropriate keys for missing keys. This process can be referred to as the "missing teeth" case of SDFT key stack management. There are very few instances where a TAR has a key transformation command, as it is considered so fundamental to the proper operation of the SDFT library on a TAR's NSstr structure that it can be implicitly performed by default in each call to concatenate / disassemble operations, rather than requiring the programmer to include them in every TAR. It can be shown that simply having the possibility to process a TAR (which may require a cryptographic key) is sufficient to enable consistent, implicit, and / or automatic checking of proper key stack management. The TAR reversal process can process the key stack in a proper reversal order. The complexity is increased due to the unique nature of the derived transitions in the key stacking pattern, which will be discussed in a subsequent section regarding how SDFT handles such situations of TAR groupings, known as dependent transitions.

[0059] Figure 34 shows a table of a Key Interchange Specification structure, or KISS. This structure can have at least two modes of operation: key or keyhole. A key's attributes can be specified by some or all of the fields defined in the table, and additional fields can be added to expand the structure to support other key attributes as needed. The TOP method of cryptographic operations can be to confirm that each cryptographic transformation requires a matching keyhole view that specifies the exact key type required for that transformation. Attributes can include (but are not limited to) an actual unique ID for the key itself, a challenge or hint for a passphrase or passcode, a key description, etc. If a key value can be present in a KISS structure, it can be simply referred to as a key. If a key value can be absent from a KISS structure, it can be referred to as a keyhole. This can be indicated by the value in the "ima" field. The field name can be an abbreviation of "im a" key / keyhole and can be read that way for simplicity. The column titled "In" may indicate the values required to generate a blank KISS structure and insert a key into it (for the purpose of placing it in the input key stack of an NSstr structure). The column titled "Gen" may indicate fields that may be automatically generated and populated during a key generation transformation from within the SDFT library. Throughout the SDFT discussion involving TARs, all key references may be synonymous with the appropriate type of KISS structure. It should be apparent that the key stacking can closely correspond to the characteristics of the processed TAR, and this method of stacking transformation commands and the necessary cryptographic keys and sequences in a specific form allows any input data to be repeatedly processed through an unlimited number of transformation changes, transformation parameter changes, 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 that a complete understanding of any particular part may not be presented in a completely linear manner.

[0060] Figure 35 shows a table 3502 of KISS operation modes, a matrix 3504 showing key type / field generation mappings, and key type definitions 3506. Table 3506 lists several key types recognized by SDFT but is not limited to these types, as new key types may be added and integrated as needed. At least three key types may require some explanation, as they are specifically structured for the SDFT library using well-known base key types. The key type "symmetric list" may be an array of lists of symmetric keys and may be stored as key values within a single KISS structure. This key type may support (but is not limited to) transformations such as locking and derivation. The secret sharing locking transformations, called sslock and sslock_b, may represent two different implementations of the Shamir secret sharing algorithm, respectively. The locking sslock transformation may expect secret sharing in a specific format (including an internal index number) and key sharing in a 256-bit key length. This may be referred to as a "tines256" key type within the SDFT library. The lock sslock_b transition may expect a secret share in a specific format (including an internal index number) and a key share in a 256-bit long key. This may be referred to as a "tinesidx256" key type in the SDFT library.

[0061] Table 3502 shows how features can be applied to a matrix of a KISS structure in the two modes it can exist in: key (or transformation) or keyhole. In transformation (key) mode, a KISS structure can be expected to store the actual cryptographic key used to generate a version of ciphertext, which may include a cryptographic digest and / or a flag. Therefore, its storage can be used on information but requires further embedding using an encryption function to permanently store it in a fixed manner. In keyhole mode, a KISS structure can be expected to have sufficient detail to accept an appropriate cryptographic key as its value to generate a version of ciphertext, which may include a cryptographic digest, a flag, and / or a derived key. Therefore, its storage can be mandatory and may not require further security by any embedding method, as it may not contain a key value as a keyhole.

[0062] Table 3504 is a matrix showing which fields can be mandatory, dependent, input by key type, and / or generated. After examining this table, it becomes apparent that a KISS structure can store salts for various cryptographic operations. This may seem redundant given the discussion of scipher-embedded headers, but the salt discussion may not present a complete picture of salts. As shown in Figure 37, the persistence of attributes 3704 and 3714 associated with a transformation can be spread across several data storage areas 3732, 3734, 3736, and 3738. The TOP method has demonstrated that salts can be embedded in certain cryptographic operations along with the resulting output data, as they may not reveal additional information about the generated ciphertext. However, when testing key derivation transformations processed in a key stacking mode, it was found that storing the associated salt values in a KISS structure can be convenient and logical. A typical method for using a key derivation function might be to accept a passphrase as input, combine it with a salt value, and generate a suitably formed cryptographic key, such as (but not limited to) a symmetric key. In this case, the salt may be used for semantic security. Therefore, it is entirely possible that each keyhole that accepts the same passphrase may have a different salt, so that the resulting secret cryptographic keys can differ from one another, regardless of any reasonable reason. This derived key can be used temporarily and discarded after use, leaving only the keyhole as evidence of its existence. Since the product of key derivation cannot typically be permanently stored (since it can be used as a key), it can be asked: where can we store it? TOP can store it in the corresponding keyhole and may prefer SDFT to store this keyhole along with the folded data, so that each keyhole that accepts the same passphrase can have its own instance of a suitable salt value. Programmers can store KISS keyholes in an entirely different external manner. The simplified transition diagram on the top of Figure 37 (which is the same as Figure 5) becomes more like the diagram on the bottom of Figure 37 when the various components of TOP and SDFT can be introduced. Table 3720 summarizes the placement of attributes.

[0063] Much has been said previously about the syntax and various transformation commands available through TOP and SDFT analysis, but what does a TAR actually look like in practice? Figure 36 shows the structure of a TAR and lists several examples of TARs. Section 3602 specifies the general structure of a transformation audit record or TAR. A "tar label01" declaration indicates the name or label of the TAR defined immediately 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 either the TAR label or a transformation command on its own line. This is similar to the macro feature of a programming language compiler; it can be used as a convenient feature to combine familiar TAR structures into a new TAR without actually copying the definition into the TAR itself. Transformation commands can be inserted in a specific sequence to process the target NSstr structure in the desired manner. TAR "test_a01" simply pushes a Python data object into an equivalent structure that lacks any Python byte data type; for other languages, this may or may not perform the same functionality, as "pushing" can be language- and / or environment-specific. TAR "test_a02" performs a push transformation twice in succession. The second push transformation may not complete a functional change to the data. This demonstrates the TAR extension at work. TAR "test_a07" pushes data, serializes it into a JSON string, and then converts it into a byte-type binary string using utf_32 encoding. TAR "test_a17" demonstrates what a terminated Möbius transformation might look like. TAR "test_a20" pushes 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 ciphertext string into a base64-encoded character string. A symmetric key for scipher transformations may be expected in a key stack containing a single KISS structure NSstr holding a 256-bit symmetric key value. An alternative approach would be to not provide a key stack and have the concatenation function continue to generate a valid key stack with a properly generated random 256-bit symmetric key, use it to perform scipher transformations, and allow the programmer to extract a copy of the key stack (and therefore the keys within it) after completion. The TAR "test_a42" shows an example of a TAR group and dependent transformations: it compresses data, serializes it into a JSON string, converts it to a binary string encoded in utf_8, derives a 256-bit symmetric key from a passphrase provided in the key stack, and then performs a ChaCha20 encryption on the data using the derived symmetric key.The last two transformations may have a permanent dependency because the cipher relies on derived keys; therefore, this dependency may be grouped within the TAR with a leading <tag> denoted as such. In forward mode, there is no noticeable impact on the TAR grouping within a TAR definition, other than visually highlighting these dependencies. However, TAR groups can play an important role when it comes to TAR reversal. When preparing a TAR for a TAR reversal process, the TAR group can remain intact as a unit, and its components may not be reversed. Figures 41 and 42 illustrate several examples of TAR reversal. The TAR "test_a64" may perform five scipher transformations and one DSS flag transformation. This TAR may expect a key stack populated with six keys of various types and lengths in a specific order. A simplified representation of a key template that may correspond to the TAR "test_a64" is shown in section 3610. This key template can be used by implicit key checking and / or generation transformations to validate any input key stack and / or generate a valid key stack for proper processing by the TAR. .

[0064] FIG38 shows a block diagram of the SDFT operations of concatenation and unconcatenation (or the reverse of concatenation). Two central operations in SDFT are "concatenation" and its reverse, "unconcatenation." The concatenation operation processes a given NSstr, which may include some or all of the following: data, TAR, key stack, and / or other attributes. The concatenation operation "concatenates" 3810, or collapses the source data within 3802, according to the sequence of transformations listed in the TAR within 3802, and ultimately produces the output as a component within an NSstr structure 3804 or an NSjson structure 3806. The unconcatenation operation "unconcatenates" 3820, or expands the source NSstr 3804 or NSjson 3806 structure according to the reverse sequence of transformations listed in the embedded TAR, and ultimately produces the output as an NSstr structure 3802. As will be shown, the symmetry of concatenation / unconcatenation can be an interesting aspect of this design. Note the consistency of terminology and perspective used throughout TOP. A concatenation operation in reverse is equivalent to an unconcatenation. This reversibility principle can not only simplify the analysis of such functions, but it can also filter modular organizational methods that can lead to higher-order concepts about data transformations.

[0065] Figure 39 shows a flow chart for an SDFT concatenation operation. Given an NSx structure, the concatenation function or method call can perform the following operations on the data therein using the parameters provided with the call and / or a TAR embedded within the NSx, where "x" in this case represents any transformation structure. Similar to the key checking / generation transformation, a Möbius transformation can be considered so fundamental to this algorithm that it can be implicitly performed on any input data structure when condition 3906 is met. Concatenation can only properly perform its core operations on an NSstr structure. Therefore, if an NSx structure is passed instead of an NSstr, it can attempt a transformation on an NSstr structure 3918. Failure to generate a valid NSstr 3924 can generate an appropriate error code 3978 and abruptly terminate the process 3984. There are at least three different ways to concatenate or collapse the data within it: First, a valid NSstr can contain a TAR that indicates the sequence of transformations to be performed on the data within the NSstr structure. Second, the name of a TAR tag can be passed as a parameter to the concatenate call, thereby indicating the preferred set of transformations to be performed on the data within the NSstr structure. Third, a customized TAR list can be passed as a parameter along with its given name in the concatenate call, thereby indicating the preferred set of transformations to be performed on the data within the NSstr structure. Preparation of the TAR 3912 can include expanding other TAR tag references and / or ordering them appropriately for traversal modes, which can be forward or reverse. Figures 41 and 42 illustrate several examples of TAR reversals. Next, a key check transformation can be performed on the TAR and NSstr structures. One component of a key check transformation can be to derive a key template list 3930 by testing the TAR. Using a TAR, an input key stack (which may be empty or partially populated), and / or a key template, the program can assemble a key stack for the appropriate traversal of the TAR 3936. This can include generating missing keys of the correct type, sequencing keys in the proper order, and / or checking that the input keys are of the proper structure and type. Any mismatch between 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 through each transformation command in the TAR in an appropriate sequence 3948 and perform the specified transformations 3954 on the data contained in NSstr. Any error 3960 encountered during the execution of a transformation command can generate an appropriate error code 3978 and abrupt termination of the program 3984. When the end of the TAR sequence 3948 is reached without errors, the concatenation operation can then be considered a success 3966 and the program can exit gracefully 3972.

[0066] Figure 40 shows a flowchart of an SDFT disassembly operation. Rather than specifying the disassembly procedure in detail, we can illustrate the symmetry of transformation reversibility by comparing the flowcharts in Figures 39 and 40. The only difference between the two flowcharts may be the TAR preparation steps 3912 and 4012. Because each transformation can already be analyzed and structured using TOP to perform well in a bidirectional manner, the disassembly process need not differ significantly from the concatenation process, except for how the TAR is presented. It can be implemented as the same code, but with a slight deviation when a reverse flag can be indicated, and performing the appropriate reverse ordering of the TAR when this is encountered. In Python v3.6, this call can take the form "obj.concatenate(..., reverse=True)". The symmetry can allow the actual implementation code to be smaller and / or present less opportunity for programming errors. One conceptual benefit may be the clarity and simplicity of thought when constructing a new TAR for a specific purpose: programmers can rely on the fact that a suitable TAR sequence is fully reversible within its limitations and need not overthink that part of the application. Another benefit may be that the programmer's workload for generating a specific set of data transformations can be effectively reduced by at least half, as they no longer need to generate the inverse codes for these data manipulations. The creation of complex encryption and locking mechanisms can require a significant number of data manipulations using a large number of cryptographic keys. The Transformation Organization Principle (TOP) approach can help achieve a more integrated and holistic approach to handling this complexity in a discrete, less error-prone manner; thus, it can allow for (but is not limited to) more consistent, reliable, secure, portable, understandable, widespread, flexible, scalable, and / or complex encodings and / or data.

[0067] Figure 43 shows a transformation table that maps to a key type template that can be generated or required during TAR processing. Referring back to the discussion of key management, one of the primary operations of key management can be analyzing a given TAR and generating a corresponding list of key type templates, which can detail the types and specifications of each key that may be necessary for successful processing of the given TAR. Table 3506 lists at least nine key types defined within the SDFT. Table 4300 shows a mapping of each transformation operation that may require a key and its corresponding key type, or "keytyp," that may be required when performing the concatenation / deconstruction process. A key template can have several attributes associated with each key type, such as, but not limited to, key length, or "keylen." For simplicity and illustrative purposes, a 256-bit symmetric key can be indicated as having a key template that can be represented as "symmetric keylen=256" or "symmetric 256." However, in practical implementations, any available data structure mechanism in a programming language can be used to store these values in an organized manner. In Python v3.6, one possible structure for a key template can be represented by an array of dictionaries, where each dictionary entry in the array stores a single key template with attributes corresponding to a 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 regenerated through key-checking transformations, eliminating the need for permanent storage of these key templates. In this way, SDFT can properly analyze any key inserted into a key stack for processing before completely failing a cryptographic transformation due to key type / structure incompatibility. A common theme in TOP and SDFT is the notion that obfuscation of data manipulation sequences may not be a guarantee of authenticity within any sensitive payload, but rather a function of the strength of the chosen cipher and its operational properties and / or characteristics.

[0068] FIG44 shows TAR instances and the key templates generated from each instance. The left column in Table 4402 lists a TAR instance "A." The right column indicates the key type template generated for each transformation command that may require a cryptographic key as an attribute input. In this example, TAR "A" may require two cryptographic keys in the indicated sequence. The left column in Table 4404 lists a TAR instance "B." The right column indicates the key type template generated for each transformation command that requires a cryptographic key as an input. In this example, TAR "B" may require four cryptographic keys in the indicated sequence. This process can be shown as key template generation from a TAR.

[0069] Figure 45 shows an expected list of TAR instances, key templates generated by each instance, and KISS structures to be input (put) or generated (generated). A KISS list is also called a key stack. We can use the two examples from Figure 44 and show the next step in a key management pattern for a concatenation / unconcatenation call. A key stack can be expected or generated in the form of a list of KISS structures corresponding to each key type template, as shown by 4510. When TAR "A" receives the "scipher salsa20 256" transformation command, the program can expect to find an input 256-bit symmetric key in the key stack, as indicated by KISS A1. When TAR "A" receives the "dign dss 1024 digestlen=512" transformation command, the program 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 interpreted in a similar manner. If the expected key cannot be found in the key stack, the TAR process can instead expect to find a generated key. This implicit key generation can benefit programmers because the only requirement for generating any type of acceptable key for a given cryptographic transform is being able to declare it within a TAR. Generating a specific key for a specific cryptographic function can eliminate the need for additional steps. Calling Splice with an empty key stack results in the output NSstr structure holding a fully compliant key stack with the appropriate generated keys to match the TAR and enable the data to be folded within it. It is highly recommended and advisable that this key stack, consisting of a KISS structure, can then be stored securely separate from the folded data and / or further modified and refolded and secured using a TAR, thereby further encrypting it using a cryptographic transform. Repeated encryption and wrapping of the key stack can be useful when dealing with many cryptographic keys to be managed and secured. TAR "B" can generate a four-key KISS key stack, which can facilitate secure storage of the entire key stack in a key repository; however, for convenience, the programmer may wish to encrypt the four-key key stack using a single key. This can be accomplished by: generating a new NSstr; inserting the four-key key stack into the data obj field; retrieving an appropriately cryptographically compiled TAR; and performing a concatenation call on the NSstr structure. This series of steps results in a key stack with a single KISS structure containing the key locked to the collapsed NSstr structure that holds the four-key key stack.

[0070] FIG46 illustrates three modes of key stack operation within the SDFT TAR process: generate, put, and inject. Section 4600 illustrates what may occur when a key stack 4602 is empty during the processing of TAR instance "B." The concatenation process may employ 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 illustrates what may occur when a key stack 4612 is input (put) 4616 to the processing of TAR instance "B." The concatenation process may employ the key type template of TAR "B" 4508 and check it against the provided key stack 4612 to verify the number, type, and order of the keys, and then allow it to be used during the processing of TAR "B" as shown in 4614. Section 4620 illustrates what happens when a 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 "missing" case. The concatenation process can take the key type templates of TAR "B" 4508 and check them against the provided key stack 4622 to verify the number, type, and order of the keys. During the repeated validation of key stack entries by each key type template, any empty KISS structure can be considered a validation failure of a particular type and can further be interpreted as an implicit key generation transition for that key type template. The concatenation process can then inject 4626 a newly generated key of the appropriate type into the empty position of the key stack and continue the key validation iteration. After this step is completed, a mixed key stack (which can be referred to as a mixture of input and generated keys, a missing case, or a key injection) can be presented and used during the processing of TAR "B," as shown in 4624.

[0071] FIG47 shows a diagram of how a key stack is generated and used throughout the lifecycle of data and its TAR. Using an SDFT 4700 for data allows it to be repeatedly transformed in an orderly fashion according to a set of variable transformations, as defined by a specific TAR 4702. The TAR can be structured to allow for cryptographic key types and, therefore, to generate key templates that specify the number and types of keys required by the TAR. The key template can then be referenced in the composition 4704 of the input key stack, regardless of whether all, some, or none of the necessary keys are present. When a required cryptographic key is missing, the composition process can generate a new key for use. The TAR, data, and key stack can then be passed to a concatenate call 4706 to perform a 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 the folded data needs to be referenced, the application can retrieve 4712 the data from its storage location, retrieve 4714 the key or key stack from its secure storage, pass the folded data and key stack to an unpack call 4716, and access the data in its original form from the unpack output structure 4702. This may represent a complete cycle of structured data folding using transformations. There may be many other paths to transform and fold any data structure, but essentially, some form of this cycle may have to be completed in order to fully retrieve the original data within the SDFT.

[0072] Storage 4710 of keys and / or key stacks may involve folding a key stack using a cryptographic TAR to protect it using fewer keys (only one key and / or different keys). The folded key stack data may become part of another structure, which may ultimately be folded itself. Data can be folded repeatedly in a cascading fashion to build an internal data structure, where precise, progressive folding results in precise, progressive encryption. This ability to direct the transformation of complex cryptographic data in a precise, organized, and / or methodical 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 of the operations performed on the target data.

[0073] One significant benefit of SDFT may be its systematic approach to key management within the context of various cryptographic operations on a given data item, such as 4704 and 4714. Programmers can, to some extent, be freed from the trivial details of generating individual keys and manually managing their storage and / or sequencing during these procedures. In the application of cryptographic functions, these trivial details can quickly accumulate into a large number of small details or properties that the application (and therefore the programmer) must track, analyze, store, and / or use. The SDFT approach may allow a given application to track, analyze, store, and / or use fewer individual properties of a cryptographic function because it allows these properties to be embedded within the context of the data and / or key stack it operates on and produces as output, thereby providing a pairwise coupling of the folded data and the transformations that folded it. The porting of data manipulation instructions from the application to the data may allow for simpler applications and / or applications with more complex uses of cryptographic functions. SDFT can be implemented as a better alternative to the Structured Cryptographic Compiler (SCP) approach, as will be discussed in the NUTS section.

[0074] FIG48 illustrates a diagram of operations that can occur on data stored in an NSstr structure. Any data 4812 referenced by a pointer and / or stored in a variable can be directly encapsulated 4804 into an NSstr structure using an instantiation method and / or a method / function call. The NSstr structure 4810 can then optionally encapsulate a TAR 4814 and its associated attributes 4816. Attributes may include key stacks, digests, transformation parameters, and / or temporary variables. This provides the minimum set of complete information necessary to process the NSstr through an SDFT concatenation / deconstruction operation, performing a TAR on the data contained therein using the attributes that may have been provided. In TOP terminology, this is referred to as a data fold. 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 4820 in a persistent and accessible manner, transmitted 4840 to another computing device using an inter-process communication (IPC) method, and / or stored 4830 in another internal data structure. The loop can restart at a subsequent point in the application for data storage 4820 and 4830. For data transmitted 4840, the loop can be initialized by receiving 4802 the data packets 4800.

[0075] Figure 49 shows a flow chart of the use of SDFT to repeatedly fold data. This series of simplified diagrams shows the systematic folding of data using N consecutive SDFT concatenation calls. An NSstr structure 4900 containing at least data 4902 and TAR 4904 can be folded by calling splice 4906 to generate output data 4908, and the output data 4908 can be modified and / or further packaged into an NSstr structure 4920 containing at least data 4922 and TAR 4924. The NSstr structure 4920 can be folded by calling splice 4926 to generate output data 4928, and the output data 4928 can be modified and / or further packaged into an NSstr structure 4940 containing at least data 4942 and TAR 4944. The NSstr structure 4940 can be folded by calling splice 4946 to generate output data 4948, and the output data 4948 can be modified and / or further packaged... This process can be repeated 4950 as needed. It should be noted that in this series of complex structured data folding, 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 programmatic expression without such repetitively encapsulated SDFTs but with the possibility of varying the transformation sequence and / or parameters of each step can be relatively long, error-prone, and / or difficult to understand.

[0076] Figure 50 shows a flow chart of SDFT usage for repeatedly unfolding data. This series of simplified diagrams illustrates the systematic unfolding of data using N consecutive SDFT unpack calls. Figure 49 is the exact reverse sequence and can therefore be understood as such. As previously shown in Figures 39 and 40, unpack calls can be identical to join calls, except for the preparation of the TAR and the state of the data fed into them. It should be noted that in this series of complex structured data unfolding, no additional reverse TARs are required to achieve the unfolding. All necessary TARs required to unpack each folded data can be found embedded within the folded structure. A more refined examination of NStar structure 3106 reveals an "expd" field defined as a "list of TAR command expansions." This can be a key feature of reversibility in SDFT: the output of TAR preparation steps 3912 and 4012 can produce a complete set of operational transformation commands, devoid of any external references to tags, and can be considered a complete description of the transformations that the transformed data may have undergone. This can be considered a static snapshot of the TAR set for the folded data, thereby ensuring that a proper expansion can be performed on the folded data regardless of any changes to the TAR definition in an external location. This can imply that the TAR definition file can grow to a large number of TAR definitions over time, but the storage of operational TAR definitions can be preserved by the SDFT process to maintain their reversibility regardless of changes to these external definition files (which may not be a recommended practice). This design can promote a systematic approach to better handle the temporal consistency of stored data.

[0077] Figure 51 shows an illustration of the SDFT API / library and the various types of TAR definition files it can access. A TAR definition can exist in many forms, such as, but not limited to, text files, .NET, encrypted files, databases, server processes, and / or runtime memory. A TAR definition can be defined by the programmer at any time as a customized TAR definition within a patch call and can therefore be a temporary TAR. For permanently stored TAR definitions, Figure 5100 illustrates various forms of these definitions but is not limited to those shown. Standard TARs 5102 can be TAR definitions that can be provided as a package with the SDFT library installation for any OS / language pairing. Hidden TARs 5104 can be TAR definitions that can only exist in access-restricted locations and / or be accessed with expressed permissions. These can be the preferred method for TAR definitions within a private network or custom application installation. The use of hidden TARs can even remain hidden within a collaged output, with the expanded form of the TAR undetected within the folded data, referred to only by the TAR tag. Administrators of these groups may be obligated to maintain hidden TARs, as data folded using hidden TARs may not necessarily contain the transformations required to expand it. Hidden TARs can appear similar to an equivalent method for obfuscating data manipulation sequences within a program. Local user TARs 5106 can be TAR definitions, which can be customized TAR definitions accessible only under the user or programmer's account permissions. These can be temporary or development TARs that a programmer can create to be permanently added to one of the TAR definition stores at a later time. Remote TARs 5108 can be TAR definitions that can be accessed with or without permission from a remote server or storage location. This topology may be necessary due to limited local storage or a policy of centralizing key TAR definitions in a central management area. This can also be a way to continually check that the standard TAR definition is up to date. Protected TARs 5110 can be TAR definitions that can be located in any suitable accessible location but can be encrypted for authorized access only. A separate authentication and / or authorization process may need to be successfully traversed in order to gain access to a protected TAR. Another form of a protected TAR can be stored in a Nut container, which may require the appropriate key(s) to gain access to it. Embedded folded TARs 5112 can be extended TAR definitions that are retained along with the folded data from a stitching call.

[0078] Figure 52 shows an exemplary Python descriptive language for performing manual data folding. Figure 53 shows an example of SDFT for a TAR definition and its use in a Python descriptive language. Figures 52 and 53 together illustrate an example of how SDFT can differ from a more direct programming approach using Python v3.6. These exemplary Python descriptive languages use methods to illustrate the key differences in the basic call sequence for each task at hand. We can begin with a sample data set 5210. The operations to be performed on the data can be specified in tasks 5220, expressed in plain language as shown in lines 02-06. Typically, for readability, these are entered as comment lines within the program itself. Section 5250 shows the actual Python code that performs the task, and section 5260 shows the reverse processing of the task to recover the original data 5210.

[0079] In the case of SDFT, data set 5310 is the same as 5210. Section 5320 expresses task 5220 as a TAR definition labeled "test_a70". Section 5350 collates the data and writes the folded data to a file. Section 5360 reads the folded data from a file and disassembles it.

[0080] There are 18 lines of Python code in Figure 52, while there are only 8 lines of code in Figure 53. It should be apparent that any changes to the type and number of data transformations can affect both sections 5250 and 5260. The method in Figure 52 requires the programmer to maintain certain variables, task sequences, and / or proper function or method calls. The reverse procedure in 5260 requires the programmer to ensure that all operations are called in the correct reverse order and that parameters are correctly passed to each function or method call. Any changes to the tasks in 5220 can result in programming changes to sections 5250 and 5260. Any additional tasks in 5220 can result in additional lines of code in sections 5250 and 5260. More temporary variables can be created and used as needed to accommodate these additions or changes to tasks.

[0081] In the SDFT method of Figure 53 , any changes to the task can be reflected directly in TAR 5320. Therefore, any additional transformation modifications can only change the length of this section. The concatenation and disassembly calls lines 10 and 14 remain unchanged. The reverse procedure in 5360 of TAR 5320 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 except line 10, where the TAR definition tag is specified in the concatenation method call.

[0082] For readability and understanding of the tasks performed, readers may prefer TAR 5320 over the actual code in sections 5250 and 5260. The tasks specified in 5220 are not coded and can typically be expressed as comments within Python code. Any changes to the code in sections 5250 and 5260 must be manually reconciled with the comments by the programmer, otherwise confusion may ensue if another programmer attempts to understand the code with inaccurate comments, and vice versa. A TAR 5320 can be considered self-describing in a clear and compact manner.

[0083] The data stored in rows 15-16 of section 5250 has no embedded metadata describing how it can be transformed. The transformation method is hard-wired into the actual code in sections 5250 and 5260. Any such data written in this manner is completely dependent on the existence of identical or similar codes for proper retrieval and recovery. These code sections, or their equivalents, must be permanently maintained to ensure that the transformed data is permanently recoverable. This is equivalent to a hidden TAR method.

[0084] The data stored by row 11 in section 5350 may contain an embedded extended TAR definition, which may have transformed the folded data. The transformation method can be paired with the folded data, making it transportable. The recoverability of the folded data can be considered independent of the encodings 5350 and 5360 that generated it. Any encoding that can properly handle the embedded TAR definition in the folded data can recover the original data. This type of functionality allows for better temporal compatibility for changing transformation sequences over time, as the old folded data is self-describing and therefore self-deterministic about how it can be recovered.

[0085] Figure 54 shows a block diagram of dynamic TAR switching within a single communication session. In the TOP approach, a higher-level communication protocol can be viewed as passing transformed data from one computing program to another. Because the transformation allows for many of the most frequently used cryptographic functions, it can be used to generate secure messages for IPC. In theory, a different TAR can be used to transform and fold each message. Each different TAR definition can be considered its own protocol by modern standards for protocol definition. Using SDFT, the TAR can be dynamically switched between two applications on a per-folded message basis, as illustrated in Figure 54. Any combination of TAR sources, such as those shown and described in Figure 51, can be used, as long as each application has access to the TAR definition sources. This rich set of embedded folded metadata (such as, but not limited to, KISS structures, e.g., keyholes that specify an exact key identifier for each key required in an embedded cryptographic transformation) allows SDFT-based communication protocols to provide security at a more complex and potentially more secure level.

[0086] TOP analysis and methods, which can lead to a framework known as SDFT, can allow stored data to contain its own portable instruction set that can have generated it. This framework can define data folding and provide methods and / or embodiments for folding data using a conceptual and logically consistent reversible transformation process that can be expressed as a transformation audit record (TAR) that can be embedded in stored data in an organized manner. The resulting folded data can then be modified in some manner and then folded repeatedly as needed to achieve the desired application or data form result. In addition to describing the TAR as a programming language, it represents a set of coordinated data manipulations in a concise form that can allow unlimited variations in transformation sequences and / or unlimited variations in transformation attributes within a given TAR and / or attributes. SDFT can allow for variable data set scoping in a manner similar to programming languages, using scoping concepts and techniques to isolate local variables. Through TOP, protocol changes can be observed within a higher-level conceptual construct, resulting in data that is self-describing and accessible and readable by a variety of applications. These applications can access its methods through an available SDFT library adapted for their programming environments. Furthermore, these features embedded within the folded data allow for dynamic switching of protocols within a single communication session or stored data object. TOP methods can serve as a fundamental building block of the NUTS ecosystem and within the composition of a NUTS. NUTS can be fully implemented independently of SDFT, but this is likely unwise. NUT ID

[0087] The NUTS design enables data identifiability regardless of location. This may require a universally unique ID (UUID), but this cannot be achieved in a guaranteed manner without some form of centralization. Therefore, we choose the concept of a truly unique ID with sufficient length and entropy-sensitive properties to provide a low probability of ID collisions. Figure 55 shows a flow chart of an example process for generating a Nut ID 5500. Here, a local device 5502 may run an application that calls a function to generate a truly unique ID from data items, such as, but not limited to, user attributes 5504, environmental attributes 5506, and / or random attributes 5508. User attributes 5504 may include data items such as, but not limited to, user login information, group ID, company ID, user ID, and / or user passcode hash. Environmental attributes 5506 may include data items such as, but not limited to, MAC address, IP address, device information, system time, OS information, directory paths and / or files, atomic clock synchronized time value, GPS synchronized time value, declared environment variables, thread ID, CPU runtime, IMEI number, phone number, application name, and / or program ID. Random attributes 5508 may include data items such as, but not limited to, session counters, UUIDs, clock cycle counts, randomly generated numbers, mouse movements, keyboard activity, file system status, partial or full screen area hashes, program available time, OS available time, and / or session duration. These data items may be collected and stored in an ID structure 5510, which may then be serialized using JSON or an alternative binding technique. The resulting binary string may then be hashed 5520 using a hashing algorithm such as SHA-512 (from the SHA-2 family of hashing algorithms published by NIST in FIPS PUB 180-2 in 2001) or an alternative hashing method that produces practical uniqueness with a recommended minimum length of 512 bits to reduce the probability of ID collisions. For portability and readability, the binary hash may be encoded 5514 as a base64 (or alternative encoding scheme) text string, which may produce a text string approximately 86 characters long. The encoding scheme may include any method that results in a printable, human-readable form that can be accepted as a text string by multiple programming languages and software systems. Depending on the mode in which the function may have been called, the resulting encoded hash string may be checked 5516 for duplication against any accessible Nut ID cache. If there is a conflict in ID values, the process can be repeated using new random attributes 5508 until a non-conflicting ID can be generated; conflicts can be expected to be rare events. The output string of this logical operation can be called a Nut ID 5518.

[0088] This procedure can be called locally within a running program or implemented within a locally resident server application or a remote server client application requesting a new Nut ID. One potential benefit of a server-based implementation may be its ability to access a larger cache of existing Nut IDs for checking and to generate a Nut ID with a lower probability of collision. Nut ID duplication checking is not mandatory, as the hash length and appropriate collection of data elements in the ID structure 5510 provide sufficient entropy. Common partitioning concepts may exist throughout some or all digital infrastructures, such as the Internet with IPv4 / IPv6 addresses, domains, directory hierarchies, and access control groups. In a similar manner, a Nut ID may be truly unique, but it may be used within the context of a compartment constructed by an external system or relationship, and therefore the chance of collision may be many orders of magnitude smaller than the mathematical probability provided by the permutation of a given bit length in a Nut ID. In cases where a different length is desired, this can be accomplished by replacing the SHA-512 hash with an alternative hashing algorithm in a modular parameterized manner by one of ordinary skill in the art.

[0089] Given a process that generates a truly unique ID in the form of a Nut ID, what can be identified? In NUTS terminology, this is called a Nut ID stamp. Within NUTS, there can be at least two structures that can be consistently stamped with a Nut ID: a lock node and a Nut. A Nut ID assigned to a lock node can be called a lock ID. A Nut ID assigned to a Nut can be called a Nut ID. A lock node can be an internal building block of a Nut. A lock node can be a self-sustaining, independent locking mechanism that can protect its payload, called a packet. A Nut can be a data structure composed of one or more lock nodes. Therefore, a Nut can hold any packet or several packets of data, in whole or in part. Nuts can be used throughout the NUTS environment to uniquely identify some or all associated software, data, and / or hardware represented in binary form. One consequence of the Nut ID stamp is that each Nut can be uniquely identified, thereby implying that each data packet stored in a Nut can be uniquely identified by the Nut ID regardless of where the Nut is physically located.

[0090] FIG56 shows a simplified diagram of a 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 through 5622 can be assigned to this Nut and can have different values. Lock nodes 5604 through 5612 can be identified by lock IDs 5614 through 5622, respectively. In a typical Nut data structure (such as this example), a 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 package 5626 of a lock node 5606. The Nut ID can be considered the payload of this lock node, which can be different from the payload of Nuts that may be stored in one or more of the other lock node packages. Each locked node 5604 to 5612 structure may contain a payload area called a packet 5624 to 5632. This shows the relationship between a Nut and its Nut ID and where we can find these items stored in a typical Nut container.

[0091] Figure 57 shows an example of the relationship between a Nut ID, path name, and / or payload data. A Nut may contain several lock nodes that can be used to store Nut metadata, metadata about the Nut payload, and / or the Nut payload. Metadata may be stored in packets within various lock nodes within the Nut. 5702 shows an example in which two different Nut payloads, D1 and D2, are stored in different Nuts identified by Nut IDs A3 and B1, respectively. A two-character Nut ID is used for illustrative purposes, although it has been previously stated that a Nut ID can be a base64 encoding of a 512-bit hash that can produce a text string up to 86 characters long. Nuts A3 and B1 also have different path names in an NTFS file system. 5704 shows two different Nuts with the same file name but different path names. 5706 shows two copies of the same Nut with the same file name in different directories. 5708 shows two copies of a Nut in the same directory with different file names. This may not be an exhaustive list of some or all permutations of these attributes, but it may illustrate the flexibility of having a metadata item (such as a Nut ID) permanently associated with each payload.

[0092] Embedding data within a Nut file that can be identified by an associated Nut ID leads to a novel feature of this method: the ability to automatically generate dynamic file names based on parameterized rules in metadata. The file name can represent the file's normal identifying string as well as a formulated summary of its other attributes, such as, but not limited to, modification date and time and / or number of writes on that day. This provides a more accurate and convenient way to instantly identify a file and its status without delving into normally hidden attributes (such as viewing file properties in a directory browsing application). It also allows file and data attributes to be embedded in containers that hold files rather than relying on a file system's attribute extraction capabilities (which can vary between file systems). As an example, a user can create a Nut with Nut ID #234 that can store a text file. The text file will always be identified by Nut ID #234, but the user can create a dynamic file name consisting of a base name, last modification date, and number of writes on that day, such as "diary_20151115_1.txt." On the same day, when the user saves to disk after making minor modifications, the file name might display "diary_20151115_2.txt," and the old file name might no longer exist in the directory. This method automatically generates a new file name that indicates some state information about the stored data. The nature of Nut IDs, which are truly unique and separable from the path name + file name specification, allows this feature to be implemented without any external references. One benefit of this feature is a common method for replicating and archiving previous states of a working document with a date stamp. An author might have a directory filled with files from their daily work on their document. Using the dynamic file name method, they would only have one Nut file in their directory with a last-written date stamp. The history (state) of this manual method can be retained within Nut itself using the Nut History feature presented in a subsequent section. This concept of Nut ID as primary content identification can then be used by Nut servers to perform replication and synchronization operations on distributed Nuts. Locking graphs and locking nodes

[0093] NUTS technology handles the storage, protection, and access control of data in a layered, integrated, modular, and / or iterative approach, which can be defined as structured cryptographic programming (SCP). The overall design of a NUTS internal component can be described and defined, and each defined structure can then be described in detail. Some features can be described in a layered manner, and then an overall description can be provided to show how the individual features work together. SDFT can be utilized throughout NUTS design to improve the organization of complex cryptographic structures and the systematic embedding of attributes associated with each folded data structure. Various embodiments can be demonstrated to demonstrate how SDFT enables SCP design to be implemented relatively easily compared to equivalent manual approaches.

[0094] There are four different methods for controlling access to a Nut: keyhole, variable locking, 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 a Nut in a novel way, allowing the Nut to provide the full functionality of a reference monitoring system in an internalized and / or standalone manner. These four layers can be embodied in a complex data structure called a locking node, which can be designed to be modular, isolated, and / or linkable.

[0095] A keyhole is a data structure that can accept any number of cryptographic keys, each of which can have an associated encrypted key mapping. Embodiments are not limited to the cryptographic key types they currently recognize and accept: passphrases, symmetric keys, and asymmetric key pairs. Any simple or complex method or process that defines a bit sequence as a key can be integrated into a keyhole. The encrypted key mapping can contain several sets of keys, one for each layer of access control within Nut: variable locking, SAC, and / or NAC.

[0096] A variable lock can provide different types of locking mechanisms within a normalized structure that can protect data within a lock node. These variable locks can include ORLOCK, MATLOCK, SSLOCK, XORLOCK, and HASHLOCK. The present invention is not limited to these predefined lock types and can be expanded or contracted to accommodate any appropriate locking scheme that can be normalized into its structure.

[0097] Hierarchical access control can regulate the permeability of access to individual lock nodes in a lock graph. This feature can give rise to a property of Nut called gradient opacity, which is the ability of a Nut to allow various levels of meta-data to be treated as given appropriate access attributes.

[0098] NUT access control or NAC can use role-based cryptographic access control (RBCAC) technology to fine-tune the modification and authentication of a NUT internal component.

[0099] Structured cryptographic programming can be used to design data structures that allow for easy and flexible interaction between different methods to express various access models. Security mechanisms can be fully embodied in the cryptographic data and its associated cryptography, eliminating the need for external applications (such as reference monitors) to control access to Nut. In some embodiments, a lock node can be used solely to protect field-level data in any portion of a payload. Nut container internal components can potentially utilize multiple cryptographic keys to implement a specific security model.

[0100] A Nut can be a directed graph data structure called a lock graph, 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 the Nut ID, so 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 a zero pointer. Using well-established programming graph extraction and traversal techniques, a lock graph can be derived from the hash array of lock nodes. A lock node that has no other lock nodes pointing to it can be a keyhole lock node (entry or external lock node). A lock node that can have a zero pointer can be a terminal lock node in a lock graph and can store a Nut payload or a reference to a 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 to itself. A circular link reference may be unusual but can be provided through custom programming of the custom Nut while ensuring this structure.

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

[0102] It should be noted that due to the data-centric nature of the present invention, most flowchart-type diagrams may be a mixture of traditional flowchart elements and data components, which can be referred to as a data flow diagram or flowchart. Furthermore, the interwoven nature of the node-locked design layer may make it difficult to expose the logical operation of its components in a completely linear manner without forward reference statements, so some rereading may be required on the part of the reader.

[0103] Figure 58 illustrates an embodiment of a Nut or lock graph 5800, which includes two logical sections: Nut lock 5802 and Nut portion 5804, employing multiple purpose aspects of modular lock nodes. The Nut lock 5802 section of the lock graph allows for complex cryptographic link locks to be interpreted for a given Nut using one or more lock nodes. There are currently five types of lock nodes defined in this disclosure, corresponding to five types of mutable locks: ORLOCK, MATLOCK, SSLOCK, XORLOCK, and HASHLOCK. Each lock node type may refer to a type of mutable lock internal locking mechanism that can be used at the heart of a particular lock node to protect cryptographic keys to storage areas and other lock node metadata and parameters. The lock transition illustrated in Figure 30 may be an embodiment of a mutable lock and may be used in the creation of a lock node. Successfully unlocking and traversing the Nut lock 5802 section of the lock graph may result in the Nut portion 5804 section of the lock graph 5800. There may be several lock nodes including a Nut portion 5804: hair 5820, tick 5822, seal 5824, vita 5826, bale 5828, and / or tale 5830. Nut portion 5804 may contain a Nut payload 5830 and / or metadata 5820-5828. The number and type of Nut portions of a lock graph may vary depending on the type of data the Nut can store and / or the design of the Nut for certain desired behaviors and characteristics. In this example, unlocking keyhole lock node 5806 (5816) may result in an appropriate cryptographic key, which can be inserted into the primary keyhole of lock node 5820 connected to 5818. Unlocking lock node 5820 may result in an appropriate cryptographic key, which can be inserted into the primary keyhole of lock node 5822 connected to 5818. Unlocking locked node 5822 may result in an appropriate cryptographic key, which can be inserted into the primary keyhole of the connected locked node 5824. Unlocking locked node 5824 may result in an appropriate cryptographic key, which can be inserted into the primary keyhole of the connected locked node 5826. Unlocking locked node 5826 may result in an appropriate cryptographic key, which can be inserted into the primary keyhole of the connected locked node 5828. Unlocking locked node 5828 may result in an appropriate cryptographic key, which can be inserted into the primary keyhole of the connected locked node 5830. Lock node 5830 may be connected to a zero pointer and thus may be the terminal locked node or innermost layer of the lock graph or Nut. Unlocking a locked node may include decomposing (expanding) a folded data structure representing the locked node using the SDFT method. Each locked node may contain multiple folded data structures, where the act of unlocking a locked node may be equivalent to expanding the applicable data structure.

[0104] FIG59 shows a simplified Nut diagram 5900 of a lock diagram embodiment including logical sections Nut lock 5902 and Nut portion 5904. This example explores a Nut lock 5902 including four lock nodes 5908, 5910, 5912, and 5916. Lock nodes 5908-5912 can be keyhole lock nodes 5906 for this Nut, as some or all of them can be outward-facing nodes and accept external cryptographic keys, referred to as primary keys. A user can have primary keys associated with one or more of these keyhole lock nodes. The Nut ID of a Nut that stores a primary key as its payload can serve as a key ID that can be automatically matched to the identifier of the keyhole to which it belongs in the keyhole lock node 5906. A passphrase key can be identified by a key ID or a text string that may or may not hold a challenge as its identifier. Complex multi-layered passes can be constructed using appropriate keyhole identifiers and plaintext Nut metadata sections with appropriate challenge lists. In a similar manner, links between locked nodes (such as 5914 and 5918) can be disconnected, where successfully unlocking a locked node can produce one or more output keys with an identifier. In this particular example, unlocking any of the keyhole locked nodes can reveal the appropriate cryptographic key, which can be inserted into the keyhole of the locked node 5916 connected to 5914. From this point on, unlocking a node including Nut portion 5904 can proceed similarly to the procedure described for Nut portion 5804. This Nut lock 5902 construction can convey the flexibility of the lock node's establishment block nature and its combination by showing that there can be three different paths to unlock the payload of Nut 5900, each path requiring different conditions to be met in order to proceed with the unlocking process.

[0105] In FIG60 , a lock node 6000 may be a data structure comprising the following sections: parameters 6002, inputs 6006, key mapping 6008, variable lock 6012, derived key 6016, key set 6020, package 6024, and / or output 6026. The parameter section 6002 may hold the lock node's underlying data, lock ID 6030, and encrypted strings of key mapping 6010, derived key 6014, key set 6018, package 6022, and a flag for these encrypted strings generated from the appropriate access role key for the lock node (a forward reference may be described in the discussion of element 8334 in FIG83 ). The design principle may be similar to the process in a lock diagram with each section unlocked, which may result in a key that can help open the next section, but then each component within the lock node may provide a specific function. The flag on the encrypted string can be used by a reader (an access role) to authenticate a specific section before a decryption attempt. When a modification is possible, the writer (an access role) of a particular segment can use the segment's encrypted string to generate a flag to retain or indicate to the appropriate writer access key holder the flag. Furthermore, each of the aforementioned encrypted strings can be represented using the SDFT method, using a TAR folded data structure containing cryptographic transformations. Given the number and variety of encrypted strings described in this section, the SDFT method can significantly reduce the burden on programmers to manage cryptographic-related attributes during coding. keyhole

[0106] In Figure 61 , the input section 6006 of the lock node can provide two different keyholes: a primary keyhole 6102 and an access keyhole 6104. Structurally, a primary keyhole 6102 can accept any number of cryptographic keys, including four different key types: symmetric, asymmetric public, asymmetric secret, and passphrase. Access keyhole 6104 can accept symmetric and / or passphrase key types. The primary and access keyholes can internally utilize one or more KISS data structures, as shown in Figure 34 , each operating in a keyhole mode (ima = "keyhole") to represent the keyhole for each unique key it accepts.

[0107] Figure 62 shows a single cryptographic key 6202, which may have an associated key ID, key type, and key attributes 6206 and may also be designated as a primary key. The key ID can be any identifying string. The primary key and any other keys mentioned in this disclosure can each be represented internally by a KISS data structure operated in a key mode (ima="key") as shown in Figure 34, with key->value fields filled with the key and other matching attribute fields filled as needed. A primary keyhole 6204 can accept a primary key 6202 that can decrypt an encrypted key map 6208. The decrypted key map 6240 can be a structure that includes three sections: primary key 6210, level key 6212, and access key set (AKS) 6214. The primary key structure may contain a symmetric key or tail (which may be referred to as the primary key), the expiration date / time of the primary key 6202, a countdown timer for the primary key, and / or instructions for action upon expiration of the primary key. Symmetric keys or tails can be used by the lock node's mutable lock. For a keyhole lock node, the key mapping structure can additionally hold a hierarchical key 6212 and / or an AKS 6214. Hierarchical keys 6212 can hold a set of keys to be inserted into hierarchical lock nodes in the lock graph, which can be identified by their hierarchical designation. AKS 6214 can hold a set of keys to be inserted into a keyhole lock node's own access keyhole 6104. Encrypted key mapping 6208 can be a SDFT folded data structure that can contain a master key 6210, hierarchical keys 6212, and an access key set (AKS) 6214 structure.

[0108] FIG63 shows a flow chart of the key insertion process for any lock node and any cryptographic key. Step 6304 may be a search across some or all of the listed lock nodes in Nut for a given cryptographic key and its associated key ID. Once a cryptographic key has been inserted into the appropriate keyhole 6304, step 6306 may attempt to decrypt and expand the encrypted key map for that key. Decryption and expansion of the encrypted key map may be equivalent to the decomposition of the SDFT-folded cryptographic key map in these embodiments.

[0109] After a keyhole lock node is successfully unlocked and expanded via one of the encrypted key maps 6208, 1) the level key can be inserted into the primary keyhole of each lock node to match the level designation found in the parameter section of each lock node, and 2) the access attribute key set unlocking key (AAKSUK) of the access key set (AKS) can be inserted into the access keyhole of the lock node. Since so many primary keys may have been inserted into the lock node, this master key unlocking (or unpacking) may occur, after which we have a set of decrypted (or expanded) key maps that together form a set of master keys that can be used by the lock node's variable lock.

[0110] Figure 64 shows an example in which three primary keys 6402-6406 can be inserted into a primary keyhole 6400. Each key (→) can be matched to its identifying key ID and inserted into a slot in a hash array or KISS keyhole structure. Key type can indicate a key type, such as, but not limited to, symmetric, asymmetric public, asymmetric private, and passphrase. In some embodiments of Nut, a user can specify any key type with a corresponding cryptographic method that is appropriately modularized for Nut integration. These key cryptographic methods may include fingerprint scans, iris scans, palm prints, voice prints, handwriting patterns, facial recognition, DNA characteristics, physical key devices, hardware security keys, software / hardware-based zero-knowledge agreement 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 can be extracted from the private portion and used to encrypt the encrypted key mapping of the primary key, so decryption operations may require the presence of a private asymmetric key. As clearly shown for a key (→) inserted into a keyhole 6402, its encrypted key map 6412 can be decrypted using a key-type cryptographic method to reveal a key map structure 6430 that may contain three distinct sets of primary keys 6432, level keys 6434, and access keys 6436. This decryption step can be performed for each of keys 6404 and 6406 to produce corresponding key map sets 6440 and 6450, respectively. Each decryption step can also be equivalent to unpacking a SDFT folded structure of these embodiments. For a passphrase key type, the key can be a passphrase, and the key attributes can indicate the passphrase derivation function used and the appropriate parameters for that function, including the number of iterations performed to generate the symmetric key that can decrypt the encrypted key map. For embodiments utilizing SDFT, these passphrase attributes can also be matched with a corresponding TAR to access the appropriate derivation transformation with matching attributes. To put the example into perspective using the locked node graph 6000 , the input section 6006 may contain a primary keyhole 6400 , the encrypted key map 6010 may be represented by 6410 and the key map 6008 section may be represented by 6420 . Variable lock

[0111] Below the lock node may be a variable lock, as shown in element 6012 of FIG. 60 . Variable locks may be a locking mechanism that can help protect the contents of the lock node stored in package 6024. Variable locks allow a lock node to utilize any of several different types of cryptographic lock 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 lock method to fit a common data flow model, thereby allowing seamless replacement of each lock method. Similarly, the primary keyhole and key mapping structure can serve as a data normalizer for the number and type of keys flowing into a variable lock. A lock node may be imprinted with a set of parameters 6002 indicating the variable lock types 6030 it can implement. Once these values are set, a lock node can rarely change these settings, although the RAT (owner of Nut) may re-encrypt and / or reset the lock node. The SDFT library describes one embodiment of a variable lock and its accompanying specifications as listed in FIG. 30 (which may be used in this section for convenience), but the use of lock transitions is not a necessary requirement to implement this functionality of a lock node.

[0112] Continuing the traversal of the lock node in Figure 64, we end up with three master keys 6432, 6442, and 6452. We can explore how its variable lock can operate in Figure 65. Variable lock 6502 can protect a derived key (DK) 6506 by encrypting it into an encrypted derived key (eDK) 6504. Some or all of the master keys 6432, 6442, and 6452 can be symmetric or tail key types and can be fed into variable lock 6502. Depending on the variable lock type, which can be specified in the lock node parameter sections 6002 and 6030, the appropriate variable lock function can be called to perform encryption / decryption operations on the DK or eDK. Figure 65 shows a decryption operation using variable lock 6502, which can use master keys 6432, 6442, and 6452, to decrypt eDK 6504 into DK 6506. Figure 66 shows an encryption operation of encrypting DK 6506 into eDK 6504 by using variable lock 6502 using master keys 6432, 6442, and 6452. In an embodiment using SDFT, DK can be data protected by a TAR that uses a lock transformation through a data fold; therefore, unfolding this structure reveals the derived key contained therein.

[0113] The table in FIG67 summarizes some key characteristics mentioned for variable locking. As the term variable locking implies, any locking technique that can be formalized into this model can be added as an additional variable locking type. Alternatively, any locking technique can be excluded. The table in FIG30 corresponds to the table in FIG67 and shows how SDFT can embody variable locking designs in its locking transitions.

[0114] The lock node's backend data segment 6030 may be a common component involved in some or all variable locks. Various identifiers (digital signatures) may be present in the lock node segment, which may have been generated using an appropriate access role key (ARK) such as 6040 through 6048 (forward reference). Some of these identifiers may be generated by a Nut owner, who may be any entity that maintains a Restricted Access Layer (RAT) access role key (specifically, a RAT private key) through its AKS. Owners with a valid primary key may possess a RAT public key, which enables them to authenticate various RAT identifiers 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 may be referred to as the RAT writer key. Further discussion of the Nut access control layer later in this document may further explore, define, and / or clarify these features. As mentioned previously in the section on SDFT and TAR, the identifier of the encrypted data can be part of the TAR specification of a folded data structure, which allows the protected data, its identifier, and the TAR that generated it to be embedded. This clearly implies that a systematic use of SDFT within a locked structure can be advantageous for programmer workloads.

[0115] An ORLOCK (also called an OR key) in Figure 68 is a variable lock that accepts any number of symmetric cryptographic keys, referred to as master keys 6808, and systematically attempts to decrypt 6814 the eDK 6806 using a symmetric cryptographic cipher (such as AES-256 or a substitution cipher). The 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, which can result in a successful unlock of the ORLOCK. Before a decryption attempt in any variable lock, the eDK 6804 signature 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 may be generated and the attempt may be stopped. The master key 6808 can be a unique key, such as, but not limited to, a symmetric 256-bit key. In this configuration, the essence of an OR lock can be isolated and formalized into a keyhole and variable locking structure to make it modular. In a folded structure, the authentication step can be part of the TAR and can be attempted implicitly by the act of disassembly.

[0116] Figure 69 depicts an ORLOCK cryptographic operation from the perspective of a RAT writer or Nut owner. It can employ any master key 6902 and perform a cryptographic operation 6920 on DK 6906 using an appropriate password to generate an eDK 6908. Then, using its RAT writer key 6904, eDK 6908, and an appropriate signature algorithm, it can generate 6922 a signature for eDK 6910, which can be stored in the lock node parameter section 6044. The SDFT method can compactly fold many of these attributes, along with the eDK, into a single data object for storage in the parameter section. The encryption process for non-RAT components of a locked node can be simple; they can erase the locked node's application memory contents, as they do not generate a true flag indicating that they cannot successfully modify its contents and mark it. Alternatively, they can use decrypted DK 6908 and encrypt the relevant contents of the locked node, but leave the eDK 6910 unaffected, as the content associated with the eDK flag is not changed. This means that only RAT writers can replace the value of DK 6906 or re-encrypt it. When using the SDFT method, non-RAT components of a locked node can choose to leave the original folded data containing the eDK in the parameter section and erase the expanded structure of the retained DK.

[0117] A MATLOCK (also known as a matroyshka lock, cascade lock, or AND lock) in Figure 70 is a variable lock that accepts a fixed number of symmetric cryptographic keys, called master keys 7006, and can be used to sequentially decrypt 7014 the eDK 7022 using each master key 7008 in ascending order using a suitable cryptographic cipher (such as AES-256 or a substitution cipher). The parameter section indicates the exact cipher used for this logical operation and the number of master keys required, or the preferred TAR when using the SDFT method. Successful sequential decryption of the eDK 7022 repeatedly generates the DK 7024 and can result in a successful unlocking of the MATLOCK. Before any decryption attempt within the variable lock, the eDK 7004 signature can be verified using the eDK 7022 and the RAT reader key 7002. If verification is successful 7010, the decryption process can continue; otherwise, an error 7030 is generated and the attempt is aborted. In this configuration, the essence of a matroyshka lock can have been isolated and formalized into a keyhole and a variable locking structure to make it modular. In a folded structure, the authentication step can be part of the TAR and can be attempted implicitly by the act of disassembly.

[0118] Figure 71 depicts a MATLOCK cryptographic operation from the perspective of a RAT writer or Nut owner. It may employ some or all of the presented master keys 7102 and may sort them in descending order 7110. It may then repeatedly perform cryptographic operations 7112 on the DK 7120 using an appropriate cipher to generate an eDK 7122. Using its RAT writer key 7124, the eDK 7122, and an appropriate signature algorithm, it may generate 7118 a signature for the eDK 7126, which may be stored in the lock node parameter section 6044. The SDFT method can compactly fold many of these attributes, along with the eDK, into a single data object for storage in the parameter section. The encryption process for non-RAT components of a locked node can be simple; they can erase the locked node's application memory contents, as they do not generate a true flag indicating that they cannot successfully change its contents and mark it. Alternatively, they can use decrypted DK 7120 and encrypt the relevant contents of the locked node, but leave eDK 7126 unaffected, as the content associated with the eDK flag is not changed. This means that only RAT writers can replace the value of DK 7120 or re-encrypt it. When using the SDFT method, non-RAT components of a locked node can choose to leave the original folded data containing the eDK in the parameter section and erase the expanded structure of the retained DK.

[0119] An XORLOCK (also known as an XOR lock) in Figure 72 is a variable lock that accepts a fixed number (>1) of symmetric cryptographic keys, referred to as master keys 7206, and generates a calculated key by sequentially applying an XOR operation 7224 to each master key 7208 in increasing order 7222. It then attempts to decrypt 7228 the eDK 7210 using the calculated key from 7224 with an appropriate cipher (such as AES-256 or a substitution cipher). The parameter section 6030 indicates the exact cipher used for this logical operation and the number of master keys required (which may not be less than two keys) or, if using the SDFT method, the preferred TAR. Successful decryption of the eDK 7210 generates the DK 7212 and results in a successful unlock of the XORLOCK. Before any decryption attempt within the variable lock, the eDK 7204 signature can be authenticated using the eDK 7210 and the RAT reader key 7202. If authentication succeeds 7220, the decryption process can continue; otherwise, an error 7230 may be generated and the attempt may be stopped. In this configuration, the essence of an XOR lock can be isolated and formalized into a keyhole and variable lock structure to make it modular. In a collapsed structure, the authentication step can be part of the TAR and can be implicitly attempted by the act of disassembly.

[0120] Figure 73 depicts an XORLOCK cryptographic operation from the perspective of a RAT writer or Nut owner. It may employ some or all of the presented primary keys 7302 and may sort them in increasing order 7320. It may then repeatedly perform XOR operations 7322 on the primary keys 7304 to generate a calculated key, which can be used to encrypt 7326 DK 7306 to generate eDK 7308. The RAT writer key 7310, eDK 7308, and an appropriate signature algorithm may be used to generate 7328 a signature for eDK 7312, which may be stored in the lock node parameter section 6044. The SDFT method can compactly fold many of these attributes, along with the eDK, into a single data object for storage in the parameter section. The encryption process for non-RAT components of a locked node can be simple; they can erase the locked node's application memory contents, as they do not generate a true flag for any content that indicates they cannot successfully change its contents. Alternatively, they can use decrypted DK 7306 and encrypt the relevant content of the locked node while leaving eDK 7312 unaffected, as the content associated with the eDK flag is unchanged. This demonstrates that only RAT writers can re-encrypt DK 7306. When using the SDFT method, non-RAT components of a locked node can choose to leave the original folded data containing the eDK in the parameter section and erase the expanded structure of the retained DK.

[0121] A HASHLOCK (also known as a hash lock) in Figure 74 is a variable lock that accepts a fixed number of symmetric cryptographic keys, called master keys 7406. It generates a calculated key by concatenating 7424 some or all of the presented master keys in a specific order 7422. It then applies a hash algorithm 7426 to the string. It then attempts to decrypt 7428 the eDK 7410 using the calculated key with an appropriate cryptographic cipher, such as AES-256 or a substitution cipher. The parameter section 6030 can indicate the exact cipher and hash used for these logical operations, the number of master keys required, and / or the order in which they are sorted, or the preferred TAR when using the SDFT method. Successful decryption of the eDK 7410 generates the DK 7412, which can result in a successful unlocking of the HASHLOCK. Before any decryption attempt in a variable lock, the identity of the eDK 7404 can be authenticated using the eDK 7410 and the RAT reader key 7402. If the authentication succeeds 7420, the decryption process can continue; otherwise, an error 7430 may be generated and the attempt may be stopped. In this configuration, the essence of a hash lock can be isolated and formalized into the keyhole and variable lock structure to make it modular. In a collapsed structure, the authentication step can be part of the TAR and can be implicitly attempted by the act of disassembly.

[0122] Figure 75 depicts a HASHLOCK cryptographic operation from the perspective of a RAT writer or Nut owner. It takes the presented master keys 7502 and sorts them in increasing order 7520. It then concatenates them 7522 and performs a hash operation 7524 on them to generate a calculated key. This calculated key can be used to encrypt 7526 DK 7506 and generate eDK 7510. The RAT writer key 7508, eDK 7510, and a suitable signature algorithm can be used to generate 7528 a signature for eDK 7512, which can be stored in the lock node parameter section 6044. The SDFT method can compactly fold many of these attributes, along with the eDK, into a single data object for storage in the parameter section. The encryption process for non-RAT components of a locked node can be simple; they can erase the locked node's application memory contents, as they do not generate a true flag for any content that indicates they cannot successfully change its contents. Alternatively, they can use decrypted DK 7506 and encrypt the relevant content of the locked node while leaving eDK 7512 unaffected, as the content associated with the eDK flag is unchanged. This demonstrates that only RAT writers can re-encrypt DK 7506. When using the SDFT method, non-RAT components of a locked node can choose to leave the original folded data containing the eDK in the parameter section and erase the expanded structure of the retained DK.

[0123] The SSLOCK in FIG76 (also known as a secret sharing lock or Shamir's secret sharing scheme) is a variable lock that accepts k out of n master keys 7606, each of which can be a different tail or secret share, where 1>p+1≤k≤n and p+1 can be the minimum number of keys required (called a threshold). To recover 7622 the key, some or all tails from the decrypted key map 7606 can be provided to a suitable secret sharing cipher, such as the Shamir's secret sharing scheme or a substitution cipher. If some or all tails are valid and a sufficient number of tails are present, recovery can be successful. Then, an attempt can be made to decrypt 7624 the eDK 7608 using the recovered key with a suitable cryptographic cipher, such as AES-256 or a substitution cipher. Parameter section 6030 may indicate the exact password used for secret sharing and encryption operations, as well as the number of shares (n) and threshold count (p+1) used for the secret sharing password and / or the preferred TAR when using the SDFT method. Successful decryption of eDK 7608 generates DK 7610 and can result in successful unlocking of the SSLOCK. Before any decryption attempt in a variable lock, the eDK 7604 signature can be authenticated using eDK 7608 and RAT reader key 7602. If authentication succeeds 7620, the decryption process can continue; otherwise, an error 7630 may be generated and the attempt may be stopped. In this configuration, the essence of a secret sharing lock can be isolated and formalized into a keyhole and variable lock structure to make it modular. In a collapsed structure, the authentication step can be part of the TAR and can be implicitly attempted by the act of decryption.

[0124] Figure 77 depicts the encryption operation of an SSLOCK from the perspective of a RAT writer or Nut owner (who may be encrypting the lock node for the first time or in the process of re-encrypting the variable lock). A new secret cryptographic key K may be generated 7720, and then the desired number of shares (tails) may be generated from K using an appropriate secret sharing method, which may be specified in parameters 6030. These tails may then be stored as master key 7702. In step 7724, key K may be used to encrypt DK 7704, thereby generating eDK 7706. The RAT writer key 7708, eDK 7706, and an appropriate signature algorithm 7726 may be used to generate a signature for eDK 7710, which may be stored in the lock node parameter section 6044. The SDFT method can compactly fold many of these attributes, along with the eDK, into a single data object for storage in the parameter section. The encryption process for non-RAT components of a locked node can be simple; they can erase the locked node's application memory contents, as they do not generate a true flag indicating that they cannot successfully modify its contents. Alternatively, they can use decrypted DK 7704 and encrypt the node's related contents while leaving eDK 7706 unaffected, as the contents associated with the eDK flag are unchanged. This demonstrates that only RAT writers can re-encrypt DK 7704. When using the SDFT method, non-RAT components of a locked node can choose to leave the original folded data containing the eDK in the parameter section and erase the expanded structure of the retained DK.

[0125] The description of variable locking and its various logical operations illustrate how a locking node can use the primary keyhole 6102 in the input section 6006, the encrypted key map 6010, the key map 6008, the variable lock 6012, the encrypted derived key 6014, and / or the 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 changes and / or re-encryption. Normalization of different locking methods ensures that the user primary key of Nut is unaffected and that a single user primary key can be used across many different locking techniques, unknown to the user, and suitable for protecting a specific Nut payload. The sections where the SDFT method can prove advantageous in some embodiments of these complex data structures are highlighted. Here are some examples. An ORLOCK can allow multiple users to gain access to packets of the locking node: this can be a form of group access, or one of the keys can represent a master key. A MATLOCK, XORLOCK, or ASHLOCK can ensure that a specific number of keys exist to decrypt its package: a sensitive corporate secret might require two specific senior executives to supply their respective keys to view its contents. An SSLOCK might require that a minimum number of keys exist to gain access to its package: a corporate payment system can be accessed by a minimum number of authorized individuals but cannot be operated independently.

[0126] By partitioning each primary keyhole using its corresponding key mapping, the key mapping can contain attributes of the primary key, such as, but not limited to, an expiration date / time, a countdown timer, and / or an expiration action. If any of the expiration attributes has been initiated, a corresponding expiration action can be set to execute after the primary key expires. For example, a typical expiration action might be to delete the primary key's key mapping. Deleting a key mapping can, due to its partitioning design, not interfere with any other registered primary keys for the keyhole lock node. Reinserting an expired primary key may no longer be recognized as a valid key because a matching key mapping may not exist. Of course, such primary key deletion should be carefully considered with respect to the variable lock type employed: ORLOCK and some SSLOCKs can accept deletion, but MATLOCK, XORLOCK, and HASHLOCK cannot, as it may create a lockout condition for the lock node.

[0127] The interplay of complex data structures (which may utilize multiple cryptographic techniques to protect their content in various ways and at various levels) can pose significant implementation challenges due to the exceptionally large number of variable attributes required and / or generated by each cryptographic operation. In these situations, the utility and elegance of SDFT becomes apparent, providing a convenient organizational approach and structure to help overcome these implementation challenges. For example, a single authenticated encryption of data may require the following attributes to be stored 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), digest's matching key ID, digest length, digest key length, digest method. Multiply this by each cryptographic operation described in the Locked Node specifications presented thus far (Locked Node has several more components discussed in subsequent sections), and it can be a significant number of attributes to keep track of. In many cases, application programmers and designers may be aware of these dilemmas and challenges and may choose to simplify the coding process by selecting a small number of encryption methods and associated attribute values and using them in a global manner throughout their implementation. Such simplifications may lead to undesirable consequences such as, but not limited to, less security, less flexibility, fewer features, more incompatibilities, and computer code that may be more difficult to maintain or modify. Hierarchy

[0128] Figure 78 shows a block diagram (lock diagram) 7800 of a Nut, highlighting the use of hierarchical keys. Each lock node in the Nut portion 7804 can be assigned a level ID. Lock nodes 7820 through 7824 are level ID "A," lock node 7826 is level ID "B," lock node 7828 is level ID "C," and lock node 7830 is level ID "D." The designation of levels can be arbitrary but can follow a grouping pattern in privacy sensitivity with the various Nut portions: the deeper the level, the more sensitive the data contained in the lock node. Through the careful use of hierarchical access control (SAC), a gradient of opacity can be implemented for a Nut. For illustrative purposes, the level IDs depicted in Figure 78 are simple letters, but in reality they can be any set of recognizable strings, such as, but not limited to, Nut IDs (as in the actual unique ID from Figure 55).

[0129] Any lock node, including Nut lock 7802, can be assigned a level. When the keyhole lock node of Nut 7806 is properly unlocked or disassembled, it can display a key map 7840 (similar to Figure 62), which can include up to three key groups 7842. This section can focus on level keys 7850 (6212) and how they can be used within a 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 the flowchart presented in Figure 79, which shows how each level key can be used. Once some or all level keys have been inserted into the primary keyholes of their matching lock nodes, the process can be completed and we can wait for the lock graph traversal to continue beyond Nut lock section 7802.

[0130] Hierarchical keys can be combined with a MATLOCK variable lock, as shown in the Nut section 7804, for some or all lock nodes. When using the SDFT method, a MATLOCK can be indicated by a "lock matlock" transition in the preferred TAR of the section in question. Each hierarchical key can be a mandatory key in a MATLOCK for the lock node in question (* in Figure 79). If the lock node's output link key or hierarchical key is missing, the specific lock node cannot be unlocked according to the definition of a MATLOCK. Therefore, some or all deeper levels beyond that level may not be unlocked. By controlling which hierarchical keys are stored in a key map 7840 of the primary key, the Nut owner can explicitly control how far someone can penetrate the lock graph 7860. The hierarchical access control layer can operate independently of the Nut access control layer and can be combined with variable locking methods.

[0131] The methods that SAC and keyholes can perform suggest that if multiple keys can be present in a keyhole lock node (such as 7806), multiple key mappings 7840 can be displayed and potentially multiple hierarchical key sets 7850 can be inserted into various lock nodes. The hierarchical keys for a single hierarchical ID can be identical, so inserting the same key into a lock node that can utilize a MATLOCK can result in a key being inserted under that ID, essentially overwriting the same key multiple times in the keyhole. This can be an additional access attribute property of the hierarchical keys.

[0132] Both hierarchical keys and Nut access control (discussed in the next section) can exhibit an additional access attribute property or characteristic. Inserting primary keys of different access levels into the primary keyhole of a lock graph can result in the lock graph's access level representing the combination or union of all valid access levels for the inserted primary keys. A powerful use of this property can be to distribute the keys for a given lock graph in a segmented manner, where a combination of primary keys may be required to obtain a very specific access level to the lock graph. This can be in contrast to a mode of operation in which a primary key can present a complete picture of the key holder's given access. Nut Access Control

[0133] Nut Access Control, or NAC, is an access control method that uses a cryptographic data structure that can operate independently of variable locking and hierarchical access control. NAC can use a combination of role-based access control (RBAC) and cryptographic access control (CAC), which we may refer to as role-based cryptographic access control (RBAC) or key-based permissions (KBP). NAC attribute keys can be localized as internal components of a single lock node. However, within a lock node, mechanisms can exist to propagate NAC attributes throughout the rest of the lock graph, allowing key holders to have consistent access levels across associated lock nodes. These NAC attributes can be found in an unlocked or unlocked keyhole lock node, where a primary key can be inserted from an external source. Similar to hierarchical keys, NAC keys can exhibit additional access attribute properties.

[0134] KBP can be implemented using well-known properties of public-key cryptography, such as generating digital signatures (signals) and asymmetrically authenticating them over a data string using algorithms such as RSASSA-PSS (the RSA parasitic signature scheme with an appendix based on the parasitic signature scheme originally invented by Bellare and Rogaway) or alternative algorithms. The basic premise of KBP is that, given a private / public key pair, the holder of the private key (writer) can use the writer's private key to generate a digital signature (signal) on a data packet, and then the holder of the public key (reader) can use the writer's public key, held by the reader, to authenticate the sign generated by the writer on the data packet. If authentication fails, something—the public key, the data packet, the sign, or some or all of these—may have been compromised. The writer is responsible for generating an updated sign on the target data packet after each modification, and the reader is responsible for authenticating both the sign and the target data packet before "reading" or decrypting the data packet. This procedure provides reasonable assurance to readers that they can read something created or modified by someone (the writer) who possesses the corresponding private key. In role-based cryptographic access control (RBCAC), each defined access role can have an asymmetric key pair, with the "writer" role having access to the private portion of the key, and the "reader" role having access to the respective public portion of the key. By separating data sets by function and labeling each functional data set with a key pair, access roles can be precisely defined and assigned to key holders by distributing the appropriate key portion. NUTS's RBCAC allows one or more symmetric keys to be coupled with the asymmetric key pair of a defined role to provide an additional layer of control over the target data set. The holder of a coupled symmetric key can decrypt and read the target data set for that role. This coupled symmetric key can be used to encrypt the target data set on top of the symmetric key encryption revealed by the variable locking and subsequent unlocking of the key in the eKS. Alternatively, the presence of a coupled symmetric key can modify the use of the displayed encryption key from the eKS and can be the only key that symmetrically encrypts the target data set. This alternative may be preferable for larger target data sets because they will not be encrypted more than once. The coupled symmetric key can be used to control read access to a target data set.

[0135] In one embodiment of the NAC, the use of SDFT can significantly simplify encoding. Encryption and marking can be embedded into a logically cohesive TAR appropriate for the function to be performed, and the SDFT disassembly process can largely automate the detailed processing of these operations. Any localized attributes associated with the TAR can be folded with the target data or further folded with another TAR to simplify its protection and storage.

[0136] The table in Figure 80 shows how key-based permissions can work with three defined roles (reader, writer, and validator) 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 signature on encrypted data using asymmetric private key R. Using asymmetric public key U, reader classes (COR) A and B have the ability to verify that a corresponding digital signature was generated on encrypted data by someone from the writer class, and they also have the ability to decrypt data using symmetric key S. Therefore, the ability to generate a valid signature implies the ability to modify data, and all other readers can verify that the signature was generated by a valid writer. The number of roles defined depends on the access control granularity desired by the owner, but some or all defined roles can utilize the approach described in Figure 80. A role player who possesses only the asymmetric public key U is called a validator. A validator may be able to traverse the entire Nut but may not be able to decrypt the target data corresponding to the role class. For example, a COR validator may only authenticate that the payload of Nut has been properly modified by a proper COW role player using the COW public key on the token, but it cannot decrypt the payload because it does not have a copy of the decryption key S.

[0137] NAC can precisely influence and control the visible and modifiable content state of a locked node, and thus the content state of a Nut. The table shown in Figure 81 lists some of the parts of a Nut, but may contain more or fewer parts than desired: hair, tick, seal, vita, face, tale, and / or bale. The table may contain forward references to the Nut log and Nut history, which will be explained in detail later in the document. Each column may represent a locked node, and the data defining the Nut parts may be stored in the package of that locked node. The column titled "Package Opacity" may display the encryption mode of the package of the locked node, which can be controlled by the metadata of the locked node. The package can be encrypted or not (explicitly) based on metadata set as packet opacity. If some or all of the Nut parts in the table in Figure 81 are present in a given Nut, the Nut parts that can be represented by a locked node can be linked sequentially from top to bottom using the locked node link pointer and link key. Traversing down the columns of this table relative to the packet opacity of each Nut portion can be referred to as the gradient opacity of a Nut. The holder of an appropriate external primary key can gain access to a Nut by ultimately unlocking the variable lock of the lock node. Depending on the SAC setting of the primary key, a key holder may be limited in how far they can traverse into a Nut. NAC can influence which primary keys are allowed to have the ability to read, modify, and / or authenticate each Nut portion by coupling careful placement of symmetric cryptographic keys, precise use of asymmetric key pairs, and the use of digital signature methods.

[0138] Figure 82 shows a table listing the key-based permission 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 sections of a Nut, which may be identified but not limited to: Bale, Vita, Tale, and All. The All section may refer to anything not explicitly covered by another access role. This may require some or all of the internal work of a locked node, such as, but not limited to, flags on key maps, eDKs, and / or encrypted packets not specified by a key pair representing a separate access role. For this discussion, a key pair may include an asymmetric key pair and a coupled symmetric key. The presence of the coupled symmetric data may depend on the presence of an access class validator role. The holder of the All private key may be referred to as a RAT (Root Access Layer) or the owner of the Nut. Each primary key may have a key map containing a copy of the RAT reader's public key for authentication purposes. Bale can be stored in a package (such as a file) that locks a node to a Nut's payload. This key pair may be specifically named as a Class of Writer (COW) and a Class of Reader (COR) due to its frequent use. This key pair controls which primary key has the ability to modify a Nut's payload. In a similar manner, the Nut log can be stored in a package in the Vita portion of a Nut and controlled by a Logger / Log Reader key pair. The Nut history can be stored in a package in the Tale portion of a Nut and controlled by a History Recorder / History Reader key pair. A validator role in each access role class may have access to at least one public key associated with that role in order to authenticate the associated token. A validator role may imply the existence of a coupled symmetric key associated with an access role class to which it does not have access. A maintenance program can be given access to a combination of defined validator roles within a Nut to check the validity, consistency, and / or authenticity of the Nut portion, but cannot read the contents of the 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 of a lock node can have a signature generated on it using its own specific key pair, and all lock nodes in a lock graph can adopt this level of specificity, which can lead to an extreme level of access control granularity; however, this extreme level of access control granularity can reduce the effectiveness of access control on these nodes.

[0139] The parameters section of the lock node can specify the digital signature algorithm used and the length of the asymmetric key (defaulting to a minimum of 2,048 bits for RSA-2048). Alternatively, SDFT usage may allow a specific TAR to indicate these preferences, and the TAR tag may instead be stored in the parameters section. The encrypted package of the lock node, which may hold a payload of Nut, may not be digitally signed by a RAT writer using the RAT writer key, but rather by a key holder with COW access (which may include the RAT writer). Primary key holders may be given access to the RAT reader key via their access key settings and a corresponding access attribute propagation key (AAPK) in their key mappings of the keyhole lock node; this RAT reader key may allow any legitimate primary key holder to authenticate any token within the lock node (instantiated by a primary key holder with access to the RAT writer key) within the RAT's authorized domain. Any failure to authenticate any RAT flag may indicate that the corresponding string or folded data may have been compromised, or that the RAT reader key may be invalid, or that the primary key may no longer be valid, or some or all of the reasons mentioned. The present invention may display this warning and may not continue the process because the integrity of Nut may be compromised and further decryption attempts may fail or may result in the display of compromised data.

[0140] FIG83 illustrates how a Nut obtains its primary NAC access key set. Starting at keyhole lock node 8300, a primary key 8304 can be inserted into primary keyhole 8306 and the encrypted key map can be decrypted or expanded, revealing key map structure 8310. An access key set (AKS) 8312 may exist, containing a set of keys consisting of access attribute key set unlocking keys (AAKSUKs) 8314, which may be symmetric. Each individual AAKSUK symmetric key may correspond to an access role, as shown in the table in FIG82. Each AAKSUK in the AKS can then be inserted into an access key hole 8320 (e.g., initial primary key hole 8306) in the same input section 8302 of the same lock node 8300. Thus, key map 8310 may contain a set of keys in AKS 8312 that can feed its own access key hole 8320. This may be a special property of keyhole-locked nodes (outward-facing lock nodes) and may not apply to internal lock nodes in most cases. In the access keyhole 8320, each appropriately inserted AAKSUK 8314 can be decrypted or expanded to reveal a corresponding access attribute key set (AAKS) 8330, which includes an access role description 8332, an access role key (ARK) 8334, and / or an access attribute propagation key (AAPK) 8336. ARK 8334 may specify the portion of a key pair corresponding to a given role: public (reader) or private (writer). AAPK 8336 may be a symmetric key that can serve as an AAKSUK in the access keyhole of the next connected lock node. The AAKSUK group may form a set of AAKSs that define the NAC access attributes of the primary key and ultimately its access within the lock node. In this diagram, AAKS 8330 can define the access attributes of a Nut owner, as it contains the RAT secret key and the COW key. Additional attributes of the AAKSUK (and therefore of the NAC) are illustrated in this diagram. Each primary key 8304 can have an AKS 8312, which can be inserted into the primary keyhole 8306. Therefore, each insertion of an AAKSUK 8314 into the access keyhole 8320 can be additive. The same AAKSUK can simply overwrite an existing one through the access keyhole, which can result in a unique AAKS association when some or all presented primary keys have been processed. This can also lead to a cumulative access attribute effect when primary keys with different access attributes can be inserted simultaneously.

[0141] Figure 84 illustrates how AAPK can be used to propagate NAC attributes throughout the rest of the lock nodes in the lock graph. Keyhole lock node 8400 may already be properly unlocked, and some or all AKSs 8402 may already be inserted into access keyhole 8404, which may result in AAKS 8420. Access attribute propagation key (AAPK) 8424 may then be inserted into access keyhole 8432 of the next connected lock node. Note that this is similar to how the access keyholes of a keyhole lock node may be filled, but these keys come from a connected lock node rather than from an AKS that may or may not be found in its own primary keyhole. The primary keyhole (not shown) of internal lock node 8430 may have an empty AKS in a key map, in addition to the RAT access level key. By following this propagation method, the access attributes of the primary key may be present in every open lock node in the lock graph. A lock node can isolate and localize some or all of its internal control mechanisms, such as having a different set of AAKS generated within the lock node for its own purposes, even though the access role may be the same (such as 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 assign a complete set of AAKS to the RAT for the entire lock node and for the lock nodes to be properly propagated throughout its lock graph. For reference, there can be a complete set of AAPKs and ARKs, which can be encrypted with the RAT public key and stored in the parameter section of the lock node, so that only the RAT can display the set when it is needed to re-encrypt a lock node.

[0142] Figure 85 illustrates the propagation of access attributes using AAPK from an externally locked node 8500 to an internally locked node 8530. The figure shows where various keys can come from to feed the primary keyhole 8550 and access keyhole 8560 of the linked node. The output section 8510 may display a linked symmetric key 8512 for the primary keyhole 8550 of the linked locked node 8530. The AAPK 8522 may be inserted 8524 into the access keyhole 8560 of the linked locked node 8530.

[0143] Figure 86 shows a flow chart for inserting a key into an access keyhole, which may have been described in detail using the example in the previous section.

[0144] FIG87 shows a table of key-based permissions for an alternative embodiment. This table can extend the table presented in FIG80 by further defining a write asymmetric key pair (UW, RW) and a per-instance data encryption symmetric key Sn. The three keys from FIG80 can alternatively be represented as a signature asymmetric key pair (UD, RD) and a default data encryption symmetric key S0. The additional keys allow the ARK to define a write-only access role, which can write to a packet on a locked node but cannot read any other portion of the packet. A write-only role can have access to the keys RD, UD, UW, and Sn. When a write-only role wishes to store a message Tn in a packet on a locked node, it can generate a singleton symmetric encryption key Sn to encrypt Tn, thereby producing an encrypted message En. The singleton symmetric encryption key Sn can then be encrypted using an asymmetric cipher with the key Uw to produce the encrypted key Kn. Both En and Kn can now be stored in the packet on the locked node. The write-only role can also generate a signature using the RD key and store it. Message authentication can alternatively or additionally be performed through the appropriate application of an authentication SDFT TAR sequence, which can embed and automatically fold this information for compactness and organizational simplicity. These TAR sequences allow for an alternative message authentication method using any cryptographic MAC transformation. Once the write-only role player has completed writing and can destroy the in-memory instance of Sn, the role player no longer has access to Sn's key for decrypting message En, as the write-only role may not possess the asymmetric secret key RW. Access roles (such as reader and writer roles) that possess only a copy of the asymmetric secret key RW can decrypt the encrypted key Kn to obtain Sn and use it to operate on the encrypted message En to obtain the original message Tn. Authentication methods may also include hashing or signature chaining similar to how Merkle trees work for more efficient authentication of payloads consisting of multiple individual messages. Write-only access does not prevent unauthorized truncation or overwriting of previous messages on a locked node operated by the local system; however, the NUTS ecosystem can help prevent or mitigate this by integrating its Nut history, replication, and synchronization features in various collaborative ways. This will be discussed later in the section on the Nut server and revision control module.

[0145] The limited role capabilities of write-only and validator, as presented in the table in Figure 87, can help alleviate some of the issues associated with the common "master key" dilemma within computer system security. This is a familiar problem, where a system administrator is given a "master key," or all-access authorization, to a system or group of systems in order to maintain, update, repair, install, and / or troubleshoot the system(s) at hand. There is a tendency in the industry to automatically associate technical capabilities with elevated security clearances, attributed to a relatively small number of highly capable and experienced system administrators with appropriate security clearances. This type of practice may be unable to address the dynamic nature of trust relationships, where the level of trust between two parties can change unilaterally over time, which may be undetectable or intentionally hidden from others. Through careful use of write-only and validator access roles, payloads can be protected against unauthorized access to data in transit or at rest. The use of these two access roles allows an organization to separate the combined nature of technical capabilities and security investigations to more appropriately and independently manage each aspect. A write-only role allows people and programs to add evidence to a Nut's log component, but may not allow them to read the payload or edit the log. Additionally, a write-only role may have access to the signature key and may generate and validate authentication strings. A validator role allows people and programs to check the internal consistency and authenticity of a Nut without allowing any access to the payload. Lock nodes can be systematically modified, adapted, and plugged into any database system (such as, but not limited to, noSQL or RDBMS) to implement this granularity of access control at the field, record, table, and / or database level. The compactness, flexibility, features, and / or independence of Lock nodes allow them to reside within computerized devices, such as embedded access gateways within the device itself. This will be discussed in more detail in a subsequent section on the Nut Internet.

[0146] NAC features can encompass a complete set of permutations of actions that can be performed on a target payload. A simple cross-reference matrix of allowed actions along with their NAC implementation can be shown below: action Read Write confirm Read Reader Writer Reader Write Writer Write-only Write-only confirm Reader Write-only Confirmer The reader and writer roles may have the implicit ability to validate or authenticate the flags contained within packets locked to a node.

[0147] To summarize, three protection methods for a lock node are available: variable locking, hierarchical access control, and / or Nut access control. Variable locking primarily protects packages within a lock node that can carry certain data content. Hierarchical access control defines how deeply a user can penetrate into the lock layer hierarchy. Nut access control specifies which parts of a Nut a user can modify, view, write, and digitally sign. Some or all of these layers can be controlled by embedded or folded key sets within a lock node's keyhole mechanism. The keyhole mechanism provides a flexible entry point that allows for 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 can be modularly constructed to exhibit the desired locking behavior for the protected content. The modularity of the lock node also simplifies the creation of many complex lock structures due to its iterative, compact, and modular design. While many different algorithms can be used to fully unlock and utilize a Nut, the information for the initialization mechanism can be represented by a cryptographic data component that can be stored entirely within a Nut's locking node, thus making its access control mechanism portable and able to travel with its payload independently of any external reference monitor. These mechanisms can further be embodied using various SDFT methods and structures to help simplify implementation and better manage the complexity of internal encoding and / or data details.

[0148] A 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 within itself and allowing the owner to directly set the access level of each Nut to facilitate portability. It can also adapt to some or all arbitrary access control models and be integrated into some or all of these environments due to its flexibility provided by its keyhole, variable locking, and other mechanisms. Furthermore, it can exhibit other features such as, but not limited to, gradient opacity, additional access attributes, and / or modular locked node links (which may be novel for NUTS). Locked Node Traversal

[0149] Now we can traverse the entire locked node and see how things can be revealed along the path. Figure 88 depicts a simplified diagram demonstrating a decrypted data flow within one locked node 8800 . Reference may be made to the elements of other diagrams involved in this intertwined and integrated depiction of the one-locked node unlocking procedure, such as Figs. Reference may be made to the same locking node segment of a different view of the same segment numbered by different component symbols but may indicate one of the same segments tested in a method of one depth exploration type. The sequencing of the logical operations required in the locking node unlocking procedure can be further optimized for efficiency and / or other purposes. The procedure for unlocking a locking node thereby finalizing a locking graph or Nut may involve steps that can be described in this instance, such as, but not limited to: obtaining access permissions and decryption keys of the locking node using a primary key; Where appropriate, certain mechanisms within the locked graph and locked nodes can benefit from one of the appropriate applications of the SDFT method.

[0150] The primary key 8804 may be inserted into the input section 8806 and each primary key may use its associated cryptographic method to attempt to decrypt its matching encrypted key map 8810 and unfold it into a one-key map 8808 structure. Each key mapping 6240 may generate a primary key 6210 which can be used by a variable lock 8812 . Within each key map 7840 (equivalent to 6240) a matching level locking node (e.g., 7820 to 7830) that can be a set of hierarchical keys 7850 and each level key (e.g. 7852 to 7858) can be inserted into the lock graph in the primary key hole 8306 of the respective input section 8302 (In this instance, a level-1 key such as 7852 to 7858 may be equivalent to a primary key in 8304); a level-specified lock node such as 7820 to 7830 may adopt a MATLOCK, which may require a minimum of one of the two keys to open it: A level-51 key such as the 7852 and output keys such as 7852 can be found in the output section 8510 or 8826 . For a keyhole locking node 8300 , a set of access attribute keyset unlock keys (AAKSUK) 8314 may be unlocked for a set of access attribute keysets (AAKSUKs) 8314 within each key map 8310 , which are referred to as access keysets (AKS) 8312 , and each AAKSUK key may be inserted into the keyhole 8320 access keyhole 8320 in the input section of the current keyhole locking node 8300 . Once a set of Access Attribute Propagation Keys (AAPKs) 8336 can be obtained in this way, their etc. 8522 (equivalent to 8336) may be inserted into the access key hole 8560 of the next via link locking node 8540 . Now we may have an Access Attribute Key Set (AAKS) 8332 which may contain an Access Role Key (ARK) 8334 . ARK may define the access role of the primary key 8304 throughout the lock graph. Signs of various locked node segments such as 8840 to 8848 can be identified using these ARKs. The sign of the lock ID and postscript data 8840 may be identified using the RAT public ARK 8344 (this may be the public part of a RAT asymmetric key pair, as may have been described in the NAC specification) and the identification algorithm specified in section 8830 . For identification purposes, section 8830 may be submitted to the identification algorithm together with the corresponding mark 8840 and the RAT public ARK 8344 . If the recognition fails, segment 8830 may have been cracked and the locked node unlocking procedure may generate an error and processing can be stopped. If the identification is successful, each flag may be for each encrypted key mapping authentication encrypted key mapping 8842 corresponding to a validly inserted primary key. For identification, each eKM 8810 string may be submitted to the identification algorithm together with the corresponding mark 8842 and the RAT public ARK 8344 . If an identification fails, the eKM may have been cracked and the locked node unlocking procedure may generate an error and processing can be stopped. If all appropriate eKMs have been successfully identified, the respective mark of the encrypted-derived key 8844 may be identified.For identification, each eDK 8814 may be submitted to the identification algorithm together with the corresponding mark 8844 and the RAT public ARK 8344 . If an identification fails, the eDK may have been cracked and the locked node unlocking procedure may generate an error and processing can be stopped. If all appropriate eDKs have been successfully identified, each mark of the encryption key 8846 group may be identified. For identification, each eKS 8818 may be submitted to the identification algorithm together with the corresponding mark 8846 and the RAT public ARK 8344 . If an identification fails, the eKS may have been cracked and the locked node unlocking procedure may generate an error and processing can be stopped. If all appropriate eKS have been successfully identified, the respective mark of the encrypted package 8848 may be identified. For identification, each eBag 8822 may be submitted to the identification algorithm together with the corresponding logos 8848 and COR ARK 8348. If an identification fails, the eBag may have been cracked and the locked node unlocking procedure may generate an error and processing can be stopped. If all appropriate eBags have been successfully identified, this locked node can be considered fully identified. It should be noted that the role key 8348 identification eBag can be accessed using the Reader Class (COR). This may apply to locked nodes holding one of the payloads of Nut, but for locked nodes holding Nut posterior data in their equal packets, the RAT public ARK may be used alternatively for identification. Then, based on the variable lock type indicated in the parameter segment 8830 of the locking node, an appropriate variable locking algorithm 8812 can be attempted using the set of primary keys 7844 from the key mapping 8808 for each encrypted derived key string (eDK) 8814 . Successful unlocking of a variable lock 8812 by decrypting an eDK 8814 may result in one or more derived keys (DKs) 8816 . Each decryptable key can be stored in one of the corresponding encrypted keyset strings (eKS) 8818 in parameter 8802 . Decrypting an eKS can generate a corresponding keyset 8820 structure, which can hold an output section 8826 structure and a packet of keys. (Several) output link keys that can be found in the key set 8820 structure may be stored in an input section 8826 and may operate as one of the keys that may be inserted into a primary key hole once linked lock node 8530 (if present). The packet key can be decrypted using an appropriate password to encrypt the encrypted packet string (eBag) 8822 that can be stored in the parameter section. Once decrypted the packet may hold data, such as, but not limited to, one payload of Nut (lock graph), postscript information about the payload, Nut postscript, packet postscript, any combination of these and / or other information. A packet posterior data may indicate whether packet 8824 maintains a Nut portion or Nut payload. If a packet maintains one Nut portion, it may indicate which Nut portion and other appropriate Nut portion posterior data and / or other data it may represent.If the packet holds a payload of Nut, it may indicate whether the stored data may be actual data or a reference thereto and, if so, what type of reference it may be, what kind of reference it may be and / or where it may be located.

[0151] This series of steps can be repeated for each locked node in the lock graph in order to unlock Nut. Figure 89 shows a general flow chart for Nut unlocking. Most of the steps may have been detailed in the previous example, but some steps may require further explanation. Step 8902 - Organize locked nodes into appropriate traversal levels: Since locked nodes can be stored in a list-type structure in a column-based form, the actual topology of the lock graph can be extracted and constructed using the connection information that can be stored in each locked node. Once the graph can be constructed, one or more additional passes can be completed to appropriately assign graph levels so that the locked nodes can be traversed in the appropriate sequence. Step 8908 - Prompt some or all pass-based keyholes: During the processing of an input segment, if a pass-based keyhole encounters a null key (password), it can prompt the password. This default behavior can be modified to call another function or bypass any null pass-word keyholes. Any logical step or process in the flowchart may have errors, which may occur and may cause the process to stop, and these are not specified in detail because this is a high-level flowchart: for example, any process that attempts an operation may fail and may cause the algorithm to stop. The rest of the flowchart may follow the path of the previous example.

[0152] Figure 90 illustrates how a NUTS-based system can open a file contained in a Nut. As a forward reference, NUTbook 9000 can be a data collection organization application that can use Nut and can essentially act as a personal PKI when it comes to storing and organizing collections of passcodes, cryptographic keys, and / or certificates. File symbols such as 9002 and 9004 can be used throughout these diagrams to represent a Nut file. Within a Nutbook system, there can be a primary Nutbook access key, Nut 9002, which can be unlocked to gain some minimum functionality from the application. This key can be stored within Nut 9002 and can be referred to as the primary Nutbook key, and the unlocking mechanism within Nut 9002 itself can include a passphrase. A hierarchical key relationship can exist between primary Nutbook key 9002 and a file access key 9004, such that the file access key can be required to access any file that maintains Nut in this configuration. Thus, the hierarchy can be configured to require primary NUT book key 9002 to open and access file access key 9004. The NUT holding the file access key may have NUT ID #33 9016. Therefore, the key stored in payload 9020 may be referred to as key ID #33: both the file access key and the NUT ID of the NUT holding it may be referenced by the same ID, in this case #33. File 9040 may be stored in a NUT 9030 with NUT ID #44 9036. Similarly, the file may be referred to as file #44. When a user decides to open file #44, one of the keyholes in the primary keyhole may specify that key ID #33 may be required to open it. NUT #33 9004 may be requested from the NUT book, and to open it, NUT 9004 may need to be opened. To open this NUT, NUT 9002 may need to be opened. Assume that the user has initialized their NUTbook using a passphrase in Nut 9002, and that the NUTbook has cached the primary NUTbook key in memory. Opening Nut 9004 may then require only an additional passphrase for file-level access to the NUTbook. Once it can be opened, a cascade of Nut unlocks can occur, ultimately revealing decrypted file #44 9050. The NUTbook can cache file access keys for a limited amount of time to expedite file extraction during a session, but certain events (such as inactivity, hibernation, screen lock, timeout, and / or explicit locks) may require a passphrase to re-establish file access. This section introduces the NUTbook application and the concept of hierarchical passcodes, 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 may be based on locking nodes and their iterative processes, and much of it may be hidden from the user. The end result may be that a piece of data may be stored in a Nut-like 9030 and its security may be consistent across some or all environments.

[0153] Figure 91 illustrates the common use of NUTS terminology to refer to a Nut payload by holding its Nut ID. Here, a keyhole 9124 labeled Key #33 is shown, which can actually find a Nut 9110 with Nut ID #33 9112 and expect Nut #33 to hold a single key 9114 that can be inserted into keyhole 9124. It is interesting to note that in many of these figures and examples, if Nuts can be stored in a file, then in most operations, the file name of a Nut file is rarely used.

[0154] The next set of figures shows various exemplary embodiments of a lock graph, which may highlight the flexibility and expressiveness of the lock node and lock graph model using variable locks and lock node links.

[0155] Figure 92 shows a simplified embodiment of a list of recipient lock models: any key 9210 can unlock the ORLOCK lock node 9220, which can reach the lock node carrying the payload 9290 of Nut. It should be noted that for simplicity, a lock node can be graphically represented as a padlock, but in reality, it is a fully functional lock node that can store some metadata of Nut.

[0156] 93 shows a simplified embodiment of an ordered locking model: key 9310 may be presented first, followed by key 9320, which may allow access to Nut's payload 9390. MATLOCK lock node 9312 may require a single key, while MATLOCK lock node 9322 may require both key 9320 and the link key from lock node 9312.

[0157] Figure 94 shows a simplified embodiment of an ordered locking model with a master key: key 9410 may be presented first, followed by key 9420, which may allow access to Nut's payload 9490. Alternatively, master key 9430 may be presented directly to ORLOCK lock node 9432, which may allow access to payload 9490. ORLOCK lock node 9432 may allow either a link key or a master key to unlock it.

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

[0159] Figure 96 shows a simplified embodiment of a lock model with a master key: Key 9610 or Master Key 9620 may be present together or separately, which may allow access to Nut's payload 9690. The placement of a MATLOCK in lock diagram 9632 may indicate that there may be some level of control in the location of this Nut and that it may be a Nut portion storing some Nut metadata.

[0160] Figure 97 shows a simplified embodiment of a safe deposit box lock model: key 9710 and bank key 9712 can be presented together, which allows access to Nut's payload 9790.

[0161] FIG98 shows a simplified embodiment of a secret sharing lock model with a master key: from a set of keys 9810, several keys that meet or exceed the secret sharing threshold can be collectively presented, which can allow access to Nut's payload 9890. Alternatively, the master key 9820 can be presented directly to the ORLOCK lock node 9822, which can allow access to the payload 9890. The key 9810 can be any combination of a passphrase, a symmetric key, and / or an asymmetric key, as the keyhole / key mapping structure can be hidden in the tail, which can be required by the secret sharing scheme utilized in the SSLOCK lock node 9812.

[0162] Figure 99 shows a simplified embodiment of a "PrivaTegrity" type of locking model: User Key 9920 can be presented to ORLOCK 9922, which can allow access to Payload 9990. Alternatively, nine Keys 9910 can be collectively presented to MATLOCK 9912, which can allow access to Nut's Payload 9990. The "PrivaTegrity" model was proposed by David Chaum in early 2016 to implement a text messaging system that can securely transmit messages using keys known to its users, but which can have a collusive backdoor system involving up to nine different keys maintained by nine international jurisdictions to grant law enforcement access to specific messages only if all nine jurisdictions can agree that the specific messages are critical and legally authorized.

[0163] Figure 100 shows a simplified embodiment of a multi-Nut configuration, where multiple payloads can be stored within a single Nut. User key 10010 or master key 10012 can access one or both payloads, depending on their hierarchical access control. Master key 10020 can access only payload 10092 due to its traversal path through the locking graph. This locking graph demonstrates the flexibility of modular locking nodes and their access control layers working together. Separate data packets can be protected differently within some or all of this single Nut. If master keys 10012 and 10020 are identical, the key holder can be allowed access to both payloads.

[0164] Figure 101 shows a simplified embodiment of a multi-Nut configuration: any one of the user keys 10110 can access some or all three payloads, depending on their hierarchical access control. Key 10120 of SSLOCK 10122 can access only payload 10194 due to its locking node connection. This locking diagram illustrates the flexibility of modular locking nodes and their access control layers working together and / or independently. Separate data packets can be protected in different ways within this single Nut. The flexible nature of the present invention allows for unlimited variations in locking configurations.

[0165] Figure 102 shows a simplified embodiment of a direct locking model with multiple payloads: this locking graph may show a flat topology of a Nut rather than the usual linear one. ORLOCK 10212 may be a node of interest because there are several ways to implement the multiple link keys required to connect it to five different locking nodes. In one embodiment, the output section of ORLOCK node 10212 may contain five output keys. In another embodiment, an output link key map may be embedded as a key map in the keyhole and then propagated to the output section. Furthermore, hierarchical keys may also play a role in determining which keys can access various nodes.

[0166] Figure 103 shows a simplified embodiment of a sequenced message passing scheme, which can be designed to resist collusion using Nuts and relationship-based keys (RBKs, or forward references). Mr. Data 10310 may have a relationship with each of Alice, Bob, Charlie, and Danny. Some or all of the participants may 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 he may also wish to read the messages in a certain sequence, without being able to surveil them through collusion among the participants. Therefore, Mr. Data can construct specific content into each of the four Nuts. The Nut sent to Alice 10320 can only be opened by Alice because it can be locked using the RBK set between Alice and Mr. Data. Inside 10320 may be a message from Alice and a key K Bob from Bob. He can read his message and send the key K Bob to Bob. Nut sent to Bob 10330 can use a MATLOCK that can only be opened with two keys simultaneously: Bob's RBK key between Bob and Mr. Data, and Alice's key K Bob. 10330 can contain a message from Bob and Charlie's key K Charlie. It can read his message and send key K Charlie to Charlie. Nut sent to Charlie 10340 can use a MATLOCK that can only be opened with two keys simultaneously: Charlie's RBK key between Charlie and Mr. Data, and Bob's key K Charlie. 10340 can contain a message from Charlie and Danny's key K Danny. It can read his message and send key K Danny to Danny. Nut sent to Danny 10350 can use a MATLOCK that can only be opened with two keys simultaneously: Danny's RBK key between Danny and Mr. Data, and the key KDanny from Charilie. Inside 10350 can be a message from Danny. It can read the message and Mr. Data's plan to sort the message that can be worked on.

[0167] In the field of cybersecurity, the term "backdoor" can carry negative connotations in various conversations about the topic. Traditionally, backdoor mechanisms have been implemented at the application level, potentially allowing unfettered access to data handled by the application. This type of application-level access can constitute a significant compromise of the security of data handled by the application, depending on which party gains access to the backdoor entry. The perception of compromise in these situations can be well-founded, due to the prevalence of these applications processing unencrypted data within their own application memory, potentially granting backdoor users access to plaintext data. In NUTS, and specifically in a NUTS lockdown model, some have observed the use of a master key as a type of backdoor into a NUTS; however, technically, this is quite different, as in all NUTS lockdown models, all doors (keyholes) are front doors and require the appropriate cryptographic key to gain access to the NUTS. The NUTS API or any NUTS-related application implementation may not have an intended backdoor designed into the application. There may be several legitimate reasons for having master key entries available to Nut, but all such entries can be defined solely by a secret key and directly detectable by a cursory examination of the input section of any locked node. Therefore, any application attempting to install backdoor functionality within a NUTS-related application can do so only after first obtaining a master key for the target set of Nuts, and it can only be applied to Nuts for which the master key is valid. This illustrates the flexibility, compartmentalization, protection, and / or resiliency of a data-centric approach to Nut security.

[0168] Some or all access control methods in NUTS may involve hiding cryptographic keys within a pattern within an encapsulated data structure, whose expansion reveals other keys that grant access to a target data set. In the embodiments illustrated herein, most of these key hiding methods may utilize data encapsulation and / or data folding methods. The method for hiding access keys may be an implementer preference or a parameterized setting within each NUTS. These methods may include data folding, data encapsulation, attribute-based encryption, functional encryption, authorization tokens from a reference monitor, or any other method that provides selective cryptographic disclosure of subsequent access keys upon access to material that decrypts or unlocks its cryptographic mechanism. The illustrated embodiments of this invention may have been selected for their simple and straightforward mechanics and their well-known properties. Other equivalent mechanisms may streamline or make certain aspects of the embodiments more efficient while still providing essentially the same functionality: controlling access to access attributes that grant access to a target data set, independent of any reference monitor, based on predefined access attributes. Any equivalent access attribute of the displayed method may be replaced by the method shown so far that provides the same level of protection for the contents of a nut.

[0169] This can be extrapolated to the Nut container's sections and internal workings. The internal mechanisms can be directly implemented or implemented through the use of the SDFT method, which can be easily encoded and managed in this embodiment. A Nut's payload can be anything that Nut can ultimately protect, and can be anything that can store digital data, such as, but not limited to, a text file, a binary application, an image file, a remote system access key, an executable descriptive language, a certificate for securely establishing a computer connection, an entire database, an operating system, links to other Nuts, streaming data, and / or text messages. Due to Nut's ability to describe what it can hold through its rich, configurable metadata, the standard list of common file types can be far less than its capacity. A locked-node architecture allows payloads to span Nuts, thus resulting in unlimited logical container size. If solid-state NUTS-compatible chips or circuits are available, it would be possible to transform a physical device into a Nut itself, making it accessible only to the key holder. A series of such devices could form entire networks and intranets that can only operate under proper authentication. The flexible nature of the modular locking node design allows for unlimited variations in the locking configuration of a Nut. In the following sections, various systems and / or methods are described that can use Nut as the foundation for secure storage to demonstrate how common services and methods can be extended, improved, and redesigned to provide capabilities that may seem beyond the reach of the average user. Modular I / O

[0170] A programmer can expend considerable effort ensuring that data is properly brought into a program, transformed, calculated, and / or edited within its runtime memory space, and then properly stored permanently. One undesirable side effect of this application development model can be the eventual degradation of file formats and their various versions. Possessing, owning, and controlling one's own data can be a useful and desirable goal, but the question arises as to whether one can properly read it. The ability to read a format, write a format, act on read data, and / or display read data can constitute some of the fundamental components of a typical program. Modular I / O (MIO) can be a system and / or method that modularizes these logical operations into a repository of modular components that can be used by anyone with access to them. One side effect of MIO can be the ability to create file format conversion modules, which can allow users to access past versions of file read and write routines, allowing their older data to be read. This can be referred to as backward compatibility. This also provides a concept of forward compatibility, but the effectiveness of this feature may depend on the skill of the programmer designing the application modules. A preferred embodiment of an MIO system may encapsulate some or all modules in Nut, so that authentication, protection, and / or access control of each module can be implemented by default. Figure 104 shows typical components in modular I / O. Component 10450 may be a modular I / O repository (MIOR), which may be a server program that stores and organizes MIO components. An MIOR may be embodied as a local and / or remote server-type application that acts as an intelligent cache for these modules. In other embodiments, an MIOR may have a local cache on the local device, thereby better facilitating the co-requesting of MIO modules. A typical application 10402 that can read and / or write to a file 10404 can be conceptually and programmatically divided into modules for reading 10406 and writing 10408 files. File 10404 can be formatted in a specific format "A" that can be unique to application 10402. Similarly, this figure shows 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 a specific format (which can be "B" and "C") in MIOR 10450. MIOR can contain other modules that can perform different tasks or processes of the application. Depicted by 10426 through 10432 may be file conversion modules that can perform conversions from one file format to another as specified by their respective tags: Module Convert_A_B 10426 can read data from file format "A" into the memory of an application via the file read module 10406 and then it can convert the memory structure into a memory structure similar to one that can be generated by the read module File_Read_B 10414. Modular I / O: read and write

[0171] FIG105 illustrates a simple read and write operation using MIOR 10500. Application 10502, which can handle files stored in file format "A," can read file F_A 10504 formatted in format "A" by requesting a file read module, File_Read_A 10506, from MIOR 10500. Module 10506, if found, is transferred 10510 to App_A 10502, which then installs and executes file read module File_Read_A 10506 on file F_A 10504. Module File_Read_A 10506 performs the file read on file F_A 10504 and constructs an internal memory structure representing the contents of file F_A 10504. This memory structure representing the contents of file F_A 10504 is then 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 be present in its execution memory space. In other embodiments, once the file contents have been read by file reading module File_Read_A 10506, there is no need to transfer the memory structure to App_A 10502. Thus, file reading module 10506 and application module 10502 can share the same memory space.

[0172] When application App_A 10502 is ready to store the modified contents of file F_A 10504 back in file form, it can contact the MIOR and request a file write module (called File_Write_A 10508) for file format "A." After receiving 10512 module 10508, App_A can install and execute the module using the same methods used by the reader to transfer the application's memory structure. Write module 10508 can perform a write operation to permanent storage, which can generate a modified file F_A 10520. The MIOR requests for read and write modules 10506 and 10508 can be completed in any sequence deemed appropriate by the application developer. In one embodiment, the application can pre-request some or all relevant I / O modules before beginning to ensure that some or all necessary I / O operations can be performed by the application, which can prevent any undesirable failures later. In another embodiment, there may be a local cache MIOR of previously fetched modules from previously run applications that may be maintained to speed up the request and fetch process.

[0173] Many methods exist for transferring and / or sharing memory structures between two or more logical programs, including, but not limited to, shared memory segments, memory-mapped files, databases, inter-process messages, binary memory dump files, and / or converted memory dumps. A preferred method for transferring application memory in an MIO system may be to use converted memory dumps between programs. JSON read and write functions can be modified to recognize binary data and automatically convert it to and from Base64 encoding or other binary-to-text encoding schemes. Figure 106 illustrates the data conversion and transfer involved in a typical MIO file read operation. The MIO read module File_Read_A 10604 reads 10620 a file named F_A 10602 in the format "A" into its running memory 10606. Consequently, the relevant contents of file 10602 can be represented 10630 in the application memory structure 10606. The application memory can be stored in a JSON-compatible data structure 10606 and assembled into text form 10610 using a JSON write function call. Optionally, the JSON output can be embedded in a Nut container 10608 for added security. Thus, the application memory 10606 can be converted and stored 10608 outside of the read module 10604. Nut 10608 can then be opened and read into memory by App_A 10612, and a JSON read can be performed on the data packet 10610. Thus, the data is reconstructed into the execution memory of App_A 10614. Data transfer methods 10622 and 10624 can include, but are not limited to, command line arguments, inter-process messages, and / or data file(s). The reading application and / or the data processing application may be separate programs on different machines, the same machine, separate threads or separate cores; or the application may be a single logical program on a local or remote machine with the dynamic capability to modify its running code in real time. Modular I / O: Backward Compatibility

[0174] An application can undergo incremental changes over time by releasing version changes with enhancements throughout its lifecycle. Many of these version changes may include changes to the format of the storage files used to save user work. Historically, this can lead to two problems: bloat and degradation. Bloat can be the software becoming bloated with each version change due to the addition of backward compatibility capabilities throughout the lifecycle of the product line. This can involve numerous format version changes. Furthermore, if there are other third-party or open formats that the application may wish to handle, this can lead to even greater software bloat. Figure 105 illustrates how an application can utilize any version of any format, and if modular read and write modules are available in the MIOR, files can be read and processed without any excessive bloat. Furthermore, Figure 105 illustrates how newer read and write modules can be added separately to the MIOR, and each application that can communicate with the MIOR now has local access to the additional formatting module without any program modifications. These newer modules may be the ability to read different versions of a file format for the same application pipeline or they may be compatibility modules that read and write third-party file formats written by anyone (including the application developer).

[0175] FIG107 illustrates a backward compatibility example, where the version of application App_B 10702 may be newer and may use a data file corresponding to the newer format version "B," but the user may wish to read and write an older version "A" of the file format 10704. Data conversion modules such as 10708 and 10710 may be generated and stored in MIOR 10700 for such scenarios. A conversion module may be responsible for reading one format and generating another: in this example, conversion module 10708 may read an "A" formatted file and convert it to a "B" formatted file; conversion module 10710 may read a "B" formatted file and convert it to an "A" formatted file. File F_A 10704 may be presented to App_B 10702, which may determine that the file is in an incompatible format from the metadata and may proceed to request MIOR 10700 to obtain the sequence of read modules required to read file "A" and generate file "B." MIOR 10700 may respond by sending the following modules to App_B 10702: File_Read_A 10706, File_Write_A 10712, Convert_A_B 10708, and Convert_B_A 10710. App_B 10702 may call File_Read_A 10706 on file F_A 10704, which may then call Convert_A_B 10708 and pass its memory structure in “A” format to module 10708, which may then convert the received data into “B” format and pass it to App_B 10702. When App_B is ready to save the modified data back to file F_A in the "A" format, it can then call Convert_B_A 10710 and pass its memory structure in the "B" format to module 10710. Convert_B_A 10710 can then convert its memory structure to the "A" format and call File_Write_A 10712 and pass its memory structure in the "A" format. File_Write_A 10712 can then overwrite file F_A 10714 with its modified contents in the "A" format and format the file for writing in the file format "A". A more complex example could be to call several conversion modules in sequence to perform an iterative conversion process to an appropriately older format version, or a developer could have added a frequently used version change converter module (such as Convert_B_F and Convert_F_B) to streamline such requests.

[0176] Software bloat can be illustrated with a simple calculation: Assume that a popular application has undergone five major revisions, spanning three format versions of three operating systems, each with a major version change within 10 years. Also assume that each of these changes may have required a different version of the application's I / O routines. This could potentially result in most current versions of the application carrying as many as 135 versions of its I / O functions. Assuming this may be an extreme case, we can understand the proliferation of code that can occur in order to maintain backward compatibility in an application over time. This characteristic can be referred to as the cumbersome nature of software.

[0177] A properly maintained MIOR 10700 with consistently updated modules added to its repository can serve as a historical I / O format library and allow users to access older versions of its data files at any time in the future. This addresses the issue of software and data format degradation. When an application is no longer produced, sold, and / or maintained, its useful life can be drastically shortened, as newer versions that allow it to run on newer operating system versions may be imminent. When an application no longer runs on modern computers due to incompatibilities, data files formatted by the application can become difficult to access. Savvy users and developers have found various solutions to these problems, but these solutions may require significant effort and / or expertise. Using a MIOR may require at least one developer to maintain modules associated with non-existing applications and to periodically add newer versions of these 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 the self-generation of OS-type and version-appropriate modules. Updated modules can be plugged into the MIOR and anyone who 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 requiring the users to have knowledge of lower-level issues and programs that can be called to automatically resolve them. Software backward and forward compatibility issues can be referred to as the degenerate nature of software. Modular I / O: Forward Compatibility

[0178] A user may sometimes find themselves in a situation where they may have imported, installed, and / or used an application many years ago, but may not have purchased subsequent updates to the application in those years. However, the user can still run the application, but can only read and write file formats compatible with the older version of the application. The latest version of the application may have introduced a newer file format with additional features at some point in the past. This situation can present two problems for the user: 1) their version of the application cannot read files formatted in the latest format version; and 2) other programs that can read the latest format from the application cannot access its older formatted data. A solution to the first problem is a forward-compatible read operation, whereby the older application can directly load a module from MIOR that performs a gradual conversion of the data. This allows the user to use the older program to read files formatted in a newer version. The solution to the second problem can be called a forward-compatible write operation, whereby older applications can directly load a set of modules from MIOR, which can perform a gradual conversion of the data. This allows users to use their older programs to write files formatted for a newer version. Programs built with forward compatibility in mind can use MIOR with minimal or no functionality loss, making this type of transition easier and more seamless. Newer features provided in the newer format version can be optimally mapped to a less complex application structure or simply replaced with the original data, allowing users to modify it at a later time. Figure 108 illustrates these two different logical operations using an example.

[0179] Forward-Compatible Read Operation: App_A 10802 may be compatible with files formatted as version "A," but the user may wish to read a newer file format, "C." This request may be communicated to MIOR 10800, which may respond with a sequence of modules that can perform these backward conversions: File_Read_C 10806, Convert_C_B 10808, and Convert_B_A 10810. Module File_Read_C 10806 may read file F_C 10804, which may be formatted as version "C." Module 10806 may then call the backward conversion function Convert_C_B 10808 and pass its memory structure to it. Module Convert_C_B 10808 may perform the conversion on the data in memory and generate a memory structure compatible with format "B," a previous file format version of the application. Module 10808 can then call the return conversion function Convert_B_A 10810 and pass its memory structure to it. Module Convert_B_A 10810 performs a conversion on the data in memory and generates a memory structure compatible with format "A" (the desired file format version compatible with the older application App_A). Module 10810 passes its memory structure in format "A" to the calling application App_A 10802, which can process it. Thus, a newer version of a file format can be read by an older version of an application without modifying the application.

[0180] Forward-Compatible Write Operation: App_A 10840 may be compatible with files formatted as version "A," but the user may wish to write to a newer file format "C" that exceeds its native capabilities. This request may be communicated to MIOR 10800, which may respond with a sequence of modules that can perform these progressive conversions: File_Write_C 10816, Convert_B_C 10814, and Convert_A_B 10812. App_A 10840 may call Convert_A_B 10812 and pass its memory structure to the function. Module Convert_A_B 10812 may perform the conversion on the data in memory and generate a memory structure compatible with format "B." Module 10812 may then call the progressive conversion function Convert_B_C 10814 and pass its memory structure to the function. Module Convert_B_C 10814 converts the data in memory and generates a memory structure compatible with format "C." Module 10814 then calls file write function File_Write_C 10816 and passes its memory structure to it. Module File_Write_C 10816 writes file F_C 10818 formatted in version "C" (the desired file format version). Thus, an older version of an application can write a newer version of a file format without modifying the application.

[0181] The present invention is not limited to the two examples shown. A conversion module can be generated to access some or all file format versions of an application on any operating system. A conversion module is not limited to conversions within its application pipeline but can be written to perform conversions across different application pipelines. The conversion module can include data conversions 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 other conversions. Modular I / O: Display

[0182] Figure 109 shows an image of a MIOR display module in operation. Once an application, App_A 10902, has successfully read data from a file, F_A 10904, into its memory, it can proceed to use the functionality of module Display_A 10908 to display the contents of file F_A 10904 to the user. Within a display module, the functional aspects of the module can vary greatly depending on the application, the data content, and / or the developer's design. Some modules may be designed to use shared memory methods, allowing the display module to directly access data in the application's memory, while other modules may pass data to the display module, allowing it to display the data. Other examples of display modules may be screen formatting commands and / or templates for displaying and possibly editing data types. This modularization 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.

[0183] The collection directory architecture discussed later in the NUT book section can take advantage of the lightweight aspect of modular displays. Instead of building larger monolithic applications to handle, display, and / or edit different sets of data, the NUT book can leverage the MIOR architecture, which allows the NUT book to be customized on a case-by-case basis based on the type of payload in the NUT being tested. Modular I / O:Application

[0184] In Figure 110 , a MIOR 11000 can store modular application modules such as 11022. A NUT browser 11020 (forward reference) can be an application that looks and behaves similarly to most file and directory browsers, but it recognizes NUTs and can interact with them by viewing their extensive metadata. Within a 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 determine which modules may be needed to open the file. The metadata can include information such as, but not limited to, application version, file format version, and / or display version. Next, the NUT browser may request 11004 that MIOR 11000 look for application App_A 11022, File_Read_A 11024, and Display_A 11026. MIOR 11000 may return some or all of the modules and the application App_A 11022 may be called by the NUT browser 11020. Once App_A is running, it may call File_Read_A 11024 to read the contents of Nut payload F_A 11028, which may be stored in Nut 11030. After passing the memory structure from 11024 to the calling module App_A 11022, it may call display module Display_A 11026 to display data F_A 11028 to the user.

[0185] A modular I / O application module can vary greatly in what it can hold and implement: in some embodiments, it may be a complex logic calculation module; in another embodiment, it may store an entire software installation package; in another embodiment, it may contain some or all aspects of I / O, display, and / or application functionality; in another embodiment, it may contain information including a Genesis Nut that can remotely regenerate a user's environment. The functionality of a modular I / O application module is not limited to these scenarios.

[0186] Modular I / O features (such as read, write, display, and / or application) 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. Much of the access control can be derived from the properties of the Nut container in which the module is stored. The mechanisms by which these MIOR requests can be derived will become apparent as the present invention is discussed in further detail. When a data file or its contents can be encapsulated within a secure Nut container, a variety of metadata levels can be available regarding the Nut content. This metadata can specify details of the data format, such as, but not limited to, the application version that created it, the display version, the file format version, size, creation time, last modification time, author, file type, and / or summary. Environmental attributes, such as, but not limited to, OS version, application version, hardware make and / or version, can be provided by the application that opens the Nut. Given this information about the environment, data content, and / or requested operation, MIOR can locate the appropriate module and respond with a set of modules that can satisfy the operation or an error message. These modular I / O modules can run as a single or separate process on the same machine, across different machines, across different chips or cores, across a network, and in other modes running one or more logical processes on a computing device. Through these modules, issues of degradation, redundancy, adaptability, compatibility, and / or flexibility can be partially or fully addressed. NUT History

[0187] Nut containers can be constructed to store the history of a payload. The form of the history can include periodic snapshots, progressive increments, a complete sequence of events, or any combination of the three or any other archiving methods. The form of the history can vary depending on the type of data stored and the preferences and design of the application and / or data. The NUTS ecosystem can include methods and systems that support these data history archiving modes. These three archiving methods can be well-established methods known to those of ordinary skill in the art. The physical location of the Nut history can be in the Nut portion called Tale (Figure 81) and its opacity can be controlled by the Nut RAT.

[0188] FIG111 shows a simplified Nut diagram illustrating the progressive changes in its history structure over three time points covering two editing sessions of a document. At time T1, Nut 11102 may hold data D1 11110 and its history may be empty 11112. At time T2, a user may edit 11126 data D1 11110 and create a new version D2 11114. The application may employ a snapshot archiving method and, at time T1 11118, store the original version of data D1 11110 as a snapshot of the data in Nut's history section 11116. Subsequently, a user may edit 11128 data D2 11114 at time T3 and create a new version D3 11120. The application may employ a snapshot archiving method and, at time T2 11124, store an older version of data D2 11114 as a snapshot of the data in Nut's history section 11122. At time T3, history section 11122 may now hold two different snapshots 11118 and 11124 of previous versions 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 creation of new files from it. Nut metadata parameters may exist that control the type, frequency, and / or age of history sections to set a reasonable history growth for the data at hand. For some text files, permanently saving some or all changes may be practical, as their size can be relatively small when using an incremental archiving method. This allows Nut to generate some or all saved versions of the file at any time thereafter. Binary files may be archived as snapshots or incrementals, depending on the application. Some event-driven applications can archive a complete sequence of events as their history. It should be noted that Nut history can be archived within Nut itself and can be independent of external programs and / or storage systems. As long as there is an archiving method available for the payload type in the NUTS environment, any payload can be historically archived in this way. NUT Log

[0189] A Nut container can be constructed to store a Nut's event log. Since computer programs can read, manipulate, and / or write to a Nut, they can generate and leave an audit trail of the logical operations performed on the Nut within the Nut itself. The audit trail can essentially exist on a per-object basis from the object's perspective. Thus, between the Nut history and the Nut log, a chronicle of events since the inception of a data object can be stored in a single container for further review at a later time. The accuracy, content, and / or granularity of the Nut archive can depend on the rigor and methodical use of these features by the developers of applications operating on the Nut. The physical location of the Nut log can be in a portion of Nut called Vita (Figure 81) and its opacity can be controlled by the Nut RAT.

[0190] FIG112 shows a simplified Nut diagram illustrating the progressive changes in its event log structure over three time points covering two events occurring on Nut. This example can be continued from the case of FIG111 for Nut history. At time T1, Nut 11102 may maintain data D1 11110 and its log 11212 may maintain a log entry 11218 indicating that event E1 occurred on Nut 11102 at time T1. A user may edit 11226 data D1 at time T2, which may create a new version D2 11114 of the data in Nut 11104. The editing application may record an event log entry in Nut log 11216 at T2, as indicated by element 11222. Subsequently, a user may edit 11228 data D2 11114 at time T3, which may create a new version D3 11120. The editing application can record an event log entry into Nut log 11230 at time T3, as indicated by element 11224. At time T3, log section 11230 can now hold three distinct event log entries 11218, 11222, and 11224. Users can freely browse and extract Nut log 11230 at any time using simple log extraction methods, which allows for auditing of Nut. Nut metadata parameters can exist to control the type, frequency, and / or age of log sections to configure reasonable and appropriate log growth for Nut.

[0191] System administrators and application developers can appreciate the effort and time involved in tracking down errors and bugs on their systems when modifying a data object can involve more than one application. They may have to browse the event logs of some or all participating applications (if they have access to all of them), filter out event log entries related to the problematic object, and then perhaps manually reconstruct the sequence of events that occurred on the object. Using a Nut log, this collection, filtering, and reconstruction of event logs can be accomplished at the object level from an object perspective. Furthermore, Nut metadata can define the event granularity of event log message detail that the object owner desires for the operating application. This granularity can range from a concise debugging level to a detailed debugging level to facilitate tracing various lines of investigation. A sensitive, top-secret payload may require the highest level of granularity in event log detail to maintain an audit trail of its access history. In short, this is a consistent and customizable way to audit the past of objects by any application at every level of granularity an object requires. The term consistent refers to the consistent design and operation of available logging features, and the term customized refers to the design's adaptability to per-object preferences. Relationship-Based Key (RBK)

[0192] The description of how relationship-based keys (RBKs) can be established should be familiar to anyone who has manually used cryptographic tools: Bob and Alice may wish to communicate privately and therefore trade randomly generated asymmetric cryptographic keys (only the public portion) or use the keys in a tool such as PGP or its equivalent to exchange encrypted messages and files. The protection and management of the key pair by Bob and Alice may be entirely up to them. This can result in a deliberately difficult task of properly establishing, maintaining, and utilizing each relationship, potentially requiring Alice and Bob to have a basic understanding of cryptography, its proper use, and / or key protection. This type of key exchange can occur when Bob or Alice does not possess a public key certificate established through a centralized directory or a trusted website. It can also occur when the participants feel an additional layer of privacy is needed to create a completely private communication channel.

[0193] What would happen if RBK were the default communication method for Alice, Bob, and others? What could the consequences be, and what would be required to make it happen painlessly? The systematic aspects of establishing, maintaining, and / or using RBK could be automated. It would be constructive to explore some of the properties and consequences of consistent application of RBK before delving into the details of how to systematically implement it. Properties of Relationship-Based Keys The level of trust between two parties can be a dynamically adjustable parameter. This can be an observation of any real-life relationship between two parties: trust can be relative. It can ebb and flow over time based on events and communications. ● Unilateral Adjustment of Trust Level. Either party in a relationship may unilaterally change the trust level of the relationship at will, with or without notifying the other party. The health of the communication channel can be determined from the context of the message. Systems and keys can be compromised by either party at any time. The default use of the RBK allows either party to test the content of the communication and determine the likelihood that the other party's system or key has been compromised. In the simplest case, a message from Bob that is not encrypted with the RBK could be a sign of a compromise. The true nature of a relationship can be assessed over time. If a message of an unusual nature is transmitted via the RBK and the sender's key has not yet been cracked, the sender may have changed the nature of the relationship. Losing a relationship can be permanent, and some or all of the relationship's history can lose commercial and / or financial value. Unilaterally, either party can sever a relationship by blocking their messages or erasing their RBK set. This logical operation of a relationship channel presents each user with a deterministic, unilateral message blocking capability. ● The parties can strictly adhere to the ground rules of mutual obedience or risk the relationship being damaged - ground rules can change over time. In other words, the violation of an implicit ground rule can lead to a unilateral severance of the relationship in a permanent way. It can allow for a tighter expression of real-world relationships in the form of a digital cryptography. Public key cryptography in its most widely used form can be a centralized model that can be the opposite of how people form relationships. RBK can be decentralized and can use public key cryptography in a private manner. Damage Isolation. RBK damage on Bob's environment can be isolated from Bob and any RBK channels he may have established with his contacts (i.e., Alice). Damage to Alice's environment can be isolated from her channel with Bob and their mutual history. Some or all of Alice's other relationship channels can be secure and cannot be compromised by a hacker who compromises Bob's environment.

[0194] A personal information manager, or PIM, is a well-known application concept in computer software. It can be broadly defined as a combination of various functions that provide productivity and organizational tools for personal use. A PIM may provide tools such as, but not limited to, a calendar, address book, contact management, passcode holder, note taking, email manager, chat functionality, project management, key manager, calculator, to-do list, and / or activity logger. A PIM may be a combination of any of these functions, or it may only provide a single function. A PIM may be designed to operate locally in an isolated manner, operate only on a PIM web server, or any combination thereof. In the discussion ahead, reference to a PIM (such as an address book, chat, or email manager) with these functionalities should be understood to mean a PIM that provides any of these functions as its offering, or as its sole function.

[0195] Figure 113 shows how a digital address book entry between Alice and Bob can be constructed to consistently support RBK for some or all relationships in the address book. Alice's address book 11310 (which may be a feature provided by her PIM) may have two entries: an entry 11320 for herself and an entry 11330 for Bob's information. Alice's entry 11320 may list her basic contact information 11322 and some personal information 11324. Alice's address book entry 11320 can be stored and fixed as a payload in a Nut file on Alice's system. On Bob's contact card 11330, Alice may have some of Bob's contact information 11332, such as his name and email address. Bob's address book entry 11330 can also be stored and fixed as a payload in a Nut file on Alice's system. Bob's address book 11350 (which may be a feature provided by his PIM) may have two entries: an entry for himself 11360 and an entry for Alice's information 11370. In Bob's own entry 11360, he may have listed his basic contact information 11352 and some personal information 11354. Bob's address book entry 11360 may be stored and fixed as a payload in a Nut file on Bob's system. On Alice's contact card 11370, Bob may have some of Alice's contact information 11372, such as her name and email address. Alice's address book entry 11370 may be stored and fixed as a payload in a Nut file on Bob's system. When Alice and Bob decide to establish a RBK with each other, they may 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 11344 the public portion of key 11334 to Bob. Transmission 11344 can be accomplished by a secure verbal Nut, a written message, a phone call to Bob, a message using Bob's public key known to the public, or any version of a secure key exchange protocol known to those skilled in the art. When Bob receives this message with key 11334, he can store it in Alice's address card entry 11370 as a private message to Alice's key 11334. Bob can then generate an asymmetric key pair 11374 and 11376, store them under Alice's address card 11370 and use the public key 11334 sent to him by Alice to transmit 11346 the public part of the key 11374 to Alice to encrypt the message.When Alice receives this message, she can decrypt the message from Bob using her private key 11336 for Bob's message. She can extract the internal key 11374, which she can store in Bob's address card entry 11330 as a key 11374 for privately sending messages to Bob. She can generate a confirmation message for Bob, encrypted using key 11374 from card 11330, and send the message to Bob via any working communication medium. Bob can receive the message, then decrypt it using key 11376 from card 11370 and mark his RBK set as established and interact with Alice.

[0196] The steps in establishing this RBK between Alice and Bob can be automated and initiated using a single action button or command. This can be the operational basis of how a NUTbook manages its contact collection and will be discussed later in the NUTbook section of this document. Bob or Alice can repeat the process separately for some or all of the contact cards in their respective address books in their PIMs. Finally, each person can establish an RBK channel for each of their contacts, which can be considered a private communication channel for each of their relationships. If Cathy is a mutual friend between Alice and Bob, Cathy's RBK relationship with Bob can be different from Cathy's RBK relationship with Alice, and the RBK configuration can reflect this reality.

[0197] Now that we've defined the context of RBK and its system usage, what can it do for Alice or Bob? Consistent use of RBK in messaging between two entities can allow for monitoring the health of their communication channels. One example of a practical use might be SPAM email reduction. It's estimated that SPAM email, both malicious and / or commercial, takes up a significant amount of global Internet bandwidth and data storage. We can hazard the assumption that not many people would appreciate this amount of SPAM. Common approaches to SPAM reduction might include using filtering techniques based on content pattern recognition, domain exceptions, address exceptions, and / or actually shutting down SPAM-rich servers through law enforcement. In a model where RBK encryption is the default communication method, SPAM can be detected with greater certainty.

[0198] One of the major obstacles in automating processes such as RBK is the significant lack of user-friendly, user-accessible, and / or user-controllable personal public key infrastructure (PKI) applications. The NUT book, along with the use of Nut, attempts to fill the PKI gap. It can provide a flexible, secure, and / or user-controllable method to store, manipulate, and access this information in a seamless manner.

[0199] FIG114 shows a flow chart for reducing SPAM between Alice and Bob, who may now have established a RBK communication channel, which may be their default communication method, and they may use well-known public email addresses. If an email is encrypted via the RBK between Alice and Bob, it may be valid email from Alice to Bob or vice versa 11414. If either person receives an email from the other that is not encrypted using the RBK, the email is likely SPAM and can be filtered out and stored in a SPAM bin 11412.

[0200] Figure 115 shows a flow chart for reducing SPAM between Alice and Bob, who now have established a RBK communication channel. This may be their default communication method, and they may use undisclosed private email addresses—anonymous email addresses. If an email is encrypted via RBK between Alice and Bob, it may be 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, the email is likely SPAM and can be filtered out and stored in a SPAM grid 11512. This example assumes that the 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 define this type of communication channel-directed email address as an anonymous email address.

[0201] A communication channel between Alice and Bob, who may consistently use RBK via anonymous email addresses, may exhibit certain characteristics that can be analyzed to determine the health of the relationship itself. We may have already, by default, removed some or all unencrypted SPAM messages from the channel, as depicted in Figure 115. Now we can test the context of appropriate RBK-encrypted messages. The table in Figure 116 lists a deterministic context-based state matrix for the health of the Alice-Bob communication channel. This may require a qualitative assessment of the content by Alice to indicate what may be happening in their relationship. This shows a unilateral action matrix for Alice, which may be based on Bob's behavior, as evidenced by the messages Bob sends to Alice.

[0202] The last symptom listed in Figure 116 can create an interesting case when Bob's role can be replaced by that of a website provider (i.e., Alice may have established an anonymous RBK communication channel with a provider). The table in Figure 117 shows a deterministic context-based state matrix of the health of the Alice-provider communication channel. Alice now has the ability to track whether this provider has sold her information to spammers through the channel-identifiable pattern of anonymous email addresses and RBK groups. This provides a level of transparency into the inner workings of the provider's marketing department, with a clear audit trail. This type of provider accountability can be made unprecedented by ordinary users in a systematic and detailed manner. The consequences of a provider violating Alice's trust can be disastrous, as the provider may permanently lose access to her. In fact, the appropriate and consistent use of anonymous email addresses and / or RBKs can allow Alice's digital equivalent to walk out of a store and never return; this can act as a deterrent for providers to misuse their clients' personal information.

[0203] Figure 118 shows a deterministic context-based state matrix of the health of the Alice-supplier communication channel from the provider's perspective. Channel characteristics can provide providers with the same types of unilateral actions they can take to protect their business and potentially their clients. A provider's use of this approach can enhance their reputation for privacy and data security. It can also implicitly state that the provider is not engaging in wholesale, unrestricted resale of client data.

[0204] Figure 119 illustrates how the use of RBKs can help isolate sensitive data on a user's system from being compromised. Bob 11900 may have RBK channels with Alice 11910 and Dave 11920. Bob may have clicked on a Trojan horse website and may have been infected with a key logger or equivalent malware. A hacker may then have been able to penetrate his secure RBK storage (such as his NUT book). Consequently, Bob's RBK set for some or all of his contacts may have been compromised 11900. Bob may contact some or all of his friends and inform them of the compromise, or some of his friends may have inferred that something is wrong with Bob or his system from SPAM messages sent to them using their private channel with Bob. If we look at Alice's NUT book 11910 (where she may store some or all of her RBK sets), she may mark her RBK set with Bob 11912 as cracked and create a new RBK set when Bob works together to remove the virus on his system. This may be detrimental to Alice, and it does not spread to other RBK relationships Alice has established. This is especially true if she also consistently uses anonymous email addresses with her contacts. Alice may receive SPAM from the hacker, but the SPAM can be automatically ignored when she marks the channel as cracked or deletes it. When Bob is ready, Alice can create a new set of RBKs and a new anonymous email channel, and they can continue their digital conversation privately. Dave's procedure can be the same as for his RBK storage 11920. Anonymous relationships

[0205] The digital relationship topologies and conventions that have enhanced and intensified the internet over the past few decades can be unnatural and inauthentic. Anonymity can be a powerful relationship construct and a level of relationship we can enjoy on a daily basis for most casual interactions, such as, but not limited to, going to a pharmacy to buy personal products, going to a restaurant to buy food, ordering a taxi, and / or attending a protest. Contrary to this physical reality, nearly every vendor on the internet may want to know who Alice is, including some or all of the personal information they can obtain from her. Many vendors themselves can remain relatively anonymous by not publishing direct phone numbers and can serve customers through email, transaction systems, and / or remote outsourced customer service representatives in remote call centers. The most common use of anonymity may be for those who wish to remain anonymous, such as hackers. Currently, there are websites that create pseudonyms for those who wish to remain anonymous on the internet, but these can require considerable effort to maintain anonymity and require careful, dual-purpose decision-making. The use of RBK and anonymous email addresses can bring some equality to this anonymity imbalance on the Internet for ordinary users and can empower them to have more meaningful two-way relationships with suppliers and each other without having to rely on false personas and accidental duplicity.

[0206] Figure 120 shows a simplified schematic diagram of a pre-packaged Personal Data Nut. A Nut can store detailed personal information about a person 12000. It can automatically pre-package different subsets of this personal information for different purposes. 12010 may be a simple Personal Data Nut, which may contain only a name and email address. An anonymous Personal Data Nut 12020 may simply display an alternative email address. A shopping Personal Data Nut 12030 may contain information fields typically required for purchasing items on shopping websites. Protection of these subsets of information 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 a provider or service accepts a Data Nut, the information can be used to insert it into the correct fields when needed by other methods. If a user utilizes an anonymous email service (forward referencing), a Data Nut such as 12020 can dynamically provide an anonymous email address generated for the specific relationship established.

[0207] Figure 121 plots a graph of a sequence of events in a registration procedure that can be automated using one of Nut. One of the providers on the Internet may use and accept personal data Nut and may be allowed to establish RBK channels with their customers in an automated manner. A user may access the provider's website and may wish to register 12100 . The user can start the process by directing their NUT book to automatically register to the provider's website and can enter the URL of the registered website. The NUT book may inquire about the supplier to extract information 12102 necessary for the supplier to register for it. The NUT book may form a subgroup of user personal information that the supplier may request and may display a preview for the user. The user may decide that the information requested for the registration may be acceptable and the NUT book may have collected the relevant information and may proceed with the procedure 12104 . NUT Books may be extracted and may generate a pre-packaged packet Nut containing preview information and may be sent to the supplier's website. The provider may accept the registration request and may send an inquiry to the e-mail address 12106 of the user specified in the pre-packaged package Nut. The User may receive inquiries from the Supplier requesting it by e-mail to provide evidence that it may not be a website bot (which can engage in trivial registration) by requesting it to go to a specific URL to enter a verification code 12108 or other possible form of confirmation. Once the code is successfully entered, the provider can be confident that the request can come from one person and can continue to establish an automatically generated login authentication, login key, and / or RBK group with the user. The user's NUT book may automatically generate a login card for the vendor, its related website information, login authentication, login key and / or RBK group 12112 . The registration procedure can be completed using user interaction at several points in the procedure: initialization, personal data encapsulation review / editing and / or human confirmation. The trouble of picking a one-login name, pass code, keying personal information and / or generating one of the items in a one-pass code holder for the vendor may not be requested and may be automated. When the user's NUT book is activated, it can seamlessly have immediate access to the supplier in a full identification mode because the NUT book can automatically record it when requested. It should be noted that this procedure can be accomplished using any supplier that may benefit from both the user and the supplier by adopting this method. Less hassle of users and suppliers The possibility of obtaining more precise information from the user's such database and possibly more transactions between them and so on.

[0208] Figure 122 plots the sequence of events in an automated registration procedure using Nut and an anonymous e-mail address. One of the providers on the Internet can use and accept Nut and may allow the use of anonymous email addresses to establish RBK channels with their customers in an automated manner. A user may access the provider's website and may wish to register 12200 . The user can start the process by directing their NUT book to automatically register to the provider's website and can enter the URL of the registered website. The NUT book may inquire about the supplier to extract information 12202 that is necessary for the supplier to register for it. The provider can accept anonymous registration, so the NUT book can contact the NUT mail service and can request a pair of anonymous email addresses under its account. The NUT book may consist of and may display a preview of the data to be sent to the vendor for registration, which may contain the newly generated anonymous e-mail address. The user may decide that the information requested for registration may be acceptable and the NUT book may proceed with the procedure 12204 . The NUT book may generate a pre-packaged packet Nut containing preview information and may be sent to the supplier's website. The Vendor may accept the registration request and may send an inquiry to a new anonymous e-mail address 12206 of the user specified in the pre-packaged package Nut. The User may receive inquiries from the Supplier to provide evidence of its anonymous e-mail address by requesting it to go to a specific URL to enter a code 12208 or other possible form of confirmation that it may not be a website bot (which can engage in trivial registration). Once the code is successfully entered, the provider can be confident that the request can come from one person and can continue to establish an automatically generated login authentication, login key, and / or RBK group with the user. The user's NUT book may automatically generate a login card for the vendor, its related website information, login authentication, login key, anonymous e-mail address and / or RBK group 12212 . The registration procedure can be completed using ...

Claims

1. A method for storing data, comprising: The process involves: encrypting a plurality of key maps using at least one processor, each key map being encrypted with one of a plurality of primary keys corresponding to a primary key; storing the plurality of key maps in an input segment of a lock node in at least one memory; encrypting a derived key using at least one processor, the encrypted derived key being configured to be decrypted by performing a logical operation corresponding to one of the plurality of primary keys applied to the input segment; storing the encrypted derived key in a variable-lock segment of the lock node in at least one memory; encrypting data using at least one processor, the encrypted data being configured to be decrypted using the derived key; and storing the encrypted data in an output segment of the lock node in at least one memory. Each key mapping includes at least one access attribute key, and the input segment further includes at least one encrypted access role key, which is configured to be decrypted by the at least one access attribute key. The at least one access role key is configured to enable at least one operation on the data, wherein the at least one access role key is based on a permission associated with a specified primary key, thereby resulting in a particular key mapping.

2. The method of claim 1, further comprising combining the at least one access role key in a logical operation with other provided at least one access role key to form a union of all defined operations permitted on the data.

3. The method of claim 1, wherein the at least one processor is coupled to one of a plurality of computers on a network, the method further comprising: Each of the plurality of computers generates a different public / private key pair for each of the computers that receive the communication; Each of the plurality of computers sends the generated public key to the computer corresponding to the public key on the network; and each of the plurality of computers uses the public key to send communications to the computer to encrypt the communications and send the encrypted communications on the network.

4. The method of claim 3, further comprising: Each of these computers stores the received public key in a personal information manager accessible only to authorized computers.

5. The method of claim 4, further comprising: This personal information manager provides key management functionality; The personal information manager provides storage management functionality.

6. The method of claim 4 further includes the personal information manager storing the data in at least one protected data storage unit.

7. The method of claim 3, wherein in response to receiving a communication at one of the plurality of computers, the computer determines that it has received the communication and decrypts the communication using a private key corresponding to the public key sent to the computer that sent the communication.

8. A method for storing data, comprising: A method is used to store a plurality of lock nodes as a protected data storage unit including at least one memory, wherein storing each of the lock nodes includes: encrypting a plurality of key maps by the at least one processor, each of the key maps being encrypted with one of a plurality of primary keys corresponding to a primary key, the key maps including a plurality of primary keys; storing the plurality of key maps in an input section of the lock node by the at least one processor; encrypting a derived key by the at least one processor, the encrypted derived key being configured to be decrypted by performing a logical operation on itself corresponding to one of the plurality of primary keys applied to the input section; storing the encrypted derived key in a variable lock section of the lock node by the at least one processor; encrypting data by the at least one processor, the encrypted data being configured to be decrypted with the derived key; and storing the encrypted data in an output section of the lock node by the at least one processor. The at least one processor configures at least one keyhole locking node of a plurality of locking nodes including a key mapping for one of the primary keys, each of the primary keys including at least one access attribute key, the at least one access attribute key being configured to provide role-based access control based on the corresponding primary key within the protected data storage unit; and the at least one processor provides an output key to at least one of the locking nodes, the output key being a primary key for the other of the locking nodes; wherein each key mapping includes at least one access attribute key, the input segment further includes at least one encrypted access role key, the at least one encrypted access role key being configured to be decrypted by the at least one access attribute key, the at least one access role key being configured to perform at least one operation on the data, wherein the at least one access role key is based on a permission associated with a specified primary key, thereby resulting in a specific key mapping.

9. The method of claim 8, wherein the input segment of one of the locking nodes provides at least one access key for the other of the locking nodes.

10. The method of claim 8, further comprising, by means of the at least one processor, combining the at least one access role key in a logical operation with other provided at least one access role key to form a combination of all defined operations permitted on the data.

11. The method of claim 8, wherein at least one key mapping for one of the locking nodes includes at least one stratum key, the at least one stratum key being used for decryption of a different key mapping for at least one of the locking nodes than the locking node.

12. The method of claim 11, wherein the at least one-level key and the input segments of the locking nodes in the storage unit control the locking nodes accessible in the storage unit for the specific primary key specified thereon.

13. The method of claim 8, further comprising storing at least one log segment by the at least one processor in the output segment of at least one locking node of the storage unit, the at least one log segment storing data relating to access to the protected data storage unit across a plurality of different applications.

14. The method of claim 13, further comprising encrypting the at least one log prior to storage in the at least one log segment by means of the at least one processor.

15. The method of claim 13, wherein at least one parameter stored in the protected data storage unit controls what is recorded and what is not recorded.

16. The method of claim 13, wherein at least one parameter stored in the protected data storage unit controls one level of detail in the at least one log.

17. The method of claim 13, wherein at least one parameter stored in the protected data storage unit controls a log type to be generated.

18. The method of request item 17, wherein the log type includes log entries relating to the processing events of the protected data storage unit.

19. The method of claim 17, wherein the log type includes entries relating to historical revisions of the data in the protected data storage unit.

20. The method of claim 13, wherein at least one parameter stored in the protected data storage unit controls the generation of a log entry.

21. The method of claim 8, wherein the at least one processor is coupled to one of a plurality of computers on a network, the method further comprising: Each of the plurality of computers generates a different public / private key pair for each of the computers that receive the communication; Each of the plurality of computers sends the generated public key to the computer corresponding to the public key on the network; and each of the plurality of computers uses the public key to send communications to the computer to encrypt the communications and send the encrypted communications on the network.

22. The method of claim 21, further comprising: Each of these computers stores the received public key in a personal information manager accessible only to authorized computers.

23. The method of claim 22, further comprising: This personal information manager provides key management functionality; The personal information manager provides storage management functionality.

24. The method of claim 22 further includes the personal information manager storing the data in at least one protected data storage unit.

25. The method of claim 21, wherein in response to receiving a communication at one of the plurality of computers, the computer determines that it has received the communication and decrypts the communication using a private key corresponding to one of the public keys sent to the computer that sent the communication.

Images