Moving and storing encrypted user data

Abstract

To provide a method and a system that allow data to be secured during storage in a data-centric software design.SOLUTION: A method of processing data includes at least one processor accessing a data storage unit that provides at least one input data object and at least one transmutation command to be performed on the at least one input data object. The at least one transmutation command operates in a forward mode with respect to the at least one input data object to generate at least one output data object to be stored in the data storage unit.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0002]

[0002] A data-centric model of computer software design is one in which user data may take priority over applications. Data-centric software design may allow data to be secured during storage. Containerization of data may be an embodiment of data-centric design. To illustrate how various concepts may be implemented within this disclosure, a series of drawings from different perspectives highlight the particular concepts being discussed, and a cohesive drawing shows how some of these processes and structures may work together.

[0003]

[0003] Data containerization may be presented in a layered approach, with each layer building upon or working in conjunction with the previous layer, partially or entirely, if preferred. The concepts, methods, apparatus, embodiments, and / or specifications described herein for a first layer may be collectively referred to as Structured Data Folding with Transmutations, 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 Transit & Storage, or NUTS. Any combination of layers may be partially or entirely deployed to build a container for data, referred to as Nut, and each layer may be partially or entirely deployed independently. The interaction and / or interweaving of these two layers may be significant and / or complex, raising challenges for clear demarcation of such layers. Therefore, these layers are presented together herein. A Nut container can then be filled with various data-centric properties that can enable logical operations on the data contained within it. With respect to a unit of storage called Nut, various embodiments can be described to show how some common data-oriented logical operations can be redefined and restructured to provide users with privacy, security, convenience, and / or capability.

[0004]

[0004] Various embodiments may be disclosed in the following detailed description and accompanying drawings. [Brief explanation of the drawings]

[0005] [Figure 1] A diagram showing a table of symbols used to represent different cipher key types. [Figure 2]FIG. 1 shows a set of simplified flowcharts illustrating data inputs, data outputs, and logic operations that may generally be performed by different cipher methods. [Figure 3] FIG. 1 is a diagram of a general network layout in which embodiments of the present disclosure may function. [Figure 4] FIG. 1 is a diagram of a computing device in which embodiments of the present disclosure may function. [Figure 5] Diagram of transmutation in forward mode or normal operation. [Figure 6] 1 is a table showing common data operations and their variant classes. [Figure 7] Diagram of metamorphism in the backward mode. [Figure 8] Diagram of irreversible metamorphism. [Figure 9] Diagram of conditional reversible transformation. [Figure 10] A diagram showing a table of common data operations and functions grouped by transformation type. [Figure 11] A table of codecs defined in Python v3. [Figure 12] Figure showing a table listing additional metamorphic definitions. [Figure 13] A diagram showing a modified invertible matrix. [Figure 14] FIG. 10 is a diagram showing a metamorphic mode action matrix. [Figure 15] A detailed example of the serialize transformation. [Figure 16] A diagram showing a detailed example of digest metamorphosis. [Figure 17] A diagram showing a detailed example of digest transformation in backward mode, also known as verification. [Figure 18] Diagram of scipher metamorphosis. [Figure 19] Diagram of salsa20(scipher) metamorphosis. [Figure 20] A diagram showing a detailed example of salsa20(scipher) metamorphosis. [Figure 21]A diagram showing a table of command specifications for the serialize and compress transforms, along with a set of sample transform commands that show their usage. [Figure 22] FIG. 10 shows a table of command specifications for the encode transform and a set of sample transform commands showing its usage. [Figure 23] FIG. 10 shows a table of command specifications for digest transformation and a set of sample transformation commands that show its usage. [Figure 24] A diagram showing a table of command specifications for the acipher and dign transforms, along with a set of sample transform commands that demonstrate their use. [Figure 25] A diagram showing a table of command specifications for the derive transformation and a set of sample transformation commands that show its usage. [Figure 26] A diagram showing a table 2602 of command specifications for scipher transformations and a set of sample transformation commands 2604 showing their use. [Figure 27] Diagram showing the output structure format for 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 key value utf8 encoded parameter string of the scipher transformation for the output message. [Figure 28] FIG. 10 shows a table of parameter keywords and specifications for header strings in the output structure format of scipher transformation. [Figure 29] Diagram of iterative embedded message encapsulation for AEAD mode scipher transformation. [Figure 30] A diagram showing a table 3002 of command specifications for lock transformation and a set of sample transformation commands 3010 showing their usage. [Figure 31] 1 shows the specification of various metamorphic structures in tabular format. [Figure 32]Figure showing a table of command specifications for mobius transform. Its usage is shown, and the graphic shows the structural changes it can perform on various structures. The matrix shows the structure type / mode valid operations that mobius transform can operate on. [Figure 33] A table 3302 of command specifications for the press and clean transforms, a table 3304 of command specifications for the key transform, and a set 3310 of sample transform commands showing their usage. [Figure 34] A diagram showing a table for the Key Interchange Specification Structure or KISS. [Figure 35] 35 shows a table 3502 for the KISS mode of operation, a table 3504 for a matrix showing key type / field occurrence mappings, and a table 3506 for key type definitions. [Figure 36] 1A and 1B are diagrams showing the structure of a TAR and an example of a TAR definition. [Figure 37] FIG. 1 shows a block diagram illustrating when metamorphic relationship attributes are persisted and a table listing attribute types and locations. [Figure 38] Block diagram of the SDFT operations Ravel and Unravel (or Ravel's inverse). [Figure 39] Flowchart of SDFT Ravel operation. [Figure 40] Flowchart of SDFT unraveling operation. [Figure 41] Diagram showing how TAR reversal is performed for general TAR. [Figure 42] Figure 1 shows an example of TAR reversal. [Figure 43] FIG. 10 shows a table of transformations mapped to key type templates that may occur or be required during TAR processing. [Figure 44] FIG. 1 shows example TARs and key templates generated from each. [Figure 45]A diagram showing example TARs, the key templates generated from each, and the expected list of KISS structures to be put or generated. The KISS list is also called a keystack. [Figure 46] A diagram showing the three modes of key stack operation within the SDFT TAR process: generation (gen), input (put), and injection (mixed). [Figure 47] A diagram of how key stacks can be generated and used in the lifecycle of data and its TAR. [Figure 48] Diagram of operations that can be performed on data stored in an NSstr structure. [Figure 49] Flow diagram of the SDFT usage to iteratively fold data. [Figure 50] 1 is a flow diagram of the SDFT usage to iteratively unfold data. [Figure 51] Diagram of the SDFT API / library and the various types of TAR definition files it may have access to. [Figure 52] FIG. 10 shows an example Python script for performing manual data folding. [Figure 53] A diagram showing a TAR-defined SDFT example and its usage in a Python script. [Figure 54] Block diagram of dynamic TAR switching within a single communication session. [Figure 55] 1 is a flowchart of an exemplary process for generating a Nut ID. [Figure 56] A block diagram showing when Nut IDs and Lock IDs can be used within Nut. [Figure 57] FIG. 10 illustrates an exemplary relationship between Nut ID, path name, and payload data. [Figure 58] 1 is a block diagram of an embodiment of a Nut or lock graph with logical sections, namely Nut locks and Nut parts. [Figure 59]FIG. 10 is a block diagram of an alternative embodiment of a Nut lock in a Nut with three keyhole lock nodes. [Figure 60] Block diagram of the internal data structure of a lock node. [Figure 61] FIG. 61 is a block diagram of the internal data structure of the input section of the lock node shown in FIG. 60. [Figure 62] A data flow diagram showing the relationship of the internal data structures of the primary keyhole of the input section shown in Figure 61 when a valid primary key can be inserted into the keyhole. [Figure 63] 10 is a flowchart of a key insertion process for any lock node and for any cipher key. [Figure 64] FIG. 1 shows an example in which three primary keys can be inserted into a primary keyhole. [Figure 65] 65 is a data flow diagram of the Variable Lock decrypt operation continuing from the example shown in FIG. 64. [Figure 66] 65 is a data flow diagram of the variable lock encrypt operation continuing from the example shown in FIG. 64. [Figure 67] FIG. 10 shows a table of variable lock types and their properties available at any lock node. [Figure 68] Data flow diagram of the ORLOCK decryption operation. [Figure 69] Data flow diagram of the ORLOCK encryption operation by the Nut owner. [Figure 70] Data flow diagram of the MATLOCK decryption operation. [Figure 71] Data flow diagram of MATLOCK encryption operations by Nut owner. [Figure 72] Data flow diagram of the XORLOCK decryption operation. [Figure 73] Data flow diagram of the Nut owner's XORLOCK encryption operation. [Figure 74] Data flow diagram of the HASHLOCK decryption operation. [Figure 75]Data flow diagram of the HASHLOCK encryption operation by the Nut owner. [Figure 76] Data flow diagram of SSLOCK decryption operation. [Figure 77] Data flow diagram of SSLOCK encryption operation by Nut owner. [Figure 78] A block diagram of Nut highlighting the Stratum Key. [Figure 79] A flowchart of how hierarchical keys can be inserted within Nut. [Figure 80] Diagram showing a Key Based Permissions table for two roles and four role players. [Figure 81] FIG. 10 shows a table listing the various Nut parts in an exemplary Nut, where each part can be represented by a lock node. [Figure 82] A diagram showing a table listing the key-based authorization access roles defined for general Nut. [Figure 83] FIG. 1 is a block diagram of how an initial set of Nut access control access keys, called Access Attribute Key Set Unlock Keys (AAKSUK), can be inserted into the access keyway for each valid primary key. [Figure 84] Block diagram of propagation of NAC access attributes from an external lock node to an internal lock node. [Figure 85] Block diagram of propagation of NAC access attributes from an external lock node to an internal lock node and insertion of an output link key into the primary keyhole of the linked lock node. [Figure 86] 1 is a flow chart for inserting a key into an access lock. [Figure 87] FIG. 10 illustrates a table of key-based permissions for an alternative embodiment. [Figure 88] Data flow diagram of the internal decryption data flow of a lock node. [Figure 89]Flowchart for unlocking Nut. [Figure 90] FIG. 1 is a block diagram of an embodiment of a NUTS-based system and how documents stored in Nut can be unlocked. [Figure 91] A diagram of common usage in NUTS terminology to refer to a Nut payload by the Nut ID of the Nut that holds it, where a cipher key may be referenced by the Nut ID of the Nut that holds it. [Figure 92] FIG. 10 illustrates a simplified embodiment of a list of receiver locking models. [Figure 93] FIG. 1 illustrates a simplified embodiment of an ordered locking model. [Figure 94] FIG. 1 illustrates a simplified embodiment of an ordered locking model with a master key. [Figure 95] FIG. 1 illustrates a simplified embodiment of a master key locking model. [Figure 96] FIG. 1 illustrates a simplified embodiment of a master key locking model. [Figure 97] FIG. 1 illustrates a simplified embodiment of a safe deposit box locking model. [Figure 98] FIG. 1 illustrates a simplified embodiment of a secret shared locking model using a master key. [Figure 99] FIG. 1 illustrates a simplified embodiment of a "PrivaTegrity" type locking model. [Figure 100] FIG. 1 illustrates a simplified embodiment of a multi-Nut configuration in which multiple payloads can be stored within a single Nut. [Figure 101] FIG. 1 illustrates a simplified embodiment of a multi-Nut configuration in which multiple payloads can be stored within a single Nut. [Figure 102] FIG. 1 illustrates a simplified embodiment of a direct locking model with multiple payloads. [Figure 103]FIG. 1 illustrates a simplified embodiment of ordered message passing that exhibits a collusion resistant design. [Figure 104] Block diagram of typical building blocks for modular I / O. [Figure 105] Illustration of simple read and write operations using MIOR. [Figure 106] FIG. 1 illustrates the data transformations and transfers that may be involved in a typical MIO file read operation. [Figure 107] Diagram showing how backward compatibility of file formats can be facilitated using modular I / O. [Figure 108] Diagram showing how forward compatibility of file formats can be facilitated using modular I / O. [Figure 109] FIG. 10 is a diagram showing how modular displays can be facilitated using modular I / O. [Figure 110] Diagram showing how modular applications can be facilitated using modular I / O. [Figure 111] Diagram showing the incremental changes in Nut history through two edits and at three points in time. [Figure 112] Diagram showing the progressive changes in the Nut log over the course of events from Figure 111. [Figure 113] 1 is a diagram showing how relationship-based keys may be represented in Alice and Bob's contact cards. [Figure 114] 1 is a flowchart of how spam can be detected using well-known email addresses and / or RBKs. [Figure 115] 1 is a flowchart of how spam may be detected using anonymous email addresses and / or RBK. [Figure 116] 1 illustrates a Deterministic Context Based Status Matrix for the Alice-Bob RBK communication channel. [Figure 117]A diagram showing the deterministic context-based status matrix for the Alice-Bender RBK communication channel. [Figure 118] 10 illustrates a deterministic context-based status matrix for the Bender-Alice RBK communication channel. [Figure 119] 10 is a diagram illustrating the isolation of RBK relationships in a compromised system for Bob. [Figure 120] Block diagram of Pre-packaged DataNut. [Figure 121] Diagram showing the sequence of events in the automated registration process using RBK. [Figure 122] 1 is a diagram illustrating the sequence of events in an automated registration process using RBK and an anonymous email address. [Figure 123] Diagram showing a table listing NUTS core applications and their descriptions. [Figure 124] Block diagram of the NUTS core application running on a computing device. [Figure 125] Block diagram of NUTserver running in a user device. [Figure 126] 1 is a block diagram of the internal components comprising a NUTserver and their functional connections to the environment of a user device. [Figure 127] FIG. 127 illustrates an alternative embodiment of the NUTserver shown in FIG. 126 that uses a NoSQL database as a caching mechanism. [Figure 128] Block diagram of the MIOR server network layout. [Figure 129] Block diagram of the MIOR server application layout. [Figure 130] 10 is a flowchart for fetching an MIO module from an MIOR server. [Figure 131] 1 is a block diagram illustrating the organization of an MIOR cache. [Figure 132] 1 is a block diagram of the NUTbrowser application in a user device environment. [Figure 133] Block diagram of the NUTbook application in a user device environment. [Figure 134] Block diagram of the Nut processing application framework in a user device environment. [Figure 135] FIG. 1 is a block diagram showing the internal components comprising the NUTbook. [Figure 136] Block diagram showing the internal organization of the NUTbook catalog cache from Figure 135. [Figure 137] A diagram showing the organization of hierarchical passwords. [Figure 138] A diagram showing how the main password opens personal documents according to the hierarchical password in Figure 137. [Figure 139] A diagram showing how the master password opens personal documents according to the hierarchy password in Figure 137 and the documents in Figure 138. [Figure 140] A diagram showing how the main password and the work password open a work document according to the hierarchical password in Figure 137. [Figure 141] A diagram showing how the master password opens the working document according to the hierarchy password in Figure 137 and the document in Figure 140. [Figure 142] Block diagram showing the internal organization of the NUTbook key cache from Figure 135. [Figure 143] 1 is a flowchart of how NUTbook might browse a card catalog. [Figure 144] A diagram showing a table of NUTS base services. [Figure 145] Diagram of the network layout for NUTS-based services. [Figure 146] Diagram of the network layout of the NUTmail server. [Figure 147]Diagram charting the sequence of events in the automated registration process for anonymous email services, such as NUTmail, that use RBK. [Figure 148] A chart showing the sequence of events when adding a communication channel in a NUTmail server. [Figure 149] A diagram charting the sequence of events when Alice and Bob send email to each other via NUTmail. [Figure 150] Diagram of the network layout for a NUTchat server. [Figure 151] Data flow diagram for three chat sessions hosted by a NUTchat server. [Figure 152] Data flow diagram of chat history persistence and replication across NUTserver. [Figure 153] Data flow diagram for three separate chat sessions using different chat IDs or chat services. [Fig. 154] Data flow diagram for a path agnostic dialog managed by the NUTchat client using the three different chat paths from Figure 153. [Figure 155] Diagram of the network layout of a NUTcloud server. [Figure 156] Diagram of the network layout for a NUTnet server. [Figure 157] Diagram of the network layout of NUThub servers for the Internet of NUTS (IoN). [Figure 158] Diagram of the direct IoN network topology. [Figure 159] Diagram of indirect IoN network topology. [Figure 160] Diagram of the NUTserver hub and its connection to the NUThub and IoN devices from Figure 159. [Figure 161]Block diagram of the NUThub / IoN interface in the NUTserver hub from Figure 160. [Figure 162] Block diagram of the NUThub / NUTserver / IoT interface in the IoN device from Figure 160. [Figure 163] Flowchart of the registration and configuration process for IoN / IoT devices. [Fig. 164] 163 is a flow chart of how the remote control interface may process the command Nut from FIGS. 161 and 162. FIG. [Figure 165] Diagram of the network layout of the NUTS certification server. [Figure 166] Block diagram highlighting the functionality of the NUTS certification server from Figure 165. [Figure 167] Diagram of the network layout for a NUTS-based WiFi / Ethernet router. [Figure 168] Flowchart of how messages can be processed in a NUTS-based WiFi / Ethernet router from Figure 167. [Figure 169] Diagram showing the device category table for NUTS-based WiFi / Ethernet routers. [Figure 170] FIG. 1 illustrates a table of exemplary device category attributes for a NUTS-based WiFi / Ethernet router. [Figure 171] Block diagram of how Application Wrapping enables automatic device backup and replication. [Figure 172] Block diagram of the Event Processing Service (EPS) in two devices. [Fig. 173] FIG. 1 is a block diagram of a typical vendor network setup that may use tracking cookies and session history stored on a big data server. [Fig. 174]Block diagram of a vendor network setup that may use the app Nut to record a copy of the session history stored locally as well as on the big data server from Figure 173. [Figure 175] Block diagram of context calculation that can be done locally using the app Nut from Figures 173 and 174. [Figure 176] Diagram of a personal home network topology with IoT devices and service providers. [Figure 177] Diagram of a personal home network with two IoN devices in an indirect IoN network topology and their respective service providers for controlling the flow of data towards a vendor. [Figure 178] A block diagram of how the context analysis app can automatically filter outgoing IoN messages to protect user privacy in the NUTserver from Figure 177. DETAILED DESCRIPTION OF THE INVENTION

[0006] table of contents ● Symbols and abbreviations ● Cipher and one-way hash ● Network diagram ● Device diagram ● Metamorphosis ● Metamorphic type ● Metamorphic structure ● Transmutation Audit Record (TAR) ● Structured Data Folding with Transformation (SDFT) Nut ID Lock graph and lock nodes Keyhole Variable Lock 〇 Hierarchy Nut Access Control (NAC) Lock Node Traversal ● Modular I / O Read and write 〇 Backward compatibility 〇 Forward compatibility Display 〇 Application ● Nut History ● Nut Log Relationship-based keys (RBK) ● Anonymous Relationship ● NUTS core applications 〇 NUTserver MIOR server NUTbrowser / NUTshell 〇 NUTbook ● NUTS-based service 〇 NUTmail NUTchat NUTcloud NUTnet 〇 NUThub NUTS certification server ● NUTS-based WiFi / Ethernet router ● Application wrapping Event processing service ● Context calculation ● Conclusion and philosophy

[0007] Symbols and Abbreviations The following symbols and abbreviations may be used throughout the description and drawings. Those marked with (*) may be NUTS specific. ● AAKS *Access Attribute Key Set ● AAKSUK *Access attribute key set unlock key ● AAPK *Access Attribute Propagation Key ● acipher AEAD: Authenticated Encryption with Associated Data ● AES Advanced Encryption Standard, also known as Rijndael ● API Application Programming Interface ● AKS *Access Key Set ● 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 Cipher-based Message Authentication Code ● CODEC Coder / decoder, encoding method for character data ● COM Component Object Model ● COR *Class of Readers, or Leaders ● 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) To create a digital signature using an asymmetric private key ● DK * Derived Key ● DRM Digital Rights Management ● DVD Digital Video Disc ● DSA Digital Signature Algorithm ● ECC Elliptic Curve Cryptography ● eDK *Encrypted Derived Key ● EPS *Event Processing Service ● 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 Equipment Identity ● IoN *Internet of Nuts ● IoT Internet of Things ● IPC Inter-process communication ● IPv4 Internet Protocol Version 4 ● IPv6 Internet Protocol version 6 ● I / O Input / Output ● ima *KISS field name, which is an abbreviation of "I am a" or "I'm a": Determines the KISS mode ● iv Initialization Vector: A random number for cryptographic use. ● JSON JavaScript Object Notation ● KBP *Key Based Authorization ● Keccak SHA3 hash family ● KISS* Key Exchange Specification Structure ● LAN Local Area Network *lock *Implementation of variable lock as a metamorphic class ● lzma Lempel-Ziv-Markov chain algorithm (Lempel-Ziv-Markov chain Algorithm) MAC (Ethernet related) Media Access Control ● MAC Message Authentication Code ● MD5 Rivest Message Digest #5 ● MIO *Modular I / O ● MIOR* Modular I / O Repository ● MMS Multimedia Messaging Service ● NAC *Nut Access Control ● NCS *NUTS certification server ● NFC Near Field Communication ● NIST National Institute of Standards and Technology NoSQL Non-Standard Query Language, also known as non-relational standard query language ● Nonce: A random number used once for encryption. ● NTFS New Technology File System (Microsoft) ● NUTS *Encrypted user data transfer and storage OAEP Optimal Asymmetric Encryption Padding by Bellare and Rogaway ● OS Operating system ● PBKDF2 RSA Password-Based Key Derivation Function #2 (PKCS) ● PGP Pretty Good Privacy ● PIM Personal Information Manager ● PKCS Public Key Cryptography Standards by RSA Laboratories ● PKCS1_V1.5 PKCS#1 version 1.5 ● PKI Public Key Infrastructure ● PSS Probabilistic Signature Scheme ● PUID: Practically Unique ID ● QA Quality Assurance ● QUOPRI Quoted-Printable or QP encoding ● RAM Random Access Memory ● RAT *Root Access Tier, Nut Owner / Creator, RAT Writer, Owner ● RBAC Role-Based Access Control ● RBCAC Role-Based Cryptographic Access Control ● RBK *Relationship-Based Key ● ROM Read-Only Memory ● RSA Rivest-Shamir-Adleman public key cryptosystem ● SAC *Hierarchical Access Control Salsa20 Bernstein's symmetric key-based stream cipher Salt: A random number for cryptographic purposes. ● scipher Symmetric cipher ● SCP *Structured Cryptographic Programming ● Password-based key derivation function by SCRYPT Percival ● SDF *Structured Data Folding ● Structured Data Folding using SDFT* transformation ● SHA Secure Hash Algorithm - Keccak hash variant ● Shake Keccak hash variant ● SMS Short Message Service ● SOAP Simple Object Access Protocol SPAM (unsolicited bulk email, also known as junk email) ● SSD Solid State Drive ● SSID Service Set Identifier ● SSO Single Sign-On tar Tape Archive: A Unix command for storing data on tape or disk. ● TAR *Transformation Audit Record ● TOP *Transmutations Organizing Principle ● tine *Shamir's Secret Sharing share, like the tines of a fork ● TMX *Metamorphic ● TOP *Metamorphic formation principle ● 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

[0008] FIG. 1 shows a table of cipher key types and their respective symbols that may be used throughout the description and figures of this disclosure. A variable-length text-based password or passphrase may be represented by symbol 102. Symbol 104 represents a key for a symmetric cipher comprising AES-256 or an alternative cipher. Symbol 106 represents a key pair for an asymmetric cipher comprising RSA-2048 or an alternative cipher. The public portion of asymmetric key pair 106 may be shown as symbol 108, and the private portion may be 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 when standard modifications or substitutions may be desired, other suitable methods may be used instead where specified in this disclosure.

[0009] Ciphers and One-Way Hashes

[0007] Figure 2 shows basic operations that may be performed by various types of ciphers. A symmetric cipher 208 in encrypting mode may accept a symmetric key 202 and data 204 to generate encrypted data 206, or ciphertext. A symmetric cipher 208 in decrypting mode may accept the same symmetric key 202 and ciphertext 206 to generate the original data 204. In a symmetric cipher implementation, the encryption method and decryption method may be two separately named function calls, or may be a singular call with a mode parameter as part of the input. A property of a symmetric cipher may be that both the encryption and decryption processes may utilize the same secret key 202.

[0010] In encryption mode, an asymmetric cipher 214 may accept the public part 210 of an asymmetric key pair and data 204 to generate encrypted data 212, or ciphertext. In decryption mode, an asymmetric cipher 214 may accept the private part 216 of the asymmetric key and ciphertext 212 to generate the original data 204. In an asymmetric cipher implementation, the encryption method and decryption method may be two separately named function calls or may be a singular call with a mode parameter as part of the input. A characteristic of an asymmetric cipher may be that the encryption and decryption processes may utilize different parts of a key pair. In implementations such as RSA-2048, the public key may be derived from the private key using a mathematical relationship; therefore, an RSA-2048 private key may be synonymous with a key pair, and the public key may be extracted from the RSA-2048 private key.

[0011] A digital signature method 222 in signing mode may accept a private part 216 of an asymmetric key pair and a ciphertext 218 to generate a digital signature 220. A digital signature method 222 in authentication mode may accept a public part 210 of an asymmetric key pair, a digital signature 220, and a ciphertext 218 to authenticate 224 whether the digital signature was created using the ciphertext 218 and the private part 216 of the asymmetric key pair. In implementations of the digital signature method, the signing method and authentication method may be two separately named function calls or may be a singular call with a mode parameter as part of the input. A characteristic of the digital signature method may be that the signing process and authentication process may utilize different parts of the key pair. In implementations such as digital signature methods based on RSA-2048 key pairs, a public key may be derived from a private key using a mathematical relationship, and thus an RSA-2048 private key may be synonymous with a key pair, and a public key may be extracted from the RSA-2048 private key. For brevity and clarity, this specification may interchangeably refer to a digital signature as a dig, the act of digitally signing a piece of data may interchangeably be referred to as digning, and having digitally signed a piece of data may interchangeably be referred to as digned.

[0012]

[0010] A digital signature method may be a type of message authentication code or MAC. A MAC may be created using a one-way hash algorithm on the data. A hash method such as SHA-512 may accept data content to generate a message digest of the data content, which may be up to 512 bits in length. Authenticating a MAC using a method such as SHA-512 involves recalculating the MAC for the piece of data and comparing the provided MAC with the calculated MAC for equality. A technique known as a keyed-hash message authentication code, or HMAC, may take an additional input of a cryptographic key along with the data content to generate an HMAC value.

[0013]

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

[0014] Network Diagram FIG. 3 illustrates a simplified network diagram to which various embodiments of the present disclosure may be applied, either in part or in whole. A wide area network (WAN) 302 may be represented as a network cloud, which may comprise many servers, routers, and switching systems in various telecommunications centers working together to provide a user or company with a simplified network cloud view. Cloud services 304 may also be diagrammatically simplified as a cloud, representing various commercial systems that may provide network services, such as cloud storage and cloud processing; these services may be implemented to their own specifications, but may comprise many instances of server farms, storage arrays, and routers. A personal router 306 may be connected to the WAN 302, which may provide Internet access to a personal user among multiple network-connectable devices 308-318 that the user may have. To access other devices on the same network or across the Internet, a user may not be limited to the devices shown in the diagram and may use any device capable of utilizing a router. The router 306 may be a dedicated routing device of an Internet service provider, or it may be a combination device providing routing and / or LAN and / or WLAN capabilities, sometimes referred to as a gateway. Enterprise router 320 may be connected to WAN 302, which may provide organizational users with access to the Internet among multiple network-connectable devices 322-330 that a company may have. A company may use any device that can utilize a router to access other devices on the same network or across the Internet, and may not be limited to the devices shown in the figure. Router 320 may be an Internet service provider's dedicated routing device, or it may be a set of interconnected and managed routers that provide routing and / or LAN and / or WLAN capabilities, sometimes referred to as a gateway and / or intranet. The systems and methods described herein in various embodiments may be used and applied to some or all parts of this network diagram.

[0015] Device Diagram A typical computing device 400 is shown in FIG. 4. A processing unit 404 may be connected to a system bus 402, which may facilitate some or all internal communication and data transfer within the device. There may be several different types of system buses available, but for simplicity, they may be collectively referred to as the system bus 402. The processing unit may represent single or multi-core processors and arrays of processors, such as those found in various specialized processing boards such as GPU boards and blade servers. Other components serviced by the system bus may be a network adapter 412, an I / O interface 410, a display interface 414, read-only memory ROM 406, which may store a BIOS program 408, volatile memory RAM 416, which may short-term 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, or flash drive 426, which may collectively and permanently store an installed operating system 428, applications 430, and / or data files 432.

[0016]

[0014] Not all components of the illustrated computing device are necessary for some or all embodiments of the present disclosure to be applicable and functional. For example, the device may not have any physical display or I / O interfaces like those found on some IoT devices, and routers and gateways may have little in the way of physical hard disks. A necessary requirement for NUTS support and compatibility may be the ability to run NUTS-compatible software, which may include a processing unit, some form of storage, and a system bus.

[0017] Transmute Transformations may be a preferred way of organizing many known data manipulation operations found in computer programming. NUTS may specify this as the Transformational Organization Principle, or TOP. Furthermore, any systematic data manipulation operation may be analyzed using TOP and classified as a type of transformation. Transformations may then be categorized, normalized, structured, integrated, and / or adapted to work collaboratively within the framework of TOP, sometimes referred to as Structured Data Folding with Transformations, or SDFT. An insightful view of operating on data using TOP and / or SDFT may enable better and / or complex data designs to be conceptually simpler and / or programmatically efficient to implement. TOP and SDFT may be preferred lower-level implementation mechanisms for NUTS components.

[0018]

[0016] Analysis, methods, and / or structures based on data transformation can show how layering such concepts and designing their associated methods can define an implementable set of integrated data structures and algorithmic methods that can enable easy, systematic transformation of data in a modular, portable, storable, and / or self-describing manner. Due to the layered and intertwined nature of such analysis, descriptions of transformations can have forward and backward references, requiring the reader to refer to different sections to gain a better understanding of some properties. Structured Data Folding with Transformation (SDFT) builds on transformations using data structures and methodologies and can help enable storability, transmissibility, modularity, portability, encapsulability, and / or time compatibility of transformed data.

[0019] Within the NUTS design, SDFT is a set of low-level operations and can be thought of as a fundamental building block for more easily constructing Nut. However, SDFT can be used independently, in part or in whole, to simplify some tedious and / or repetitive data transformations within an application. SDFT can enable computer communication protocols to dynamically switch transformation sequences and / or transformation parametric distributions within the same session between two different applications. Currently, such single-session dynamic switching can be an important programmatic exercise. While using SDFT to build Nut may not be a necessary requirement, its features can help build Nut more conveniently, clearly, and flexibly. SDFT can be further described as a data state transition methodology that allows infinite variation of transition events with well-defined behavior regarding the reversibility of state transition sequences, and can provide iterative encapsulation techniques for persisting necessary attributes and data in a simple, context-sensitive manner. SDFT can accept and embrace the chaos of everyday programming problems and present a practical set of organizational principles on which theoretical proof can be subordinated to empirical proof.

[0020] 5 shows how the transformational organization principle can view data operations as data transformations 510, which can require input data sources 502 and attributes 504 and output transformed data 512 and associated attributes 514. Any well-defined manipulation, operation, conversion, and / or transformation of data can be classified as a type of transformation 510. TOP can make it possible to systematically build a consistent set of ways to transform data in a modular, portable, and / or self-describing manner.

[0021] The table in Figure 6 shows a sample set of common data operations and how they might be categorized using TOP. Transformations can encompass classes of fundamental data operations that may traditionally be separated, both perceptually and in practice. Such may be the case when programmers describe encryption and data compression; these two classes of data operations can generally be thought of as two very distinct and different operations on data. Beyond the algorithmic differences between each operation, through the perspective of TOP, these operations can be viewed as a type of ciphering and compression transformation. In the table, "JSON serialization" might be categorized as a "serialize" transformation using the "json" operation; therefore, the executable transformation command might be stated as "serialize json." An AES symmetric cipher encryption call on a piece of data might be categorized as a "scipher" transformation using the "aes" operation; therefore, the executable transformation command might be stated as "scipher aes." Those skilled in the art will readily recognize all the other types of data operations listed in the table and can follow the organizational pattern of variable classes and operation category groups.

[0022] FIG. 7 shows a diagram of transformation in reverse mode or inverse operation. This diagram is equivalent to FIG. 5 except for the data flow arrows flowing in the opposite direction. Transformation 510 may have a well-defined reversible algorithm, indicated by block 710. Reversible transformation 710 may require a transformed data source 712 and attributes 714 as input, and may output the original data 702 and associated attributes 704. There may be a field of computation called reversible computation that may exhibit similar concepts to reversible transformation. There may be some differences in the goals of each organizational principle. Reversible computation may theorize the existence of a generalized reversible computation language in which operations can be implemented down to the silicon layer for the possible energy efficiency of general computation. Reversible transformations may be aimed at specific implementations of TOP for benefits including, but not limited to, minimizing code written, minimizing programmatic errors, convenient key management, simplifying key generation, structuring portable self-describing data, normalizing data manipulation concepts, introducing a programming language independent way of performing transformations, and / or simplifying the construction of complex cryptographic data structures.

[0023]

[0021] Figure 8 shows a graphical representation of an irreversible transformation. A transformation 810 in forward mode may perform a transformation on data 802 and attributes 804, which may produce transformed data 812 and attributes 814; however, these outputs, along with the type of operation the transformation may perform on the input, may be irreversible in nature. Such irreversible transformations may be exemplified by hashes, MACs, lossy data compression, and other one-way functions or data manipulations. TOP may introduce analytical techniques that can augment the properties of such irreversible transformations and generate operations that can define their reverse transformation properties.

[0024]

[0022] Figure 9 shows a block diagram of a conditional invertible transformation. Such a transformation 910 may have a well-defined invertible algorithm but may require additional inputs and / or attributes 914 for the inversion operation to succeed. A conditional invertible 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 conditional invertible transformations, since the absence of the correct key (attribute) may prevent the decryption of the cipher text.

[0025] FIG. 10 is a table listing common data operations and functions and their respective variants. Those skilled in the art may recognize some or all of the data operations and / or functions listed in the table. For illustrative purposes, the material presented herein may refer to the programming language called Python version 3.6 and its syntax, concepts, functions, and / or methods. Many of the cryptographic functions referenced in this disclosure may be found in the Python standard, pyCryptodome, secretsharing, and / or pyCrypto libraries. Those skilled in the art will find equivalent syntax, concepts, functions, and / or methods in most modern programming languages ​​and their respective libraries. Note that "dign" is a variant for digital signature; other mnemonics may be listed in the Symbols and Abbreviations section of this specification. A more detailed description of each variant may be found in the table in FIG. 12.

[0026] FIG. 11 is a table of codecs defined in Python v3.6. This list may not be complete due to the large number of codecs in existence, the proliferation of new codecs, and / or limitations of those defined in Python v3.6. A "codec" is short for code / decode and a mapping for a character set in computation. Characters are assigned arbitrary but unique binary values ​​within a single codec; thus, a complete set of characters may define 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 character sets in different languages. The "encode" transform may be able to perform any of these codec encoding operations on a given data string. Codecs with names beginning with "utf_" may specify compliance with the Unicode Transformation Format (UTF), which may be the organization principle of international character sets for many Internet-based standards.

[0027] FIG. 12 is a table listing the transformations described so far, along with their detailed descriptions. Additional transformations can be defined within the framework using TOP, as indicated by the last six transformations in the table: key, clean, TAR group, press, lock, and mobius. Some of these additional transformations may be specific to the Structured Data Folding with Transformations (SDFT) library, some may be language-specific, and / or some may be operations related to NUTS. This may demonstrate the flexible nature of TOP by allowing new transformation types to be defined and categorized to expand its repertoire. This flexible extension feature is by design such that the SDFT library can accommodate new transformation operations in the future. The extension feature may also allow older versions of transformation operations to be added retroactively for backward compatibility. The benefit of such flexibility may be the ability of SDFT-processed data to obtain better time-compatibility properties. Time compatibility of data may be defined as those properties that may allow stored data to be easily processed by the same or a different application at some future point in time. Time incompatibility may arise from, but is not limited to, differences in application file format versions, different character encodings, unused application file formats, differences in data operation methods, differences in data operation ordering, and / or inherent parametric variances in data operations.

[0028]

[0026] Figure 13 shows a transformation invertibility matrix. Each transformation can be designated as invertible, irreversible, and / or conditionally invertible. The criteria for making such a designation may be based on the ideal intent of the transformation, rather than on the implemented and / or theoretical deficiencies of the actual transformation. In other cases, the designation may be arbitrary. This can be illustrated by a digest operation called MD4, which can produce a 128-bit long hash of the source data. The MD4 hash can be considered a significantly weaker hashing algorithm compared to hash operations such as the 512-bit SHA2 due to its susceptibility to collisions, which can be an undesirable characteristic in hashing algorithms. A TOP perspective can recognize one of MD4's original intentions as an irreversible unique hash and categorize it as such. Such categorization may not exclude this type of transformation from achieving well-defined and planned reversibility properties through additional TOP analysis, as shown in a later section. The compress transformation can qualify for both a lossy and lossy designation based on the specific compression operation performed. Many image and / or audio compression techniques can be lossy due to their sampling nature; a 12MB digital image may be compressed down to 360KB for efficient transmission via a chat application, but due to the nature of human visual perception, the general impression of the image may be adequately conveyed despite permanent data loss. Such compressed images may be irreversibly modified due to the large amount of original data that may have been discarded during the conversion.

[0029]

[0027] Lossless compression transformation may be exemplified by gzip compression, which may operate on the principle of identifying and reducing repeating bit patterns in binary data, while preserving enough information to reverse the process and recreate the original data in its entirety. Conditional reversible transformation may be exemplified by an AES symmetric cipher, which may operate on the principle of taking cleartext and a symmetric key and producing ciphertext. The decryption process may take the key and ciphertext to produce the original cleartext. Thus, presentation of the correct symmetric key for the ciphertext may be a necessary condition that must be met to decrypt the ciphertext or reverse the encryption process.

[0030]

[0028] TOP may define a transformation mode, which may indicate the direction of a given transformation operation, as either forward or reverse. A forward mode of transformation may perform its normal process and / or its planned forward process. A reverse mode of transformation may perform its inherent reverse process and / or its planned reverse process. The table in Figure 14 shows a matrix indicating the types of operations a transformation may perform internally based on its transformation mode. For reference, the table lists commonly known operation names, such as "serialize" and "deserialize," or "encrypt" and "decrypt." Note the planned reverse processes of digest and dign, namely, "digest" and "verification," "sign" and "authentication." In a "clean" transformation, where a "clean" transformation may delete various internal data associated with its transformed data structure, it may be impossible to restore such deleted data without appropriate additional data and / or re-executing the forward transformation process on the original data to recreate the deleted transient data. A "key" transformation may perform key generation and / or management operations related to performing the transformation. Therefore, due to the inherent random nature of key generation, it may be impossible to theoretically and / or algorithmically reverse such a process in a deterministic manner in finite time. The key management aspect of a "key" transformation is described in detail in a later section when addressing how the transformation may work within the context of Structured Data Folding (SDF); the key management aspect of a key transformation may be difficult to project a reversible counterpart due to its nature of setting up the appropriate key structure for successful processing in an SDF context.

[0031] FIG. 15 shows a series of three diagrams, each of which further details an example of a serialize transformation 1504 that can specify a reversible transformation. In computer programming, serialization and / or marshalling techniques can take a complex, language-specific internal data structure and systematically decompose and / or linearly organize its contents to generate an equivalent data string or set of data strings (hereafter referred to as data strings). The data string format may be more suitable for persistent storage, data transmission, and / or further transformation. Serialization by definition may require that it be logically completely reversible to reconstruct the original content or its equivalent in the source language. A Python structure 1512 can be transformed using JSON operations 1514 to generate an equivalent JSON string 1516; the reverse process may be possible, as indicated by the bidirectional process flow arrows. A simple tree data structure that can illustrate a complex Python data structure is shown at 1522. A serialize transformation 1524 can generate an equivalent string 1526 from 1522. This output string 1526 can then be stored, transmitted and / or transformed as the program progresses.

[0032]

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

[0033] 17 shows a detailed example of a digest transform in reverse mode, also known as verification. In TOP, this is sometimes referred to as a projected reversal of the transform. A digest transform 1710 may accept data D1 1702 and attribute A1 1704 as inputs to perform a forward mode digest transform 1710, which may produce a digest string DG1 1712 as output 1708. A reverse mode 1720 of this transform may accept data D1 1722, attribute A1 1724, and digest string DG1 1728 as inputs 1736 to perform a reverse mode digest transform 1720, which may produce a flag and / or value indicating whether digest string DG1 1728 was verified 1732 or failed verification 1734 as output 1738. The verification process 1740 may generate digest string DG2 1722 by performing forward mode digest transformation 1720 on input D1 1722 and input A1 1724. The output digest string DG2 1722 may then be compared 1730 for equality against input digest string DG1 1728. The results 1738 of the comparison may be presented in some form to indicate whether the reverse digest transformation was successful. In this way, planning this digest reversal may require the forward mode of transformation to be reprocessed and the outputs compared rather than relying on the workaround of finding the logical reversibility of such operations, which may be difficult, time-consuming, and / or impossible to achieve.

[0034]

[0032] Figures 18, 19, and 20 show detailed examples of scipher transforms in forward and reverse modes, also known as symmetric ciphers. Scipher transform 1806 in forward mode may accept clear text 1802 and attributes 1804 as input to generate cipher text 1810 and / or attributes 1812 as output. Scipher transform 1826 in reverse mode may accept cipher text 1830 and attributes 1832 as input to generate clear text 1822 and / or attributes 1824 as output. Figure 19 shows how a salsa20 symmetric cipher may operate as a scipher transform. Scipher salsa20 transform 1906 in forward mode may accept clear text 1902 and attributes 1904 as input to generate cipher text 1910 as output. The attributes for this particular cipher in forward mode may comprise a binary symmetric key, a key length, and / or a salt value. This salsa20 forward (encrypt) implementation may be a streaming cipher, and no additional output attributes may be generated during the encryption process, except for any hidden attributes the function may embed within its own output string. The scipher salsa20 transform 1926 in reverse mode may accept as input cipher text 1930 and attributes 1932 to produce clear text 1922 as output. The attributes for this particular cipher in reverse mode may comprise a binary symmetric key, a key length, and / or a salt value. This salsa20 reverse implementation (decrypt) may be a streaming cipher, and no additional output attributes may be generated during the decryption process. Figure 20 shows how a salsa20 symmetric cipher may operate as a transform on sample data as it may be expressed in Python v3.6 and PyCryptodome library functions. Scipher salsa20 transformation 2006 in forward mode may accept as input a data string 2002 and attributes 2004 comprising a 256-bit symmetric private key and a nonce (as salt) to produce ciphertext 2010 as output.In Python, the symmetric key may be represented as a "byte" data type string, so the key length attribute may be easily derived with the len() function on the key byte string. The scipher salsa20 transformation 2026 in reverse mode may accept as input the ciphertext 2030 and an attribute 2032 comprising the 256-bit symmetric private key and nonce to produce cleartext 2022 as output. In Python, the symmetric key may be represented as a "byte" data type string, so the key length attribute may be easily derived with the len() function on the key byte string. The attribute 2032 may be required to be equal to the attribute 2004 so that this conditional reversible transformation properly processes the ciphertext 2030 in reverse mode (decryption) to recover the original cleartext 2002.

[0035] Metamorphosis Type In the following tables and examples presented in Figures 21-35, each transformation may not be limited to the operations specified in the table; any suitable operations may be analyzed through TOP and then integrated into the framework to extend the computational capabilities of a particular transformation. To illustrate the examples in more detail, Python v3.6 syntax and constructs may be used. Equivalent data types, structures, syntax, and / or methods may be found in different programming languages ​​by those skilled in the art and used instead. In some cases, key / value options may not be relevant to a particular language or library, and may be ignored or modified as needed as long as the processing can produce equivalent results.

[0036] serialize / compress transformation FIG. 21 shows a table 2102 of command specifications for the serialize and compress transforms, along with a set of sample transform commands 2104 illustrating their usage. Table 2102 lists the transform name and acceptable operation types for each transform. A column header with a trailing "=" indicates that the value presented below it may be presented in key / value format in a command syntax construct. The "Input" and "Output" columns may specify the expected data type / structure for the transform / operation within the context of Python v3.6. For example, the command "serialize json sortkeys=t" may perform the following sequence of data manipulations: take a Python data structure as input, perform json.dumps() on it with the "sort_keys" flag set to true, and then output a Python string with a serialized version of the data. The reverse mode of this command may expect a JSON-formatted Python string as input, perform json.loads() on it, and then output a Python data structure. The "sort_keys" flag informs the json.dumps() function to process the keys of a Python dictionary structure in ascending order. Python v3.6 may not guarantee a consistent processing order for dictionary structures when processing by key, and therefore the resulting JSON string may be inconsistent between multiple runs of this transformation on the same data structure. Sorting the keys in a specific order within the serialization transformation may provide a consistent processing sequence that results in equivalent JSON strings as output between multiple runs on the same data structure. This may be crucial for determining whether two JSON strings are equivalent and therefore may represent two equivalent pre-serialized data structures.

[0037] The compress transform in table 2102 indicates several different lossless or lossless compression operations. Lossy or lossy compression operations can expand the compression transform repertoire, but for purposes of describing lossless transforms, it may not be interesting or constructive to describe one-way functions that serve little cryptographic purpose beyond data size reduction. From a TOP perspective, lossy compression can be analyzed and treated similarly to the digest transform described in a later section. In the example in 2104, the command "compress bz2" can perform bz2 compression on a binary string input, producing a binary string output that may or may not be smaller in size than the input string. Some data is no longer compressible using a particular compression scheme; one example of this may be when a bz2-compressed string can be processed again and no further data size reduction may be achieved.

[0038] encode FIG. 22 shows a table 2202 of command specifications for the encode transform and a set of sample transform commands 2204 illustrating its usage. There are numerous encodings available in computer science, and the references in this table do not necessarily represent all known encodings. The encodings listed under the "encoding=" column can be found in Python v3.6 and its associated standard library. Those skilled in the art will recognize the utility of having access to all these types of encodings toward solving problems related to applications that may manipulate data. "Codecs(98)" refers to the list of supported codecs in Python v3.6 as of this writing and listed previously in the table in FIG. 11. The transform command "encode strbin utf_8" can take a Python string as input, perform utf_8 Unicode encoding on it, and output the result as a Python byte string. The transform command "encode utf utf_16" may take a Python string as input, perform utf_16 Unicode encoding on it, and output the result as a Python string. The transform command "encode binascii hex" may take a Python byte string as input, perform hex encoding on it, and output the result as a Python string. The transform command "encode base 64" may take a Python byte string as input, perform base64 binary encoding on it, and output the result as a Python string. The transform command "encode utf_8" is equivalent to "encode utf utf_8". These descriptions may illustrate the consistency and types of permutations allowed in the encode transform command syntax.

[0039] digest metamorphosis

[0037] Figure 23 shows a table 2302 of command specifications for digest transform and a set of sample transform commands 2304 illustrating its usage. The digest transform shown in table 2302 defines three types of operations: hash, hmac, and / or cmac. The transform command "digest hash md5 The mutate command "digest hash sha2 512" may take a source data string as input and perform the SHA2 hash function on it, producing an output digest byte string that is 128 bits in length. Note that the input source data string may not be modified or overwritten during the digest mutate call, and the output digest byte string may be additional data generated from the digest mutate call and may be given a separate memory space. The mutate command "digest hash sha2 512" may take a source data string as input and perform the SHA2 hash function on it, producing an output digest byte string that is 512 bits in length. The mutate command "digest hash shake256 digestlen=332" may take a source data string as input and perform the SHAKE256 hash function on it, producing an output digest byte string that is 332 bits in length. The mutate command "digest hmac sha2 256" may take as input a source data string and perform an HMAC function on it using a SHA2 hash, producing an output digest byte string that is 256 bits in length. The mutate command "digest cmac aes 256" may take as input a source data string and a 256-bit symmetric key and perform a CMAC function on it using an AES256 cipher, producing an output digest byte string that is 128 bits in length. All of these digest mutate example operations and types may be found in the standard Python library and / or the PyCryptodome library and do not necessarily represent all the variety of operations, types, digest lengths, key lengths, and / or other parameters that may exist outside of these sample libraries in a theoretical and / or implemented sense. Additional variants may be analyzed and integrated into the mutate shaping formula as appropriate through TOP. Such integration into the mutate shaping formula may require refactoring and retesting of existing mutate operations.

[0040] acipher / dign transmutation 24 shows a table 2402 of command specifications for the acipher transform and tables 2404 and 2406 of command specifications for the dign transform, along with a set of sample transform commands 2410 illustrating their use. The transform command "acipher pkcs1_oaep 2048" may take as input a byte string and a 2048-bit RSA asymmetric public key, and perform an RSA PKCS#1 OAEP cipher operation on it using a 512-bit SHA2 hash, producing as output a ciphered byte string that is 2048 bits in length. The transform command "acipher pkcs1_v1_5 3072" may take as input a byte string and a 3072-bit RSA asymmetric public key, and perform an RSA PKCS#1 v1.5 cipher operation on it, producing as output a ciphered byte string that is 3072 bits in length. The reverse modes of these acipher transformations may require as input the ciphertext as a byte string and the private part of an appropriate RSA key to produce the original cleartext.

[0041] The transform command "dign pkcs1_v1_5 2048" may take as input a byte source string and a 2048-bit long RSA asymmetric private key, perform an RSA PKCS#1 v1.5 digital signature operation on it using a 512-bit SHA2 hash, and produce as output a digest byte string that is 2048 bits in length. Note that the term "digest byte string" may be used interchangeably with "digital signature byte string" since TOP may consider these outputs to provide similar functionality and may therefore store such a byte string under the "digest" variable name. The transform command "dign dss The "1024 hashtyp=sha2" may take as input a byte source string and a 1024-bit long DSA asymmetric private key, and perform a DSS digital signature operation on it in FIPS-186-3 mode using a 512-bit SHA2 hash, producing as output a digest byte string that is 1024 bits long. The transform command "dign dss 256" may take as input a byte source string and a 256-bit long ECC asymmetric private key, and perform a DSS digital signature operation on it in FIPS-186-3 mode using a 512-bit SHA2 hash, producing as output a digest byte string that is 256 bits long. The reverse modes of these dign transforms may require as input the digest byte string (digital signature), the source byte string, and the public part of the appropriate asymmetric key to authenticate it.

[0042] derivetransformation 25 shows tables 2502, 2504, 2506 of command specifications for the derive transform, and a set of sample transform commands 2510 illustrating its use. The sample operations pbkdf2, hkdf, and scrypt may also be known as key derivation functions and / or key stretching functions. The basic function of the derive transform may be to derive one or more symmetric keys of a desired length from a binary or character data string that may be known to a user, and a common use of a key derivation function may be to derive one or more appropriately formed symmetric encryption key(s) from a password or passphrase. The transform command "derive pbkdf2 keylen=256 iterations=100000" may take as input a character data string (password or passphrase) and perform a PBKDF2 operation on it using a SHA2 512-bit hash function, a randomly generated 512-bit initialization vector as salt, and an iteration count parameter set to 100,000 to generate a corresponding symmetric key that is a 256-bit long byte data string. The transform command "derive hkdf keylen=256 numkeys=4" may take as input a byte data string and perform an HKDF operation on it using a SHA2 512-bit hash function, a randomly generated 512-bit initialization vector as salt, to generate a corresponding set of four related symmetric keys, each of which is a 256-bit long byte data string. The transform command "derive scrypt keylen=128 mode=login" may take a data string as input and perform a login mode SCRYPT operation on it using a randomly generated 512-bit initialization vector as the salt to generate a corresponding symmetric key, which may be a 256-bit long byte data string. The login mode of the derive scrypt transform may be shorthand for setting the three parameters n, r, and p to the values ​​shown in Table 2506. These parameter values ​​may be the suggested settings of the author of the SCRYPT algorithm.

[0043] The TOP approach of the derive transformation may suggest a bimodal operation. Data mode: If the transformation can only involve a type of data source string, without any key stack (to be explained in detail in a later section), it may transform this input data source string and replace it with the output of the transformation, which may be in the form of a symmetric key(s). Key mode: If the transformation can involve a key stack and a type of data source, it may transform the corresponding key source material present in the key stack, replace that key source material, and thereby derive cryptographically usable symmetric key(s) and place them in the key stack. These statements may be further clarified in later sections when key stacks and key management are explained within the context of transformation audit records or TARs and dependent transformations.

[0044] scipher transmutation Using TOP, symmetric cipher operations can be categorized as scipher transforms and as groups, and these transforms can exhibit sets of associated attributes that can be extensive in both number and / or variety. The following three figures show how TOP can systematically normalize each scipher transform with all its attributes and encapsulate them into the same output string. This type of attribute embedding technique can be found in a variety of functions and libraries for many types of operations. However, widely accepted standards for such embedding techniques can be quite scarce. TOP can propose a consistent methodology that can be applied to all scipher transforms for different purposes, supporting a feature called Structured Data Folding with Transformations, or SDFT. Whether such a methodology can become a widely used standard may be beyond the scope of this specification, but the reader may recognize the possible benefits of its use within the TOP framework, especially as we later describe the TAR and SDFT constructs and methods.

[0045] FIG. 26 shows a table 2602 of command specifications for scipher transformation and a set of sample transformation commands 2604 illustrating its usage. The table shows three types of scipher operations: aes, chacha20, and salsa20. This is not an exhaustive list of known symmetric ciphers, but it may present their associated variety to show how TOP may organize them and suggest their usage. Symmetric ciphers may have the following attributes associated with them, to a greater or lesser extent: key length (keylen), operation mode (mode), salt type (salttyp), salt length (saltlen), block size (block), cipher operation type (type), and / or padding (pad). Key length may specify the length of the secret symmetric key that may be used in the cipher to generate cipher text from clear text. For AES ciphers, they may have at least 10 different operation modes, as shown in the table. Most symmetric ciphers may require the input of a salt (random value) of a specific type (iv or nonce) and a specific salt length, the use of which may promote better semantic security. Symmetric ciphers may provide at least three different operation types: block ciphers, stream ciphers, and / or AEAD ciphers. Newer modes may be proposed and integrated using TOP as an additional transformational variant. Block mode ciphers may require additional attributes comprising padding methodology, pad positioning, pad type, and / or pad length.

[0046]

[0044] In the example in section 2604, the transformation command "scipher aes 256 mode=ofb" may take as input a byte data string and a 256-bit symmetric key, encrypt the input data string using an AES-256 OFB mode streaming cipher with the provided key and a randomly generated 128-bit initialization vector, and produce an output string that may consist of the cipher text and all associated attributes involved in the process embedded in the header of the output byte string formatted in a consistent key / value format as specified in Figure 27 (which will be described in a later section). The mutate command "scipher aes 128 mode=gcm" may take as input a byte data string and a 128-bit symmetric key, encrypt the input string using an AES-256 GCM mode AEAD streaming cipher with the provided key and a 128-bit nonce, and produce an output byte string that may consist of the cipher text and all associated attributes involved in the process embedded in the header of the output string formatted in a consistent key / value format as specified in Figure 27. AEAD is an acronym for authenticated encryption with associated data, and may be a standardized or well-known way of embedding authentication functionality along with the cipher capabilities of a symmetric cipher within a single function call. The transform command "scipher chacha20 256" may take as input a byte data string and a 256-bit symmetric key, encrypt the input string using the CHACHA20 streaming cipher with the provided key and a 64-bit nonce, and produce an output string that may consist of the cipher text and all associated attributes involved in the process embedded in the header of the output string formatted in a consistent key / value format as specified in Figure 27.The mutate command "scipher salsa20 128" may take as input a byte data string and a 128-bit symmetric key, encrypt the input string using a SALSA20 streaming cipher with the provided key and a 64-bit nonce, and produce an output byte string that may consist of the cipher text and all associated attributes involved in the process embedded in the header of the output byte string formatted in a consistent key / value format as specified in FIG. 27.

[0047]

[0045] Figure 27 shows the output structure format for 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 key value UTF8 encoding parameter string of the scipher transformation for the output message. In step 1, the scipher may accept as input a variable-length message byte string "message," with optional padding of pad length typically placed at the end of the message if necessary. The message may be prepended with a salt value as may be recommended by the selected cipher. Padding may be a necessary requirement of block-mode symmetric ciphers. If a specific padding methodology is not specified by the programmer, a default padding methodology may be used and appended to the end of the message. This message and padding may be referred to as plaintext. The selected cipher may then process the input plaintext, as shown in step 2, and generate an output, sometimes referred to as the encrypted message. The chosen scipher transformer may then prepare the embedded header as a printable key / value pair in character string format, where the keys may represent parameter types and the values ​​represent their respective settings. The details of the keys / values ​​are explained in the next section. Once the header string has been generated, the transformer may calculate the length of this header string, called the header size, and may be formatted as a 2-byte long unsigned big-endian integer. The 2 bytes may range from 0 to 216The header size may range up to (65,536), which may be sufficient to describe all attributes for a symmetric cipher for the foreseeable future in this particular format. Step 2 may then proceed to create a packed message comprising the header size, the header, and the encrypted message. This packed message may be the actual output string from the scipher transform, and therefore it may be considered to have successfully encapsulated and embedded all attributes associated with the transformed data. The data flow for the reverse scipher transform may follow this process in reverse; i.e., the transform command may specify the exact scipher transform to perform, and the matching symmetric key and packed message may be given as input. The scipher transform may then unpack the packed message, read and store all attributes found in the header, and then prepare to decipher the encrypted message. Symmetric ciphers may not have a deterministic method for communicating successful decryption. An overlapping verification method may be used to determine such an outcome. An example of a rudimentary method might be to extract the prepended salt value from the decrypted message and compare it with the stored salt value from the header. A matching salt value might indicate a successful decryption, but not guarantee it. AEAD-mode symmetric ciphers might address this problem somewhat successfully by embedding a MAC (CMAC, HASH, or HMAC) of the data string within the encrypted message (before or after encryption) and performing the comparison. A more sophisticated method might require authentication of some form of digitally signed hash of the message using a different key. As will be shown in a later section, the use of SDFT and TAR can enable such refinements in a procedurally simple and logical manner. In all of these hash-based methodologies, it may be impossible to deterministically state the conditions for a decryption attempt sufficiently due to the weaknesses inherent in hashing schemes for universally uniquely identifying data.One deterministic method would be to compare the decrypted message with the original message for equality, but there may be an efficiency trade-off for lengthy messages.

[0048]

[0046] Figure 28 shows a table of parameter keywords and specifications for the header string in the output structure format of a scipher transform. The keywords chosen for this attribute table may be sufficiently self-descriptive and / or self-explanatory to one skilled in the art. Example attribute values ​​are shown in the right-hand column. The first attribute listed, header size, may be the only attribute that can be presented as a 16-bit binary unsigned big-endian integer value and may be the first field present in the header. This header size may indicate the number of subsequent bytes that may describe the attributes of this particular scipher transform in a printable format. The attribute format may be chosen to be printable to allow for variability in the range and length of attribute values. All attribute values ​​that may naturally exist as binary strings in a running program, including the salt value (salt_val) and MAC string (mac_val), may be encoded in base64 to satisfy the preference for printable characters.

[0049]

[0047] In this manner, the output string of a scipher transformation may comprise one or more encapsulated layers of attributes, depending on the specifics of the selected scipher. Figure 29 shows a diagram of iterative embedded message encapsulation for an AEAD-mode scipher transformation. An AEAD-mode AES cipher may output the listed subsequent layers from inner to outer. A message preparation layer 2910 may comprise a cleartext message to be ciphered 2914 combined with an appropriate salt value 2912. This prepared message 2910 may be encrypted with a selected AEAD cipher, which may then additionally generate a MAC value and additional data 2922 as part of the cipher process; this combined message may be referred to as the AEAD cipher output 2920. This AEAD cipher output 2920 may also be referred to as the encrypted message 2934. The encrypted message 2934 may have associated attributes from the scipher process, which may be parameterized using the keyword / value header method from FIG. 28 to generate the header 2932; this combination may be referred to as a scipher packed message 2930. This scipher packed message 2930 may be the output of a selected scipher transformation, which may be stored in the obj pointer or variable 2944 of an NSstr structure 2940, which may be associated with the TAR that called the scipher transformation. The structure of an NSstr is more fully described in a later section. Other attributes 2942 may also be stored in this data storage unit, called an NSstr structure, which may include the TAR, key stack, digest, and / or status flags. The obj pointer or variable 2944 in the NSstr structure 2940 may have been the starting point of the clear text message 2914, and therefore a recursive path 2950 may be possible, and there may be as many nested encapsulations of the object 2944 as required by the TAR it may be processing, which may itself be stored in an attribute 2942 of the NSstr structure 2940.

[0050] In the header 2932 of the scipher-packed message 2930, the parameters comprising a description of the symmetric cipher, its mode, and the attribute values ​​used may be completely and precisely described by the keywords listed in FIG. 28. In this regard, the TOP approach may not rely on obfuscation and hiding of non-cryptographic processes and procedures to secure data, but rather may rely solely on the theoretical and implemented security of the cipher being used as a metamorphosis. While this may not appear significant upon initial observation, it may later be shown that such clarity of the relevant details of a data transformation, embedded in the output of the transformation itself, may ultimately lend itself to novel methodologies and designs that may rely more on self-describing data than on hardwired programs to properly process it. This approach may help formulate one of the fundamental primitives in data-centric design and models that operate on data at some of the lowest layers of data storage science. NUTS, as will be shown in a later section, may rely heavily on data-centric designs and models.

[0051] FIG. 30 shows a table 3002 of command specifications for the lock transformation and a set of sample transformation commands 3010 illustrating its usage. The lock transformation is one of the additional transformations listed in the table in FIG. 12, which may be an embodiment of variable lock from NUTS, as described in detail in FIGS. 65-77. Variable lock may represent several different ways of cryptographically locking a secret message, including sslock, orlock, matlock, xorlock, and hashlock. A feature of variable lock may be the ability to input and use several cryptographic keys in the process of enciphering a secret message in a normalized, systematic, and coherent way. The TOP approach may allow for a concise way of implementing such locking techniques in a simple and convenient manner. In the example of section 3010, the mutate command "lock orlock 128 numkeys=10 scipherkeylen=128" may take as input a byte data string and up to ten 128-bit equivalent symmetric keys, encrypt the input string using the "scipher aes 128 mode=eax" mutate command, and generate an output string with ciphertext and associated embedded attributes. The mutate command "lock matlock 256 numkeys=5" may take as input a byte data string and five 256-bit symmetric keys, and iteratively encrypt the input string using the "scipher aes 256 mode=eax" mutate command for each key, and generate an output string with ciphertext and associated embedded attributes. The 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 shared keys, encrypt the input string using an implementation of Shamir's secret sharing method with the supplied secret shares, and produce an output string with cipher text and associated embedded attributes.The mutating 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 shared keys, encrypt the input string using an implementation of Shamir's secret sharing method with the supplied secret shares, and produce an output string comprising cipher text and associated embedded attributes. The "xorlock 128 numkeys=6" may take as input a byte data string and six 128-bit symmetric keys, derive a calculated key by repeatedly performing XOR operations on the supplied keys, and encrypt the input string using the "scipher aes 128 mode=eax" transformation command to generate an output string with ciphertext and associated embedded attributes. The "lock hashlock 192 numkeys=7" may take as input a byte data string and seven 192-bit symmetric keys, derive a calculated key by performing a hash on the ordered concatenation of the supplied keys, and encrypt the input string using the "scipher aes 192 mode=eax" transformation command to generate an output string with ciphertext and associated embedded attributes.

[0052] A description of each variable lock type and mode of operation can be found in the later section on variable locks, beginning with Figure 60. The TOP analysis and method may allow complex iterative locking variations that potentially utilize multiple encryption keys to be performed in a concise and logical manner, allowing for easy extension to different types of locking algorithms in the future. It will also be shown later that the key management aspects of SDFT may allow programmers to conveniently generate and manage such multiple encryption keys with relative ease.

[0053] As presented in Figures 12, 13, and 14, the TOP analysis and method may enable one skilled in the art to take a given data manipulation function and determine its suitability for transformational operations and normalization to types. The table in Figure 12 may represent a sampling of very well-known data manipulations and may very well be considered sufficient for use by a wide audience of developers. However, in cases where a data manipulation function may not be found in this table, it may be possible to analyze the function and adapt it to work within the SDFT framework using functions such as the TOP method, lossy compression, bit scattering, message dispersal, erasure coding (ECC), and message-level RAID encoding and structuring. In most cases of such transformational extensions, recoding or rewriting the actual data manipulation function may be unnecessary. In fact, doing so in most situations may be counterproductive and procedurally weak. Libraries containing data manipulation functions can be accessed by the transformation library, and the TOP method can allow developers to provide normalized wrapper functions around specific data manipulation functions to behave well within the SDFT framework.

[0054] Metamorphic Structure, Metamorphic Audit Record (TAR) and Structured Data Folding with Metamorphism (SDFT) FIG. 31 shows the specification of various mutating structures in tabular format. The structure definition relies on a nested key-based approach similar to how structures are defined in Javascript, which may be an intentional design choice so that its representation can be easily replicated in a wide variety of programming languages ​​and may not rely on specific language idiosyncrasies. For example, Python v3.6 allows classes to be defined, but some languages, such as Javascript, may not allow this, and thus the mutating data structure may not rely on classes to define it for broader applicability. A mutating structure may provide a well-defined working memory area where mutating inputs and outputs may be prepared, processed, and / or stored. The main data storage unit or structure that may be used in most, if not all, mutating operations is called the NSstr structure 3108. There may be at least one instance of NSstr associated with a mutating call. Every mutating structure may have a "typ" or structure type field that specifies what structure it represents. An NSstr structure may further define a "state" field that specifies the state of the structure and / or its data. The "obj" or object field may either hold a single value, or it may be a pointer that references another region of memory. The obj field may be where the input data to most transforms can be found. The obj field may also be where the output data of most transforms can be found. The "digest" field, if present, may store a digest of the data stored or referenced by the obj field. The manner in which the digest may be generated may depend on the particular dig or digest transform and the parameters and / or attributes supplied to that transform command. The "key stack," if present, may be a single instance of a KISS (Key Exchange Specification Structure, to be described in a later section) structure, or it may be a list of KISS structures in a predetermined order corresponding to its operation TAR.The key stack essentially holds the private key(s) of various types that may be required by some transformation. The 'tar' field may point to an instance of an NStar structure 3106.

[0055]

[0053] The NStar structure 3106 may specify a particular transformation audit record (TAR) that can be applied to input data stored in the obj field of an NSstr structure. A TAR can be a collection of transformation commands in a logical order that may be intelligently ordered to process the data in the NSstr in a coherent and well-behaved manner to produce a single "fold" of the NSstr data. This process of performing a TAR on an NSstr data structure is sometimes referred to as a "ravel" function call. Conversely, an "unravel" function call can "unfold" a single folded data in an NSstr structure using the same TAR, relying on the inherent properties of reversible transformations. Thus, reversibility of transformations can be a central feature in Structured Data Folding with Transformations (SDFT). SDFT methodologies can use a TAR on an NSstr structure to iteratively transform objects in a manner that resembles assembly-line operations on the data. Analysis may be performed on the reversible behavior of each transformation command in the TAR, so that the TAR can be calculated in reverse mode or unravel function calls. This topic will be explained in more depth as additional necessary components that may enable such behavior will be presented in the following sections.

[0056] The NSbin structure 3102 may service specific functions that may or may not be related only to Python v3.6. In Python v3.6, a distinction may be made in the way a string of data may be stored internally. It may be stored as a "byte" string or a character string. A byte string data type may indicate that the information held in a variable may be a series of binary bytes. A character string may indicate that the information held in a variable may be a series of bits representing characters encoded in some type of encoding scheme. Python v3.6 may employ sophisticated internal management schemes to best determine how to store a particular character string, as different encodings may require different storage requirements per "character." One example may be that UTF-8 may use an 8-bit long code unit to represent each character, while UTF-16 may use a 16-bit long code unit to represent each character; these variations may be necessary to convey different international character sets, where the number of characters in a language may be quite different from the English alphabet and therefore may not fit into an 8-bit transposition of data. The preferred internal serialization method for transmutation, TAR, and SDFT may be JSON, which may not have native support for mapping the Python "byte" data type to one of its own. If a conversion is attempted, the JSON function call may suddenly fail with some indication that the particular data type may not be supported. An NSbin structure may be specially designed for this type of situation and may be substituted with a "byte" data string, thus making the Python variable JSON-compatible. The "byte" string may be encoded into a base64 character string and stored in the "b64" field of the NSbin structure. A byte string variable may then be made to 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 may be that NSbin structures can be fully JSON-compatible and can then be safely serialized using JSON functions without errors due to incompatible data types.

[0057] In the TOP technique, this conversion and substitution from "bytes" data to NSbin structures is sometimes referred to as the "press" transform from Figures 12 and 33. In Python v3.6, the press transform listed in Table 3302 can take any valid Python structure or variable and iteratively transform any byte string into an equivalent NSbin structure, which may result in a Python structure lacking the byte data type. Those skilled in the art can customize appropriate press transforms and their JSON function calls for languages ​​other than Python v3.6 to eliminate such sources of data serialization errors. The reverse mode of "press," sometimes referred to as "depress," can iteratively undo the conversion and substitution so that a data structure containing its original data type can be restored.

[0058]

[0056] The NSjson structure 3104 may serve a particularly useful function: holding only data that can be fully JSON-compatible. A glance at the fields defined for NSstr 3108 may alert us to a potential problem if the structure were submitted directly for JSON serialization, with its digest field potentially holding the digest value of the source obj in binary string form or a byte data string in Python v3.6. Referring again to Figure 12, we reintroduce the "mobius" transform for this particular problem. Note that the reasonable definition of the mobius transform prior to this point in this description may not be entirely clear to the reader due to the intertwined nature of the transform and TOP techniques. The mobius transform in Figure 32 may transform a given structure from one form to another, circularly, but with a slight twist, as in the case of a Möbius strip. The mobius transform can be a key enabler of structured data folding with transforms by systematically converting NSstr structures into JSON-serializable structures such as NSjson; the conversion process embeds the operation TAR for NSstr as a whole along with the transformed data, thereby resulting in the self-describing properties of the resulting storable object. The mobius transform can be one embodiment that implements the essence of structured data folding in the SDFT library in a convenient manner. While developers may choose to implement SDF manually using a logical combination of transform commands other than the mobius command, the mobius command adds at least one extra logical step that may require developers to implement that step outside of the SDFT library: the ability to serialize the NSstr data structure that the mobius command is operating on and from into another structure such as NSjson. The mobius transform can be the last transform command in the TAR. Because of its functionality, this may be the only logical place where the mobius transform can be placed.When a mobius transform is processed, it may take the NSstr structure that it may be operating from and on and transform it into an NSjson structure. The TAR embedded in the NSstr structure may no longer exist in a useful or accessible form, and therefore the mobius transform may be the last transform command for a given TAR to be processed. The mobius transform may simply compress the NSstr structure, JSON serialize it, and then store it in an NSjson structure, which may be stored, transmitted, JSON serialized, folded, or subjected to other valid data operations that may be performed on such a structure. While there may be a reverse mode for the mobius transform, another way to view this transform may be to state that it is a circular transform; whether in forward or reverse mode, it performs a specific data transformation depending on the input data structure type. Table 3204 shows the NSx structure of which NSjson may be a variant. In case the need for additional transformation structures other than those defined in Figure 31 arises in the future and they may need to be accommodated in the mobius transform, this table shows how the mobius transform may behave for transformation structures other than NSstr. While it may not be entirely obvious without actually programming with SDFT, the mobius transform may logically imply that there may be no TAR processing possible from an uncompressed NSjson structure unless the mobius transform is operated on the uncompressed NSjson structure to convert it into its original NSstr structure, which may retain the TAR that may have folded it. To start this mobius spin cycle with an NSjson structure, mobius(reverse) may be kickstarted with a mobius function call from the SDFT library to generate an NSstr structure, access the embedded TAR, and process the embedded TAR in the reverse direction.This may further imply that the mobius transform command in the TAR, which by definition is the first command to be processed in reverse mode, can be safely ignored during processing because it may have already been performed by a kickstart function call, thereby preventing it from performing the mobius function more than once during such a reversal. With this ordering, failing to ignore the mobius transform in reverse mode could potentially generate an infinite oscillation of mobius calls that continuously convert from NSstr to NSjson and vice versa. While this may seem like a roundabout way of expressing such an operation, it may generate a fairly compact bidirectional TAR that can be systematically embedded in the output transformed data, thereby providing self-describing properties to the folded data. This property may be novel in that it can be acted upon in both forward or reverse mode for similar interpreted scripts to perform operations on data in a consistent, reproducible manner across any language and / or operating system that can support an implementation of the SDFT library.

[0059] FIG. 33 shows a table 3302 of command specifications for the press and clean transforms, a table 3304 of command specifications for the key transform, and a set of sample transform commands 3310 illustrating their usage. The clean transform may be a housekeeping function that removes transient or temporary fields from within an NSstr structure. Some transforms may have a need for additional temporary fields during processing and may create additional fields within the NSstr structure to store and access them. The creation and use of such transient fields within an NSstr may be done in a judicious manner after analyzing their coexistence within the TOP methodology and minimizing their interference with the proper functioning of other transforms. Due to the function of the clean transform, there may be no inverse mode for the clean transform, and therefore it may be safely ignored. This inverse implication may be taken into account when proposing a new transient field within an NSstr structure; the field may not be present in the inverse mode processing of the transform, and therefore the transform in the reverse direction may not depend on the presence of the field to function properly. An important function of the clean transformation may be to delete the internal copy of the complete key stack used in the TAR process, or it may delete only the private key in the key stack and convert the KISS structure to a keyhole. This may be the single most important transformation in the SDFT TAR process, because failing to properly clean NSstr before preparing it for storage may result in the storage of any and all encryption keys that may be used in a particular TAR process, which may be inadvertently stored in cleartext along with the folded data. This situation may reveal the private key and compromise some or all ciphered data within the folded data, which may not be the intended purpose of enciphering the data.

[0060] In Table 3304, the key transformation is shown along with some of its operations. This transformation may be part of the key management functionality of the SDFT, and may operate primarily on the key stack field by referencing the tar field of the NSstr structure. A check transformation may examine a stored TAR and generate a list of key templates. When a key stack is input, it may be compared to such key templates to determine if the correct key types in the proper 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 may list "symmetric" in the list. NSstr structure prior to TAR processing on the data stored in the obj field. A partial "key generation" mode may be engaged. The key check and key generate transformations may cooperate to determine whether the partially supplied keys in the key stack are of the appropriate type and in the appropriate sequence. It may then proceed to generate appropriate keys for the missing keys. This process is sometimes referred to as the "missing tooth" scenario of SDFT key stack management. Examples of TAR with key transformation commands may be few, if any, because they may be considered so fundamental to the SDFT library's proper operation on TAR-based NSstr structures that they may therefore be implicitly implemented by default in every call to a Ravel / Unravel operation, rather than requiring the programmer to place it in every TAR. However, it may be seen that having the possibility to process a TAR that may require a cryptographic key may be sufficient cause for consistent, implicit, and / or automatic checks for proper key stack management. The TAR reversal process may process the key stack in reverse order accordingly. A feature of the derive transformation in key stack mode may cause complications, which are explained in a later section on how SDFT handles such a situation, called TAR grouping for dependency transformations.

[0061]

[0059] Figure 34 shows a table for the Key Exchange Specification Structure, or KISS. This structure can have at least two modes of operation: key or keyhole. Key attributes can be specified by some or all of the fields defined in the table, and additional fields can be added as needed to extend the structure to support other key attributes. A TOP approach to cryptographic operations can be to assert a view of that transformation to request a matching keyhole that specifies the exact type of key required for each cryptographic transformation. Attributes can include, but are not limited to, a virtually unique ID for the key itself, a passphrase or password question or hint, a key description, etc. If a key value can be present in a KISS structure, it may simply be referred to as a key. If a key value can be missing from a KISS structure, it may be referred to as a keyhole. This can be indicated by the value in the "ima" field. The field name can be a shortened form of "I'm a" key / keyhole and can be read as such for clarity. The column titled "In" may indicate required values ​​for inserting a key into a blank KISS structure in order to create it and place it in the input key stack of the NSstr structure. The column titled "Gen" may indicate fields that may be automatically created and filled during key generation transformations from within the SDFT library. Throughout the SDFT description involving TAR, all key references may be synonymous with a KISS structure of the appropriate type. It may be clear that the key stack may correspond exactly to the characteristics of the TAR being processed, and that this method of stacking transformation commands and stacking required cryptographic keys in a specific format and sequence may allow input data to be iteratively processed through an infinite number of transformation variants, parametric distribution of transformations, and / or sequential data folding. At this point in the description of TOP, one may begin to understand the intertwined nature of the various components of SDFT and that a complete understanding of a particular part may not be fully exposed in a linear fashion.

[0062]

[0060] Figure 35 shows table 3502 for the KISS operation mode, table 3504 for a matrix showing key type / field occurrence mapping, and table 3506 for key type definitions. Table 3506 lists several types of keys recognized by SDFT, but it may not be limited to these, as new key types may be added and integrated as needed. At least three key types may be structured specifically for the SDFT library using well-known base key types, so these may require some explanation. The key type "symmetriclist" may be an array or list of symmetric keys and may be stored as key values ​​within a single KISS structure. This key type may support transformations such as, but not limited to, lock and derive. The secret-sharing lock transformations, called sslock and sslock_b, may represent two different implementations of Shamir's secret-sharing algorithm, respectively. The lock sslock transformation may expect secret shares in a specific format with an internal index number and key shares in a 256-bit key. This is sometimes referred to as the "tines256" key type within the SDFT library. The lock sslock_b variant may expect secret shares in a specific format with an internal index number and key shares in a 256-bit long key. This is sometimes referred to as the "tinesidx256" key type within the SDFT library.

[0063] Table 3502 is a matrix showing what properties can be applied to a KISS structure in the two modes it can exist in: key (or metamorphic) or keyhole. In metamorphic (key) mode, the KISS structure can be expected to store the actual cryptographic key to generate a version of ciphertext that may include a keyed digest and / or dign. Therefore, its storage can be used informationally, but it needs to be further embedded using a cryptographic function to store it persistently in a secure manner. In keyhole mode, the KISS structure can be expected to have sufficient detail to accept an appropriate cryptographic key as its value to generate a version of ciphertext that may include a keyed digest, dign, and / or derived keys. Therefore, its storage can be mandatory and may not need to be further secured by an embedding methodology, since it may not contain a key value as a keyhole.

[0064] Table 3504 is a matrix indicating, by key type, which fields are required, relevant, entered, and / or can be generated. Upon examining the table, it may be apparent that the KISS structure may hold salts related to various cryptographic operations. This may seem redundant in light of the description of the scipher-embedded header, but that description of the salt may not present the full picture. As shown in FIG. 37, the persistence of attributes 3704, 3714 related to transformations may be distributed among several data storage areas 3732, 3734, 3736, and 3738. The TOP approach may indicate that salts may be embedded during some cryptographic operations along with the resulting output data, since the resulting output data may not reveal additional information about the generated ciphertext. However, upon examining key derivation transformations processed in key stack mode, it may be noted that it may be convenient and logical to store the associated salt values ​​in the KISS structure. A common use of a key derivation function might be to accept a passphrase as input and combine it with a salt value to generate an appropriately formed encryption key, such as, but not limited to, a symmetric key. The use of the salt in this case might be for semantic security. Thus, it might be entirely possible that every keyhole that can accept the same passphrase might have a different salt in an order that would cause the resulting private encryption keys to differ from each other, for whatever reasonable reason. This derived key might be used in a temporary manner and discarded after use, thereby leaving only the keyhole as evidence of its existence. Since the product of the key derivation might be used as a private key, it might not generally be saved permanently, which might obscure the question of where it might be stored. TOP might store it in the corresponding keyhole, and SDFT might prefer to store this keyhole along with the folded data, so that each keyhole that can accept the same passphrase can dedicate its storage to its own instance of the salt value. The programmer can store the KISS keyhole externally in a completely different way.The simplified transformation diagram at the top of Figure 37, which is the same as in Figure 5, becomes the diagram at the bottom of Figure 37 when various components of TOP and SDFT can be introduced. Table 3720 summarizes the placement of the attributes.

[0065] Most have been analyzed via TOP and SDFT and discussed above in terms of the syntax and variety of available transformation commands, but what exactly is a TAR? Figure 36 shows the structure of a TAR and lists some examples of TARs. Section 3602 specifies the general structure of a transformation audit record, or TAR. The "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. Thus, many TARs can be declared in a single text file. The TAR definition section can contain a TAR label by itself or a line with transformation commands. This can be similar to the macro feature of programming language compilers, and can be used as a convenient feature to combine familiar TAR constructs into a new TAR without having to actually copy the definitions into the TAR itself. Transformation commands can be inserted in a specific sequence to process the target NSstr structure in a desired manner. TAR "test_a01" may simply press a Python data object into an equivalent structure lacking the Python byte data type; in other languages, it may or may not perform the same function, as "press" may be language and / or environment specific. TAR "test_a02" performs the press transformation twice in succession. The second press transformation may not achieve a functional change to the data. This indicates that TAR extensions are working. TAR "test_a07" may press the data, serialize it into a JSON string, and then convert it to a byte-type binary string using utf_32 encoding. TAR "test_a17" shows what the final mobius transformation may look like.The TAR "test_a20" compresses the data, serializes it to a JSON string, converts it to a utf_8 encoded binary string, ciphers it using chacha20 with a 256-bit symmetric key, and then converts the resulting binary ciphertext string to a base64 encoded character string. The symmetric key for the scipher transformation can be expected in the NSstr's key stack, which may contain a single KISS structure holding the 256-bit symmetric key value. An alternative is that no key stack can be provided, and the Ravel function proceeds to generate a valid key stack with an appropriately generated random 256-bit symmetric key and uses it to perform the scipher transformation, allowing the programmer to fetch a copy of the key stack (and therefore the keys within it) upon completion. The TAR "test_a42" shows an example of a TAR group and dependency transformation: 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 the passphrase provided in the key stack, and then performs chacha20 encryption on the data using the derived symmetric key. The last two transformations may have persistent dependencies because the cipher relies on the derived key; therefore, this dependency may be grouped within the TAR and marked as such with a leading <tag>. In forward mode, there may be no obvious impact of TAR grouping within the TAR definition, except to visually highlight such dependencies. However, TAR groups may play a significant role with respect to TAR reversal. When a TAR is being prepared for the TAR reversal process, the TAR group may be kept intact as a unit, and its components may not be reversed. Figures 41 and 42 show some examples of TAR reversal. The TAR "test_a64" may perform five scipher transformations and the DSS dign transformation. This TAR may expect a key stack filled 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" may be shown in section 3610.This key template can be used by implicit key check and / or generate transformations to validate the input key stack and / or generate a valid key stack for proper processing of the TAR.

[0066]

[0064] Figure 38 shows a block diagram of the SDFT operations Ravel and Unravel (or the inverse of Ravel). The two central operations in SDFT may be "Ravel" and its inverse, "Unravel." A Ravel operation may process a given NSstr, which may comprise some or all of the following items: data, TAR, key stack, and / or other attributes. A Ravel operation may "ravel" or fold 3810 the source data in 3802 according to the sequence of transformations listed in the TAR in 3802, ultimately producing output as components in an NSstr structure 3804 or an NSjson structure 3806. An unravel operation may "unravel" or unfold 3820 the source NSstr 3804 or NSjson 3806 structure according to the reversed sequence of transformations listed in the embedded TAR, ultimately producing output as an NSstr structure 3802. As will be shown, Ravel / Unravel symmetry can be an interesting aspect of this design. Note the consistency of terminology and perspectives used throughout TOP. A Ravel operation in reverse can be equivalent to an Unravel. This reversibility principle not only can simplify the analysis of such functions, but it can also permeate modular organizational methods that can lead to higher-order concepts related to data transformations.

[0067]

[0065] Figure 39 shows a flowchart of the SDFT Ravel operation. Given an NSx structure, a Ravel function or method call can utilize either the parameters with the call and / or the TAR embedded within the NSx to perform the following operations on the data contained therein, where "x" represents any transformation structure. Like the key check / generate transformation, the mobius transformation can be considered very fundamental to this algorithm, and therefore can be implicitly performed on the input data structure if conditions are met 3906. Ravel can only properly perform its core operations on NSstr structures; therefore, if an NSx structure that is not an NSstr is passed, the NSx structure can attempt to convert it to an NSstr structure 3918. Failure to generate a valid NSstr 3924 can trigger an appropriate error code 3978 and abruptly terminate the process 3984. There are at least three different ways in which the data within can be labeled or folded: first, a valid NSstr may contain a TAR that indicates the sequence of transformations to be performed on the data in the NSstr structure; second, the name of a TAR label may be passed as a parameter to a label call, thereby indicating a preferred set of transformations to be performed on the data in the NSstr structure; and third, a customized TAR list may be passed as a parameter in a label call along with its given name, thereby indicating a preferred set of transformations to be performed on the data in the NSstr structure. Preparing the TAR 3912 may comprise expanding other TAR label references and / or ordering them appropriately for traversal modes, which may be either forward or reverse. Figures 41 and 42 show some examples of TAR inversion. Key check transformations can then be effectively performed on the TAR and the NSstr structure. A component of the key check transformation may be deriving 3930 a list of key templates by examining the TAR.Using the TAR, the input key stack (which may be empty or partially populated), and / or the key template, the process may construct a key stack 3936 for proper traversal of the TAR. This may comprise generating missing keys of the correct type, sequencing the keys in the proper order, and / or checking the input key for the proper structure and type. A mismatch between the input key type and the corresponding derived key template may generate an error condition 3942, leading to an appropriate error code 3978 and abruptly terminating the process 3984. The process may then iterate through each transform command in the TAR in the appropriate sequence 3948, performing the specified transformation on the data contained within NSstr 3954. Errors 3960 that may be encountered during transform command execution may cause an appropriate error code 3978 and abruptly terminate the process 3984. When the end of the TAR sequence 3948 is reached, if there are no errors, the Ravel operation may be considered successful 3966, and the process may end successfully 3972.

[0068]

[0066] Figure 40 shows a flowchart of the SDFT unravel operation. Rather than specifying the unravel process in detail, the symmetry of the reversibility of the transformation can be shown by comparing the flowchart in Figure 39 with the flowchart in Figure 40. The only difference between the two flowcharts may be the TAR preparation steps 3912 and 4012. Because every transformation may be analyzed and structured using TOP to perform in a manner that works well in both directions, the unravel process may not need to be significantly different from the Ravel process, except for how the TAR may be presented. The unravel process is implemented as the same code, but with a slight deviation when the reverse flag may be indicated, which may perform the proper reverse ordering of the TAR when encountered. Such a call in Python v3.6 may take the form "obj.ravel(...,reverse=True)". The symmetry may allow the actual implemented code to be much smaller and / or present fewer opportunities for programming errors. A conceptual benefit may be clarity and simplicity of thought when constructing a new TAR for a specific purpose; i.e., a programmer may rely on the appropriate TAR sequence to be fully reversible within its limits and may not need to think through that part of the application. A benefit may be that the programmer's workload for creating a particular set of data transformations may be effectively reduced by at least half, since the programmer may no longer need to create reversal code for such data manipulations. Building complex ciphering and locking mechanisms may require a huge number of data manipulations utilizing multiple cryptographic keys. The transformation organization principle (TOP) method may help achieve a more cohesive and unitized way of approaching such complexity in a discrete, less error-prone manner, which may therefore enable, without limitation, more consistent, reliable, secure, portable, understandable, comprehensive, flexible, extensible, and / or complex code and / or data.

[0069]

[0067] Figure 43 shows a table of transformations mapped to key type templates that may occur or require transformations during TAR processing. Referring again to the discussion regarding key management, one of the main operations of key management may be to analyze a given TAR and generate a corresponding list of key type templates that may detail the type and specifications of each key that may be required in the successful processing of the given TAR. Table 3506 lists at least nine of the key types defined within SDFT. Table 4300 shows the mapping of each transformation operation, which may require the keys and corresponding key types or "keytyp" that it may require through the Lavel / UnLavel process. The key template may have several attributes associated with each key type, such as, but not limited to, key length or "keylen." For brevity and simplified explanation, a 256-bit long symmetric key may be shown as having a key template that can be represented as "symmetric keylen=256" or "symmetric 256," but an actual implementation may utilize available data structure mechanisms in a programming language to store such values ​​in an organized manner. In Python v3.6, a possible structure for key templates may be represented by an array of dictionaries, where each dictionary entry in the array stores a single key template, with each attribute corresponding to the dictionary key and attribute value corresponding to the value associated with that key in the dictionary. Within SDFT, all key templates may be temporary structures and may be subject to repeated regeneration via key check transformations; persistent storage of such key templates may not be necessary. In this way, SDFT can properly analyze keys inserted into the key stack for processing before key type / structure incompatibility causes the cipher transformation to fail outright. A major theme in TOP and SDFT may be the view that obfuscation of data manipulation sequences may not be a reliable component in securing sensitive payloads, but rather may require the strength of the chosen cipher and its computational attributes and / or properties.

[0070]

[0068] Figure 44 shows example TARs and the key templates generated from each. The left column in table 4402 lists TAR example "A". The right column shows the key type templates generated for each morph command that may require an encryption key as an attribute input. In this example, TAR "A" may require two encryption keys in the sequence shown. The left column in table 4404 lists TAR example "B". The right column shows the key type templates generated for each morph command that requires an encryption key as an input. In this example, TAR "B" may require four encryption keys in the sequence shown. This process may be known as key template generation from TAR.

[0071] FIG. 45 shows an example TAR, the key templates generated from each, and the expected list of KISS structures to be put or generated. The KISS list is also called a key stack. Taking two examples from FIG. 44, we can illustrate the next steps in the Ravel / Enravelcord key management aspect. The key stack can be expected or generated in the form of a list of KISS structures corresponding to each key type template, as indicated by 4510. When the TAR "A" process reaches the "scipher salsa20 256" transform command, the process can expect to find an input 256-bit long symmetric key in the key stack, as indicated by KISS A1. When the TAR "A" process reaches the "dign dss 1024 digestlen=512" transform command, the process can expect to find an input 1024-bit dsa key in the key stack, as indicated by KISS A2. It can be read and understood that the KISS list for TAR "B" is done similarly. If such an expected key cannot be found in the key stack, the TAR process may instead expect to find a generated key. This implicit key generation can be beneficial to programmers, since the only requirement for generating an acceptable key of any type for a given keyed transformation is to be able to declare it in TAR. There may be no additional steps required to generate a specific key for a particular cryptographic function. By calling Lavel with an empty key stack, the output NSstr structure may hold a fully compliant key stack with appropriately generated keys that match TAR and are capable of folding the data within. It is highly recommended and advisable that this key stack, constructed from a KISS structure, may then be stored separately in a secure manner from the folded data, and / or it may be further modified in some way, folded again, and secured using TAR with a cryptographic transformation, thus further encrypting it. Repeated encryption and encapsulation of the key stack may be useful when dealing with many cryptographic keys that must be managed and secured.TAR "B" may generate a four-key KISS key stack, which may be convenient for securely storing the entire key stack in a key repository, but a programmer may wish to encrypt the four-key key stack using a single key for convenience. This may be accomplished by creating a new NSstr, inserting the four-key key stack into the data obj field, choosing the appropriate encryption TAR, and performing a Ravel call on the NSstr structure. This series of steps may produce a key stack with a single KISS structure containing the locking key for the folded NSstr structure holding the four-key key stack.

[0072] Figure 46 shows three modes of key stack operation within SDFT TAR processing: generation (gen), input (put), and injection (mixed). Section 4600 shows what may happen when key stack 4602 is empty in the processing of TAR instance "B". The Ravel process takes key type template 4508 for TAR "B" and generates 4606 the appropriate number of randomly generated encryption keys of the same type and in the same order as found in the key type template shown in 4604. Section 4610 shows what may happen when key stack 4612 is put 4616 into the processing of TAR instance "B". The Ravel process may take key type template 4508 for TAR "B" and check it against the given key stack 4612 to validate the number, type, and ordering of keys, which may then enable its use in the processing of TAR "B", as shown in 4614. Section 4620 shows what may happen when key stack 4622 is presented to the processing of TAR instance "B" with only one key, namely KISS B3, or what is also called a partially filled key stack or "missing tooth" scenario. The Ravel process may take the key type template 4508 for TAR "B" and check it against the given key stack 4622 to validate the number, type, and ordering of keys. During the iterative validation of each key type template against the key stack entry, an empty KISS structure may be considered a special type of validation failure and may further be interpreted as an implicit key generate transformation for that key type template. The Ravel process may then inject 4626 a newly generated key of the appropriate type into the empty position of the key stack and continue in key validation iterations. Upon completing this step, the mixed key stack (sometimes called mixing of input and generated keys, missing tooth scenario, or key injection) can be presented and used during the processing of TAR "B", as shown in 4624.

[0073]

[0071] Figure 47 shows a diagram of how a key stack can be generated and used in the life cycle of data and its TAR. The use of SDFT 4700 on data can allow it to be iteratively transformed in a coherent manner according to a variable set of transformations defined by a particular TAR 4702. The TAR can be structured in a way that allows for cryptographic key type analysis and thus generates a key template that details the number and type of keys required by the TAR. The key template can then be referenced in the construction of an input key stack 4704, regardless of whether all, some, or none of the required keys may be present. When a required cryptographic key may be missing, the construction process can generate a new key for use. The TAR, data, and key stack can then be passed to a Ravel call 4706 to perform folding of the structured data according to the TAR. The folded data can then be stored by any means 4708. The keys in the key stack can be stored in a separate, secure location 4710. When the folded data needs to be referenced, the application can retrieve it from its storage location 4712, retrieve the key or key stack from its secure storage 4714, pass the folded data and key stack to the Unravel call 4716, and access the data in its original form 4702 from the Unravel output structure. This may represent one complete cycle of structured data folding with transformation. There may be many other paths for the data structure to be transformed and folded, but essentially some form of this cycle may be necessary to be complete in order to fully retrieve the original data within the SDFT.

[0074] Key and / or key stack storage 4710 may involve folding of the key stack using cryptographic TAR to protect it with fewer keys, only one key, and / or different keys. The folded key stack data may become part of another structure that may itself eventually be folded. Data may be folded iteratively in a cascading fashion to build an internal data structure, where precise, fractional folding may lead to precise, fractional encryption. This ability to direct complex cryptographic data transformations in a precise, organized, and / or systematic way may lead to better and / or simpler designs for the protection of sensitive data using more sophisticated transformation schemes. The simplicity and clarity of the TAR syntax may lead to better understanding of operations being performed on target data by others.

[0075] An important benefit of SDFT may be its systematic treatment of key management within the context of combining various cryptographic operations on a given piece of data, as in 4704 and 4714. The programmer may be somewhat freed from the details of generating each key and manually manipulating its storage and / or ordering during such a process. In the application of a cryptographic function, these details may quickly add up to a large number of small details or attributes that the application (and therefore the programmer) must track, analyze, remember, and / or use. The SDFT method may enable a given application to track, analyze, remember, and / or use fewer individual attributes of the cryptographic function, because it may allow those attributes to be embedded within the context of the data and / or key stack it operated on and produced as output, which may provide a pairwise combination of the folded data with any transformations that may have folded the data. Porting data manipulation instructions from applications to data may enable simpler applications and / or applications with more sophisticated use of cryptographic functions. SDFT may enable a better alternative to expressing Structured Cryptographic Programming (SCP) methods as described in the NUTS section.

[0076] Figure 48 shows a diagram of operations that may be performed on data stored in an NSstr structure. Data 4802 referenced by pointers and / or stored in variables may be encapsulated directly into an NSstr structure 4812 using instantiation methods and / or using method / function calls 4804. The NSstr structure 4810 may then encapsulate a TAR 4814 and, if necessary, its associated attributes 4816. The attributes may comprise a key stack, digest, transformation parameters, and / or temporary variables. This may provide the minimum complete set of information needed to process the NSstr through an SDFT Ravel / Unravel operation to perform a TAR on the data contained within using the attributes that may have been provided 4810. In TOP terminology, this is sometimes referred to as folding the data. The output of the SDFT may be returned as the same NSstr structure 4810, or as an NSx structure such as NSjson. This output may then be stored in some persistent and accessible manner 4820, transmitted to another computing device using inter-process communication (IPC) methods 4840, and / or stored in another internal data structure 4830. The cycle may begin anew at a later point in the application for the stored data 4820 and 4830. For transmitted data 4840, the cycle may be initiated by the receipt of such a data packet 4800.

[0077]

[0075] Figure 49 shows a flow diagram of a method for using SDFT to iteratively fold data. A series of simplified diagrams shows the systematic folding of data using SDFT Ravel Call for N successive data folds. An NSstr structure 4900 containing at least data 4902 and TAR 4904 may be folded by calling Ravel 4906 to generate output data 4908, which may be modified and / or further encapsulated into an NSstr structure 4920 containing at least data 4922 and TAR 4924, which NSstr structure 4920 may be folded by calling Ravel 4926 to generate output data 4928, which may be modified and / or further encapsulated into an NSstr structure 4940 containing at least data 4942 and TAR 4944, which NSstr structure 4940 may be folded by calling Ravel 4946 to generate output data 4948, which may be modified and / or further encapsulated, ...this process may be repeated as necessary 4950. Note that in this complex series of structured data folding, any TAR at any step can be modified separately from the application code by simply modifying the TAR instructions stored in some text file or equivalent. An equivalent programmatic representation without SDFT of such an iterative encapsulation, with its metamorphic sequences and / or parametric distribution possibilities for each step, may be relatively long, error-prone, and / or difficult to understand.

[0078]

[0076] Figure 50 shows a flow diagram of SDFT usage for iteratively unfolding data. A series of simplified diagrams shows the systematic unfolding of data using SDFT unravel calls for N successive data unfoldings. It is the exact reverse sequence of the flow in Figure 49, and therefore can be understood as such. As previously shown in Figures 39 and 40, unravel calls can be equivalent to unravel calls, except for the preparation of the TARs and the state of the data being fed to them. Note that in this complex series of structured data unfoldings, additional reverse TARs may not be necessary to achieve the unfolding. All necessary TARs needed to unravel each folded data can be seen to be embedded within the folded construct. A closer inspection of the NStar structure 3106 shows the "expd" field, which is defined as the "list-expand form of the TAR command." This may be an important feature of reversibility in SDFT: the output of TAR preparation steps 3912 and 4012 may generate a full set of operable transformation commands, devoid of label references and other external references, and may be considered a complete description of the transformations to which the transformed data may have been subjected. This may be considered a static snapshot of the TAR set for the folded data, thereby ensuring that proper unfolding can be performed on the folded data despite any changes to the TAR definition in the external location. It may imply that although the TAR definition file may grow over time with multiple TAR definitions, the memory of the operational TAR definition may be saved by the SDFT process in such a way as to preserve its reversibility despite changes to such external definition files (which may not be a recommended practice). This design may facilitate a systematic approach to better address the time compatibility of stored data.

[0079] FIG. 51 shows a diagram of the SDFT API / library and the various types of TAR definition files it may have access to. TAR definitions may exist in many forms, including, but not limited to, text files, Nut, encrypted files, databases, server processes, and / or in running memory. A TAR may be defined at any time by a programmer as a customized TAR definition in Ravel Call and thus may be a temporary TAR. For TAR definitions that may be stored persistently, diagram 5100 may illustrate these various forms but may not be limited by those shown. Standard TAR 5102 may be a TAR definition that may be provided as a package with the SDFT library installation for an OS / language pairing. Hidden TAR 5104 may be a TAR definition that may be a customized TAR definition that may exist only in locations with restricted access and / or accessed only by explicit permissions. These may be the preferred method of TAR definitions within private networks or custom application installations. The use of hidden TARs can be kept hidden even within Label's output; the expanded form of the TAR is not seen in such folded data; only a reference to it by the TAR label may be present. Because data folded using hidden TARs does not necessarily contain the set of transformations required to unfold it, the responsibility for maintaining hidden TARs may belong to an administrator in such a group. Hidden TARs may appear familiar as an equivalent method of obscuring data manipulation sequences within a program. Local user TARs 5106 may be TAR definitions, which may be customized TAR definitions that can only be accessed under the user's or programmer's account privileges. These may be temporary or development TARs that a programmer may be organizing for later permanent addition to one of the TAR definition storage formats. Remote TARs 5108 may be TAR definitions that can be accessed with or without authorized access from a remote server or storage site.Such a topology may be necessary due to limited local storage or a policy of centralizing key TAR definitions in a centrally managed area. This may also be a way to constantly check to see if the standard TAR definition may be the latest version. The protected TAR 5110 may be a TAR definition that may be in a suitable and accessible location, but may be encrypted for authorized access only. A separate authentication and / or authorization process may need to be successfully traversed to gain access to the protected TAR. Another form of protected TAR may be stored within a Nut container that may require the appropriate key(s) to gain access to the Nut container. The embedded folded TAR 5112 may be an expanded TAR definition stored with folded data from a Ravelcall.

[0080]

[0078] Figure 52 shows an example Python script for performing manual data folding. Figure 53 shows a TAR-defined SDFT example and its usage in a Python script. Figures 52 and 53 together can show an example of how SDFT differs from a simpler programmatic approach using Python v3.6. These example Python scripts can show the significant differences in the basic calling sequence for each task at hand using each methodology. We can start 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 on lines 02-06. Typically, these can be entered as comment lines in the program itself for readability. Section 5250 shows the actual Python code for performing the tasks, and section 5260 shows the reverse processing of the tasks to recover the original data 5210.

[0081] Using SDFT, dataset 5310 is the same as 5210. Section 5320 represents task 5220 as a TAR definition labeled "test_a70". Section 5350 labels the data and writes the folded data to a file. Section 5360 reads the folded data from the file and unlabels it.

[0082] There are 18 lines of Python code in Figure 52 and only 8 lines of code in Figure 53. It may be apparent that changes in the type and number of data transformations may affect both section 5250 and section 5260. The method in Figure 52 requires the programmer to maintain several variables, the sequence of tasks, and / or the proper calling of each function or method. The reverse process in 5260 requires the programmer to ensure that all operations are called in the correct reverse order and that parameters are supplied in the correct manner for each function or method call. A change to a task in 5220 may result in programming changes in sections 5250 and 5260. An additional task in 5220 may result in additional program lines in sections 5250 and 5260. More temporary variables may be created and used as needed for these additions to or changes to tasks.

[0083] In the SDFT method in Figure 53, changes to the task can be reflected directly in TAR 5320. Therefore, additional transformational modifications can only change the length of this section. Ravel calling line 10 and unravel calling line 14 remain unchanged. The reversal process in 5360 of TAR 5320 need not be specified beyond the original TAR definition in 5320. In effect, sections 5350 and 5360 can remain the same for the chosen TAR definition except for line 10, where the TAR definition label is specified in the Ravel method call.

[0084]

[0082] With regard to readability and comprehension of the tasks being performed, a reader may prefer TAR 5320 over the actual program code in sections 5250 and 5260. The tasks specified in 5220 may typically be expressed as comments in the Python code, rather than as code. Changes to the program code in sections 5250 and 5260 must be manually coordinated with the comments by the programmer; otherwise, confusion may result if another programmer attempts to understand the code using inaccurate comments, and vice versa. TAR 5320 may be considered self-describing in a clear and compact manner.

[0085] The data stored by lines 15-16 in section 5250 has no embedded metadata describing how it may have been transformed. The transformation method is hardwired in sections 5250 and 5260 as actual code. Any such data written in this manner may be entirely dependent on the presence of the same or similar code for its proper retrieval and restoration. These code sections, or their equivalents, must be maintained permanently so that the data they transformed is permanently recoverable. It may be the equivalent of a hidden TAR method.

[0086] The data stored by line 11 in section 5350 may include embedded expanded TAR definitions that may transform the folded data. The transformation method may be paired with the folded data, thereby making it transportable. The recoverability of the folded data may be considered independent of the code 5350 and 5360 that created it. Code that can properly process the embedded TAR definitions in the folded data may recover the original data. This type of functionality may allow for better time compatibility for changing the transformation sequence over time, so that older folded data may self-describe, and therefore self-define, how it can be restored.

[0087] Figure 54 shows a block diagram of dynamic TAR switching within a single communication session. In the TOP approach, higher-level communication protocols can be viewed as the passing of transformed data from one computing process to another. Because transformation can enable many of the most frequently used cryptographic functions, it can be used to create secure messages for IPC. In theory, each message can be transformed and folded using a different TAR. Each different TAR definition can be considered its own protocol by modern standards for protocol definition. Using SDFT, TAR can be dynamically switched for each folded message between two applications as shown in Figure 54. A mixture of TAR sources shown and described in Figure 51 can be used as long as each application has access to their TAR definition source. A rich set of embedded and folded metadata, such as, but not limited to, a KISS structure as a keyhole that specifies the exact key identifier for each key required in the embedded cryptographic transformation, can enable SDFT-based communication protocols to provide security at a more sophisticated and potentially more secure level.

[0088] TOP analysis and methods may result in a framework called SDFT, which may enable stored data to contain its own portable instruction set. This framework may define data folds and provide a methodology and / or embodiment for folding data using a conceptually and logically consistent, reversible transformation processing method expressible as a transformation audit record (TAR), which may be embedded in an organized manner within the stored data. The resulting folded data may then be modified in some way and then folded repeatedly as needed to achieve a desired application or data format result. Aside from describing the TAR as a programming language, it represents a set of cooperating data operations in a concise format that may allow for infinite variations in transformation sequences and / or infinite variations in transformation attributes within a given TAR and / or attribute. SDFT may enable variable scoping for data sets, similar to the way programming languages ​​isolate local variables using scoping concepts and techniques. Through TOP, protocol distribution can be observed in higher conceptual constructs, leading to data that can be self-describing and, in some cases, accessible and readable by a wide variety of applications, which can access its methodology through available SDFT libraries adapted to their programming environments. Furthermore, these properties that can be brought to the folded data can enable dynamic switching of protocols within a single communication session or a single stored data object. The TOP approach can be utilized as a fundamental building block for the NUTS ecosystem and in the construction of Nut. NUTS could be implemented entirely without relying on SDFT, but this may be unwise.

[0089] Nut ID The NUTS design may enable data identifiability regardless of location. This may require a universally unique ID (UUID), which may not be achievable in a guaranteed manner without some form of centralization, and therefore may settle on the concept of a virtually unique ID with sufficient length and entropy properties to provide a low probability of ID collision. Figure 55 shows a flowchart 5500 of an example process for generating a Nut ID. Here, a local device 5502 may be running an application that may invoke a function to generate a virtually unique ID from pieces of data, such as, but not limited to, user attributes 5504, environment 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 password hash. Environmental attributes 5506 may include data items such as, but are not limited to, MAC addresses, IP addresses, device information, system time, OS information, directory paths and / or files, atomic clock synchronized time values, GPS synchronized time values, declared environment variables, thread IDs, CPU runtimes, IMEI numbers, phone numbers, application names, and / or process IDs. Random attributes 5508 may include data items such as, but are not limited to, session counters, UUIDs, clock cycle counts, randomly generated numbers, mouse movements, keyboard activity, file system state, partial or complete screen area hashes, process uptime, OS uptime, and / or session duration. These pieces of data may be collected and stored in an ID structure 5510, which may then be serialized using JSON or an alternative marshaling technique.The resulting binary string may then be hashed 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 may produce de facto uniqueness with a suggested minimum length of 512 bits to reduce the probability of ID collisions 5520. The binary hash may be encoded into a base64 (or alternative encoding scheme) text string that may produce a text string approximately 86 characters long for portability and readability 5514. The encoding scheme may provide a method that may produce a printable, human-readable form and may be accepted as a text string by multiple programming languages ​​and software systems. Depending on the modality in which the function is being called, the resulting encoded hash string may be checked for duplicates against an accessible Nut ID cache 5516. If there may be an ID value collision, the process may be repeated with a new random attribute 5508 until a non-colliding ID can be generated, and collisions may be expected to be a rare occurrence. The output string of this logical operation is sometimes called Nut ID5518.

[0090] This process can be called locally within a running program or implemented within a server application residing locally or remotely that services client application requests for new Nut IDs. A possible benefit of a server-model implementation may be its ability to access a larger cache of existing Nut IDs to check against, generating Nut IDs with a lower probability of collision. Nut ID duplication checks are not required, as the hash length and properly grouped data components in the ID structure 5510 may provide sufficient entropy. There may be a general concept of compartmentalization across some or all digital infrastructures, such as the Internet with IPv4 / IPv6 addresses, domains, directory hierarchies, and access control groups. Similarly, while a Nut ID may be effectively unique, it may be used within the context of compartments established by external systems or relationships; therefore, the likelihood of a collision may be much smaller than the mathematical probability provided by transposition, given the length of the Nut ID's bits. If a different length may be desired, this may be achieved by one skilled in the art by substituting an alternative hash algorithm for the SHA-512 hash in a modular parameterized manner.

[0091] Given a process by which a virtually unique ID can be generated in the form of a Nut ID, what can be identified by a Nut ID? In NUTS terminology, this can be known as Nut ID stamping. There can be at least two structures within NUTS that can be consistently stamped with a Nut ID: lock nodes and Nuts. A Nut ID assigned to a lock node may be referred to as a lock ID. A Nut ID assigned to a Nut may be referred to as a Nut ID. Lock nodes can be the internal building blocks of Nut. A lock node can be a self-contained, standalone locking mechanism that can protect its payload, known as a bag. A Nut can be a data structure composed of one or more lock nodes. Thus, a Nut can hold one or more parcels of data, in whole or in part. Nuts can be used throughout the NUTS environment to virtually uniquely identify some or all related software, data, and / or hardware represented in binary format. A consequence of Nut ID stamping implies that every Nut can be uniquely identified, and that every data parcel stored within a Nut can be uniquely identified by its Nut ID, regardless of where the Nut may be physically located.

[0092]

[0090] Figure 56 shows a simplified diagram of a Nut data structure. This diagram may highlight the usage and relative placement of lock IDs and Nut IDs within the Nut data structure. Specific lock IDs 5614-5622 may be assigned in this Nut, and they may be different values. Lock nodes 5604-5612 may be identified by lock IDs 5614-5622, respectively. In a general Nut data structure formation, such as this example, Nut 5602 may be a group of lock nodes organized into a graph, such as a data structure called a lock graph. A specific Nut 5602 may be identified by its Nut ID 5634, which may be stored in bag 5626 of lock node 5606; the Nut ID may be considered the payload of this lock node, which may differ from the payload of Nuts, which may be stored in one or more of the other lock node bags. Every lock node 5604-5612 structure may include a payload area called a bag 5624-5632. This shows the relationship between a Nut and its Nut ID, where these items stored in a general Nut container can be found.

[0093]

[0091] Figure 57 shows an example of the relationship between Nut IDs, path names, and / or payload data. There may be several lock nodes in Nut that can be used to store Nut metadata, metadata about Nut payloads, and / or Nut payloads. Metadata portions may be stored in bags in various lock nodes in Nut. 5702 shows a scenario in which there may be two different Nut payloads, D1 and D2, each stored in a different Nut, identified by Nut ID A3 and Nut ID B1, respectively. For illustrative purposes, a two-character Nut ID is used, but it has been previously specified that a Nut ID may be a base64 encoding of a 512-bit hash, which may produce a text string up to 86 characters long. Nut A3 and Nut 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 Nut with different filenames located in the same directory. This may not be an exhaustive listing of permutations of some or all of these attributes, but it may illustrate the flexibility of persistently having metadata items associated with each payload, such as the Nut ID.

[0094]

[0092] Data embedded within a Nut file, which can be identified by its associated Nut ID, can result in a novel feature of this methodology: the ability to automatically create dynamic filenames based on parameterization rules in the metadata. The filename can represent a typical identifying string for the file as well as an organized summary of its other attributes, such as, but not limited to, the modification date and time and / or the number of writes for that day. This can provide a more accurate and convenient way to identify a file and its state over time without having to examine normally hidden attributes, such as having to view file properties in a directory browsing application. It can also allow for the embedding of file and data attributes into the container that holds the file, rather than relying on the file system's attribute-capture capabilities, which can vary from file system to file system. An example: A user can create a Nut with Nut ID #234 that can store a text document; the text document can always be identified by Nut ID #234, but the user can set up a dynamic file name with the base name + date of last modification + write count for that day, such as "diary_20151115_1.txt." When saving it to disk later that same day after some modifications, the file name might indicate "diary_20151115_2.txt," and the old file name might no longer exist in the directory. This methodology can automatically create new file names that can indicate some state information for the stored data. The property of the Nut ID, which can be virtually unique and separate from the path name + file name specification, can allow such a feature to be implemented without any external references. One benefit of such a feature could be the often-used method of copying and archiving previous states of a working document with a date stamp. An author can find a directory full of files for each day that the author may have worked on their document.Using the dynamic filename method, an author may have only one Nut file in their directory with the datestamp of the last time the author wrote to it. The history (state) saving aspect of the manual method can be preserved within Nut itself using the Nut history feature presented in a later section. This concept of the Nut ID being the main identification of content can later be used by the NUT server to perform replication and synchronization operations across distributed Nuts.

[0095] Lock graph and lock nodes

[0093] NUTS technology may address data storage, protection, and access control in a layered, integrated, modular, and / or iterative manner, which may be defined as Structured Cryptographic Programming (SCP). The internal overall design of Nut may be described and defined, and then each defined structure may be subsequently described in detail. Several features may be described in a layered manner, and then an integration explanation may be given to show how individual features may work together. SDFT may be utilized throughout the NUTS design to improve the organization of complex cryptographic structures and the systematic embedding of attributes associated with each folded data structure. Various embodiments may show how SDFT enables SCP designs to be implemented relatively easily compared to equivalent manual methods.

[0096]

[0094] There may be four different methodologies by which access to Nut may be controlled: keyhole, variable lock, hierarchical access control (SAC), and / or Nut access control (NAC). Some or all of these methodologies may be layered together and / or integrated, partially or wholly, in novel ways within Nut, which may give the full functionality of a reference monitoring system in an internalized and / or agnostic manner. These four layers may be embodied in complex data structures called lock nodes, which may be designed to be modular, isolated, and / or linkable.

[0097] A keyhole may be a data structure that can accept any number of cipher keys, each of which may have an associated encrypted key map. The embodiment is not limited to the cipher key types it currently recognizes and can accept: passphrases, symmetric keys, and asymmetric key pairs. Any simple or complex method, or any process that can designate a sequence of bits as a secret key, may be integrated into a keyhole. The encrypted key map may contain several sets of keys, one set for each layer of access control within Nut: variable lock, SAC, and / or NAC.

[0098]

[0096] Variable locks may provide different types of locking mechanisms in a normalized structure that may protect data in lock nodes. These variable locks may include ORLOCK, MATLOCK, SSLOCK, XORLOCK, and HASHLOCK. This disclosure is not limited to these predefined lock types and may be expanded or contracted to accommodate any appropriate locking scheme that may be normalized into its structure.

[0099]

[0097] Hierarchical access control can regulate ingress access to individual lock nodes in a lock graph. This feature can result in a property in Nut called Gradient Opacity, which can be an ability that allows Nut to view various levels of metadata given the appropriate access attributes.

[0100]

[0098] NUT Access Control or NAC may employ Role-Based Cryptographic Access Control (RBCAC) techniques to provide fine-grained control over modifications and authentication within Nut.

[0101]

[0099] Structured cryptography programming can be the design of data structures that can enable easy and flexible interaction between different methodologies to represent various access models. Security mechanisms can be fully embodied in the enciphered data and their associated ciphers, and therefore there can be no external application dependencies on Nut's access control, such as reference monitors. In some embodiments, locking nodes can be used individually to protect field-level data in any part of the payload. The interior of a Nut container can potentially utilize multiple cipher keys to embody a particular security model.

[0102]

[0100] Nut may be a directed graph data structure called a lock graph, composed of nodes called lock nodes. Each lock node may be identified by a lock ID, which may be created by the same function for generating Nut IDs; therefore, they may both have the same properties. Lock nodes may be stored in a hashed array that may be referenced by their lock ID. Each lock node may have pointers linking to other lock IDs or a null pointer. A lock graph may be derived from the hashed array of lock nodes using well-established programmatic graph extraction and traversal techniques. A lock node that has no other lock nodes pointing to it may be a keyhole lock node (entry or external lock node). A lock node that may have a null pointer may be a terminal lock node in the lock graph and may store the payload of Nut or a reference to the payload. A lock node may have multiple lock nodes linking to it. Under most circumstances, a lock node does not link to previous lock nodes in the lock graph or itself. Circular link references may be unusual, but can be accommodated through customized programming for custom Nuts if such a structure is warranted.

[0103]

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

[0104]

[0102] Note that due to the data-centric nature of this disclosure, most flowchart-type diagrams may be a mixture of traditional flowchart elements mixed with data components, sometimes called data flow diagrams or data flowcharts. Also, the intertwined nature of the lock node design layer may make it difficult to expose the logical operations of its components in a completely linear manner without making forward reference statements, and therefore some rereading may be required on the part of the reader.

[0105] FIG. 58 is an embodiment of a Nut or lock graph 5800 with two logical sections, Nut lock 5802 and Nut part 5804, that employ multiple objective aspects of a modular lock node. The Nut lock 5802 section of the lock graph may allow cryptographically linked complex locks to be constructed for a given Nut using one or more lock nodes. Currently, there are five types of lock nodes defined in this disclosure that correspond to the five types of variable locks mentioned: ORLOCK, MATLOCK, SSLOCK, XORLOCK, and HASHLOCK. Each lock node type may refer to a type of variable lock internal locking mechanism that may be utilized at the heart of a particular lock node to protect encryption keys to storage areas and other lock node metadata and parameters. The lock metamorphosis disclosed in FIG. 30 may be one embodiment of a variable lock and may be used in constructing a lock node. Successfully unlocking and traversing the Nut lock 5802 portion of the lock graph may lead to the Nut part 5804 section of the lock graph 5800. There may be several lock nodes comprising the Nut part 5804: hair 5820, tick 5822, seal 5824, vita 5826, bale 5828, and / or tale 5830. The Nut part 5804 may contain a Nut payload 5830 and / or metadata 5820-5828. The number and type of Nut parts for a lock graph may vary depending on the type of data the Nut may be storing and / or the design of the Nut for certain desired behaviors and properties. In this example, unlocking 5816 the keyhole lock node 5806 may result in an appropriate cipher key that can be inserted into the primary keyhole of the linked 5818 lock node 5820. Unlocking a lock node 5820 may result in an appropriate cipher key that can be inserted into the primary keyway of the linked lock node 5822.Unlocking lock node 5822 may result in an appropriate cipher key that can be inserted into the primary keyhole of linked lock node 5824. Unlocking lock node 5824 may result in an appropriate cipher key that can be inserted into the primary keyhole of linked lock node 5826. Unlocking lock node 5826 may result in an appropriate cipher key that can be inserted into the primary keyhole of linked lock node 5828. Unlocking lock node 5828 may result in an appropriate cipher key that can be inserted into the primary keyhole of linked lock node 5830. Lock node 5830 may link to a null pointer, and thus it may be the terminal lock node or innermost layer of this lock graph or Nut. Unlocking a lock node may comprise unfolding a folded data structure representing the lock node using the SDFT method. Each lock node may contain multiple folded data structures, where the action of unlocking a lock node may be equivalent to unfolding the applicable data structures.

[0106] FIG. 59 shows a simplified Nut schematic 5900 of a lock graph embodiment with logical sections: Nut lock 5902 and Nut part 5904. This example considers Nut lock 5902 with four lock nodes 5908, 5910, 5912, and 5916. Lock nodes 5908-5912 may be keyhole lock nodes 5906 of this Nut, since some or all of them may be outbound nodes and may accept external cipher keys, called primary keys. A user may have a primary key associated with one or more of these keyhole lock nodes. The Nut ID of a Nut that stores a primary key as its payload may serve as a key ID that can be automatically matched with the identifier marking the keyhole to which it belongs in keyhole lock node 5906. A passphrase key may be identified by a key ID or a text string that may or may not carry a question as its identifier. Complex multi-level passphrases can be constructed using the appropriate keyhole identifier and a cleartext Nut metadata portion with the appropriate question list. Linkages between lock nodes, such as 5914 and 5918, can be opened in a similar manner, where a successfully unlocked lock node can generate output key(s) with the identifier. In this particular example, unlocking any one of the keyhole lock nodes can reveal the appropriate cipher key that can be inserted into the keyhole of the linked 5914, lock node 5916. From this point on, unlocking a node comprising Nut part 5904 can proceed similarly to the process described for Nut part 5804. This Nut lock 5902 construction can convey the building-block nature of lock nodes and their combinatorial flexibility by indicating that there can be three different paths to unlocking the payload of Nut 5900, with each path requiring different conditions to be met for the unlocking process to proceed.

[0107] In Figure 60, lock node 6000 may be a data structure comprising the following sections: parameters 6002, inputs 6006, key map 6008, variable lock 6012, derived keys 6016, key set 6020, bag 6024, and / or outputs 6026. The parameters section 6002 may hold the lock node's metadata, lock ID 6030, encrypted strings of key map 6010, derived keys 6014, key set 6018, bag 6022, and the dig of said encrypted strings created by the appropriate access role key for the lock node (forward references may be explained in the description for element 8334 of Figure 83). The design principle may be similar to the flow through a lock graph, with unlocking each section leading to a key that may help open the next section, but in that case each component within a lock node may provide a specific function. The dign associated with an encrypted string can be used by a reader (access role) to authenticate a particular section prior to a decryption attempt. A dign can be created by a writer (access role) of a particular section using the section's encrypted string when there may be some modifications to be saved, or to indicate that the holder of the appropriate writer's access key generated the dign. Furthermore, each of the above encrypted strings can be implemented through the use of SDFT methods to fold data structures using TAR containing cryptographic transformations. Given the several and varied encrypted strings described in this section, the SDFT method can significantly reduce the burden of cryptographically managing related attributes by the programmer when coding.

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

[0109] FIG. 62 shows a single encryption key 6202, which may have an associated key ID, key type, and key attributes 6206, and which may also be designated as a primary key. The key ID may be any identifying string. The primary key and other keys described in this disclosure may each be represented internally by the KISS data structure shown in FIG. 34, operating in key mode (ima="key"), with the key->value field populated with the key and other matching attribute fields filled in as necessary. The primary keyhole 6204 may accept a primary key 6202, which may decrypt the encrypted key map 6208. The decrypted key map 6240 may be a structure that may comprise three sections: a main key 6210, a hierarchical key 6212, and an access key set (AKS) 6214. The main key structure 6210 may contain a symmetric key or tine, sometimes referred to as the main key, an expiration date / time for the primary key 6202, a countdown timer for the primary key, and / or action instructions upon expiration of the primary key. The symmetric key or tine may be used by the variable lock of the lock node. For a keyhole lock node, the key map structure may additionally hold a hierarchical key 6212 and / or an AKS 6214. The hierarchical key 6212 may hold a set of keys to be inserted into a strata lock node of the lock graph, i.e., a lock node that can be identified by its hierarchical designation. The AKS 6214 may hold a set of keys to be inserted into the access keyhole 6104 for the keyhole lock node. The encrypted key map 6208 may be an SDFT folded data structure that may contain the main key 6210, hierarchical key 6212, and access key set (AKS) 6214 structures.

[0110]

[0108] Figure 63 shows a flowchart of the key insertion process for any lock node and for any cipher key. Step 6304 may be a search through some or all listed lock nodes in Nut for a given cipher key and its associated key ID. Once the cipher key is inserted into the appropriate keyhole 6304, step 6306 may attempt to decrypt and unfold the encrypted key map for that key. Decrypting and unfolding the encrypted key map may, in such an embodiment, be equivalent to unraveling the SDFT's folded encrypted key map.

[0111] Upon successfully unlocking and unfolding the encrypted key map 6208 for a keyhole lock node, 1) a hierarchical key may be inserted into each lock node's primary keyhole that matches the hierarchical designation found in each lock node's parameters section, and 2) the access attribute keyset unlocking key (AAKSUK) of the access keyset (AKS) may be inserted into the lock node's access keyhole. This primary key unlocking (or unraveling) may be done because many primary keys may have been inserted into a lock node, after which one may have a set of decrypted (or unfolded) key maps that collectively constitute the set of main keys for possible use by the lock node's variable locks.

[0112]

[0110] Figure 64 shows an example in which three primary keys 6402-6406 may be inserted into a primary keyhole 6400. Each key (→) may be matched with its identifying key ID and inserted into a slot in a hashed array or KISS keyhole structure. The key type may indicate a key type, such as, but not limited to, symmetric, asymmetric public, asymmetric private, and passphrase. In some embodiments of Nut, users may specify any type of key that may have a corresponding cipher methodology appropriately modularized for NUTS integration. These key cipher methodologies may include fingerprint scan, iris scan, palm print, voice print, handwriting pattern, facial recognition, DNA signature, physical key device, hardware-secured key, software / hardware-based zero-knowledge protocol key, and / or NFC key. If an asymmetric private key, such as may be used in RSA-2048, is inserted, it may represent both a public and private portion; the public portion may be extracted from the private portion and used to encrypt the encrypted key map of the primary key; therefore, the decryption operation may require the private asymmetric key to be presented. As clearly shown for one key (→) inserted into one keyhole 6402, its encrypted key map 6412 may be decrypted using a key type cipher methodology to reveal key map structure 6430, which may contain three distinct sets of keys 6432, 6434, and 6436. This decryption step may be performed for each key 6404 and 6406 to generate the respective corresponding key map sets 6440 and 6450. Each decryption step may also be equivalent to unraveling the SDFT folded structure in such an embodiment. In a passphrase key type, the key may be a passphrase, and the key attributes may indicate the passphrase derivation function to use and appropriate parameters for that function, including the number of iterations to perform to generate a symmetric key that can decrypt the encrypted key map. In embodiments utilizing SDFT, such passphrase attributes may also be matched with the corresponding TAR to access the appropriate derive transformation with matching attributes.Looking at the example in perspective with the lock node diagram 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.

[0113] Variable Lock The next part of the lock node may be a variable lock, as shown in element 6012 of FIG. 60. The variable lock may be a locking mechanism that can help protect the contents of the lock node stored in bag 6024. The variable lock may allow the lock node to utilize any one of several different types of cryptographic locking techniques well known to those skilled in the art. For example, these different lock types may comprise ORLOCK, MATLOCK, XORLOCK, HASHLOCK, and / or SSLOCK. This may be achieved by normalizing the inputs and / or outputs of each locking method to conform to a common dataflow model, so that each locking method can be seamlessly substituted for one another. Similarly, the primary keyhole structure and key map structure may act as data normalizers for the number and key types of keys flowing into the variable lock. The lock node may be imprinted with a set of parameters 6002 that indicate what type of variable lock it may be implementing 6030. Once this value is set, the lock node will rarely change this setting, but it may be possible for the lock node to be rekeyed and / or reset by the RAT (owner of the Nut). The SDFT library describes one embodiment of a variable lock, listed in Figure 30, and its accompanying specification, which may be used in this section for convenience, although the use of the lock mutation is not a necessary requirement to fulfill this function of the lock node.

[0114] Continuing the traversal of the lock nodes in FIG. 64, which ended with the three main keys 6432, 6442, and 6452, we can consider how its variable lock may operate in FIG. 65. The variable lock 6502 may protect the derived key (DK) 6506 by encrypting the DK 6506 as an encrypted derived key (eDK) 6504. Some or all of the main keys 6432, 6442, and 6452 may be symmetric or tine key types and may fit within the variable lock 6502. Depending on the variable lock type, which may be specified in the lock node parameter sections 6002 and 6030, the appropriate variable lock function may be called to perform a cipher / decipher operation on the DK or eDK. Figure 65 shows the decryption operation of eDK 6504 to DK 6506 by variable lock 6502, which may use main keys 6432, 6442, and 6452. Figure 66 shows the encryption operation of DK 6506 to eDK 6504 by variable lock 6502, which may use main keys 6432, 6442, and 6452. In an embodiment using SDFT, the DK may be data protected by TAR employing lock transformation with data folding, and thus unfolding such a structure will expose the derived keys contained within.

[0115]

[0113] The table in Figure 67 summarizes some of the key properties that variable locking describes. As the term variable locking may imply, any locking technique that can be normalized to this model may be added as an additional variable lock type. Alternatively, any locking technique may be excluded. The table in Figure 30 may correspond to the table in Figure 67 and shows how SDFT may embody a variable locking design in its lock transformation.

[0116] The lock node metadata section 6030 may be a common component that may be involved in some or all variable locks. There may be various digns (digital signatures) of the lock node sections, such as 6040-6048 (see forward), that may have been created by appropriate access role keys (ARKs). Some of these digns may be created by the Nut owner, who may be someone who holds the Root Access Tier (RAT) access role keys, particularly the RAT private key, through their AKS. Anyone with a valid primary key may have a RAT public key, which may enable anyone to authenticate various RAT digns across lock nodes to ensure that the Nut components have not been compromised. In the figures, sometimes the RAT public key may be referred to as the RAT reader key, and the private key may be referred to as the RAT writer key. Further discussion regarding the Nut access control layer later in this specification may discuss, specify, and / or clarify these features in more depth. As mentioned earlier in the section on SDFT and TAR, the dign of encrypted data can be part of the TAR specification of a folded data structure that can embed the protected data, its dign, and the TAR that created it. It clearly implies that the systematic use of SDFT within a lock node can be advantageous for programmer workload.

[0117]

[0115] The ORLOCK in FIG. 68, also known as an OR lock, is a variable lock that can accept any number of symmetric cipher keys, called the main key 6808, and can systematically attempt to decrypt 6814 the eDK 6806 using a symmetric encryption cipher, such as AES-256 or an alternate cipher. The parameters section 6002 can indicate the cipher method to be used for this logical operation, or the preferred TAR when using the SDFT method. The first successful decryption of the eDK can generate a derived key (DK) 6816, resulting in the successful unlocking of the ORLOCK. Prior to a decryption attempt on the variable lock, the eDK's dign 6804 can be authenticated using the eDK 6806 and the RAT reader key 6802. If authentication is successful 6810, the decryption process can continue; otherwise, an error 6830 can be raised and the attempt can be paused. The main key 6808 may be an equivalent key, such as, but not limited to, a symmetric 256-bit key. In this configuration, the essence of the OR lock may be isolated and normalized into a keyhole and variable lock structure to make it modular. In the collapsed structure, the authentication step may be part of the TAR and may be implicitly attempted by the act of unraveling.

[0118]

[0116] Figure 69 shows the encryption operation of ORLOCK from the perspective of a RAT writer or Nut owner. It may take a main key 6902 and perform an encryption operation 6920 on the DK 6906 using an appropriate cipher to generate an eDK 6908. Then, using its RAT writer key 6904, the eDK 6908, and an appropriate digning algorithm 6922, it may create an eDK dign 6910 that may be stored in the lock node parameters section 6044. The SDFT method may collapse many of these attributes into a single data object to be stored in the parameters section in a compact manner along with the eDK. The encryption process for non-RAT members of the locked node may be simple: they may either erase the locked node's application memory contents, since they may not create authentic dign for anything, implying that they may successfully modify its contents and not dign it; or they may use an already decrypted DK 6908, which encrypts the locked node's relevant contents but leaves eDK 6910 untouched, since nothing that may be relevant to eDK dign may be changed. This may indicate that only a RAT writer may be able to replace the value of DK 6906 or re-key it. When using the SDFT method, non-RAT members of the locked node may choose to leave the original folded data containing the eDK in the parameters section and erase the unfolded structure holding the DK.

[0119] MATLOCK in FIG. 70, also known as a matroyshka lock, cascade lock, or AND lock, is a variable lock that can accept a fixed number of symmetric cipher keys, called main keys 7006, and can sequentially decrypt an eDK 7022 using each main key 7008 in ascending order using an appropriate cryptographic cipher 7014, such as AES-256 or an alternate cipher. The parameters section can indicate the exact cipher to use for this logical operation, as well as the number of main keys that may be required, or the preferred TAR when using an SDFT method. Successful ordered iterative decryption of eDK 7022 can produce DK 7024, resulting in the successful unlocking of MATLOCK. Prior to a decryption attempt on the variable lock, the eDK's dign 7004 can be authenticated using eDK 7022 and the RAT reader key 7002. If authentication is successful 7010, the decryption process may continue; otherwise, an error 7030 may be raised and the attempt may be paused. In this configuration, the essence of the matroyshka lock may be isolated and normalized into a keyhole and variable lock structure to make it modular. In the collapsed structure, the authentication step may be part of the TAR or may be implicitly attempted by the act of unraveling.

[0120] Figure 71 shows the encryption operation of MATLOCK from the perspective of a RAT writer or Nut owner. It may take some or all of the presented main keys 7102 and sort them in descending order 7110. It may then iteratively perform encryption operations 7112 on the DK 7120 using an appropriate cipher to generate an eDK 7122. Then, using its RAT writer key 7124, the eDK 7122, and an appropriate digning algorithm 7118, it may create an eDK dign 7126 that may be stored in the lock node parameters section 6044. The SDFT method may collapse many of these attributes into a single data object to be stored in the parameters section in a compact manner along with the eDK. The encryption process for non-RAT members of the locked node may be simple: they may either erase the locked node's application memory contents, since they may not create authentic dign for anything, implying that they may successfully modify its contents and not dign it; or they may use an already decrypted DK7120, which encrypts the locked node's relevant contents but leaves eDK7126 untouched, since nothing that may be related to eDK dign may be changed. This may indicate that only a RAT writer may be able to replace the value of DK7120 or re-key it. When using the SDFT method, non-RAT members of the locked node may choose to leave the original folded data containing the eDK in the parameters section and erase the unfolded structure holding the DK.

[0121]

[0119] The XORLOCK in Figure 72, also known as an XOR lock, is a variable lock that can accept a fixed number (>1) of symmetric cipher keys, called main keys 7206, and can generate a calculated key by successively applying an XOR operation 7224 to each main key 7208 in ascending order 7222. It can then attempt to decrypt 7228 the eDK 7210 using the calculated key from 7224 with an appropriate cipher, such as AES-256 or an alternate cipher. The parameters section 6030 can indicate the exact cipher to use for this logical operation, as well as the number of main keys required, which can be two or more keys, or the preferred TAR when using an SDFT method. Successful decryption of the eDK 7210 can produce the DK 7212, resulting in the successful unlocking of the XORLOCK. Prior to a decryption attempt on the variable lock, the eDK's dign 7204 may be authenticated using the eDK 7210 and the RAT leader key 7202. If authentication is successful 7220, the decryption process may continue; otherwise, an error 7230 may be raised and the attempt may be paused. In this configuration, the essence of the XOR lock may be isolated and normalized to the keyhole and variable lock structure to make it modular. In the collapsed structure, the authentication step may be part of the TAR and may be attempted implicitly by the act of unraveling.

[0122] Figure 73 shows the XORLOCK encryption operation from the perspective of a RAT writer or Nut owner. It may take some or all of the main keys 7302 presented to it and sort them in ascending order 7320. It may then iteratively perform XOR operations 7322 on the main keys 7304 to generate calculated keys, which may be used to encrypt 7326 the DK 7306 to generate an eDK 7308. The RAT writer key 7310, the eDK 7308, and an appropriate dign algorithm 7328 may be used to create the eDK's dign 7312, which may be stored in the lock node parameters section 6044. The SDFT method may collapse many of these attributes into a single data object to be stored in the parameters section in a compact manner along with the eDK. The encryption process for non-RAT members of the locked node may be simple: they may either erase the locked node's application memory contents, since they may not create authentic dign for anything, implying that they may not successfully modify its contents; or they may use an already decrypted DK7306, which encrypts the locked node's relevant contents but leaves the eDK7312 untouched, since nothing related to the eDK dign may be changed. This may indicate that only the RAT writer may be able to re-key the DK7306. When using the SDFT method, non-RAT members of the locked node may choose to leave the original folded data containing the eDK in the parameters section and erase the unfolded structure holding the DK.

[0123]

[0121] The HASHLOCK in FIG. 74, also known as a hash lock, is a variable lock that may accept a fixed number of symmetric cipher keys, called main keys 7406, and may create a calculated key by concatenating 7424 some or all of the main keys presented in a particular order 7422. It may then apply a hashing algorithm 7426 to the string. It may then attempt to decrypt 7428 the eDK 7410 using the calculated key with an appropriate cryptographic cipher, such as AES-256 or an alternative cipher. The parameters section 6030 may indicate the exact cipher and hash to use for these logical operations, the number of main keys requested, and / or the sort order of the main keys, or the preferred TAR when using the SDFT method. Successful decryption of the eDK 7410 may produce the DK 7412, resulting in the successful unlocking of the HASHLOCK. Prior to a decryption attempt on the variable lock, the eDK's dign 7404 may be authenticated using the eDK 7410 and the RAT leader key 7402. If authentication is successful 7420, the decryption process may continue; otherwise, an error 7430 may be raised and the attempt may be paused. In this configuration, the essence of the hashing lock may be isolated and normalized to the keyhole and variable lock structure to make it modular. In the collapsed structure, the authentication step may be part of the TAR and may be attempted implicitly by the act of unraveling.

[0124] Figure 75 shows the encryption operation of HASHLOCK from the perspective of a RAT writer or Nut owner. It may take the presented main keys 7502, sort them in ascending order 7520, then concatenate them 7522, and then perform a hash operation 7524 on it to generate a calculated key. This calculated key may be used to encrypt 7526 the DK 7506, generating an eDK 7510. The RAT writer key 7508, the eDK 7510, and an appropriate dign algorithm 7528 may be used to create the eDK's dign 7512, which may be stored in the lock node parameters section 6044. The SDFT method may collapse many of these attributes into a single data object to be stored in the parameters section in a compact manner along with the eDK. The encryption process for non-RAT members of the locked node may be simple: they may either erase the locked node's application memory contents, since they may not create authentic dign for anything, implying that they may not successfully modify its contents; or they may use an already decrypted DK7506, which encrypts the locked node's relevant contents but leaves the eDK7512 untouched, since nothing related to the eDK dign may be changed. This may indicate that only the RAT writer may be able to re-key the DK7506. When using the SDFT method, non-RAT members of the locked node may choose to leave the original folded data containing the eDK in the parameters section and erase the unfolded structure holding the DK.

[0125]

[0123] The SSLOCK in FIG. 76, also known as a secret-shared lock or Shamir's secret-shared scheme, is a variable lock that can accept k of n main keys 7606, each of which can be a different tine or secret-shared share, where 1 > p + 1 ≦ k ≦ n, and p + 1 can be the minimum number of required keys, called the threshold. To recover the private key, some or all tines from the decrypted key map 7606 can be given to an appropriate secret-shared cipher, such as a Shamir's secret-shared scheme or an alternative cipher 7622. Recovery can be successful if some or all tines are valid and there are a sufficient number of tines. It can then attempt to decrypt 7624 the eDK 7608 using the recovered private key with an appropriate cryptographic cipher, such as AES-256 or an alternative cipher. The parameters section 6030 may indicate the exact cipher to use for the secret sharing and enciphering operations, as well as the number of shares (n) and threshold count (p+1) for the secret sharing cipher, and / or the preferred TAR when using the SDFT method. Successful decryption of the eDK 7608 may produce the DK 7610, resulting in a successful unlock of the SSLOCK. Prior to a decryption attempt on the variable lock, the eDK's dign 7604 may be authenticated using the eDK 7608 and the RAT reader key 7602. If authentication is successful 7620, the decryption process may continue; otherwise, an error 7630 may be raised and the attempt may be paused. In this configuration, the essence of the secret sharing lock may be isolated and normalized to the keyhole and variable lock structure to make it modular. In the collapsed structure, the authentication step may be part of the TAR and may be implicitly attempted by the act of unraveling.

[0126]

[0124] Figure 77 shows the encryption operation of the SSLOCK from the perspective of a RAT writer or Nut owner, who may be encrypting a lock node for the first time or who may be in the process of re-keying a variable lock. A new private cipher key K may be generated 7720, and then the desired number of shares (tines) may be created from K using an appropriate secret sharing methodology, which may be specified in parameters 6030. These tines may then be stored as the main key 7702. In step 7724, key K may encrypt the DK 7704 to generate the eDK 7706. The RAT writer key 7708, the eDK 7706, and an appropriate dign algorithm 7726 may be used to create the eDK's dign 7710, which may be stored in the lock node parameters section 6044. The SDFT method may collapse many of these attributes into a single data object to be stored in the parameters section in a compact manner along with the eDK. The encryption process for non-RAT members of the locked node may be simple: they may either erase the locked node's application memory contents, since they may not create authentic dign for anything, implying that they may not successfully modify its contents; or they may use an already decrypted DK7704, which encrypts the locked node's relevant contents but leaves the eDK7706 untouched, since nothing related to the eDK dign may be changed. This may indicate that only the RAT writer may be able to re-key the DK7704. When using the SDFT method, non-RAT members of the locked node may choose to leave the original folded data containing the eDK in the parameters section and erase the unfolded structure holding the DK.

[0127] The description of variable locks and illustrations of their various logical operations may show how a lock node may employ 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 create a robust data structure that may allow different locking techniques to be normalized and modularized, such that substituting one for another may require changing and / or re-keying some parameter 6030. Normalization of different locking methods may ensure that the user primary key for Nut is untouchable, and that a single user primary key may be employed in many different locking techniques in different Nuts without the user being aware that the locking technique may be deemed appropriate for protecting a particular Nut payload. Sections have been highlighted where SDFT methods may prove advantageous in some embodiments of these complex data structures. Here are some examples: ORLOCK may allow multiple users to gain access to a locked node's bag; this may be a form of group access, or one of the keys may represent the master key. MATLOCK, XORLOCK, or HASHLOCK may ensure that a certain number of keys can exist to unravel its bag; a highly sensitive trade secret may require two specific executives to provide their respective private keys to view its contents. SSLOCK may require that a minimum number of private keys can exist to gain access to its bag; a corporate payment system may be accessed by a minimum number of authorized personnel, but it may not be operated alone.

[0128]

[0126] By partitioning each primary keyhole with its corresponding key map, the key map may contain attributes for 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 is activated, a corresponding expiration action may be set to be performed upon primary key expiration. For example, a common expiration action may be to delete the primary key's key map. Deleting a key map may not interfere with other registered primary keys in the keyhole lock node due to its partitioned design. Reinserting an expired primary key may no longer be recognized as a valid key because there may not be a matching key map for it. Of course, such primary key deletion should be done carefully with respect to the type of variable lock being employed; while deletion may be acceptable for ORLOCK and some SSLOCK, deletion may be counterproductive for MATLOCK, XORLOCK, and HASHLOCK because it may create a lockout situation for that lock node.

[0129] The interplay of complex data structures that may utilize multiple cryptographic techniques to protect their contents in various ways and layers can pose significant challenges in implementation details, due to the extraordinary number of variable attributes required and / or generated for each cryptographic operation. It is in these situations that the utility and sophistication of SDFT shines through and can provide convenient organizational methods and structures to help overcome such implementation challenges. For example, a single authenticated ciphering 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 keyed MAC string (digest), matching key ID for the digest, digest length, digest key length, digest method. Multiply this by each ciphering operation described in the lock node specification presented thus far (lock nodes have several more components that will be described in later sections), and it can become a huge number of attributes to track. In many cases, application programmers and designers may be aware of such predicaments and challenges and may choose to simplify the coding process by selecting a small number of ciphering methods and associated attribute values ​​and using them globally throughout their implementations. Such simplification may lead to undesirable consequences, including, but not limited to, less security, less flexibility, fewer features, greater incompatibilities, and computer code that may be more difficult to maintain or modify.

[0130] hierarchy

[0128] Figure 78 shows a block diagram of Nut (lock graph) 7800 highlighting hierarchical key usage. Each lock node in the Nut part 7804 section can be assigned a hierarchical ID. Lock nodes 7820-7824 have hierarchical ID "A," lock node 7826 has hierarchical ID "B," lock node 7828 has hierarchical ID "C," and lock node 7830 has hierarchical ID "D." The hierarchical designation can be arbitrary but may follow a pattern of grouping various Nut parts together by degree of privacy sensitivity; the deeper the hierarchy, the more sensitive the data contained in the lock node may be. Gradient opacity in Nut can be implemented through the precise use of hierarchical access control (SAC). For purposes of illustration, the hierarchical IDs shown in Figure 78 are simple characters, but in practice they can be any set of identifiable strings, such as, but not limited to, Nut IDs (as in the case of the effectively unique ID from Figure 55).

[0131] Any lock node with a Nut lock 7802 can be assigned a hierarchy. When a Nut keyhole lock node 7806 is properly unlocked or unlabeled, it can reveal a key map 7840 that can have up to three key sets 7842 (similar to FIG. 62). This section can focus on hierarchy keys 7850 (6212) and how they can function within the lock graph. In this example, there can be four hierarchy keys 7852, 7854, 7856, 7858, which can correspond to hierarchies "A, B, C, D," respectively. Each hierarchy key can be stored in the hierarchy keys 7850 section along with an associated hierarchy ID. The flowchart presented in FIG. 79 can be followed to show how each hierarchy key can be used. Once some or all hierarchy keys have been inserted into the primary keyholes of their matching lock nodes, the process can terminate, waiting for lock graph traversal to continue beyond the Nut lock section 7802.

[0132] Hierarchical keys may work in conjunction with MATLOCK variable locks, as indicated for some or all lock nodes in the Nut part 7804 section. When using the SDFT method, MATLOCK may be indicated by a "lock matlock" transformation in the preferred TAR of the relevant section. Each hierarchical key may be a mandatory key in the MATLOCK for that lock node (* in Figure 79). If either the lock node output link key or the hierarchical key is missing, a particular lock node may not be unlocked according to the MATLOCK definition. Therefore, some or all deeper hierarchies beyond that level may not be opened either. By controlling which hierarchical keys may be stored in the primary key's key map 7840, the Nut owner may explicitly control exactly how far someone can enter the lock graph 7860. The hierarchical access control layer may work independently from the Nut access control layer, and it may work in conjunction with the variable lock method.

[0133]

[0131] The way SACs and keyholes can work may imply that if multiple keys can be presented to a keyhole lock node such as 7806, there may be multiple key maps 7840 exposed and possibly multiple hierarchical key sets 7850 that can be inserted into various lock nodes. Hierarchical keys of a single hierarchical ID may be equivalent keys, so inserting the same key into a lock node that may utilize MATLOCK may result in inserting one key under that ID; essentially, the same key may be overwritten several times in a keyhole. This may be an additive access attribute property of hierarchical keys.

[0134]

[0132] Both hierarchical keys and Nut access control (described in the next section) can exhibit an additive access attribute property or characteristic. Inserting primary keys of different access levels into the primary keyholes of a lock graph can result in an access level of the lock graph that can represent the combination or union of the access levels of all valid inserted primary keys. One powerful use of this property can be in the distribution of keys for a given lock graph in a segmented manner, where a combination of primary keys can be required to gain a very specific level of access to the lock graph. This can be contrasted with a mode of operation where a primary key can present a complete picture of a given access for that keyholder.

[0135] Nut Access Control Nut access control, or NAC, is an access control method that uses cryptographic data structures that can work independently of variable locks and hierarchical access control. NAC may use a combination of role-based access control (RBAC) and cryptographic access control (CAC), which is sometimes called role-based cryptographic access control (RBCAC) or key-based authorization (KBP). While the NAC attribute key set may be localized within a single lock node, there may be a mechanism in the lock node for propagating NAC attributes along the rest of the lock graph, which may grant keyholders consistent levels of accessibility across associated lock nodes. These NAC attributes may be found in unlocked or unlabeled keyhole lock nodes for primary keys that may have been inserted from an external source. Like hierarchical keys, NAC keys may exhibit additive access attribute properties.

[0136]

[0134] KBP may be deployed using well-known properties of public key cryptography, such as creating digital signatures (dign) and asymmetrically authenticating them over strings of data using an algorithm such as RSASSA-PSS (RSA probabilistic signature scheme with an adjunct based on the probabilistic signature scheme originally invented by Bellare and Rogaway) or an alternative algorithm. The basic premise of KBP may be that, given a private / public key pair, a private key holder (writer) can create a digital signature (dign) over a parcel of data using the writer's private key, and then a public key holder (reader) can use the writer's public key, held by the reader, to authenticate that dign was created by the writer over the parcel of data. If authentication fails, something may have been compromised, such as the public key, the parcel of data, or dign, or some or all of these. The writer may be responsible for creating an updated dign for the target data parcel upon each modification of dign, and the reader may be responsible for authenticating dign and the target data parcel before "reading" or decrypting the data parcel. This process may provide a reasonable assurance to the reader that they are reading something that may have been created or modified by someone (the writer) who may have the counterpart private key. In role-based cryptographic access control (RBCAC), there may be an asymmetric key pair for each defined access role, where the "writer" of the role may obtain the private part of the key and the "reader" of the role may obtain the respective public part of the key. By separating data sets by function and digning each function data set using a different key pair, access roles may be precisely defined and assigned to various key holders by distributing the appropriate key parts. NUTS's RBCAC may allow the binding of one or more symmetric keys to a defined role's asymmetric key pair to provide an additional layer of control over the target data set. Holders of the bound symmetric keys may decrypt and read the target data set for that role.This combined symmetric key may encrypt the target dataset in addition to encryption by the symmetric key exposed by unlocking the variable lock and subsequent keys in the eKS. Alternatively, the presence of the combined symmetric key may override use of the exposed encrypting key from the eKS and may be the only key for symmetrically enciphering the target dataset. This alternative may be preferable for large target datasets, as it will not be encrypted more than once. The combined symmetric key may be used to control read access to the target dataset.

[0137] The use of SDFT in one embodiment of NAC can greatly simplify coding. Encryption and dig can be embedded in a logically coherent TAR appropriate to the function to be performed, and the SDFT unraveling process can automate much of the detailed handling of such 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.

[0138]

[0136] The table in Figure 80 shows an example of how key-based authorization might work with three defined roles, namely, reader, writer, and verifier, and five role-players, namely, A, B, V, X, and Y. Any role-player in possession of the bound symmetric key S might have the ability to encrypt or decrypt data using symmetric key S. A class of writers (COW), namely, X and Y, might have the ability to create a dign on encrypted data using an asymmetric private key R. Using an asymmetric public key U, a class of readers (COR), namely, A and B, might have the ability to verify that the corresponding digital signature was created by someone from the writer class on the encrypted data, and A and B might have the ability to decrypt the data using symmetric key S. Thus, the ability to create a valid dign might imply that one has the ability to modify the data, and that all other readers can authenticate that a dign may have been created by a valid writer. The number of roles defined depends on the access control granularity desired by the owner, but some or all of the defined roles may utilize the methodology described with respect to Figure 80. A role player that only possesses the asymmetric public key U may be known as a verifier, and a verifier may have the ability to traverse the entire Nut but may not be able to decrypt the target data corresponding to the role class. For example, a COR verifier may only authenticate that the payload of Nut may have been properly modified by the appropriate COW role player by using the COW public key for dig, but the COR verifier cannot decrypt the payload because it does not have a copy of the decryption key S.

[0139]

[0137] The NAC may precisely affect and control the viewable and modifiable aspects of content, thereby affecting and controlling aspects of the lock node, and thereby affecting and controlling aspects of Nut. The table shown in Figure 81 lists several parts of Nut, namely, hair, tick, seal, vita, face, tale, and / or bale, but may include more or fewer parts as needed. There may be several forward references in the table to Nut logs and Nut histories, which may be described in more detail later in this specification. Each row may represent a lock node, and data defining Nut parts may be held in that lock node's bag. The column titled Bag Opacity may indicate the cipher mode of the lock node's bag, which may be controlled by the lock node's metadata. Bags may be encrypted or unencrypted (clear) based on metadata settings, which may be referred to as bag opacity. If some or all of the Nut parts in the table in Figure 81 are present in a given Nut, each Nut part that can be represented by a lock node can be linked in a top-to-bottom sequence using the lock node link pointer and link key. Traversal down this table column of bag opacities for each Nut part is sometimes referred to as the gradient opacity of the Nut. Holders of appropriate external primary keys can gain access to the Nut by eventually unlocking the variable locks of the lock nodes. Depending on the SAC settings of the primary keys, key holders can be limited in how far they can traverse into the Nut. The NAC can affect which primary keys can be enabled with the ability to read, modify, and / or authenticate each Nut part through careful placement of bound symmetric cipher keys, the correct use of asymmetric key pairs, and the use of digital signature methods.

[0140]

[0138] Figure 82 shows a table listing key-based authorization access roles that may be defined for and available to a typical Nut. Access roles may not be limited by this list, as there may be more or fewer access roles defined depending on the needs of the Nut owner. The table lists, but is not limited to, four sections of Nut that may be identified: Bale, Vita, Tale, and All. The All section may refer to anything not explicitly covered by another access role. This may involve some or all of the internal workings of the lock node, such as, but not limited to, key maps, eDKs, and / or diggins related to encrypted bags that are not specified by a key pair representing a separate access role. For purposes of this description, a key pair may comprise an asymmetric key pair and a bound symmetric key. The existence of the bound symmetric key may depend on the existence of an access class verifier role. The holder of the All private key may be referred to as the RAT (Root Access Tier) or the owner of Nut. Each primary key may have a key map that may contain a copy of the RAT leader public key for authentication purposes. Bales may be kept in a bag of lock nodes that hold Nut payloads, such as documents. This key pair may be specifically referred to as the Class of Writer (COW) and Class of Reader (COR) due to its frequent use. This key pair may control which primary keys may have the ability to modify Nut payloads. In a similar manner, Nut logs may be kept in a bag of Nut's Vita part and controlled by a Logger / Log Reader key pair. Nut history may be kept in a bag of Nut's Tale part and controlled by a Historian / History Reader key pair. A verifier role for each access role class may have access to at least one public key associated with that role to authenticate its associated dign. A verifier role may imply that there may be bound symmetric keys associated with the access role class to which it does not have access.A maintenance process is given access to a defined combination of verifier roles within Nut to check the validity, consistency, and / or authenticity of Nut parts, but may not be able to read the contents of the protected data. Key pairings are not limited to these sets and may be expanded or contracted based on requirements. Any encrypted and / or unencrypted string of a lock node may have a dign created for it by its own specific key pair, and all lock nodes in the lock graph may adopt this level of specificity, which may lead to an extreme level of access control granularity, but such an extreme level of access control granularity may weaken the effectiveness of access control for such Nut.

[0141]

[0139] The parameters section of a lock node may specify the digital signature algorithm to be applied and the asymmetric key length (defaulting to a minimum of 2,048 bits for RSA-2048). Alternatively, SDFT usage may allow a specific TAR to express such a preference, and the TAR label may be stored in the parameters section instead. A lock node's encrypted bag, which may be holding a Nut payload, may not be digitally signed by a RAT writer using a RAT writer key, but rather by a key holder with COW access, which may include a RAT writer. Primary key holders may be given access to a RAT reader key via their access key set in their key map of the keyhole lock node and a corresponding access attribute propagation key (AAPK), which may allow legitimate primary key holders to authenticate dign within a lock node that may be within the jurisdiction of the RAT authority (exemplified by a primary key holder that may have access to a RAT writer key). Failure to authenticate the RAT dign may imply that the corresponding string or folded data may be compromised, or that the RAT leader key may be invalid, or that the primary key may no longer be valid, or some or all of the reasons stated. The application may signal this warning and not proceed further as the integrity of Nut may be compromised and further decryption attempts may be unlikely to succeed or may indicate compromised data.

[0142]

[0140] Figure 83 shows how Nut achieves its initial set of NAC access keys. Starting at a keyhole lock node 8300, a primary key 8304 may be inserted into the primary keyhole 8306, which may decrypt or unpack the encrypted key map, which may expose the key map structure 8310, and there may be an access key set (AKS) 8312, which may contain a set of keys comprised of access attribute key set unlocking keys (AAKSUK) 8314, which may be symmetric. Each individual AAKSUK symmetric key may correspond to an access role, as shown in the table in Figure 82. Each AAKSUK in the AKS may then be inserted into an access keyhole 8320 in the same input section 8302 of the same lock node 8300 as the initial primary keyhole 8306; thus, the key map 8310 may hold in the AKS 8312 a set of keys that may fit into its own access keyhole 8320. This may be a special property of keyhole lock nodes (outgoing lock nodes) and may not be applicable to internal lock nodes in most cases. In the access keyhole 8320, each properly inserted AAKSUK 8314 may be decrypted or expanded to reveal a corresponding access attribute key set (AAKS) 8330, which comprises an access role description 8332, an access role key (ARK) 8334, and / or an access attribute propagation key (AAPK) 8336. The ARK 8334 may specify the key pair part corresponding to a given role, i.e., public (reader) or private (writer). The AAPK 8336 may be a symmetric key that can serve as the AAKSUK to the access keyhole of the next linked lock node. The set of AAKSUKs may constitute a set of AAKS that may define the NAC access attributes of a primary key and ultimately its access at the lock node. In this illustration, the AAKS 8330 may specify the access attributes of the Nut owner because it contains the RAT private key and COW key. The additive attribute property of AAKSUK (and thereby the additive attribute property of NAC) can be shown in this figure, where there can be an AKS8312 for each primary key 8304 that can be inserted into the primary keyhole 8306, and therefore any insertion of an AAKSUK8314 into the access keyhole 8320 can be additive.An equivalent AAKSUK may simply overwrite an existing one by the access keyhole, which may lead to the union of unique AAKS when some or all of the presented primary keys have been processed. This may result in a cumulative access attribute effect when primary keys with different access attributes may be inserted at the same time.

[0143]

[0141] Figure 84 shows how an AAPK can be used to propagate NAC attributes throughout the rest of the lock nodes in the lock graph. A keyhole lock node 8400 may be properly unlocked and some or all of its AKS 8402 may have been inserted into its access keyhole 8404, which may result in an AAKS 8420. An access attribute propagation key (AAPK) 8424 may then be inserted into the access keyhole 8432 of the next linked lock node. This may be similar to how a keyhole lock node's access keyhole may be populated, but note that the key comes from the linked 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 an internal lock node 8430 may have an empty AKS in its key map, except for the RAT access level key. By following this propagation methodology, the access attributes of the primary key may be present in every open lock node in the lock graph. A lock node may isolate and localize some or all of its internal control mechanisms, such as generating a different set of AAKs for its own use within the lock node, even though the access role may be the same as COW, etc. Even the AAKSUK and AAKPK symmetric keys may be different, as long as they can be properly mapped. Allocating a RAT with a complete set of AAKs for the entire lock node and having it properly propagate throughout its lock graph may be a well-defined Nut assumption. For reference, there may be a complete set of AAKs and AAKs that can be encrypted by the RAT public key and stored in the lock node's parameters section, so that only the RAT can reveal it when it needs to rekey the lock node.

[0144]

[0142] Figure 85 shows the propagation of access attributes using an AAPK from an external lock node 8500 to an internal lock node 8530. The diagram shows where the various keys to fit into the primary keyhole 8550 and access keyhole 8560 of the linked nodes can come from. The output section 8510 can reveal the link symmetric key 8512 for the primary keyhole 8550 of the linked lock node 8530. The AAPK 8522 can be inserted 8524 into the access keyhole 8560 of the linked lock node 8530.

[0145]

[0143] Figure 86 shows a flow chart for inserting a key into an access lock, which may be covered in detail using examples in the previous section.

[0146] Figure 87 shows a table of key-based permissions for an alternative embodiment. The table includes a write asymmetric key pair (U W , R W ) and the per-instance data ciphering symmetric key S n The table presented in Figure 80 may be expanded by further defining the three keys from Figure 80 as the Dign asymmetric key pair (U D , R D ) and a default data enciphering symmetric key S0. An additional key may allow the ARK to define a WriteOnly access role that may write to the lock node's bag but may not read other parts of the bag. The WriteOnly role is defined by the key R D , U D , U W and S n A write-only role can have access to message T n When you want to save a lock node's bag, it is called T n and encrypt the encrypted message E n To generate a single-instance symmetric encryption key S n Then, a single-instance symmetric encryption key Sn is the encrypted key K n To generate the key U W Then, E n and K. n Both can be saved in the lock node's bag. The write-only role also D The key may be used to create dign and save it. Message authentication may alternatively or additionally be performed by appropriate application of an authenticating SDFT TAR sequence, which may embed and automatically fold such information for compactness and simplicity of organization. Such a TAR sequence may allow for an alternative method of message authentication using any keyed MAC transformation. A write-only role-player may finish writing, S n Once the in-memory instance of can be destroyed, the role player can replay the write-only role with the asymmetric private key R. W Since you may not have the message E n S to decipher n The asymmetric private key R may no longer have access to the key. W The only access roles that can have a copy of S n The encrypted key K is used to obtain n can be decrypted and converted into the original message T n Encrypted message E to get n S to operate against nThe authentication methodology may additionally include hashing or dign chaining, similar to the way Merkle trees work, to make the authentication process more efficient for payloads with many individual messages. While write-only role access may not prevent unauthorized truncation or overwriting of previous messages on a lock node running on a local system, the NUTS ecosystem can help prevent or accentuate such occurrences by involving its Nut history, replication, and synchronization features in various collaborative ways. This is explained later in the sections on NutServer and revision control modules.

[0147] The write-only and verifier limited role capabilities presented by the table in FIG. 87 may help alleviate some of the problems associated with the pervasive “God Key” conundrum within computer system security. This may be a well-known class of problem, where in some cases a system administrator may be given the “God Key,” or all-access credentials to a system or set of systems, to maintain, upgrade, repair, install, and / or troubleshoot the system(s) at hand. With a relatively small number of highly competent and experienced system administrators with appropriate security clearance checks, there may be a tendency in the industry to automatically correlate technical ability with high security clearance. This type of practice may be unable to address the dynamic nature of trust relationships, where the trust level between two parties may change over time in a unidirectional manner that may not be detectable by the other or may be intentionally hidden from the other. Through careful use of write-only and verifier access roles, payloads can be protected from unauthorized access at all times for data in motion or at rest. The application of these two access roles can allow organizations to decouple the combined nature of technical ability and security clearance to more appropriately and independently fully manage each aspect. The write-only role can allow people and processes to augment the log components of Nut as evidence of handling, but may not allow them to read the payload or edit the logs. Additionally, the write-only role may have access to both Dign keys and can create and verify authentication strings. The verifier role can allow people and processes to check Nut for internal consistency and authenticity without enabling any access to the payload.Lock Nodes may be systematically modified, adapted, and inserted within any database system, such as, but not limited to, noSQL or RDBMS, to enforce such granularity of access control at the field, record, table, and / or database level. Compactness, flexibility, features, and / or independence may allow Lock Nodes to exist within computerized appliances as embedded access gateways to the appliances themselves. This may be described in more detail in a later section on the Internet of Nuts.

[0148]

[0146] The NAC feature may contain a complete set of permutations for actions that may be taken on a target payload. A simple cross-reference matrix of allowed actions, along with its NAC implementation, may be shown as follows:

[0149] [Table 1] Reader and writer roles may have the implicit ability to verify or authenticate the dign contained within a locked node's bag.

[0150]

[0147] Three methods of lock node protection can be summarized as variable locking, hierarchical access control, and / or Nut access control. Variable locking may primarily protect a bag of lock nodes that may be used to carry some data content. Hierarchical access control may define how deep a user may go into the lock graph hierarchy. Nut access control may specify which parts of Nut may be modified, viewed, written to, or digitally signed by a user. Some or all of these layers may be controlled by an embedded or folded set of keys within the lock node's keyhole mechanism. The keyhole mechanism may be a flexible gateway that may allow a wide variety of cipher keys to be inserted and processed for various functions. Some or all of these components may be customized per Nut to exhibit the locking behavior that may be desired for the content to be protected, and may work together and / or separately to provide a rich set of access controls that can be modularly constructed. The modularity of the lock node may also afford simplicity in building many complex locking structures due to its repetitive, compact, and modular design. While many different algorithms may be used to fully unlock and utilize Nut, the information to initiate the mechanism may be represented by an enciphered data portion that may be stored entirely within Nut's lock node, and thus its access control mechanism may be portable and travel with its payload without relying on any external reference monitor. These mechanisms may further be embodied by various SDFT methods and structures to help simplify implementation and better manage the complexity of internal coding and / or data details.

[0151]

[0148] Nut's access control model may be a combination of mandatory access control (centralized), discretionary access control (user-centric), etc. Nut's access control model may resemble a discretionary access control model in the way it can store some or all of its access attributes within itself and in the way owners can directly set access levels per Nut to facilitate transportability. It may also accommodate some or all mandatory access control models and integrate into some or all such environments due to its flexibility afforded by its keyholes, variable locks, and other mechanisms. Furthermore, it may exhibit other properties, such as, but not limited to, gradient opacity, additive access attributes, and / or modular locked node links, which may be new to NUTS.

[0152] Locked Node Traversal Next, we can traverse the entire lock node and see how things can be revealed along the way. Figure 88 shows a simplified diagram illustrating decryption data flow within a lock node 8800. References may be made to elements in other figures that participate in a blended and integrated depiction of the lock node unlocking process, such as Figures 62, 78, 83, 84, 85, and 88. References may be made to the same lock node sections numbered by different element numbers, but different figures of the same section may represent examination in a drill-down type approach. The ordering of logical operations that may be required in the lock node unlocking process may be further optimized for efficiency and / or other purposes. The process of unlocking a lock node, and thereby ultimately unlocking the lock graph or Nut, may involve steps that may be described in this example, such as, but not limited to, using a primary key to obtain access privileges to the lock node and a decryption key, authenticating the lock node, propagating access privileges throughout the lock graph, logically operating on variable locks, and / or decrypting stored data, and these steps may be expanded, contracted, or reordered as may be required. Where appropriate, several mechanisms within the lock graph and lock nodes may benefit from appropriate application of SDFT methods.

[0153]

[0150] Primary keys 8804 may be inserted into the input section 8806, and each primary key may use its associated cipher method to attempt to decrypt its matching encrypted key map 8810 and unpack it into a key map 8808 structure. Each key map 6240 may generate a main key 6210 that may be used by a variable lock 8812. Within each key map 7840 (equivalent to 6240) there may be a set 7850 of hierarchical keys, and each hierarchical key (such as 7852-7858) may be inserted into a matching hierarchical lock node (such as 7820-7830) of the lock graph in the primary keyhole 8306 of the respective input section 8302 (in this example, hierarchical keys such as 7852-7858 may be equivalent to the primary key in 8304), and hierarchically designated lock nodes such as 7820-7830 may employ a MATLOCK, which may require a minimum of two keys to open it: a hierarchical key such as 7852 and an output link key such as 8512, which may be found in the output section 8510 or 8826. In a keyhole lock node 8300, within each key map 8310 there may be a set of access attribute key set unlock keys (AAKSUK) 8314, referred to as the access key set (AKS) 8312, and each AAKSUK key may be inserted into the access keyhole 8320 of the input section 8302 of the current keyhole lock node 8300. Once a set of access attribute propagation keys (AAPK) 8336 may have been achieved in this way, an AAPK 8522 (equivalent to 8336) may be inserted into the access keyhole 8560 of the next linked lock node 8540. This may then have an access attribute key set (AAKS) 8332, which may contain an access role key (ARK) 8334. The ARK may define the access role of the primary key 8304 for the entire lock graph. The identities of various lock node sections, such as 8840-8848, may be authenticated using these ARKs. The lock ID and metadata Dign8840 may be authenticated using the RAT public ARK8344 (which may be the public part of the RAT asymmetric key pair, as may be described in the NAC specification) and the authentication algorithm specified in section 8830.To authenticate, section 8830 may be submitted to an authentication algorithm along with the corresponding dign 8840 and RAT public ARK 8344. If authentication fails, section 8830 may be compromised and the lock node unlock process may raise an error and stop processing. If authenticated successfully, each Dign 8842 of the encrypted key map may be authenticated for each encrypted key map corresponding to a valid inserted primary key. To authenticate, each eKM 8810 string may be submitted to an authentication algorithm along with the corresponding dign 8842 and RAT public ARK 8344. If authentication fails, the eKM may be compromised and the lock node unlock process may raise an error and stop processing. If all appropriate eKMs are authenticated successfully, each Dign 8844 of the encrypted derived key may be authenticated. Each eDK8814 may be submitted to an authentication algorithm for authentication along with its corresponding dign8844 and RAT public ARK8344. If authentication fails, the eDK may be compromised, and the locked node unlock process may cause an error and stop processing. If all appropriate eDKs are successfully authenticated, each Dign8846 of the encrypted key set may be authenticated. Each eKS8818 may be submitted to an authentication algorithm for authentication along with its corresponding dign8846 and RAT public ARK8344. If authentication fails, the eKS may be compromised, and the locked node unlock process may cause an error and stop processing. If all appropriate eKSs are successfully authenticated, each Dign8848 of the encrypted bag may be authenticated. Each eBag8822 may be submitted to an authentication algorithm for authentication along with its corresponding dign8848 and COR ARK8348. If authentication fails, the eBag may be compromised and the locked node unlocking process may cause an error and stop proceeding. If all appropriate eBags are successfully authenticated, the locked node may be considered fully authenticated.Note that eBags may be authenticated using the Class of Reader (COR) Access Role Key 8348. This may be true for lock nodes that hold Nut payloads, but for lock nodes that hold Nut metadata in their bags, the RAT public ARK may instead be used to authenticate them. In that case, based on the variable lock type indicated in the lock node's parameters section 8830, the appropriate variable lock algorithm 8812 may be attempted for each encrypted derived key string (eDK) 8814 using the set of main keys 7844 from the key map 8808. Successfully unlocking the variable lock 8812 by decrypting the eDK 8814 may yield one or more derived keys (DK) 8816. Each derived key may decrypt a corresponding encrypted key set string (eKS) 8818, which may be stored in parameters 8802. Decrypting the eKS may produce a corresponding key set 8820 structure, which may hold an output section 8826 structure and a bag key. The output link key(s) that may be found in the key set 8820 structure may be stored in the output section 8826, which may serve as the key that may be inserted into the primary keyhole of the linked lock node 8530, if any. The bag key may decrypt an encrypted bag string (eBag) 8822 that may be stored in the parameters section using an appropriate cipher. The decrypted bag may hold data such as, but not limited to, a Nut (lock graph) payload, metadata about the payload, Nut metadata, bag metadata, any combination of these, and / or other data. The bag metadata may indicate whether the bag 8824 holds a Nut part or a Nut payload. If the bag holds a Nut part, it may indicate which Nut part it may represent, as well as other appropriate Nut part metadata and / or other data.If the bag holds a Nut payload, it may indicate whether the stored data may be actual data or a reference to it, and if so, what type of reference it may be, what the reference may be and / or where it may be.

[0154]

[0151] This series of steps may be repeated for each lock node in the lock graph to unlock Nut. Figure 89 shows a general flowchart for Nut unlocking. Most of the steps may have been detailed in previous examples, but some steps may require further clarification. Step 8902 - Organize lock nodes into appropriate traversal levels. Since lock nodes may be stored in a row-based format in a list-type structure, the actual topology of the lock graph may be extracted and constructed using linkage information that may be stored within each lock node. Once the graph has been constructed, one or more additional passes may be made to properly assign graph levels so that lock nodes can be traversed in the proper sequence. Step 8908 - Prompt for some or all passphrase-based keyholes. If, during processing of the input section, a passphrase-based keyhole is encountered with an empty key (passphrase), it may prompt for a passphrase. This default behavior may be modified to call another function or to bypass empty passphrase keyholes. Any logical step or process in the flowchart may have errors that may occur and lead to the process being paused; these are not specified in detail as this is a higher level flowchart; for example, a process attempting to perform an operation may fail, causing the algorithm to pause. The remainder of the flowchart may continue along the path of the previous example.

[0155]

[0152] Figure 90 shows how a NUTS-based system might open a document contained in Nut. Forward references are introduced, i.e., NUTbook 9000 may be a data collection organization application that may use Nut and essentially act as a personal PKI with respect to storing and organizing collections of passwords, cipher keys, and / or certificates. File symbols such as 9002 and 9004 may be used throughout the diagram to represent Nut files. Within the NUTbook system, there may be a main NUTbook access key, Nut 9002, that can be unlocked to gain some minimal functionality from the application. The key may be stored within Nut 9002 and may be referred to as the main NUTbook key, and the unlocking mechanism to Nut 9002 may itself comprise a passphrase. There may be a hierarchical key relationship between the main NUTbook key 9002 and the document access key 9004; thus, the document access key may be required to access documents that hold Nut in this configuration. Thus, the hierarchy may be configured to require the main NUTbook key 9002 to open and access document access key 9004. The Nut holding the document access key may have Nut ID #33 9016. Thus, key 9020, which may be stored in the payload, may be referred to as key ID #33, and both the document access key and the Nut ID of the Nut holding it may be referenced by the same ID, in this case #33. Document 9040 may be stored in Nut 9030 with Nut ID #44 9036. Similarly, the document may be referred to as document #44. When a user decides to open document #44, one of the keyholes in primary keyhole 9032 may specify that it may require key ID #33 to open document #44. Nut #33 9004 may be requested from the NUTbook, and to open Nut #33 9004, the NUTbook may request that Nut 9004 be opened. In order for that Nut to be opened, Nut 9002 may need to be opened.Assume that the user may have already initialized their NUTbook with a passphrase to Nut9002, and that the NUTbook may have cached the main NUTbook key in memory. In that case, opening Nut9004 may merely require an additional passphrase for document-level access to the NUTbook, which, once opened, may result in a cascade of Nut unlocks to ultimately reveal the decrypted document #44 9050. The NUTbook may cache the document access key for a finite amount of time to facilitate document fetching during a session, but some events, such as inactivity, hibernation, screen lock, timeout, and / or explicit locking, may require the passphrase to be entered again for document access. This section introduced the NUTbook application and hierarchical password concepts, which may be further described in later sections. The sequence of steps that may be required to open a single document may be large, but some or all of the logic employed may be based on locking nodes and their iterative processes, much of which may be hidden from the user. The end result may be that a single piece of data can be stored in a Nut such as the 9030 and its security may be consistent in some or all environments.

[0156]

[0153] Figure 91 shows the common usage in NUTS terminology to refer to a Nut payload by the Nut ID of the Nut that holds it. Here, it shows how a tagged keyhole 9124 for key #33 might actually be looking for a Nut 9110 with Nut ID #33 9112, which indicates that Nut #33 might expect to hold a single key 9114 that can be inserted into keyhole 9124. It may be interesting to note that in many of these figures and examples, the filename of the Nut file may rarely be referenced in most operations, as Nuts may be stored in files.

[0157]

[0154] The next set of figures shows various exemplary embodiments of lock graphs that may highlight the flexibility and expressiveness of lock node and lock graph models using variable locks and lock node links.

[0158]

[0155] Figure 92 shows a simplified embodiment of a list of receiver locking models, any one of which can unlock an ORLOCK lock node 9220, thereby reaching a lock node carrying a Nut payload 9290. Note that for simplicity, the lock node may be represented diagrammatically as a padlock, but in reality the lock node is a fully functional lock node that may be storing some metadata about the Nut.

[0159] 93 shows a simplified embodiment of an ordered locking model, where key 9310 may be presented first, then key 9320 may be presented second, which may enable access to Nut's payload 9390. MATLOCK lock node 9312 may request a single key, and MATLOCK lock node 9322 may request both key 9320 and a link key from lock node 9312.

[0160]

[0157] Figure 94 shows a simplified embodiment of an ordered locking model with a master key, where key 9410 may be presented first, then key 9420 may be presented second, 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.

[0161]

[0158] Figure 95 shows a simplified embodiment of a locking model using a master key, where a key 9510 or a master key 9520 may be presented together or separately, which may enable access to the Nut payload 9590.

[0162]

[0159] Figure 96 shows a simplified embodiment of a locking model with a master key, where a key 9610 or a master key 9620 may be presented together or separately, which may allow access to a Nut payload 9690. The MATLOCK placement 9632 in the lock graph may indicate that some hierarchical control for this Nut may be in place, which may be a Nut part that stores some Nut metadata.

[0163]

[0160] Figure 97 shows a simplified embodiment of a safe deposit box locking model in which a key 9710 and a bank key 9712 may be presented together, which may enable access to a Nut payload 9790.

[0164]

[0161] Figure 98 illustrates a simplified embodiment of a secret sharing locking model using a master key, where from a set of keys 9810, a number of keys that meet or exceed a secret sharing threshold may be presented together, which may enable access to the Nut payload 9890. Alternatively, a master key 9820 may be presented directly to an ORLOCK lock node 9822, which may enable access to the payload 9890. The keys 9810 may be any combination of passphrases, symmetric keys, and / or asymmetric keys, as the keyhole / key map structure may hide the tine that may be required by the secret sharing scheme utilized in the SSLOCK lock node 9812.

[0165] FIG. 99 shows a simplified embodiment of a “PrivaTegrity” type locking model, in which a user key 9920 may be presented to an ORLOCK 9922, which may enable access to a payload 9990. Alternatively, nine keys 9910 may be presented together to a MATLOCK 9912, which may enable access to Nut's payload 9990. The “PrivaTegrity” model was proposed by David Chaum in early 2016 to implement a text messaging system that could securely send messages using a key known to its user, but it may have a collusionary backdoor system that may involve up to nine different keys being held by nine international jurisdictions to grant law enforcement access to a particular message only if all nine jurisdictions can agree that that access may be critical and legally warranted.

[0166]

[0163] Figure 100 shows a simplified embodiment of a multi-Nut configuration in which 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 only access payload 10092 due to its traversal path through the lock graph. This lock graph can demonstrate the flexibility of modular lock nodes and their access control layers working together. Separate data parcels can be protected in part or in whole differently within this single Nut. If master keys 10012 and 10020 can be the same, it can allow key holder access to both payloads.

[0167]

[0164] Figure 101 shows a simplified embodiment of a multi-Nut configuration, where any of the user keys 10110 may have access to some or all three payloads, depending on their hierarchical access control. The key 10120 for SSLOCK 10122 may only have access to payload 10194 due to its lock node link. This lock graph may display the flexibility of modular lock nodes and their access control layers working together and / or individually. Separate data parcels may be protected differently within this single Nut. The flexible nature of this disclosure may allow for infinite variations in locking configurations.

[0168]

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

[0169]

[0166] Figure 103 shows a simplified embodiment of an ordered message passing example, which may be a collusion-resistant design using Nut and a Relationship Base Key (RBK; see above). 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. Mr. Data's relationship may be symbolized by having a relationship base key with each person. Mr. Data may wish to send each person a set of secret instructions, but Mr. Data may want the messages to be read in a certain sequence without the possibility of prior snooping by collusion between the participants. Thus, Mr. Data may construct these four Nuts, each with specific content. Nut 10320 sent to Alice can only be opened by Alice, as it may be locked using the RBK established between Alice and Mr. Data. Inside 10320, there is a message for Alice and a key for Bob, K Bob Alice can read her message and give Bob the key K Bob The Nut10330 sent to Bob contains two keys: Bob's RBK key between Bob and Mr. Data, and the key K from Alice. Bob A MATLOCK can be used that can only be opened by using both the key and the message for Bob. Charlie Bob can read the message and give Charlie the key K Charlie The Nut10340 sent to Charlie contains two keys: Charlie's RBK key between Charlie and Mr. Data, and the key K from Bob. Charlie The inside of the 10340 has a message for Charlie and a key for Danny, K Danny Charlie can read the message and give Danny the key K Danny The Nut10350 sent to Danny contains two keys: Danny's RBK key between Danny and Mr. Data, and the key K from Charlie. Dannyand MATLOCK can be employed, which can only be opened using the same password at the same time. Inside 10350 there can be a message for Danny. Danny can read the message, and Mr. Data's plan for ordering the messages can work.

[0170]

[0167] In the field of cybersecurity, the term "backdoor" can carry negative connotations in various dialogues surrounding the topic. Traditionally, backdoor mechanisms have been implemented at the application level, allowing unfettered access to data processed by the application. This type of application-level access can be interpreted as a serious compromise to the security of the data processed by the application, depending on which party gains access to the backdoor entry. The perception of compromise in such situations can be well-founded due to the prevalence of such applications, which often handle unencrypted data within their own application memory, thereby potentially granting backdoor users access to cleartext data. In NUTS, particularly in its locking model, some may consider the use of a master key as a type of backdoor to Nut, but technically, this can be quite different, since in all Nut locking models, every door (keyhole) is a front door and requires the appropriate cryptographic key to gain access to Nut. The NUTS API or any NUTS-related application implementation may not have intended backdoors designed at the application level. While there may be many legitimately valid reasons for having a master key entry available to Nut, all such entries may only be defined by a private key and be directly visible from a cursory inspection of the input section of a locked node. Thus, any application attempting to install backdoor-type functionality within a NUTS-related application may only do so after first gaining access to the master key for the target set of Nut, which may only be applicable to Nut for which that master key is valid. This may demonstrate the flexibility, compartmentalization, protection, and / or resiliency of Nut's data-centric approach to security.

[0171] Some or all methods of access control in NUTS may involve patterns of hiding cryptographic keys within encapsulated data structures, the unfolding of which may expose other keys that may enable access to the target data set. In the embodiments shown in this disclosure, most of these key hiding methods may use data encapsulation and / or data folding methods. The method of hiding access keys may be a preference made by the implementer, or it may be a parameterized setting within each NUTS. These methods may comprise data folding, data encapsulation, attribute-based encryption, function encryption, authorization tokens from a reference monitor, or any other method that can provide selective cryptographic exposure of subsequent access keys given access material that decrypts or unlocks its cryptographic mechanism. The demonstrative embodiments in this disclosure may have been chosen for their simple and straightforward mechanics and their well-known properties. Other equivalent mechanisms may streamline or make some aspects of the embodiments more efficient, but they may still essentially provide the same functionality—i.e., the ability to control access to access attributes that may precisely grant access to the target data set and may not by default depend on a reference monitor. Any equivalent access attribute exposure methodology may be used in place of the method presented thus far to provide the same level of protection of the nut's contents.

[0172] This concludes the section on the Nut container and its internal workings. The internal mechanisms can be embodied directly or through the use of SDFT methods, which can simplify the coding and management of such embodiments. Nut's payload can be anything that Nut can ultimately protect, including, but not limited to, text files, binary applications, image files, access keys to remote systems, executable scripts, certificates for securely establishing computer-to-computer connections, entire databases, operating systems, links to other Nuts, streaming data, and / or text messages. Due to Nut's ability to describe what it may be holding through its rich, configurable metadata, a standard list of common file types can be far from its holding capacity. The locked node architecture can allow payloads to span Nut, thus resulting in unlimited logical container sizes. If solid-state NUTS-compatible chips or circuitry were available, it might be possible to turn a physical device into Nut itself, so that the device can only be accessed by key holders. A series of such devices may constitute entire networks and intranets that may only be operational with proper authentication. The flexible nature of the modular lock node design may allow for an infinite variety of locking configurations for Nut. In the following sections, various systems and / or methods may be introduced that may use Nut as the basis for secure storage to show how some common services and methodologies may be expanded, improved, or redesigned to provide capabilities that may otherwise seem beyond the reach of the average user.

[0173] Modular I / O

[0170] A significant amount of programmer effort can be expended ensuring that data is properly brought into a program, transformed, calculated, and / or edited in its running memory space, and then properly stored persistently. An unpleasant by-product of this mode of application development can be the eventual obsolescence of file formats and their various versions. Owning, possessing, and controlling one's own data can be a useful and laudable goal, but what good is it if one cannot read that data properly? The ability to read formats, write formats, act on read data, and / or display read data can constitute some of the fundamental building blocks 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 it. A by-product of MIO can be the ability to create file format conversion modules that can allow users to access file read and write routines of past versions, thereby making those older data readable. This is sometimes called backward compatibility. The concept of forward compatibility may also be provided, although the usefulness of this feature may depend on the skill of the programmer who may design the application modules. It may be a preferred embodiment of an MIO system that some or all modules may be encapsulated in Nut, and therefore authentication, protection, and / or access control for each module may exist by default. Figure 104 shows the general components in a modular I / O. Element 10450 may be a modular I / O repository (MIOR), which may be a server process that may store and organize MIO components. The MIOR may be embodied as a local and / or remote server-type application that may act as an intelligent cache for such modules.In other embodiments, the MIOR may have a local cache on the local device, which may therefore better facilitate the normally required MIO modules. A general application 10402, which may read and / or write to a file 10404, may be conceptually and programmatically decomposed into modules for reading 10406 ​​and writing 10408 the file. The file 10404 may be formatted in a particular format "A," which may be specific to the application 10402. Similarly, the diagram shows two other applications 10410 and 10418 with corresponding data files 10412 and 10420 for the particular formats they may be in "B" and "C," and their respective read and write modules 10414, 10422, 10416, and 10424, which may be stored in the MIOR 10450. The MIOR may contain other modules that may perform different tasks or procedures for the application. 10426-10432 may denote file conversion modules that may perform conversions from one file format to another as specified by their respective labels, module Convert_A_B 10426 may take data read from file format "A" by file read module 10406 ​​into the application's memory, which may then convert the memory structure into one that resembles a memory structure that may be created by file read module File_Read_B 10414.

[0174] Modular I / O: Read and Write

[0171] Figure 105 shows simple read and write operations using MIOR 10500. An application 10502 that can process files that can be stored in file format "A" can read a file F_A 10504 formatted in format "A" by requesting a file read module File_Read_A 10506 from MIOR 10500. If module 10506 is found, it can be sent 10510 to App_A 10502, at which point App_A 10502 can install the file read module File_Read_A 10506 and run it on file F_A 10504. Module File_Read_A 10506 can perform a file read on file F_A 10504 and build an internal memory structure that can represent the contents of file F_A 10504. This memory structure, which may represent the contents of file F_A 10504, may then be transferred to the calling application App_A 10502. Once successfully transferred, App_A 10502 may continue to perform its functions using the contents of file F_A 10504, which may reside in its running memory space. In other embodiments, it may not be necessary to transfer the memory structure to App_A 10502 if the file contents may have been read by the file read module File_Read_A 10506, where there may be a facility whereby both the file read module 10506 and the application module 10502 may share the same memory space.

[0175] When application App_A 10502 is ready to store the modified contents of file F_A 10504 back into a file format, it may contact the MIOR and request a file write module for file format "A," called File_Write_A 10508. Upon receiving module 10508 10512, App_A may install and execute it using the same methodology for transferring application memory structures as the read process. Write module 10508 may perform a write operation to persistent storage, which may create the modified file F_A 10520. Requests to the MIOR for read module 10506 and write module 10508 may be made in any sequence deemed appropriate by the application developer. In one embodiment, an application may request some or all relevant I / O modules in advance before proceeding, to ensure that some or all necessary I / O operations can be performed by the application, which may prevent undesired failures later. In another embodiment, there may be a locally cached MIOR of previously fetched modules by previously executed applications that may be maintained to expedite the request and fetching procedure.

[0176]

[0173] There may be many ways to transfer and / or share memory structures between two or more logical processes, such as, but not limited to, shared memory segments, memory-mapped files, databases, inter-process messages, binary memory dump files, and / or converted memory dumps, known to those skilled in the art. A preferred method of application memory transfer in an MIO system may be using converted memory dumps between processes. JSON read and write functions may be modified to recognize binary data and automatically convert them to and from base64 encoding or other binary-to-text encoding schemes. Figure 106 illustrates the data conversions and transfers that may be involved in a typical MIO file read operation. An MIO read module, File_Read_A 10604, may read 10620 a file named F_A in format “A” 10602 into its running memory 10606. Thus, the associated contents of file 10602 may be represented 10630 in application memory structures 10606. Application memory may be stored in a JSON-compatible data structure 10606 and marshaled into text format 10610 using a JSON write function call. Optionally, the JSON output may be embedded in a Nut container 10608 for added security. Thus, application memory 10606 may be converted and stored outside 10608 of the read module 10604. Nut 10608 may then be opened and read into memory by App_A 10612, and a JSON read may be performed on the data parcel 10610, thus reconstructing the data into the running memory of App_A 10614. Data transfer methods 10622 and 10624 may include, but are not limited to, command line arguments, inter-process messages, and / or data file(s).The reading application and / or data processing application may be separate processes on different machines, the same machine, separate threads or separate cores, or the application may be a single logical process on a local or remote machine with the dynamic ability to modify its running code on the fly.

[0177] Modular I / O: Backwards Compatibility An application may undergo incremental changes over time by issuing version changes with enhancements throughout its lifetime. Many of these version changes may include format changes for storage files used to save users' work. Historically, this can lead to two problems: encumbrance and obsolescence. Encumbrance can be when software becomes bloated by adding backward compatibility capabilities to every version for every format change during the life of a product line. This can involve numerous format version changes. Furthermore, if there may be other third-party or open formats that the application may want to handle, this can result in further software bloat. Figure 105 shows how files can be read and processed without undue bloat if modular read and write modules are available in the MIOR for any format in any version that the application may utilize. Additionally, Figure 105 shows how newer read and write modules can be added independently to the MIOR, and then any application that can communicate with the MIOR can have access to the additional formatting modules without program modification. These newer modules can be the ability to read different versions of file formats for the same application product line, or they can be compatibility modules for reading and writing third-party file formats written by anyone, including the application developer.

[0178] FIG. 107 illustrates a backward compatibility example in which an application App_B 10702 may be a more recent version and may use a corresponding newer format version “B” data file, but the user may want to read and write an older version “A” file format 10704. In such a case, data conversion modules such as 10708 and 10710 may be created and stored in MIOR 10700. A conversion module may be responsible for reading one format and generating another format; in this example, conversion module 10708 may read an “A” formatted file and convert it to a “B” formatted file, and 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 from the file's metadata that the file may be in an incompatible format, and may proceed to make a request to MIOR 10700 for the read module sequence that may be required to read "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_B10702 may call File_Read_A10706 on file F_A10704, which may then call Convert_A_B10708 and transfer its memory structure in "A" format to module 10708, which may then convert the received data to "B" format and transfer it to App_B10702.When App_B is ready to save the modified data back to file F_A in the "A" format, it may call Convert_B_A 10710 and transfer its memory structure in format "B" to module 10710, which may then convert its memory structure to format "A", and call File_Write_A 10712 and transfer its memory structure in the "A" format, which may then overwrite file F_A 10714 with its modified contents in format "A", formatting the file write in file format "A". A more complex example might be where several conversion modules may be called in sequence to perform an iterative conversion process to appropriate older format versions, or where a developer may have added frequently used version change converter modules, such as Convert_B_F and Convert_F_B, to streamline such requests.

[0179]

[0176] Software bloat can be illustrated using simple calculations: Suppose a popular application has undergone five major revisions and three file format versions across three operating systems, each spanning ten years, with three major version changes. Also, suppose every one of these changes requires a different version of an I / O routine for the application. This could potentially lead to the most recent version of an application carrying up to 135 versions of its I / O functions within itself. Even if this may be an extreme case, it illustrates the proliferation of program code that can be generated to maintain backward compatibility in an application over time. This characteristic is sometimes called the dependency property of software.

[0180] A properly maintained MIOR 10700, with consistently updated modules added to its repository, can act as a historical I / O format library, allowing users to access older versions of their data files at any time in the future, which can address the problem of software and data format obsolescence. When an application may no longer be produced, sold, and / or maintained, the useful life of the application may be significantly shortened because newer versions that could allow it to run on newer operating system versions may not appear. When an application may no longer run on modern computers due to incompatibility, data files formatted by that application may be difficult to access. Clever users and developers may have found various solutions to these problems, but it may require a lot of effort and / or specialized knowledge on their parts. Using MIOR may require at least one developer to maintain modules that may be related to now-defunct applications and that developer to create newer versions of modules to be added periodically that may be compatible with newer versions of various operating systems. This type of routine maintenance can be automated using automated unit testing tools, automatically generating the appropriate modules for the OS type and version in a timely manner. Updated modules can be inserted into the MIOR, allowing anyone with access to the MIOR to benefit from the developer's work; if a particular MIOR can be accessible by anyone on the Internet, some or all users on the Internet can automatically benefit from that MIOR without requiring users to be familiar with the low-level problems and the processes that can be invoked to automatically resolve them. Software backward and forward compatibility issues are sometimes referred to as software obsolescence properties.

[0181] Modular I / O: Forward Compatibility

[0178] Users may sometimes experience a situation in which they may have bought, installed, and / or used an application many years ago, but have not purchased subsequent upgrades for it for many years. However, the application may still be functional to the user, but it may only be able to read and write file formats that may be compatible with the user's older version of the application. The most recent version of the application may have introduced a newer file format with additional features at some point in the past. This situation may present two problems for the user: 1) the user's version of the application may not read files formatted in the latest format version, and 2) other programs that can read the latest format from this application may not be able to access the user's older formatted data. A solution to the first problem may be called a forward-compatible read operation, whereby the user's older application may load a set of modules directly from MIOR that may perform incremental conversions on the data, which may allow the user to read files formatted in the newer version using the user's older program. A solution to the second problem is sometimes called forward-compatible write operations, whereby a user's older application can load a set of modules directly from MIOR that can perform incremental conversions on the data, which can enable the user to write files formatted in the newer version using the user's older program. Programs built with forward compatibility in mind can make this type of transition easier and seamless using MIOR, with little or no loss of functionality. Newer features provided in more recent format versions can be optimally mapped to less sophisticated application constructs, or can simply be substituted for the raw data, allowing the user to modify it later.Figure 108 illustrates these two different logical operations with examples.

[0182] Forward Compatible Read Operations: App_A 10802 may be compatible with files formatted in 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 may perform these recursive 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 in version "C." Module 10806 may then call recursive conversion function Convert_C_B 10808 and transfer module 10806's memory structure to it. Module Convert_C_B 10808 may perform the conversion on the data in memory and produce a memory structure that is compatible with format "B," i.e., the application's previous file format version. Module 10808 may then call recursive conversion function Convert_B_A 10810 and transfer its memory structure to it. Module Convert_B_A 10810 may perform a conversion on the data in memory to generate a memory structure compatible with format "A", i.e., the desired file format version that is compatible with older application App_A. Module 10810 may transfer its memory structure in format "A" to calling application App_A 10802, which may process it. Thus, newer version file formats can be read by older version applications without modifications to the application.

[0183]

[0180] Forward Compatible Write Operation: App_A 10840 may be compatible with files formatted in version "A", but a user may wish to write a newer file format "C", which may be beyond its original capabilities. This request may be communicated to MIOR 10800, which may reply with a sequence of modules that may perform these incremental conversions: File_Write_C 10816, Convert_B_C 10814, and Convert_A_B 10812. App_A 10840 may call Convert_A_B 10812 and transfer App_A 10840's memory structure to it. Module Convert_A_B 10812 may perform the conversion on the data in memory, producing a memory structure that is compatible with format "B". Module 10812 may then call the incremental conversion function Convert_B_C 10814 and transfer the memory structure of module 10812 to it. Module Convert_B_C 10814 may perform the conversion on the data in memory and create a memory structure that is compatible with format "C". Module 10814 may then call the file write function File_Write_C 10816 and transfer the memory structure of module 10814 to it. Module File_Write_C 10816 may write file F_C 10818, which may be formatted in version "C", i.e., the desired file format version. Thus, newer version file formats can be written by older version applications without modifications to the application.

[0184]

[0181] This disclosure is not limited by the two examples shown. Conversion modules can be generated to access any or all versions of file formats for applications on any operating system. Conversion modules may not be limited to conversions within their application product line and can be written to perform conversions across different application product lines. Conversion modules may include conversions of data to different formats, such as, but not limited to, file-to-database, database-to-file, file-to-datastream, datastream-to-file, file-to-webpage, webpage-to-file, file-to-cloud storage, cloud storage-to-file, etc.

[0185] Modular I / O: Displays

[0182] Figure 109 shows a diagram of the MIOR display module in operation. Once application App_A 10902 has successfully read data from file F_A 10904 into its memory, it may proceed to use the functionality of module Display_A 10908 to display the contents of file F_A 10904 to the user. Within the display module, the functional aspects of the modules may vary greatly depending on the application, data content, and / or developer design. Some modules may be designed to use shared memory methods that may allow the display module to directly access data in application memory, while others may transfer data to the display module, which may allow the display module to display the data. Other embodiments of the display module may have screen formatting instructions and / or templates for the type of data to be displayed, which may be edited in some cases. This modularization of display functionality may allow custom display modules to be created for various hardware and OS platforms, while allowing the calling program to remain relatively unchanged.

[0186] The catalog of collections architecture described later in the NUTbook section can take advantage of lightweight aspects of the modular display. Instead of building larger monolithic applications to handle, display, and / or edit different collections of datasets, NUTbook can make extensive use of the MIOR architecture, which can give NUTbook piecemeal customization based on the type of payload in Nut being examined.

[0187] Modular I / O: Applications In FIG. 110, MIOR 11000 may store modular application modules such as 11022. NUTbrowser 11020 (forward reference) may be an application that may be similar in appearance and behavior to most file and directory browsers, but it may recognize Nuts and act on them by looking at Nut's extensive metadata. Within Nut 11030's metadata 11002 may be information related to the type of payload it may be protecting and storing. When a user selects Nut from NUTbrowser 11020 and double-clicks to open it, NUTbrowser may open Nut and read the metadata to figure out which modules may be required to open the file. The metadata may include data such as, but not limited to, application version, file format version, and / or display version. NUTbrowser may then make a request to MIOR11000 11004 looking for applications App_A11022, File_Read_A11024, and Display_A11026. MIOR11000 may return some or all of the modules, and application App_A11022 may be called by NUTbrowser11020. Once App_A is running, it may call File_Read_A11024 to read the contents of Nut payload F_A11028, which may be stored in Nut11030. After transferring the memory structure from 11024 to the calling module App_A11022, it may call display module Display_A11026 to show the data F_A11028 to the user.

[0188] Modular I / O application modules can vary greatly in what they contain and what they can do; in some embodiments, they can be complex logic calculation modules; in other embodiments, they can store entire software installation packages; in other embodiments, they can contain some or all aspects of I / O, display, and / or application functions; in other embodiments, they can contain information including Genesis Nut, which can kickstart the reincarnation of a user's environment in a remote manner. The functionality of modular I / O application modules is not limited to these cases.

[0189] 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 to ensure that only properly authorized users can access them. These access control mechanisms may advantageously include, but are not limited to, access control policies, ownership requirements, and / or DRM mechanisms. Much of the access control may arise from the properties of the Nut container in which the modules may be stored. As this disclosure is described in more detail, it may become clearer regarding the mechanisms by which these MIOR requirements may be derived. When a data file or its contents may be encapsulated within a secure Nut container, there may be many levels of metadata available about the Nut contents, which may specify data format details such as, but not limited to, the application version that created it, the display version, the file format version, the size, the creation time, the last modification time, the author, the file type, and / or a summary. Environmental attributes, such as, but not limited to, the OS version, the application version, the hardware type and / or version, may be provided by the application opening the Nut. With this some information about the environment, data content, and / or requested operation, the MIOR can look up the appropriate module and respond with either a set of modules to satisfy the operation or an error message. These modular I / O modules can operate as single or separate processes on the same machine, across different machines, across different chips or cores, across a network, and other modes of executing logical process(es) on a computing device. Through these modules, issues of obsolescence, dependency, adaptability, compatibility, and / or flexibility can be addressed, in part or in whole.

[0190] Nut History Nut containers can be structured to store the history of payloads. The form of history can comprise periodic snapshots, incremental deltas, full event sequences, or any combination of the three, or any other archiving method. The form of history can vary depending on the type of data being stored and the application and / or data preferences and design. The NUTS ecosystem can include methods and systems to support these modes of data history archiving. These three methods of archiving can be well-established methods known to those skilled in the art. The physical location of the Nut history can be in a Nut part called a Tale (Figure 81), the opacity of which can be controlled by the Nut RAT.

[0191]

[0188] Figure 111 shows a simplified Nut schematic diagram, illustrating the evolution of 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. A user may edit data D1 11110 at time T2 11126, generating a new version D2 11114. The application may employ a snapshot archiving method, storing the original version 11110 of data D1 as a snapshot 11118 of the data at time T1 in the history section 11116 of Nut. The user may then edit data D2 11114 at time T3. The application may edit 11114 11128 to generate a new version D3 11120. The application may employ a snapshot archiving method, storing an older version 11114 of data D2 as a snapshot 11124 of the data at time T2 in Nut's history section 11122. At time T3, the history section 11122 may now hold two different snapshots 11118 and 11124 of a previous version 11120 of data D3. Nut's history 11122 may be browsed and extracted at will by the user at any time using a simple history extraction method, enabling reversion or creating entirely new documents from them. There may be Nut metadata parameters that can control the type, frequency, and / or lifespan of the history section to set reasonable history growth for the data at hand. For some text documents, saving some or all changes forever may be practical when using the delta method of archiving, as its size may be relatively small. This may allow Nut to generate saved versions of part or all of the document at any time thereafter. Binary documents may be archived as snapshots or deltas depending on the application. Some event-driven applications may archive a complete set of event sequences as its history. Note that Nut history may be archived within Nut itself and may not depend on external programs and / or storage systems. Payloads may be archived historically in this way, as long as there are archival methods available for the payload type in the NUTS environment.

[0192] Nut Log

[0189] Nut containers can be structured to store Nut event logs. As computer processes read, manipulate, and / or write to Nut, they can generate and leave within Nut itself an audit trail of the logical operations performed on Nut. The audit trail can exist essentially from an object-by-object perspective. Thus, between the Nut history and the Nut log, a chronicle of events on a data object from its inception can be stored in a single container for further review at a later time. The precision, content, and / or granularity of the Nut archive can depend on the disciplined and systematic use of these features by developers of applications operating on Nut. The physical location of the Nut log can be in a Nut part called Vita (Figure 81), and its opacity can be controlled by the Nut RAT.

[0193] FIG. 112 shows a simplified Nut schematic diagram illustrating the evolution of its event log structure over three time periods, covering two events occurring on Nut. This example may continue the scenario from FIG. 111 for Nut history. At time T1, Nut 11102 may hold data D1 11110, and its log 11212 may hold one log entry 11218 for event E1, which may indicate that Nut 11102 was created at time T1. A user may edit data D1 11226 at time T2, which may create a new version 11114 of data D2 in Nut 11104. The editing application may log the event log entry at T2 to the Nut log 11216, as may be indicated by element 11222. The user may then edit 11228 data D2 11114 at time T3, generating a new version D3 11120. The editing application may log the event log entry at T3 to the Nut log 11230, as may be shown by element 11224. At time T3, the log section 11230 may now hold three different event log entries 11218, 11222, and 11224. Nut's log 11230 may be browsed and extracted at will by the user at any time using simple log extraction methods, which may enable auditing for Nut. To set reasonable and appropriate log growth for Nut, there may be Nut metadata parameters to control the type, frequency, and / or lifespan of the log section.

[0194]

[0191] System administrators and application developers may understand the work and effort that can be involved in tracking down bugs and errors on their systems when more than one application may be involved in modifying a data object, as they may have to examine some or all of the responsible application's event logs (if they have access to them at all), filter out event log entries related to the object in question, and then, in some cases, manually reconstruct those events in the sequence in which they may have occurred on the object. With the Nut log, this event log collection, filtering, and reconstruction may already be done at the object level from the object's perspective. Furthermore, Nut metadata may specify the level of granularity of event log message detail desired by the object owner for the working application. This granularity may range from a concise debug level to a detailed debug level to uncover various lines of investigation. A highly sensitive and confidential payload may require the most granular level of event log detail to implement an audit trail for its access history. In essence, this can be a consistent and customized way of controlling the auditable history of an object by any application on a per-object basis according to the level of granularity required by the object. The term consistent can refer to the consistent design and operation of the available logging features, and the term customized can refer to the per-object preferences that the design can accommodate.

[0195] Relationship-Based Keys (RBK) The description of how a Relationship-Based Key (RBK) can be established should be familiar to anyone who has used encryption tools manually: Bob and Alice may wish to communicate privately, and therefore may trade randomly generated asymmetric cipher keys (public parts only) with each other, which they may use in a tool such as PGP or its equivalent to exchange enciphered messages and documents. The protection and management of the key pair by Bob and Alice may be left entirely to them. This can tend to be a careful and tedious task for each relationship to be established, maintained, and properly utilized, and in some cases may require Alice and Bob to have a primer or two on ciphers, their proper usage, and / or key protection. This type of key exchange can occur when neither Bob nor Alice has an established public key certificate, via a centralized directory or web of trust. It may also occur if either participant feels that an additional layer of privacy may be required by creating a completely private communication channel.

[0196]

[0193] What could happen if RBKs were the default method of communication for people like Alice and Bob? What could be the consequences, and what might be needed to make that happen in a painless way? Systematic aspects of the establishment, maintenance, and / or usage of RBKs could be automated. Before going into the details of how that could be achieved systematically, it can be constructive to consider some of the properties and consequences of consistent application of RBKs. Properties of Relationship-Based Keys ● The level of trust between two parties can be a dynamically adjustable parameter. It can be an observation of a real-life relationship between any two parties, and trust can be relative. It can wax and wane over time based on events and communications. - Unidirectional adjustment of trust level: Either party in a relationship can unidirectionally change the trust level of the parties in the relationship at will, with or without the knowledge of the other party. Relationship channel health can be determined from message context. Systems and keys can be compromised from time to time for anyone. Default usage of the RBK can allow either party to inspect the content of a communication and determine the likelihood that the other person's system or key has been compromised. In the simplest case, a message coming from Bob without RBK ciphering could potentially be a sign of compromise. The true nature of the relationship can be assessed over time: if messages of an anomalous nature are sent via the RBK and the sending party's key is not compromised, the sending party may be changing the nature of the relationship. ● Losing a relationship can be permanent, and some or all of the relationship's history may lose commercial and / or meaningful value. Unidirectionally, either party can sever the relationship by blocking its messages or erasing their RBK set. This logical operation of relationship channels can present each user with deterministic unidirectional message blocking ability. ● Parties may strictly adhere to ground rules that they are mutually obliged to follow or risk losing the relationship, i.e. ground rules that may change over time. Violation of implied ground rules may result in a unilateral severance of the relationship in a permanent manner, digitally speaking. ● It may allow for a more detailed representation of real-world relationships in digital cryptographic form. Public key cryptography in its most widely used form can be a centralized model that may be counter to how people form relationships. RBK may be decentralized and use public key cryptography in a private manner. ● Subversion isolation. Subversion of the RBK on Bob's environment can be isolated to Bob and any RBK channels he may have established with his contacts, namely Alice. Damage to Alice's environment can be isolated to Alice's channel with Bob and their mutual history communications. Some or all other relationship channels for Alice may be secure and may not be breached by a hacker who subverts Bob's environment.

[0197] A personal information manager, or PIM, is a well-known application concept in computer software. It can be broadly defined as a mixture of various functions that can 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, password keeper, notes, email manager, chat functionality, project management, key manager, calculator, task list, and / or activity logger. A PIM may provide any combination of these functions, or it may provide only a single function. A PIM may be designed to operate locally, in an isolated manner, or on a PIM web server only, or any combination thereof. In the following description, references to such functions of a PIM, such as an address book or chat or email manager, may be understood to refer to a PIM providing any of those functions as part of its offerings, or it may be the sole function of the PIM.

[0198]

[0195] Figure 113 shows how digital address book entries between Alice and Bob can be structured to support RBK in a consistent manner for some or all relationships in the address book. Alice's address book 11310, which may be a feature provided by Alice's PIM, may have two entries: an entry 11320 for herself and an entry 11330 for Bob's information. In Alice's entry 11320, Alice may list her basic contact data 11322 and some personal data 11324. Alice's address book entry 11320 may be stored as a payload in a Nut file on Alice's system and secured. On Bob's contact card 11330, Alice may have some contact information 11332 about Bob, such as Bob's name and email address. Bob's address book entry 11330 may be stored as a payload in a Nut file on Alice's system and secured. Bob's address book 11350, which may be a feature provided by Bob's PIM, may have two entries: an entry 11360 for himself and an entry 11370 for Alice's information. In Bob's entry 11360, Bob may list his own basic contact data 11352 and some personal data 11354. Bob's address book entry 11360 may be stored as a payload in a Nut file on Bob's system and may be secured. On Alice's contact card 11370, Bob may have some contact information 11372 about Alice, such as Alice's name and email address. Alice's address book entry 11370 may be stored as a payload in a Nut file on Bob's system and may be secured. When Alice and Bob decide to set up an RBK with each other, Alice and Bob may decide to set up a private two-way communication channel between themselves. Alice may begin the process by generating an asymmetric key pair 11334 and 11336, storing them under Bob's address card 11330, and sending 11344 the public part of key 11334 to Bob.The sending process 11344 may be accomplished by a passphrase-secured Nut, a message written on paper, a phone call to Bob, a message using Bob's public key known to the world, or any version of a secure key exchange protocol familiar to those skilled in the art. When Bob receives this message along with his internal key 11334, he may store it in Alice's address card entry 11370 as key 11334 for sending messages privately to Alice. Bob may then generate an asymmetric key pair 11374 and 11376, store them under Alice's address card 11370, and send Alice the public portion of key 11374 using the public key 11334 that Alice sent to Bob to encrypt the message 11346. When Alice receives this message, she may decrypt the message from Bob using Alice's private key 11336 for Bob's message. Alice may extract internal key 11374, which she may store in Bob's address card entry 11330 as key 11374 for sending messages privately to Bob. Alice may create a confirmation message for Bob encrypted with key 11374 from card 11330 and send it to Bob over any working communication medium. Bob may receive the message, which he may then decrypt using key 11376 from card 11370 and mark Bob's RBK set as established and active with respect to Alice.

[0199]

[0196] The steps in this RBK setup between Alice and Bob can be automated and initiated with a single action button or command. This may be the operational basis for how NUTbook manages its contact collection and will be explained in the NUTbook section later in this specification. The process can be repeated independently by either Bob or Alice for some or all of the contact cards in Bob's or Alice's address book in Bob's or Alice's PIM. 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 may differ from Cathy's RBK relationship with Alice, and the RBK configuration can reflect that reality.

[0200] Now that we have defined the RBK and the context for its systematic use, what might it do for Alice or Bob? Consistent use of the RBK to send messages between two entities could enable monitoring of the health of their communication channel. One example of a practical use could be spam email mitigation. It can be estimated that a significant amount of global Internet bandwidth and data storage could be occupied by spam email, both malicious and / or commercial. We might venture to assume that not many people would welcome such a volume of spam. Some of the common methods of spam mitigation could be by using filtering techniques based on content pattern recognition, domain exceptions, address exceptions, and / or by actually taking down prolific spam servers through law enforcement. In a mode in which RBK encryption could be the default way of communicating, spam could be detected in a more deterministic manner.

[0201] One of the major obstacles in automating processes such as RBK can be the significant lack of user-friendly, user-accessible, and / or user-controllable personal public key infrastructure (PKI) applications. NUTbook, along with its use of Nut, can attempt to fill the PKI gap. It can provide a flexible, secure, and / or user-controllable way to store, manipulate, and access such information in a seamless manner.

[0202]

[0199] Figure 114 shows a flowchart for reducing spam between Alice and Bob, who may now have established an RBK communication channel, which may be their default way of communicating, and who may be using well-known public email addresses. If an email is encrypted via the RBK between Alice and Bob, it may likely be a valid email from Alice to Bob or vice versa 11414. If either person receives an email from the other that is not encrypted with the RBK, it is likely spam and may be filtered out and stored in a spam trash bin 11412.

[0203]

[0200] Figure 115 shows a flowchart for reducing spam between Alice and Bob, who may now have established an RBK communication channel, which may be their default way of communicating, and who may be using private email addresses that are not made public, i.e., anonymous email addresses. If an email is encrypted via the RBK between Alice and Bob, it may likely be a valid email from Alice to Bob or vice versa 11514. If either person receives an email from the other that is not encrypted with the RBK, it may most likely be spam and may be filtered out and stored in a spam trash bin 11512. This example may assume that a set of private email addresses may 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. This type of communication channel-oriented email address may be defined as an anonymous email address.

[0204]

[0201] A communication channel between Alice and Bob, who may consistently use RBK via anonymous email addresses, may exhibit several characteristics that can be analyzed to determine the health of the relationship itself. As can be illustrated in Figure 115, some or all unencrypted spam messages may already be filtered out of the channel by default. Next, the context of appropriate RBK-encrypted messages may be examined. The table in Figure 116 lists a deterministic context-based status matrix of the health of the Alice-Bob communication channel. It may require a qualitative assessment of the content by Alice to elucidate what may be happening in the Alice-Bob relationship. This shows a unidirectional action matrix by Alice, which may be based on Bob's behavior, as evidenced by Bob's messages to Alice.

[0205]

[0202] The last symptom listed in Figure 116 may raise an interesting scenario when Bob's role can be replaced by a web vendor, i.e., Alice may have established an anonymous RBK communication channel with the vendor. The table in Figure 117 shows a deterministic context-based status matrix of the health of the Alice-vendor communication channel. Alice may now have the ability to find out whether this vendor has been selling Alice's information to spammers through the channel's identifiable aspects of the anonymous email address and RBK set. This may provide a level of transparency into the inner workings of the vendor's marketing department, along with a clear audit trail. This type of vendor accountability may be unprecedented in such a systematically detailed manner by the average user. The consequences for a vendor violating Alice's trust may be dire, as the vendor may lose all means to contact Alice forever. In effect, proper and consistent use of anonymous email addresses and / or RBKs may allow Alice's digital equivalent to leave the store and never return, which may serve as a deterrent to vendors from misusing the personal information of their clients.

[0206]

[0203] Figure 118 shows a deterministic context-based status matrix of the health of the Alice-vendor communication channel from the vendor's perspective. The channel characteristics may provide the vendor with the same types of unidirectional actions they can take to protect their business and potentially protect their clients. The vendor's use of this methodology may potentially improve the vendor's reputation for privacy and data security. It may also implicitly state that the vendor may not engage in indiscriminate reselling of client data on a large scale.

[0207] FIG. 119 shows a graphical representation of how the use of RBKs can help isolate the compromise of sensitive data on a user's system. Bob 11900 may have an RBK channel with Alice 11910 and an RBK channel with Dave 11920. Bob may have clicked on a Trojan horse website and been infected with a key logger or equivalent malicious program, after which a hacker may be able to break into Bob's secure data store for RBKs, such as Bob's NUTbook. As a result, Bob's RBK set with some or all of his contacts may have been compromised 11900. Bob may contact some or all of his friends, who may notify them of the breach, or some of Bob's friends may have already inferred that something was wrong with Bob or his system from spam messages that may have been sent to them using Bob's private channel with them. If Alice views Alice's NUTbook 11910, which may store some or all of Alice's RBK set, Alice may mark Alice's RBK set with Bob 11912 as compromised and generate a new RBK set whenever Bob is ready to remove the virus on Bob's system. Such may be the extent of the damage to Alice, which does not spread to other RBK relationships Alice may have established. This may be especially true if Alice also consistently uses anonymous email addresses with Alice's contacts. Alice may receive spam from hackers, but the spam may be automatically ignored when Alice marks the channel as compromised or deleted. When Bob is ready, Alice may generate a new set of RBKs and a new anonymous email channel, and Bob and Alice may continue their digital dialogue privately. The process for Dave may be the same for Dave's RBK store 11920.

[0208] Anonymous Relationship

[0205] Digital relational topologies and conventions that have emerged and solidified on the Internet over recent decades can be unnatural and unrealistic. Anonymity can be a powerful relational construct, a level of connection that can be enjoyed daily with most ad hoc interactions, such as, but not limited to, going to a drugstore to buy personal products, going to a restaurant to buy a meal, hailing a medallion cab for a ride, and / or showing up at a protest. Contrary to this physical reality, almost any vendor on the Internet may want to know exactly who Alice might be, including some or all of the personal information the vendor might obtain from her. Many vendors themselves may remain relatively anonymous by not publishing their direct phone numbers and may serve customers through email, transaction systems, and / or remotely outsourced customer service representatives in remote call centers. The most pervasive use of anonymity may be by people who may wish to hide, such as hackers. Currently, there may be many pseudonymous persona generating websites for people who may wish to remain anonymous on the Internet, but they may have to track their anonymity in a very cumbersome manner and may have to make a cautious decision to intentionally be two-faced. The use of RBK and anonymous email addresses may bring some balance to this imbalance of anonymity on the Internet for the average user and may allow those users to have more meaningful interactive relationships with vendors and each other without having to rely on pseudonyms and ad hoc two-faces.

[0209]

[0206] Figure 120 shows a simplified diagram of pre-packaged personal data Nut. Nut can store detailed personal information 12000 about a person. It can automate the pre-packaging of different subsets of this personal information for different purposes. 12010 can be a simple personal data Nut that might contain only a name and email address. Anonymous personal data Nut 12020 can indicate only an alternative email address. Shopping personal data Nut 12030 can include information fields commonly required for shopping websites for purchasing items. The generation of these data subsets from master information 12000 can be done via simple rules and filters, and can be generated on request during an online registration process. Regardless of whether a vendor or service can accept data Nut, the information can be made available for insertion into the correct fields when needed by other means. If a user utilizes an anonymous email service (forward lookup), data Nut such as 12020 can provide a dynamically created anonymous email address for the specific relationship being established.

[0210]

[0207] Figure 121 charts the sequence of events in an automated registration process that may use Nut. An internet vendor may use and accept personal data Nut, allowing an RBK channel with its customers to be automatically established. A user may visit the vendor's website and wish to register 12100. The user may begin the process by instructing the user's NUTbook to automatically register on the vendor's website and may enter the URL of the registration site. NUTbook may query the vendor to fetch information the vendor may need to register the user 12102. NUTbook may construct a subset of the user's personal information that the vendor may be requesting and may show the user a preview. The user may determine that the information requested for registration is acceptable and NUTbook may gather related information and continue the process 12104. NUTbook may extract and create a pre-packaged Nut containing the previewed information and send it to the vendor's site. The vendor may accept the registration request and send a query to the user's email address specified in the pre-packaged Nut 12106. The user may receive the vendor's query on the user's email asking the user to provide proof that they may not be a web bot that may be engaging in unscrupulous registration by asking the user to go to a specific URL to enter a captcha 12108 or other form of possible verification. If the captcha is successfu...

Claims

1. 1. A method of processing data, comprising: accessing by at least one processor a data storage unit providing at least one input data object and at least one transformation command to be performed on said at least one input data object; and operating said at least one transformation command in a forward mode on said at least one input data object to generate at least one output data object to be stored in said data storage unit.

2. 10. The method of claim 1, further comprising operating the at least one transform command in a reverse mode on the at least one output data object to generate the at least one input data object.

3. 2. The method of claim 1, wherein the at least one transformation command operating in the reverse mode comprises processing the at least one input data object in the forward mode to generate a second at least one output data object, and comparing the first at least one output data object with the second at least one output data object to generate a verification result.

4. 2. The method of claim 1, wherein the at least one transformation command operating in the forward mode requires at least one attribute for processing the at least one input data object to generate at least one output data object.

5. 5. The method of claim 4, wherein the at least one transformation command operating in the reverse mode requires the at least one attribute for processing the at least one output data object to generate the at least one input data object.

6. 5. The method of claim 4, wherein the at least one processor generates at least one attribute required by the at least one transformation command operating in the forward mode for processing the at least one input data object to generate at least one output data object.

7. 6. The method of claim 5, wherein the at least one transformation command operating in the reverse mode requires the at least one attribute for processing the at least one input data object to generate at least one output data object comprising a verification result.

8. 5. The method of claim 4, further comprising: the at least one processor validating the format of the at least one attribute submitted for use by the at least one transformation command operating in the forward mode that requires the at least one attribute in a particular format for processing the at least one input data object to generate the at least one output data object.

9. 9. The method of claim 8, further comprising: the at least one processor validating the format of the at least one attribute submitted for use by the at least one transformation command operating in the reverse mode that requires at least one attribute of a particular format for processing the at least one output data object to generate the at least one input data object.

10. 2. The method of claim 1, wherein the at least one transform command converts the data storage unit into a second data storage unit having a different structure than the first data storage unit.

11. The method of claim 10 , wherein the at least one transformation command is a mobius transformation.

12. 2. The method of claim 1, further comprising: the data storage unit providing a plurality of transformation commands in a logical order operating in a forward mode to the at least one input data object to generate the at least one output data object to be stored in the data storage unit.

13. 13. The method of claim 12, further comprising operating the plurality of transformation commands in logical order in a reverse mode on the at least one output data object to generate the at least one input data object.

14. the data storage unit is provided as at least one input data object in a second data storage unit; The method of claim 1 , wherein at least one processor accesses the second data storage unit for processing the second data storage unit.

15. two or more transformation commands within said plurality of transformation commands in logical order form a dependency group; 13. The method of claim 12, wherein each transformation command in the dependency group is processed in the same order and operates in the forward mode or the reverse mode.

16. 13. The method of claim 12, wherein one or more transform commands in the plurality of transform commands in logical order operating in the forward mode require one or more corresponding attributes for processing the at least one input data object to generate the at least one output data object.

17. 17. The method of claim 16, wherein the one or more transform commands in the plurality of transform commands in logical order operating in the reverse mode require the one or more corresponding attributes for processing the at least one output data object to generate the at least one input data object.

18. 13. The method of claim 12, further comprising: the at least one processor operating in the forward mode to generate the at least one output data object and generating one or more corresponding attributes for use by the one or more transformation commands that require one or more corresponding attributes for processing the at least one input data object.

19. 17. The method of claim 16, further comprising: the at least one processor validating the format of the one or more corresponding attributes submitted for use by the one or more transformation commands operating in the forward mode, each requiring the one or more attributes in a particular format for processing the at least one input data object to generate the at least one output data object.

20. 20. The method of claim 19, further comprising: the at least one processor validating a format of the one or more corresponding attributes submitted for use by the one or more transformation commands operating in the reverse mode, each requiring the one or more corresponding attributes in a particular format for processing the at least one output data object to generate the at least one input data object.

21. 13. The method of claim 12, wherein at least one transform command in the plurality of transform commands in logical order converts the first data storage unit into a second data storage unit having a different structure than the first data storage unit.

22. 22. The method of claim 21, wherein the last transform command in the plurality of transform commands in logical order is a mobius transform.

23. the data storage unit is provided as at least one input data object in a second data storage unit; 13. The method of claim 12, wherein at least one processor accesses the second data storage unit for processing the second data storage unit.

24. 13. The method of claim 12, wherein at least one transform command in the plurality of transform commands in the logical order operating in the reverse mode processes the at least one input data object to generate at least one output data object comprising a verification result.

25. 25. The method of claim 24, wherein at least one transform command within the plurality of transform commands in the logical order operating in the reverse mode generates a verification failure and terminates processing of the plurality of transform commands in the logical order.

26. A method of communication between a plurality of computers coupled via a network, comprising:

13. A method comprising each of the plurality of computers processing messages using the method of claim 12.

27. 27. The method of claim 26, wherein the logical order of the plurality of transformation commands in a first message is different from the logical order of the plurality of transformation commands in a second message.

28. 1. A method of processing data, comprising: at least one processor operating one or more key-requiring cryptographic functions comprising at least one input cleartext data object and zero or more input keys, wherein: the cryptographic function, having no input key, operates in an encryption mode and generates the required set of properly formed keys for encrypting the at least one input cleartext data to produce at least one output ciphertext data and the required set of properly formed keys; said cryptographic function with a subset of input keys operates in an encryption mode to generate at least one output ciphertext data and a combined set of keys, generating a required missing set of appropriately formed keys and combining them in logical order with said subset of input keys to encrypt said at least one input cleartext data; the cryptographic function with a required set of input keys operates in an encryption mode, validating the structure of each input key for encrypting the at least one input cleartext datum with the validated set of required input keys to generate at least one output ciphertext datum; wherein the cryptographic function, with the required set of input keys, operates in a decryption mode and validates the structure of each required input key for decrypting the at least one output ciphertext data with the validated set of required input keys to produce the at least one input cleartext data.

29. 30. The method of claim 28, wherein the cryptographic function is a wrapper function that accesses at least one primitive cryptographic function that requires one or more keys from at least one cryptographic library.

30. 30. The method of claim 28, further comprising generating the requested set of properly formed keys by accessing a key generation service or function.

31. 30. The method of claim 29, further comprising indicating a preference for a particular cryptographic method and mode requiring one or more keys to operate on at least one data object.

32. 1. A method of folding data, comprising: at least one processor processing at least one input data object to generate at least one output data object using at least one logical operation, wherein said at least one logical operation encapsulates at least an essence of said at least one logical operation within said at least one output data object; and at least one processor processing the at least one output data object to generate the at least one input data object using the at least one essence of the at least one logical operation encapsulated in the at least one output data object.

33. 33. The method of claim 32, wherein the at least one logical operation is a transformation.

34. 33. The method of claim 32, wherein the at least one output data object is storable in a computing environment.

35. 33. The method of claim 32, wherein the at least one output data object is transmittable to another computer process.

36. 33. The method of claim 32, further comprising providing the at least one output data object as at least one input data object to at least one processor that folds data.

37. A method of communication between a plurality of computers coupled via a network, comprising:

33. A method comprising each of the plurality of computers processing messages using the method of claim 32.

38. 38. The method of claim 37, wherein the at least one essence of the at least one logical operation in a first message is different from the at least one essence of the at least one logical operation in a second message.

39. A lock node for storing data, comprising: an input section providing a plurality of key maps, each corresponding to one of a plurality of primary keys; and the plurality of primary keys being respectively applied to the input section, each key map including at least one main key; a variable lock section that generates a derived key from a logical operation on the main key corresponding to the primary key applied to the input section; an output section that generates said data in response to said derived key.

40. 1. A protected data storage unit, comprising: a plurality of lock nodes for storing data, an input section providing a plurality of key maps, each corresponding to one of a plurality of primary keys; and the plurality of primary keys being respectively applied to the input section, each key map including at least one main key; a variable lock section that generates a derived key from a logical operation on the main key corresponding to the primary key applied to the input section; an output section for generating said data in response to said derived key; a plurality of lock nodes for storing data, a keyhole lock node of the plurality of lock nodes having a key map for each designated primary key, the keyhole lock node may further include at least one access attribute key, the attribute key providing role-based cryptographic access control based on the corresponding primary key in the protected data storage unit; and and at least one of said lock nodes providing an output key that can serve as a designated primary key for another of said lock nodes.

41. 40. The lock node of claim 39, wherein each key map includes at least one access key, and wherein the input section further utilizes the at least one access key to provide at least one access role key that defines operation permissions on the data, wherein the access role key is based on permissions associated with the designated primary key that results in the particular key map.

42. 41. A lock node as claimed in claim 40, wherein the input section also provides at least one access key for another lock node.

43. 41. The storage unit of claim 40, wherein at least one key map includes at least one hierarchical key, and wherein the input section of at least one lock node different from the lock node including the key map enables the at least one hierarchical key to provide a different key map for the at least one different lock node.

44. 44. The storage unit of claim 43, wherein the at least one hierarchical key and the input section of the lock node in the storage unit control which lock nodes within the storage unit are accessible for the particular designated primary key.

45. 41. The storage unit of claim 40, wherein the storage unit stores a log of events involving the storage unit.

46. 46. ​​The storage unit of claim 45, wherein the log is stored in encrypted form.

47. 46. ​​The storage unit of claim 45, wherein parameters control which events are logged and which events are not logged.

48. 46. ​​The storage unit of claim 45, wherein a parameter controls the level of detail of events given in the log.

49. 41. The storage unit of claim 40, wherein the storage unit stores a history of revisions of the data in the data storage unit.

50. 50. The storage unit of claim 49, wherein the history is stored in encrypted form.

51. 50. The storage unit of claim 49, wherein parameters control how revisions are presented in the history.

52. 50. The storage unit of claim 49, wherein the history also includes the source of each revision.

53. 1. A method of processing data, comprising: accessing the data storage unit by at least one processor to provide an identification of at least one application operating on the data in the data storage unit; the at least one processor retrieving the at least one application from a collection of applications; and using the at least one application to operate on the data in the data storage unit.

54. 54. The method of claim 53, wherein the at least one application reads the data in the data storage unit.

55. 54. The method of claim 53, wherein the at least one application writes the data to the data storage unit or to a different data storage unit.

56. 54. The method of claim 53, wherein the at least one application causes the data to be displayed.

57. 54. The method of claim 53, wherein the at least one application converts the data from one version to another.

58. 54. The method of claim 53, wherein the at least one application operates on information related to the data in the data storage unit.

59. 1. A method of secure communication between a plurality of computers coupled over a network, comprising: each of said plurality of computers creating a different public / private key pair for each of the other computers from which communications are to be received; each of the plurality of computers confidentially sending the generated public key to a computer corresponding to the public key; each of said plurality of computers using said public key of the computer to which said communication is to be sent to encrypt said communication.

60. 60. The method of claim 59, further comprising each of the computers storing the received public key in a personal information manager accessible only to authorized computers.

61. the personal information manager providing key management functionality; 61. The method of claim 60, wherein the personal information manager provides storage management functions.

62. 61. The method of claim 60, further comprising the personal information manager storing its data in at least one protected data storage unit.

63. The at least one protected data storage unit comprises a lock node, the lock node comprising: an input section providing a plurality of key maps, each corresponding to one of a plurality of primary keys; and the plurality of primary keys being respectively applied to the input section, each key map including at least one main key; a variable lock section that generates a derived key from a logical operation on the main key corresponding to the primary key applied to the input section; an output section that generates the data in response to the derived key.

64. The at least one protected data storage unit comprises a plurality of lock nodes for storing data, an input section providing a plurality of key maps, each corresponding to one of a plurality of primary keys; and the plurality of primary keys being respectively applied to the input section, each key map including at least one main key; a variable lock section that generates a derived key from a logical operation on the main key corresponding to the primary key applied to the input section; an output section for generating said data in response to said derived keys; and a keyhole lock node of the plurality of lock nodes having a key map for each designated primary key, which may further include at least one access attribute key, the attribute keys providing role-based cryptographic access control based on the corresponding primary key in the protected data storage unit; and and at least one of the lock nodes providing an output key that can serve as a designated primary key for another of the lock nodes.

65. 60. The method of claim 59, wherein when one of the plurality of computers receives a communication, the one computer determines the computer from which the communication was received and decrypts the communication using the private key that corresponds to the public key sent to the computer sending the communication.

66. 1. A method for storing data, comprising: storing data in a protected data storage unit, said storage unit also storing a history of revisions of data in said storage unit and / or a log of events involving said storage unit; deleting the storage unit for the previous version of the data when the updated version of the data is stored in the protected data storage unit; and using the history and / or the log of events of the storage unit storing the updated version to recreate a previous version of the data.

67. a plurality of protected data storage units, each comprising: a data storage section constructed and arranged to store data; a log section that stores a log of events involving each storage unit across applications that access the each storage unit.

68. 68. The storage unit of claim 67, wherein each log is stored in encrypted form.

69. 68. The storage unit of claim 67, wherein parameters control which events are logged and which events are not logged.

70. 68. The storage unit of claim 67, wherein a parameter controls the level of detail of events given in the log.

71. 1. A protected data storage unit, comprising: a data storage section constructed and arranged to store data; a history section that stores a history of revisions of the data stored in the storage unit across applications that access the storage unit.

72. 72. The storage unit of claim 71, wherein the history is stored in encrypted form.

73. 72. The storage unit of claim 71, wherein parameters control how revisions are presented in the history.

74. 72. The storage unit of claim 71, wherein the history also includes the source of each revision.

75. 1. A method of processing data, comprising: operating, by at least one processor, an access control function to the data using at least one input key; the at least one input key revealing at least one corresponding access key, each access key cryptographically conferring a particular access attribute to the data; and each exposed corresponding at least one access key is combined in a logical operation with at least one other exposed corresponding access key available and applicable to said data to form a union of all said cryptographically granted specific access attributes to said data.

Images