HK40006940A - Encrypted userdata transit and storage - Google Patents

Description

Encrypted user data transmission and storage

Cross Reference to Related Applications

This application is based on and is filed on priority from U.S. provisional patent application No. 62/395,084, filed on 2016, 9, 15, which is hereby incorporated by reference in its entirety.

Disclosure of Invention

The data center model of computer software design is where user data may be prioritized over applications. Data center software design may allow data to be fixed at a point of storage. Data containerization (containerization) may be an embodiment of a data center design. To show how various concepts may be implemented within this disclosure, a series of figures from different perspectives highlights the particular concept sought and the overall figure shows how several of these processes and structures may work together.

Data containerization may be present in a layered approach and, if preferred, each layer may be partially or fully built on or work with the previous layer. The concepts, methods, apparatus, embodiments, and/or specifications described herein for the first layer may be collectively referred to as structured data folding or SDFT utilizing transitions. The concepts, methods, apparatus, embodiments, and/or specifications described herein for the second layer (which may include the first layer) may be collectively referred to as encrypted user data transmission and storage or nut. Any combination of layers may be partially or fully deployed to construct a data container called Nut, and layers may be partially or fully deployed in isolation. The interaction and/or interlacing of such two layers may be significant and/or complex and may present challenges to the clear demarcation of such layers. Thus, these layers are collectively presented in this specification. The Nut container may then be populated with various data center features that may allow logical operations to be performed on the data contained therein. In accordance with a storage unit referred to as Nut, various embodiments may be described to show how certain common data orientation logic operations may be redefined and re-structured to provide privacy, security, convenience, and/or capabilities to a user.

Drawings

Various embodiments may be disclosed in the following detailed description and accompanying drawings:

fig. 1 shows a symbol table used to represent different cryptographic key types.

Fig. 2 shows a simplified set of flow diagrams showing data input, data output, and logic operations that may typically be performed by different cryptographic methods.

Fig. 3 shows an illustration of a general network layout in which embodiments of the present disclosure may operate.

FIG. 4 shows an illustration of a computing device in which embodiments of the present disclosure may operate.

FIG. 5 shows an illustration of a transition in a forward mode or normal operation.

FIG. 6 shows a table of common data operations and their transition classifications.

FIG. 7 shows an illustration of a transition in reverse mode.

Fig. 8 shows a diagram of the irreversible transition.

FIG. 9 shows a diagram of conditional reversible transitions.

FIG. 10 shows a table of common data operations and functions grouped by transition types.

Figure 11 shows the coding table defined in Python v3.

Fig. 12 shows a table listing additional transition definitions.

FIG. 13 shows a transition reversibility matrix.

FIG. 14 shows a transition mode action matrix.

FIG. 15 shows a detailed example of a serialized transition.

Fig. 16 shows a detailed example of a summary transition.

Fig. 17 shows a detailed example of a digest transition (also known as a check) in reverse mode.

Fig. 18 shows a schematic of a scipher transition.

Fig. 19 shows a diagram of a salsa20 (scicher) transition.

Fig. 20 shows a detailed example of a salsa20(scipher) transition.

FIG. 21 shows a command specification table for serialization and compression translation and a set of sample translation commands showing their use.

FIG. 22 shows a command specification table for an encoding transition and a set of sample transition commands showing their use.

FIG. 23 shows a command specification table for a summary transition and a set of sample transition commands showing their use.

FIG. 24 shows a command specification table for an acipher and dign transition and a set of sample transition commands showing their use.

FIG. 25 shows a command specification table for a derived transition and a set of sample transition commands showing their use.

Fig. 26 shows a command specification table 2602 for a scipher transition and a set of sample transition commands 2604 for its purpose.

FIG. 27 shows the output structure format of the 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 string of encoded parameter values utf8 for the scipher transition on the output message.

FIG. 28 is a table showing parameter keywords and specifications for a header string in the output structure format of a scipher transition.

FIG. 29 shows an illustration of iterative embedded message encapsulation for an AEAD mode scipher transition.

FIG. 30 shows a command specification table 3002 for a lock (lock) transition and a set of sample transition commands 3010 showing their use.

FIG. 31 shows specifications for various transition structures in a table format.

FIG. 32 shows a command specification table for a mobius transition. Its use is shown and a figure shows the structural changes it can make to various structures. A matrix shows the structure type/mode efficient operations that the mobius transition can act on.

FIG. 33 shows command specification tables 3302, 3304 for information gathering (press), clearing (clear), and key (key) transitions and a set of sample transition commands 3310 showing their use.

Fig. 34 shows a table of key exchange specification structures or KISS.

Fig. 35 shows a table 3502 of KISS modes of operation, a matrix 3504 showing key type/field generation mappings, and a key type definition 3506.

FIG. 36 shows an example of the structure and TAR definition of a TAR.

FIG. 37 shows a block diagram showing where a transition-related attribute persists and a table listing the type and location of the attribute.

FIG. 38 shows a block diagram of SDFT operation with stitching and unstitching (or vice versa).

FIG. 39 shows a flow diagram of an SDFT stitching operation.

FIG. 40 shows a flow chart of an SDFT teardown operation.

FIG. 41 shows how reverse TAR is performed on sibling TARs.

FIG. 42 shows an example of an inverted TAR.

FIG. 43 shows a transition table that is mapped to key type templates that it may generate or need during TAR processing.

FIG. 44 shows TAR examples and key templates generated by the examples.

FIG. 45 shows TAR examples and key templates generated by the examples and an expected list of KISS structures to be input (put) or generated (gen). The KISS list is also known as a key stack (keystack).

FIG. 46 shows three modes of key stack operation within the SDFT TAR process: generate (gen), input (put), and inject (mixed).

FIG. 47 shows an illustration of how a key stack is generated and used in the lifecycle of data and its TARs.

FIG. 48 shows a diagram of operations that may occur on data stored in the NSstr structure.

FIG. 49 shows a flow diagram for SDFT use of iteratively folded data.

FIG. 50 shows a flow diagram for SDFT use of iteratively expanded data.

FIG. 51 shows an illustration of an SDFT API/library and its various types of TAR definition files that are accessible.

FIG. 52 shows an exemplary Python script that performs manual data folding.

FIG. 53 shows an example of SDFT defined by TAR and its use in Python scripts.

Fig. 54 shows a block diagram of dynamic TAR handoff within a single communication session.

Fig. 55 shows a flowchart of an exemplary process for generating a Nut ID.

FIG. 56 shows a block diagram showing the locations within Nut where Nut IDs and lock IDs can be used.

Fig. 57 shows an exemplary relationship between Nut ID, path name, and payload data.

FIG. 58 shows a block diagram of an embodiment of a Nut or lock map that includes a logical segment Nut lock and Nut portion.

Figure 59 shows a block diagram of an alternative embodiment of a Nut lock in Nut comprising three keyhole lock nodes.

FIG. 60 shows a block diagram of the internal data structure of a lock node.

FIG. 61 shows a block diagram of the internal data structure of the input section of the lock node shown in FIG. 60.

Fig. 62 shows a dataflow diagram that illustrates the relationship of the internal data structures of the first-level cryptographic keyway of the input section shown in fig. 61 when a valid first-level (primary) key is insertable into the cryptographic keyway.

FIG. 63 shows a flow diagram of a key insertion procedure for any lock node and for any cryptographic key.

Fig. 64 shows an example in which three first level keys may be inserted into a first level key hole.

FIG. 65 shows a data flow diagram for a variable lock decryption operation continuing from the example shown in FIG. 64.

FIG. 66 shows a data flow diagram of a variable lock encryption operation continuing from the example shown in FIG. 64.

FIG. 67 shows a table of variable lock types and their characteristics that may be used in any lock node.

FIG. 68 shows a data flow diagram of an ORLOCK decryption operation.

Figure 69 shows a data flow diagram of an ORLOCK encryption operation by the Nut owner.

FIG. 70 shows a data flow diagram for a MATLOCK decryption operation.

FIG. 71 shows a data flow diagram of a MATLOCK encryption operation by the Nut owner.

FIG. 72 shows a data flow diagram of an XORLOCK decryption operation.

FIG. 73 shows a data flow diagram of a XORLOCK encryption operation by the Nut owner.

Fig. 74 shows a data flow diagram of a hash key decryption operation.

Fig. 75 shows a data flow diagram of a hash key encryption operation by the Nut owner.

FIG. 76 shows a data flow diagram for an SSLOCK decryption operation.

Figure 77 shows a data flow diagram of an SSLOCK encryption operation by the Nut owner.

Fig. 78 shows a block diagram highlighting Nut of the hierarchical key.

Fig. 79 shows a flow chart of how the hierarchical keys may be inserted within Nut.

Fig. 80 shows a table of key-based allowances for two roles and four role-players.

Fig. 81 shows a table listing various Nut portions in an exemplary Nut, where the portions may be represented by lock nodes.

Figure 82 shows a table listing key-based allowed access roles defined for a typical Nut.

Fig. 83 shows a block diagram of how an initial set of Nut access control access keys, referred to as Access Attribute Key Set Unlocking Keys (AAKSUK), may be inserted into an access key keyway for each valid first level key.

FIG. 84 shows a block diagram of NAC access attribute propagation from an external lock node to an internal lock node.

FIG. 85 shows a block diagram of NAC access attribute propagation from an external lock node to an internal lock node and insertion of an output link key into a first level key keyway of the linked lock node.

Fig. 86 shows a flow chart for inserting a key into an access keyway.

FIG. 87 shows a table of key-based allowances for an alternative embodiment.

FIG. 88 shows a dataflow diagram of the internal decrypted data flow of the lock node.

Fig. 89 shows a flowchart of the unlock Nut.

FIG. 90 shows a block diagram of an embodiment of a NUTS-based system and how files stored in Nut may be unlocked.

Figure 91 shows an illustration of common usage in Nut parlance to refer to the payload of Nut by the Nut ID of Nut holding it. Here, the cryptographic key may be referred to by the Nut ID of the Nut holding it.

FIG. 92 shows a simplified embodiment of a list of recipient locking models.

FIG. 93 shows a simplified embodiment of an ordered locking model.

FIG. 94 shows a simplified embodiment of an ordered locking model with master keys.

FIG. 95 shows a simplified embodiment of a locking model with master key.

FIG. 96 shows a simplified embodiment of a locking model with master key.

FIG. 97 shows a simplified embodiment of a security safe deposit box locking model.

FIG. 98 shows a simplified embodiment of a secret shared locking model with a master key.

FIG. 99 shows a simplified embodiment of a "PrivaTegrid" type locking model.

Fig. 100 shows a simplified embodiment of a multiple Nut configuration, where multiple payloads may be stored within a single Nut.

Fig. 101 shows a simplified embodiment of a multiple Nut configuration, where multiple payloads can be stored within a single Nut.

FIG. 102 shows a simplified embodiment of a direct lock model with multiple payloads.

Fig. 103 shows a simplified embodiment of ordered messaging that exhibits collusion resistant design.

FIG. 104 shows a block diagram of typical components of a modular I/O.

FIG. 105 shows an illustration of a simple read and write operation using MIOR.

FIG. 106 shows data translation and transfer that may be involved in a typical MIO file read operation.

FIG. 107 illustrates how backward compatibility of file formats may be facilitated using modular I/O.

FIG. 108 illustrates how forward compatibility of a file format may be facilitated using modular I/O.

FIG. 109 depicts how modular I/O can be used to facilitate modular displays.

FIG. 110 depicts how modular I/O can be used to facilitate modular applications.

Fig. 111 shows the progressive change in Nut history over two edits and at three points in time.

Fig. 112 depicts the progressive change of Nut logs within the course of events from fig. 111.

FIG. 113 shows how relationship-based keys can be represented in Alice and Bob's contact cards.

Fig. 114 shows a flow chart of how SPAM can be detected using well-known email addresses and/or RBKs.

Fig. 115 shows a flow diagram of how SPAM can be detected using anonymous email addresses and/or RBKs.

FIG. 116 shows a deterministic context-based state matrix for an Alice-Bob RBK communication channel.

FIG. 117 shows a deterministic context-based state matrix for an Alice-vendor RBK communication channel.

FIG. 118 shows a deterministic context-based state matrix for a vendor-Alice RBK communication channel.

FIG. 119 shows isolation of RBK relationships in a constrained system for Bob.

Fig. 120 shows a block diagram of the prepackaged data Nut.

FIG. 121 plots a sequence of events in an automated registration process using RBK.

FIG. 122 depicts a chart of a sequence of events in an automated registration process using RBKs and anonymous e-mail addresses.

FIG. 123 shows a table listing NUTS core applications and their descriptions.

FIG. 124 shows a block diagram of a NUTS core application running in a computer device.

Fig. 125 shows a block diagram of a nut server operating in a user device.

Fig. 126 shows a block diagram that includes the internal components of the NUT server and its functional connections to the environment of the user device.

FIG. 127 shows an alternative embodiment of the NUT server shown in FIG. 126 using the NoSQL database as a caching mechanism.

FIG. 128 shows a block diagram of a MIOR server network layout.

FIG. 129 shows a block diagram of a MIOR server application layout.

FIG. 130 shows a flow diagram for fetching an MIO module from an MIOR server.

FIG. 131 shows a block diagram depicting a MIOR cache.

FIG. 132 shows a block diagram of a NUT browser application in a user device environment.

FIG. 133 shows a block diagram of a NUT book application in a user device environment.

FIG. 134 shows a block diagram of a NUT processing application architecture in a user device environment.

FIG. 135 shows a block diagram depicting internal components including a NUT book.

Fig. 136 shows a block diagram depicting the internal organization of the NUT directory cache from fig. 135.

FIG. 137 illustrates a diagram showing the organization of hierarchical passcodes.

Fig. 138 shows how the master passcode opens a personal file according to the hierarchical passcode of fig. 137.

FIG. 139 shows how the main passcode opens the personal file according to the hierarchical passcode of FIG. 137 and the file in FIG. 138.

FIG. 140 shows how the master and work passcodes open the work document according to the hierarchical passcode of FIG. 137.

FIG. 141 shows how the master passcode opens the work file according to the hierarchical passcode of FIG. 137 and the file in FIG. 140.

Fig. 142 shows a block diagram depicting the internal organization of NUT book key caching from fig. 135.

FIG. 143 shows a flowchart of how a NUT book may view card directories.

Fig. 144 shows a table of nut-based services.

Fig. 145 shows an illustration of a network topology for nut-based services.

FIG. 146 shows a diagram of a network layout of a NUT mail server.

Figure 147 plots a sequence of events in an automated registration program for anonymous email services (such as NUT mail) using RBKs.

Fig. 148 is a chart plotting the sequence of events when a communication channel is added in the NUT mail server.

Fig. 149 is a diagram showing a sequence of events when Alice and Bob send an email via NUT mail.

Fig. 150 shows an illustration of a network topology for a NUT chat server.

Fig. 151 shows a data flow diagram of three chat sessions hosted by a NUT chat server.

FIG. 152 shows a dataflow diagram of chat history persistence and replication across NUT servers.

Fig. 153 shows a data flow diagram for three separate chat sessions using different chat IDs or chat services.

Fig. 154 shows a data flow diagram of path agnostic conversations managed by NUT chat clients using three different chat paths from fig. 153.

Fig. 155 shows a diagram of a network layout of a NUT cloud server.

Fig. 156 shows an illustration of the network topology of a NUT web server.

Fig. 157 shows an illustration of the network topology of NUT hub servers for NUT networking (IoN).

Fig. 158 shows an illustration of a direct IoN network topology.

Fig. 159 shows an illustration of an indirect IoN network topology.

Diagram 160 shows an illustration of the NUT server hub from diagram 159 and its connections to the NUT hub and IoN devices.

Fig. 161 shows a block diagram of the NUT hub/IoN interface in the NUT server hub from fig. 160.

Diagram 162 shows a block diagram of the NUT hub/NUT server/IoT interface in the IoN device from diagram 160.

Fig. 163 shows a flow diagram for the registration and configuration process of IoN/IoT devices.

Fig. 164 shows a flow chart of how a remote control interface may process command Nuts from fig. 161 and 162.

Fig. 165 shows an illustration of a network topology of a nut authentication server.

FIG. 166 shows a block diagram highlighting the functionality of the NUTS authentication server from FIG. 165.

Fig. 167 shows an illustration of a network topology for a nut-based WiFi/ethernet router.

Diagram 168 shows a flow diagram of how messages may be processed in the nut-based WiFi/ethernet network router from diagram 167.

Fig. 169 shows a table of device classifications for nut-based WiFi/ethernet routers.

Diagram 170 shows a table of exemplary device classification attributes on a nut-based WiFi/ethernet router.

FIG. 171 shows a block diagram of how application wrappers enable device backup and replication in an automated fashion.

FIG. 172 shows a block diagram of an Event Processing Service (EPS) in both devices.

FIG. 173 shows a block diagram of a typical provider network setting that can use tracking cookies and session history stored on a big data server.

Fig. 174 shows a block diagram of vendor network settings that can use App Nut to record a copy of the session history at the local and stored on the big data server from fig. 173.

FIG. 175 shows a block diagram of context calculations that can be done locally using App Nut from FIG. 173 and FIG. 174.

Fig. 176 shows an illustration of a personal home network topology including IoT devices and service providers.

Fig. 177 shows an illustration of a personal home network that includes two IoN devices in an indirect IoN network topology and their respective service providers to control the flow of data out to the providers.

Fig. 178 shows a block diagram of how the context analysis App can automatically filter outgoing IoN messages to protect user privacy in the NUT server from fig. 177.

Detailed Description

Directory

Symbols and abbreviations

Password and one-way hash (hash)

Network graph

Device diagram

Transformation of

Type of transition

Transformation Structure

Change Audit record (TAR)

Structured data folding with transformation (SDFT)

·Nut ID

Lock graph and Lock node

○ Key hole (keyhole)

○ variable lock

○ level

○ 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 Key (RBK)

Anonymous relationships

NUTS core applications

○ NUT server

○ MIOR server

○ NUT browser/NUT shell

○ NUT book

NUTS-based services

○ NUT mail

○ NUT chat

○ NUT cloud

○ NUT network

○ NUT hub

○ NUTS authentication server

NUTS-based WiFi/Ethernet router

Application packaging

Event processing service

Context calculation

Conclusion and philosophy

Symbols and abbreviations

The following symbols and abbreviations may be used throughout the description and figures. The symbol marked (#) may be unique to nut:

AAKS access attribute key set

AAKSUK access attribute key set unlocking key

AAPK access attribute propagation Key

Acipher asymmetric password

Authenticated encryption with AEAD having associated data

AES advanced encryption Standard; also 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 authorization

CAC cryptogra phic access control

Chacha20 Bernstein's symmetric key-based stream cipher

CLI Command line interface

CMAC password-based message authentication code

CODEC/DECoder; encoding scheme for character data

COM component object model

COR reader class; or reader

CORBA common object request broker architecture

COW writer category; or writer

CPU central processing unit

CRC cyclic redundancy check

Dign digital signatures generated using asymmetric private keys

Dign (verb) uses an asymmetric private key to generate a digital signature

DK derivation of keys

DRM digital rights management

DVD digital video disk

DSA digital signature Algorithm

ECC elliptic Curve cryptography

eDK encrypted derivative Key

EPS event handling service

FIPS Federal information processing Standard

HMAC hash-based message authentication code

GPS global positioning system

GPU graphics processing Unit

GUI graphical user interface

GUID globally unique identifier

Gzip GNU zip compression

HKDF HMAC-based key derivation function

Ikm initial Key Material

IMEI International Mobile station Equipment identity

IoN Nuts networking

IoT Internet of things

IPC inter-program communication

IPv4 Internet protocol version 4

IPv6 Internet protocol version 6

I/O input/output

Ima — KISS domain name abbreviated "Iama" or "I' ma": determining KISS mode

Iv initialization vector: random number for cryptogra phic operations

JSON JavaScript object representation

KBP Key-based Admission

Keccak SHA3 hash series

KISS key exchange specification structure

LAN local area network

Lock implements a variable lock into a transition class

Lzma Lempel-Ziv-Markov chain algorithm

MAC media Access control (for Ethernet)

MAC message authentication code

Message digest #5 of MD5 Rivest

MIO Modular I/O

MIOR modular I/O repository

MMS multimedia messaging service

NAC Nut Access control

NCS NUTS authentication server

NFC near field communication

NIST national institute of standards and technology

NoSQL non-standard query language; and non-related standard query language

The number of nonces used only once: random number for cryptogra phic operations

NTFS New technology File System (Microsoft)

NUTS encrypted user data transmission and storage

OAEP Bellae and Rogaway optimized asymmetric encrypted padding

OS operating System

The passcode-based key derivation function #2 of PBKDF2 RSA (PKCS)

PGP preferred privacy

PIM personal information manager

Public key cryptography standards for PKCS RSA laboratories

Version 1.5 of PKCS1_ V PKCS #1

1.5

PKI public Key infrastructure

PSS probabilistic signature scheme

PUID actual unique ID

QA quality assurance

QUOPRI queued-Printable or QP coding

RAM random access memory

RAT root access layer, owner/producer of Nut; also RAT writer, owner

Role-based access control by RBAC

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 based symmetric key stream cipher

Salt random number for cryptogra phic applications

Scipher symmetric cipher

SCP structured cryptographic programming

Password-based key derivation function (function) of SCRYPT Perrival

SDF structured data folding

SDFT structured data folding with transitions

SHA secure Hash Algorithm-Keccak Hash variable

Shake Keccak hash variable

SMS short message service

SOAP simple object Access protocol

Bulk email with unknown SPAM-ways; also known as spam email

SSD solid state drives

SSID service set identifier

SSO Single sign on

Tar tape storage: unix commands to store data on tape or disk

TAR Change Audit records

TOP transformation of tissue principle

Secret share of tine Shamir, e.g. tail (tine, tip, tooth) on fork

TMX transition

TOP transformation of tissue principle

URL Uniform resource locator

UTF Unicode conversion 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 compression algorithm

FIG. 1 shows a table of cryptographic key types and their respective symbols that may be used throughout the description and drawings of the present invention. A passcode or passphrase based on variable length text may be represented by symbol 102. Symbol 104 denotes a key for a symmetric cipher or an alternative cipher including AES-256. Symbol 106 represents a key pair for an asymmetric cipher or an alternative cipher comprising RSA-2048. The public portion of asymmetric key pair 106 may be depicted as symbol 108 and the private portion may be shown as symbol 110. One of ordinary skill in the art can readily recognize that such codes can be well known and well tested algorithms and that substitutions to other suitable methods can be made where standards change or alternatives are desired in the disclosure.

Password and one-way hash

Fig. 2 depicts basic operations that may be performed by various types of passwords. In an encryption mode, the symmetric cipher 208 may accept the symmetric key 202 and the data 204 to produce encrypted data 206 or cipher text. In the decryption mode, the symmetric cipher 208 may accept the same symmetric key 202 and cipher text 206 to produce the original data 204. In implementations of symmetric cryptography, the encryption and decryption methods may be two separately named function calls or may be a single call with a mode parameter as part of the input. A property of symmetric cryptography may be that both encryption and decryption processes may utilize the same secret key 202.

In an encryption mode, the asymmetric cipher 214 may accept the public portion of the asymmetric key pair 210 and the data 204 to produce encrypted data 212 or ciphertext. In the decryption mode, the asymmetric cipher 214 may accept the secret portion of the asymmetric key pair 216 and the cipher text 212 to produce the original data 204. In an asymmetric cryptographic implementation, the encryption and decryption methods may be two separately named function calls or may be a single call with a mode parameter as part of the input. A characteristic of asymmetric cryptography may be that the encryption and decryption processes may utilize different portions of a key pair. In implementations such as RSA-2048, the public key may be derived (derived ) from the private key using a mathematical relationship, so the RSA-2048 private key may be synonymous with the key pair and the public key may be extracted from it.

In the signing mode, the digital signature method 222 may accept the private portion of the asymmetric key pair 216 and the ciphertext 218 to produce the digital signature 220. In the authentication mode, the digital signature method 222 may accept the public portion of the asymmetric key pair 210, the digital signature 220, and the ciphertext 218 to authenticate 224 whether the digital signature was generated using the ciphertext 218 and the private portion of the asymmetric key pair 216. In an implementation of the digital signature method, the signing and authentication method may be two separately named function calls or may be a single call with a mode parameter as part of the input. A feature of the digital signature method may be that the signing and authentication process may utilize different parts of the key pair. In implementations such as the digital signature method based on the RSA-2048 key pair, the public key may be derived from the secret key using a mathematical relationship, so the RSA-2048 secret key may be synonymous with the key pair and the public key may be extracted therefrom. For brevity and simplicity, this document refers to the digital signature interchangeably as dign; the behavior of a digitally signed data piece is interchangeably referred to as digning; digitally signed pieces of data are interchangeably referred to as signed.

The digital signature method may be a type of message authentication code or MAC. The MAC may be generated using a one-way hashing algorithm performed on the data. Hashing methods such as SHA-512 may accept data content to produce a message digest thereof, which may be up to 512 bits long. MAC authentication using methods such as SHA-512 requires recalculating the MAC for the data piece and comparing whether the provided MAC and calculated MAC are equal. A technique known as keyed hashed message authentication code or HMAC may employ additional inputs of a cryptographic key along with data content to generate an HMAC value.

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

Network map

Fig. 3 illustrates a simplified network diagram in which various embodiments of the present disclosure may be partially or fully applied. Wide area network WAN 302 may represent a network cloud that may include many servers, routers, and switching systems at various telecommunications centers working together to provide a simplified network cloud view to a user or company. Cloud services 304 may also be graphically simplified to represent a cloud of various business systems that may provide network services such as cloud storage and cloud processing; these services may be implemented in their own specifications but may include many instances of server farms, storage arrays, and routers. The personal router 306 may be connected to the WAN 302, which may give the user access to the internet among a plurality of network connectable devices 308-318 that the individual user may have. The user may not be limited to the devices depicted on the figures, but may use any device that may utilize a router to access other devices on the same network or other devices across the internet. Router 306 may be a dedicated routing device of an internet service provider or it may be a combination of devices that provide routing and/or LAN and/or WLAN capabilities and may be referred to as a gateway. The company router 320 may be connected to the WAN 302, which may give the agency user access to the internet among the multiple network connectable devices 302-330 that the company may have. A company may not be limited to the devices depicted on the figures, but may use any device that may utilize a router to access other devices on the same network or other devices across the internet. The router 320 may be a dedicated routing device of an internet service provider or it may be an interconnected and managed set of routers that provide routing and/or LAN and/or WLAN capabilities and may be referred to as a gateway and/or an internal network. The systems and methods described in various embodiments herein may be used and applied to some or all portions of such a network diagram.

Device diagram

A general purpose computing device 400 is depicted in fig. 4. The processing unit 404 may be connected to the system bus 402, which may facilitate some or all internal communication and data transfer within the device. There are several different types of system buses that may be used, but which may be collectively referred to as system bus 402 for purposes of illustration. The processing units may represent single or multi-core processors and processor arrays, such as those found in various special purpose processing boards, such as GPU boards and blade servers. Other components served by the system bus may be: a network adapter 412; an I/O interface 410; a display interface 414; a read only memory ROM 406 that may store a BIOS program 408; a volatile memory RAM 416 that may be stored temporarily in the running operating system 418, running applications 420, and/or application data 422; and non-volatile storage 424, such as a hard disk drive, SSD, and flash drive 426, which collectively can permanently store installed operating system 428, application programs 430, and/or data files 432.

Not all components of the depicted computing device are required to make some or all embodiments of the present disclosure applicable and operational. For example, a device may not have any physical display or I/O interface as found on some IoT devices; routers and gateways may have fewer physical hard drives. A necessary requirement for nut support and compatibility may be the ability to run nut compatible software, which may include a processing unit, some form of storage, and a system bus.

Transformation of

The transition may be a preferred method of organizing many known data manipulation operations found in computer programming. Nut may designate this as a transitional organization principle or TOP. Furthermore, any system data manipulation operation may be analyzed using TOP and classified as a transition type. The transitions may then be classified, normalized, structured, integrated, and/or adapted to work cooperatively within the architecture of TOP, which may be referred to as structured data folding or SDFT utilizing the transitions. The deep perspective of TOP and/or manipulation of data with SDFT may allow for better and/or complex data design to be implemented in a manner that is conceptually simpler and/or programmatically efficient. TOP and SDFT may be preferred low-order implementation mechanisms for nut components.

Analysis, methods, and/or structures based on data transformations may show how such concepts are layered, and designing their associated methods may define a set of integrated data structures and algorithmic methods that may be implemented that may allow easy and systematic transformation of data in a modular, portable, storable, and/or self-describing manner. Due to the hierarchical and interleaved nature of these analyses, the description of the transitions may have forward and backward references and may require the reader to refer to different sections in order to obtain a better understanding of certain characteristics. Structured Data Folding (SDFT) with transformation builds on the transformation using data structures and methods and may help achieve storage, transport, modularity, portability, encapsulation, and/or time compatibility of the transformed data.

Within the Nut design, SDFT is a set of low-order operations and can be considered as a basic building block for easier construction of Nut. However, SDFT may be used alone, partially, or fully to simplify some lengthy and/or repetitive data transitions within an application. SDFT may enable a computer communication protocol to dynamically switch transition sequences and/or transition parameter changes within the same session between two different applications. Currently, this single session dynamic switching can be a significant programming exercise. It is not necessary to use SDFT in order to establish Nut, but its features can help to establish Nut more conveniently, clearly and flexibly. SDFT can be further described as a data state transition method that allows infinite variation of transition events with well defined behavior for the reversibility of the state transition sequence and can provide an iterative packing technique to persist necessary attributes and data in a simple context sensitive manner. SDFT accepts and contains a cluttered situation of daily programming problems and may present a set of actual organizational principles, where theoretical evidence may be subordinate to experimental evidence.

FIG. 5 shows how the transformation organization rules may treat any data operation as a data transformation 510, which may require input of a data source 502 and attributes 504 and may output transformed data 512 and associated attributes 514. Any well-defined manipulation, operation, transformation, and/or transformation of data may be classified as a transformation type 510. TOP can allow us to systematically construct a consistent set of methods to transform data in a modular, portable, and/or self-describing manner.

The table in figure 6 shows a simple set of common data operations and how they are classified using TOP. The transition may encompass a classification of basic data operations that may have been traditionally separated in perception and practice. This may be the case when programmers discuss cryptography and data compression, such two classifications of data operations may be generally considered as two very separate and distinct operations on the data. Apart from the algorithmic differences of the operations, these operations can be considered as types of encryption transition and compression transition from the TOP perspective. In the table, "JSON serialization" may be categorized as a "serialization" translation using a "JSON" operation, so an executable translation command may be stated as "seriolize JSON". An AES symmetric cipher encryption call to a data piece may be classified as a "scipper" transition with an "AES" operation, so the executable transition command may be stated as "scipper AES". One of ordinary skill in the art can readily recognize all other data manipulation types listed in the table and follow the organizational scheme of the transition classification and manipulation classification.

FIG. 7 shows a diagram of a transition in a reverse mode or reverse operation. This figure is the same as fig. 5 except that the data flow arrows flow in the opposite direction. Transition 510 may have a well-defined reversible algorithm, as depicted by block 710. The reversible transition 710 may require the transformed data source 712 and the attributes 714 as inputs and may output the raw data 702 and the associated attributes 704. The field of computing may exist so-called reversible computing, which may exhibit concepts similar to reversible transitions. There may be some differences in the goals of the organization principles. Reversible calculations may infer the existence of a general reversible calculation language, the operation of which may be implemented down to the silicon layer to obtain the possible energy efficiency of the general calculation. Reversible transformations may be directed to implementing TOP specifically to obtain benefits such as, but not limited to, minimizing write code, minimizing programming errors, facilitating key management, simplifying key generation, structuring portable self-describing data, normalizing data manipulation concepts, introducing programming language independent methods to perform transformations, and/or simplifying the building of complex cryptographic data structures.

FIG. 8 shows a graphical representation of an irreversible transition. In forward mode, transition 810 may perform a transition on data 802 and attributes 804, which may result in transformed data 812 and attributes 814, but these outputs, along with the types of manipulations that the transition may perform on the inputs, may have irreversible properties. These irreversible transitions may be exemplified by hashing, MAC, lossy data compression, and other one-way functions or data manipulation. TOP can introduce analytical techniques that can peripherally increase the characteristics of such irreversible transitions and can produce operations that can define their reverse transition characteristics.

FIG. 9 shows a block diagram of a conditional reversible transition. This transition 910 may have a well-defined reversible algorithm but may require additional inputs and/or attributes 914 for the reverse operation to succeed. A conventional reversible transition 910 may require the transformed data source 912 and/or attributes 914 as input and may output the original data 902 and/or associated attributes 904 if and when the required conditions 916 are met, otherwise it may fail under the error condition 920. A cipher that may require a key may be classified as a traditional reversible transition because the absence of the correct key (attribute) may hinder decryption of the ciphertext.

FIG. 10 is a table listing common data operations and functions and their respective transition classifications. One of ordinary skill 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 in this document may refer to a programming language referred to as Python version 3.6 and its syntax, concepts, functions and/or methods. Many cryptographic functions referred to in this disclosure may be found in Python standards, pycryptodomes, secret shares, and/or pyCrypto libraries. Those of ordinary skill in the art may find equivalent syntax, concepts, functions and/or methodologies in most modern programming languages and their respective libraries. Note that "dign" is a transition for a digital signature; other mnemonics may be listed in the notation and abbreviations section of this document. Further details of the transitions can be found in the table in fig. 12.

Figure 11 is an encoding table defined in Python v 3.6. This list may be incomplete due to the presence of multiple coding codes, the proliferation of new coding codes, and/or the limitations of coding codes defined in Python v 3.6. "codec" is an abbreviation for encoding/decoding and is a map used for a character set in a calculation. Characters are assigned an arbitrary but unique binary value within a single codec; thus, a complete set of characters may define a single codec. Not all characters within a given codec may be read or printed by a human. A common use of transcoding is the proper representation of different character sets for different languages. An "encoding" transition may be capable of performing any of these encoding-coding-encoding operations on a given string of data. Transcoding with the name beginning with "UTF _" may provide for operations that conform to the universal code conversion format (UTF), which may be the organization of the international character set of many internet-based standards.

FIG. 12 is a table listing the transitions discussed thus far and their equivalent detailed descriptions. Additional transitions may be defined within architectures using TOP, as shown by the last six transitions in the table: key transitions, clear transitions, TAR group (TAR group) transitions, info solicitation, lock transitions, and mobility transitions. Some of these additional transitions may be specific to a Structured Data Folding (SDFT) library that utilizes transitions, some may be language specific, and/or some may be operations on nut. This can depict the flexible nature of TOP by allowing new transition types to be defined and classified to expand their instruction table. This flexible extension feature is achieved by design so that the SDFT library can accommodate new transition operations in the future. The extended feature may also allow retroactively adding older versions of transition operations for backwards compatibility. One benefit of this flexibility may be the ability of the SDFT to process data for better time compatibility. Temporal compatibility of data may be defined as a property that may enable stored data to be easily processed by the same or different applications at some future point in time. Time incompatibilities may arise from, but are not limited to, application file format version differences, different character encodings, expired application file formats, data manipulation method differences, data manipulation sequencing differences, and/or data manipulation specific parameter changes.

FIG. 13 shows a transition reversibility matrix. Each transition may be designated as reversible, irreversible, and/or conditionally reversible. The criteria for making such a designation may be based on the ideal intent of the transition rather than its actual implementation and/or theoretical shortcomings. In other cases, the designation may be arbitrary. This may be depicted by a digest operation, referred to as MD4, which may produce a 128-bit long hash of the source data. Compared to hashing operations such as 512-bit SHA2, MD4 hashing may be considered a very weak hashing algorithm due to its sensitivity to collisions (which may be an undesirable trait in hashing algorithms). The TOP perspective may be to recognize one of the original intents of MD4 as an irreversible unique hash and classify the hash in that manner. This classification may not exclude this type of transition from obtaining well-defined engineering reversibility characteristics through additional TOP analysis, as will be shown in a subsequent section. Compression transitions may fall into both reversible and irreversible designations based on the particular compression operation performed. Many image and/or audio compression techniques exhibit irreversibility due to their sampling properties; a 12MB digital image can be compressed to 360KB for efficient transmission via chat, but due to the nature of human visual perception, the overall impression of the image can be properly conveyed despite permanent data loss. Such compressed imagery may be irreversibly modified due to the fact that a significant amount of raw data may have been discarded during the transformation.

Reversible compression transitions may be exemplified by gzip compression; it can operate in principle to identify and reduce the re-reset pattern within the binary data but it can maintain enough information to reverse the procedure and reproduce the original data completely. A conditional reversible transition may be exemplified by AES symmetric cipher; it can operate in principle taking plaintext and symmetric keys and generating ciphertext. The decryption process may use the key and the ciphertext to generate the original plaintext. Thus, the 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.

TOP may define a transition pattern that may indicate the direction of a given transition operation as either forward or reverse. The transformed forward mode may perform its normal process and/or its engineered forward process. The reverse mode of transition may perform its inherent reverse process and/or its engineering reverse process. The table in FIG. 14 illustrates a matrix indicating the types of operations that a transition may inherently perform based on its transition pattern. For reference, the table lists commonly known operation names, such as "serialize" and "deserialize" or "encrypt" and "decrypt". Note the engineering reverse process of summarization and dign: "digest" and "verification", "signature (sign)" and "authentication". For a "clean" transition in which various internal data associated with its transition data structure may be deleted, it may not be possible to recover this deleted data and/or rerun the forward transition process on the original data to reproduce the deleted transient data without having the appropriate additional data. The "key" translation may perform key generation and/or management operations related to performing the translation. As such, due to the inherently random nature of key generation, it may not be possible to reverse this process theoretically and/or algorithmically in a deterministic manner for a limited time. The key management aspects of "key" translation will be discussed in detail in the subsequent sections when we shall deal with how the translation can be made to work within the context of Structured Data Folding (SDF); the key management aspects of key translation can make it difficult to design a reversible copy due to the nature of it setting the appropriate key structure to obtain successful processing in the SDF context.

Fig. 15 shows a series of three diagrams, each of which further details a serialized transition 1504 example, which may be designated a reversible transition. In computer programming, serialization and/or aggregation techniques may employ internal data structures that are specific to complex languages and whose contents may be systematically deconstructed and/or organized in a linear fashion to produce equivalent strings of data or groups of data words (referred to herein as data strings). The data string format may be more suitable for permanent storage, data transmission, and/or further transformation. Serialization by definition may require that it be fully reversible in a logical manner to recreate the original content in the original language or its equivalent. The Python structure 1512 can be transformed using JSON operation 1514 to produce an equivalent JSON string 1516 and a reverse process may be possible, as shown by the bi-directional process flow arrows. A simple tree data structure is shown at 1522, which may instantiate a complex Python data structure. The serialized transition 1524 may produce the equivalent string 1526 from 1522. The output string 1526 may now be stored, transferred and/or transformed as a program process.

Fig. 16 shows a series of three graphs, each of which further details a digest transition 1606 example, which may be assigned an irreversible transition. This example shows the SHA2 hash operation as a digest transition 1616, which may require data 1612 as an input and a digest length 1614 as an attribute 1604. SHA2 hash digest transition 1616 may generate a hash 1618 of a specified length. The Pyhton data string 1622 and the desired digest length 1624 of 256 bits may be the input to SHA2 hash transition 1626 to generate a hash string 1628 of 256 bits in length.

Fig. 17 shows a detailed example of digest transition (also referred to as verification) in reverse mode. In TOP, this may be referred to as the engineering reversal of the transition. The digest transition 1710 may accept data D11702 and attribute a 11704 as inputs to perform a forward mode digest transition 1710, which may generate a digest string DG 11712 as an output 1708. The reverse mode 1720 of this transition may accept the data D11722, the attribute A11724, and the digest string DG 11728 as inputs 1736 to perform a reverse mode digest transition 1720, which may generate a flag and/or value indicating whether the digest string DG 11728 was verified 1732 or a verification failure 1734 as an output 1738. The process 1740 of verification may generate the digest string DG 21722 by performing a forward mode digest transition 1720 on the inputs D11722 and a 11724. The output digest string DG 21722 may then be compared 1730 with the input digest string DG 11728 for equality. The comparison result 1738 may be presented in some form to show whether the reverse digest transition was successful. In this way, the engineering of this digest reversal may require reprocessing of the converted forward mode and comparing the outputs, rather than relying on any flexible approach to find the logical reversibility of such an operation (which may be difficult, time consuming, and/or unattainable).

Fig. 18, 19, and 20 show detailed examples of scipher transitions (also known as symmetric ciphers) in forward and reverse modes. In forward mode 1806, the scipher transition may accept plaintext 1802 and attributes 1804 as inputs to produce ciphertext 1810 and/or attributes 1812 as outputs. In reverse mode 1826, the scipher transition may accept ciphertext 1830 and attribute 1832 as inputs to produce plaintext 1822 and/or attribute 1824 as outputs. Fig. 19 shows how a salsa20 symmetric cipher can operate as a scipher transition. In forward mode 1906, scipher salsa20 transforms acceptable plaintext 1902 and attributes 1904 as inputs to produce ciphertext 1910 as an output. In forward mode, the attributes of this particular cipher may include a binary symmetric key, a key length, and/or a salt value. Such a salsa20 forward (encryption) implementation may be a stream cipher and may not generate additional output attributes during the encryption process, except for hidden attributes that functions may be embedded within their own output strings. In reverse mode 1926, the scipher salsa20 transforms the acceptable ciphertext 1930 and attributes 1932 as inputs to produce plaintext 1922 as an output. In the reverse mode, the attributes of this particular cipher may include a binary symmetric key, a key length, and/or a salt value. This salsa20 reverse implementation (decryption) may be a stream cipher and may not generate additional output attributes during the decryption process. Fig. 20 shows how a salsa20 symmetric cipher may operate as a transition to sample data, as may be represented within pythonv3.6 and PyCryptodome library functions. In the forward mode 2006, the scipher salsa20 transforms the acceptable data string 2002 and an attribute 2004 that includes a 256-bit symmetric secret key and a random number (e.g., salt) as inputs to produce a ciphertext 2010 as an output. In Python, the symmetric key can be represented as a "byte" data type string and thus the key length attribute can be easily derived by the len () function on the key byte string. In reverse mode 2026, scipher salsa20 transforms the acceptable ciphertext 2030 and an attribute 2032 that includes a 256-bit symmetric secret key and a random number as inputs to produce plaintext 2022 as an output. In Python, the symmetric key can be represented as a "byte" data type string and thus the key length attribute can be easily derived by the len () function on the key byte string. Attribute 2032 may need to be equivalent to attribute 2004 in order for this conditionally reversible transition to properly process ciphertext 2030 in reverse mode (decryption) to recover original plaintext 2002.

Transition type

In the following table and the examples presented in fig. 21-35, the transitions may not be limited to the operations specified in this table; any suitable operation can be analyzed through TOP and can then be integrated into the architecture to expand the operational capabilities of a particular transition. Pythonv3.6 syntax and constructs can be used to illustrate the examples in more detail. Those of ordinary skill in the art may find and substitute equivalent data types, structures, syntax, and/or methods in different programming languages. In some cases, the key/value option may not be relevant to a particular language or library and it may be ignored or modified as needed, as long as the processing can produce an equivalent result.

Serialization/compression conversion

FIG. 21 shows a command specification table 2102 for serialization and compression translation and a set of sample translation commands 2104 for their purpose. Table 2102 lists the transition names and acceptable operation types for each transition. Any tab header with a tail "═" indicates that the value presented below it can be presented in the command syntax construct in a key/value format. The "input" and "output" columns may specify the expected data types/structures for the transitions/operations within the Python v3.6 context. For example, the command "serilizejson sortkeys ═ t" may perform the following sequence of data manipulations: any Python data structure is used as input; duplicates () is performed on it, with the "sort keys" flag set to true; the Python string with the data serialized version is then output. The reverse mode of this command may expect the JSON formatted Python string as an input, execute JSON loads () on it, and then output the Python data structure. This "sort keys" flag informs the json. times () function to process the keys of any Python dictionary in increasing order. When processing a key, Python v3.6 may not guarantee a consistent processing order for the dictionary structure, and thus there may be inconsistencies between JSON strings resulting from running this transition multiple times on the same data structure. Ordering the keys in a particular order within a serialization transition may provide consistency of process columns, resulting in the same JSON string as output across multiple runs on the same data structure. This may become important for the purpose of determining whether two JSON strings are equivalent and thus may represent two equivalent pre-serialized data structures.

The compression transitions in table 2102 show several different lossless compression operations or reversible compression. Any irreversible or lossy compression operation may extend the compression transition instruction table, but for purposes of discussing reversible transitions, it is neither interesting nor constructive to discuss one-way functions that may not provide for cryptographic purposes other than data size reduction. From the TOP perspective, lossy compression can be analyzed and processed in the same manner as summary transformation, as discussed in a subsequent section. In the example in 2104, the command "compress bz 2" may perform bz2 compression on the binary string input and may generate a binary string output, which may or may not have a size smaller than the input string. Some data can no longer be compressed using a particular compression scheme; an example of this may be to process the bz2 compressed string again and no further data size reduction can be achieved.

Coding transition

FIG. 22 shows a command specification table 2202 for encoding transitions and a set of sample transition commands 2204 showing their use. There may be several encoding schemes in computer science and references in this table do not represent all known encoding schemes. The coding scheme listed under the "coding ═ column" can be found in Python v3.6 and its associated standard library. One of ordinary skill in the art can recognize the utility of access to all of these types of encodings to address issues related to applications that can manipulate data. "Codecs (98)" refers to the list of Codecs supported in Python v3.6 as written in this document and previously listed in the table in fig. 11. The transition command "encode string utf _ 8" may take the Python string as an input, perform utf _8 Unicode encoding on it, and output the result as a Python byte string. The transition command "encode utf _ 16" may take the Python string as an input, perform utf _16 Unicode encoding on it, and output the result as a Python string. The transition command "encode biascii hex" may take the Python byte string as an input, perform hexadecimal coding on it, and output the result as a Pyhton string. The transition command "encode base 64" may take as input a Python byte string, perform base64 binary encoding on it and output the result as a Pyhton string. The transition command "encode utf _ 8" is equivalent to "encode utf utf _ 8". Such descriptions may depict the types of consistency and arrangement allowed in the coding transition command syntax.

Summary transformation

FIG. 23 shows a command specification table 2302 for summary transformation and a set of sample transformation commands 2304 showing their use. The summary transitions as shown in table 2302 define three operation types but are not so limited: hash, hmac, and/or cmac. The transition command "digest hash MD 5128" may take a source data string as input, perform an MD5 hash function on it and generate an output digest byte string that is 128 bits long. It should be noted that the input source data string may not be modified and overwritten during the digest transition call; the output digest byte string may be additional data resulting from the digest transition call and may be provided a separate memory space. The transition command "digest hash SHA 2512" may take the source data word string as input, perform a SHA2 hash function on it and generate an output digest byte string that is 512 bits long. The transition command "digest hash SHAKE256 digest len-332" may take the source data string as input, perform a shift 256 hash function on it and generate an output digest byte string that is 332 bits long. The transition command "digest HMAC SHA 2256" may take the source data string as input, perform the HMAC function on it using SHA2 hashing, and generate an output digest byte string that is 256 bits long. The transition command "digest CMAC AES 256" may take a source data string and a 256-bit symmetric key as inputs, perform the CMAC function on it using the AES256 cipher and generate an output digest byte string that is 128 bits long. All of these digest transformation instance operations and types may be found in the standard Python library and/or the pycryptodom library and may not represent all of the various operations, types, digest lengths, key lengths, and/or other parameters that exist outside of such a sample library in a theoretical and/or implementation sense. Any additional changes can be suitably analyzed by TOP and integrated into a transition form. Such integration of any transition form may require reconstruction and retesting of existing transition operations.

Acipher/Dign conversion

FIG. 24 shows a command specification table 2402, 2404, 2406 for the acipher and dign transitions and a set of sample transition commands 2410 showing their use. The transition command "adipoher PKCS1_ OAEP 2048" may take as input the string of bytes and the 2048-bit long RSA asymmetric public key, perform the RSA PKCS #1 OAEP cryptographic operation on it with 512-bit SHA2 hashing, and may generate as output an encrypted string of bytes that is 2048 bits long. The transition command "adipoher PKCS1_ v1_ 53072" may take the byte string and the 3072 bit long RSA asymmetric public key as inputs, perform the RSA PKCS #1 v1.5 cryptographic operation thereon, and may generate an encrypted byte string of 3072 bits length as an output. The reverse mode of these acipher transitions may require the ciphertext in the form of a string of bytes and the private portion of an appropriate RSA key in order to produce the original plaintext.

The transition command "dign PKCS1_ v1_ 52048" may take as input the byte source string and the 2048-bit long RSA asymmetric private key, perform the RSA PKCS #1 v1.5 digital signature operation thereon with 512-bit SHA2 hashing, and may generate as output a 2048-bit long digest byte string. It should be noted that the term "digest byte string" may be used interchangeably with "digitally signed byte string" because TOP may treat these outputs as providing similar functionality and thus may store such byte strings referred to by the "digest" variable name. The transition command "dign dsshtyp ═ SHA 2" may take as input the byte source string and a 1024-bit long DSA asymmetric private key, perform DSS digital signature operations on it with 512-bit SHA2 hashing in FIPS-186-3 mode, and may generate as output a 1024-bit long digest byte string. The transition command "dign DSS 256" may take the byte source string and the 256-bit long ECC asymmetric private key as inputs, perform a DSS digital signature operation on it with 512-bit SHA2 hashing in FIPS-186-3 mode, and may generate a 256-bit long digest byte string as an output. The reverse mode of these dign transitions may require as input a digest byte string (digital signature), the source byte string, and the public portion of the appropriate asymmetric key in order to authenticate it.

Derivative transformation

FIG. 25 shows a command specification table 2502, 2504, 2506 for derived transitions and a set of sample transition commands 2510 showing their use. The sample operations pbkdf2, hkdf, and scrypt may also be referred to as key derivation functions and/or key expansion functions. The basic function of deriving a transition may be to derive a symmetric key or keys of a desired length from a string of binary or character data known to the user; a common use of the key derivation function may be to derive a properly formed symmetric cryptographic key(s) from the passcode or passphrase. The transition command "derived PBKDF2 keylen 256 iterations 100000" may take a string of character data (passcode or passphrase) as input, perform a PBKDF2 operation on it using a SHA 2512 bit hash function, a randomly generated 512 bit initial vector as salt and an iteration count parameter set to 100,000, and may generate a corresponding symmetric key, which is a 256-bit long string of byte data. The transition command "derived HKDF keyen 256numkeys 4" may take a byte data string as input, perform the HKDF operation on it using the SHA 2512 bit hash function, a randomly generated 512-bit initial vector as salt, and may generate a set of corresponding four related symmetric keys, each of which is a 256-bit long byte data string. The transition command "derived script key 128mode logic" may take the data string as input, perform a login mode SCRYPT operation on it using a randomly generated 512-bit initial vector as salt, and may generate a corresponding symmetric key, which may be a 256-bit long byte data string. The login pattern of the derived scrypt transition may be an abbreviation for setting the three parameters n, r, and p to the values indicated in table 2506. These parameter values may be set for the recommendations of the author of the SCRYPT algorithm.

The TOP approach of derivative transitions may suggest a dual mode operation. Data mode: if the transition does not splice with the key stack (discussed in detail in a subsequent section) and only splices with some type of data source string, it may transform this input data source string and replace it with a transition output, which may be in the form of a symmetric key(s). Key mode: if the transition can interface with the key stack and some type of data source, it can transition the corresponding key source material present in the key stack and can replace the key source material, thereby deriving a password(s) that can use the symmetric key and place it in the key stack. When the key stack and key management are discussed within the context of transition audit records or TARs and dependent transitions, such references may be further clarified in a subsequent section.

Scipher transformation

With TOP, symmetric cryptographic operations may be classified as scipher transitions, and as a group, these transitions may present a set of associated attributes, which may be broad in number and/or variety. The next three figures illustrate how TOP can systematically normalize and encapsulate each scicher transition with all its attributes 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, there may be very few widely accepted standards for such embedding techniques. TOP may suggest a consistent method that may be applied to all scipher transitions for the distinct purpose of supporting features known as structured data folding or SDFT with transitions. Whether this approach can become a widely used standard may exceed the scope of this document, but the reader will recognize the possible benefits of the use of this approach within the TOP architecture, especially as we discuss TAR and SDFT construction and methods later.

Fig. 26 shows a command specification table 2602 for scipher transitions and a set of sample transition commands 2604 showing their use. The table shows three types of scipher operations: aes, chacha20, and salsa 20. This is not a complete list of known symmetric ciphers, but it can present various related symmetric ciphers to show how TOPs can organize them and put them into use. Symmetric ciphers may have the following properties more or less associated with them: key length (keylen), mode of operation (mode), salt type (salttype), salt length (sallen), Block size (Block), type of cryptographic operation (type), and/or pad (pad). The key length may specify the length of a secret symmetric key that may be used in a cipher to produce ciphertext from plaintext. For the AES cipher, it may have at least ten different modes of operation, as shown in the table. Most symmetric ciphers may require the input of salt (random value) of a particular type (iv or nonce) and a particular salt length, the use of which may promote better semantic security. Symmetric ciphers may provide at least three different types of operations: block, stream, and/or AEAD cipher. Newer models can be proposed and can be integrated as an additional transition variant using TOP. Block mode ciphers may necessitate additional attributes including padding method, padding position, padding type, and/or padding length.

In the example in portion 2604, the transition command "scipher AES256 mode" OFB "may take a byte data string and a 256-bit symmetric key as inputs, encrypt the input data string using AES-256 OFB mode stream cipher with the presented key and a randomly generated 128-bit initial vector, and generate an output string, which may consist of the ciphertext involved in the process embedded in the header of the output byte string formatted in the consistent key/value format as specified in fig. 27 and all associated attributes (discussed in a subsequent portion). The transition command "scipheres AES 128mode ═ GCM" may take the byte data string and 128-bit symmetric key as inputs, encrypt the input string using AES-256GCM mode AEAD stream cipher with the presented key and 128-bit nonce, and generate an output byte string, which may consist of the ciphertext involved in the process embedded in the header of the output string formatted in the consistent key/value format as specified in fig. 27 and all associated attributes. AEAD is an acronym for authenticated encryption with associated data and may be a normalized or well-known method of embedding an authentication function along with the encryption capabilities of symmetric passwords within a single function call. The transition command "scipherchacha 20256" may take a byte data string and a 256-bit symmetric key as inputs, encrypt the input string using the CHACHA20 stream cipher with the presented key and 64-bit nonce, and generate an output string, which may consist of the ciphertext involved in the process embedded in the header of the output string formatted in the consistent key/value format as specified in fig. 27 and all associated attributes. The transition command "scipher SALSA 20128" may take a byte data string and a 128-bit symmetric key as inputs, encrypt the input string using the SALSA20 stream cipher with the presented key and 64-bit nonce, and generate an output string, which may consist of the ciphertext involved in the process embedded in the header of the output byte string formatted in the consistent key/value format as specified in fig. 27 and all associated attributes.

FIG. 27 shows the output structure format of the 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 string of encoded parameter values utf8 for the scipher transition of the outgoing message. In step 1, the scipher may accept as input a Message byte string "Message" of variable length, with an optional pad of pad length typically placed at the end of the Message as needed. The message may have a salt value prepended, as may be recommended by the selected password. Padding may be a necessary requirement for block mode symmetric ciphers. If the programmer does not specify a particular padding method, a default padding method may be used and attached to the end of the message. This message and padding may be referred to as plaintext. The selected password can now process the input plaintext and generate and output an item referred to as an encrypted message, as shown in step 2. The selected scipher transition may now make the embedded header a printable key/value pair in a string of characters format, where the key may represent a parameter type and the values represent their respective settings. The details of the keys/values will be discussed in the next section. Once a header string may be generated, a transition may calculate the length of such header string, which is referred to as the header size and may be formatted as a two-byte long unsigned high endian (big endian) integer. Two bytes may have from 0 to 2¹⁶(65,536) and may be sufficient to describe all the attributes of any symmetric cipher in the foreseeable future in this particular format. Step 2 may then continue to generate a packet message including the header size, the header, and the encrypted message. This envelope message may be the actual output string from the scipher transition, so it may be considered as having successfully encapsulated and embedded all the attributes associated with the transformed data. The data flow of the reverse scipher transition may follow this procedure in reverse: the transition command may specify an exact scipher transition to perform the matching symmetric key and the envelope message may be provided as input. The scipher transition may then unpack the packaged message, read and store all attributes found in the header, then prepare to decrypt the encrypted message. Symmetric ciphers may not have a deterministic method to convey successful decryption. Can be used forThe overlay approach uses a verification method to determine these results. An example of a basic approach may be to extract a pre-considered salt value from the encrypted message and compare it to a saved salt value from the header. A matching salt value may indicate successful decryption but may not guarantee successful decryption. AEAD mode symmetric cryptography can handle this problem to a better extent by embedding the MAC (CMAC, HASH, or HMAC) of a string of data within the encrypted message (either before or after encryption) and performing a comparison. More complex methods may require the use of different keys to authenticate a hash of a digital signature of a message of some form. As can be shown in a subsequent section, the use of SDFT and TAR can allow for this complexity in a procedurally simple and logical manner. In all of these hash-based methods, it is determined that the conditions under which a decryption attempt cannot be fully stated are due to the inherent weakness in hashing schemes that universally uniquely identify data. One deterministic method may be to compare whether the encrypted message is equal to the original message but there may be an efficiency tradeoff due to lengthy messages.

FIG. 28 shows a table of parameter keywords and specifications for a header string in the output structure format for scipher transition. The keywords selected for this attribute table may be sufficient to self-describe and/or self-explain to those of ordinary skill in the art. An instance of an attribute value is shown in the right-hand column. The first attribute listed header size may be the only attribute that may be represented as a 16-bit binary unsigned high priority integer value and may be the first field present in the header. This header size may indicate the number of bytes, after which the attributes of this particular scipher transition in a printable format may then be described. The attribute format may have been selected to be printable to allow variability in the range and length of attribute values. It may naturally exist that all attribute values as binary strings including a salt value (salt _ val) and a MAC string (MAC _ val) in a running program may be encoded as base64 to satisfy the preference of printable characters.

In this way, the output string of scipher transitions may include one or more encapsulation layers of attributes depending on the details of the selected scipher. FIG. 29 shows an illustration of iterative embedded message encapsulation for AEAD mode scipher transition. The AEAD mode AES cipher may be output from the inner layer to the outer layer listed below. The message preparation layer 2910 may include a plaintext message 2914 in encrypted combination with an appropriate salt value 2912. This prepared message 2910 may be encrypted using a selected AEAD cipher, which may then additionally generate a MAC value and additional data 2922 as part of the cryptographic process and we may refer to this combined message as AEAD cipher output 2920. This AEAD cipher output 2920 may also be referred to as an encrypted message 2934. The encrypted message 2934 may have associated properties from the scicher process, which may be parameterized using the key/value header method from fig. 28 to generate a header 2932 and this combination may be referred to as scicher encapsulated message 2930. This scipher envelope message 2930 may be the output of the selected scipher transition, which may be stored into the obj pointer or variable 2944 of the NSstr structure 2940, which may be associated with a TAR, referred to as the scipher transition. The NSstr structure will be discussed more fully in a subsequent section. Other attributes 2942 may also be stored in the data storage unit referred to as the NSstr structure, including the TAR, key stack, digest, and/or status flags. The obj pointer or variable 2944 in the NSstr structure 2940 may already be the starting point of the plaintext message 2914, so an iteration path 2950 may be feasible and may exist for the object 2944, since it may handle as many nested encapsulations as required by the TAR, which may itself be stored in the properties 2942 of the NSstr structure 2940.

In the header 2932 of the scipher envelope message 2930, parameters including the description of the symmetric cipher, its mode, and the attribute values used can be completely and exactly described by the keywords listed in fig. 28. In this regard, the TOP approach may not rely on the non-cryptographic process and the obfuscation and hiding of the program for the fixed data, but only on the theory and implementation security of the cipher used as the transitions. This does not seem significant to the initial observation, but such conciseness, which can then show the associated details of data transitions embedded in the output of the transition itself, can ultimately lead itself to novel methods and designs that can rely more on self-describing data than freeing the hardwire program that processes it. This approach can help formulate one of the basic source languages in a data center design and data center model that operate on some of the lowest layers of the data storage science. NUTS may rely heavily on data center design and models, as may be shown in a subsequent section.

FIG. 30 shows a command specification table 3002 for lock transitions and a set of sample transition commands 3010 showing their use. The locked transition is one of the additional transitions as listed in the table in fig. 12, and may be an embodiment of a variable lock from nut, as will be described in detail in fig. 65-77. The mutable lock can exhibit several different methods of cryptographically locking secret messages, including sslock, orllock, matlock, xorlock, and hashlock. A variable lock may be characterized by the input and use of a number of cryptographic keys in the process of encrypting a secret message in a normalized, systematic, and orderly manner. The TOP approach may allow a compact approach to implementing this lock technique in a simple and convenient manner. In the example of portion 3010, the transition command "lockorlock 128 numkeys" 10 scipherkeyen "128" may take as input a string of byte data and up to ten 128 bits of the same symmetric key, encrypt the input string using the "scipheres aes 128 mode" transition command, and generate an output string comprising ciphertext and associated embedded attributes. The transition command "lock matched 256numkeys 5" may take a string of byte data and five 256-bit symmetric keys as inputs, iteratively encrypt the input string for each key using the "clipher aes256 mode" transition command, and generate an output string comprising ciphertext and associated embedded attributes. The transition command "lock sslock 256numkeys 4 threshold 2" may take a string of byte data and at least two 256-bit tins 256 secret shared keys as inputs, encrypt the input string using an implementation of Shamir's private sharing method with provisioned secret sharing, and generate an output string that includes ciphertext and associated embedded attributes. The transition command "lock sslock _ b 256numkeys 6 threshold 3" may take a string of byte data and at least three 256-bit tinesid 128 secret sharing keys as inputs, encrypt the input string using an implementation of the Shamir secret sharing method with supplied secret sharing, and generate an output string that includes ciphertext and associated embedded attributes. The transition command "lock xorlock 128 numkeys" 6 "may take a string of bytes of data and six 128-bit symmetric keys as inputs, derive a computed key by iteratively performing XOR operations on the supplied key, encrypt the input string using the" clipher aes 128mode "transition command, and generate an output string that includes ciphertext and associated embedded attributes. The transition command "lock hashlock 192 numkeys" 7 "may take a string of bytes and seven 192-bit symmetric keys as inputs, derive a computed key by performing a hash on an ordered concatenation of supplied keys, encrypt the input string using the" clipher aes 192mode "eax transition command, and generate an output string comprising ciphertext and associated embedded attributes.

The various variable lock type descriptions and modes of operation may be found in the subsequent sections on the variable lock beginning with FIG. 60. TOP analysis and methods may allow complex iterative lock changes potentially utilizing multiple cryptographic keys to be accomplished in a straightforward logical manner and may allow easy expansion of different types of future lock algorithms. Furthermore, key management aspects of the SDFT may be subsequently exposed that may allow programmers to generate and manage such multiple cryptographic keys with relative ease.

As presented in fig. 12, 13, and 14, TOP analysis and methods may allow one of ordinary skill in the art to do a given data manipulation function and determine its applicability to normalization into transition operations and types. The table in fig. 12 may show sampling of very well known data manipulations and may be considered quite well enough for a wide range of developers to use. However, in such a case where the data manipulation functions cannot be found in this table, the functions can be analyzed and customized to operate within the SDFT architecture using the TOP approach; functions such as, but not limited to, lossy compression, bit scattering, message scattering, erasure coding (ECC), and message-level RAID coding and structuring. In most cases of these transition extensions, it is not necessary to re-encode or rewrite the actual data manipulation functions. In fact, in most cases, doing so can be counterproductive and programmatically weak. The library containing the data manipulation functions may be accessed by the transformation library and the TOP approach may allow developers to provide normalized wrapping functions around particular data manipulation functions to perform well within the SDFT architecture.

Transition structure, Transition Audit Record (TAR) and Structured Data Folding (SDFT) Using transitions

Fig. 31 shows specifications of various transition structures in a table format. The structure is defined by a method based on nested keys, which is similar to how the structure is defined in Javascript; this may be a deliberate design choice so that its representation can be easily replicated in a variety of programming languages and may not rely on the uniqueness of a particular language. For example, Python v3.6 allows a classification to be defined while some languages such as Javascript may not, and thus the transition data structure may not rely on a classification to define it with broader applicability. The transition structure may provide a well-defined working memory area, whereby the inputs and outputs of the transition may be prepared, processed and/or stored. The primary data storage cell or structure that may be used in most, but not all, of the transition operations is referred to as NSstr structure 3108. There may be at least one instance of the NSstr associated with the transition call. All transition structures may have a "typ" or structure type field that specifies what structure they represent. The 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 hold a single value or it may be a pointer to another memory region. The obj field may be the location where most of the transformed input data can be found. Also, the obj field may be the location where most of the transformed output data can be found. The "digest" field (if present) may store a digest of the data stored or referred to by the obj field. The manner in which the digest may have been generated in this manner may depend on the particular dign transition or digest transition and the parameters and/or attributes supplied to the transition command. The "key stack" (if present) may be a single instance of a KISS (key interchange specification structure, discussed in a subsequent section) structure or it may be a list of KISS structures in a predetermined order corresponding to their operating TAR. The key stack essentially holds the various types of keys that may be required for certain transitions. The "tar" field may point to an instance of the NStar structure 3106.

NStar structure 3106 may specify a particular Transition Audit Record (TAR) that may be applied to the input data stored in the obj field of the nstr structure. The TAR may be a logically sequential set of transition commands that may have been insightfully sequenced to process data in NSstr in an ordered and well behaved manner to produce a single "fold" of NSstr data. We may refer to this process of performing TAR on an NSstr data structure as a "spelled" function call. Conversely, a "tear down" function call may "unfold" folded data pieces within the NSstr structure using the same TAR, relying on the inherent properties of a reversible transition. Thus, the reversibility of the transition may become a central feature in Structured Data Folding (SDFT) that exploits the transition. The SDFT method may use TAR on NSstr structures to iteratively transform objects as within an assembly line operation on data. Since the analysis of the reversible behavior of each transition command in the TAR may have been completed, any TAR may be invoked in reverse mode or in a tear down function call. This topic can be discussed more deeply as additional necessary ingredients that can make such operations feasible can be presented in the following sections.

The NSbin structure 3102 may be used for specific functions that may or may not only relate to Python v 3.6. In Python v3.6, a distinction can be made in such a way that strings of data can be stored internally. Which may be stored as a "byte" string or a string of characters. The byte string data type may indicate that the information held within the variable may be a series of binary byte data. A string of characters may indicate that the information held within the variables may be a series of bits representing characters encoded in some type of encoding scheme. Python v3.6 may employ a complex internal management scheme to optimally determine how to store a particular string of characters, since different encodings may require different storage requirements for each "character". Examples may be that UTF-8 may use 8-bit length coding units to represent each character, while UTF-16 may use 16-bit length coding units to represent each character; such variations may be necessary to convey different sets of international characters, where the number of characters in a language may be quite different from the english alphabet and thus may not fit into an arrangement of 8 data bits. The preferred internal serialization method for transitions, TARs, and SDFTs may be JSON and JSON may not have native support for mapping Python "byte" data types to one of itself. If a translation is attempted, the JSON function call may suddenly fail, with some indication that a particular data type may not be supported. The NSbin structure may be specifically designed for this type of situation and may replace any "byte" string of data and thus may make the Python variable JSON compatible. The "bytes" string may be encoded as a base64 string and stored in the "b 64" field of the NSbin structure. The byte string variable may now 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 the NSbin structure is fully compatible with JSON and can now be safely serialized using the JSON function without errors due to incompatible data types.

In the TOP method, this "byte" data for NSbin structure transitions and replacements may be referred to as "information syndrome" transitions from FIGS. 12 and 33. In Python v3.6, the information syndrome transition as listed in table 3302 may take any valid Python structure or variable and iteratively convert each byte string into an equivalent NSbin structure, which may result in a Python structure lacking any byte data type. One of ordinary skill in the art can customize an appropriate syndrome transition for languages other than Python v3.6 and its JSON function calls to remove such sources of data serialization errors. The reverse mode of "information levet" may be referred to as "de-information levet" (decompression) and may iteratively undo and replace so that the data structure containing its original data type may be recovered.

NSjson structure 3104 may be used for a particularly useful function that only holds data that is fully compatible with JSON. Quick browsing of fields defined for NSstr 3108 can alert us of a potential problem with JSON serialized direct commit structures due to digest fields that potentially hold digest values of the source of byte data strings in binary string form or Python v 3.6. We refer back to fig. 12 and reintroduce the "mobilus" transition for this particular problem. It should be noted that any reasonable definition of a mobilus transition prior to this point in this description may not be fully apparent to the reader due to the interleaved nature of the transition and the TOP approach. The mobilus transformation in fig. 32 can transform a given structure from one form to another in a circular fashion but with slight distortion as in a mobilus band. The mobilus transformation can be an important implementer of structured data folding with transformations by systematically transforming NSstr structures into JSON serializable structures (such as NSjson); the process of transformation may embed the operation TAR for the NSstr ensemble along with the transformed data, so that the resulting storable object has a self-describing property. The mobilus transformation may be an embodiment of the essence of performing structured data folding in an SDFT library in a convenient manner. The developer may choose to manually execute the SDF using a logical combination of transition commands other than the mobilus command, but the mobilus command adds at least one additional logical step that may require the developer to perform this step outside the SDFT library: the ability to serialize the NSstr data structure it is operating on into another structure, "such as NSjson. The mobilus transition may be the last transition in the TAR. This may be the only logical location where a mobius transition may be placed due to its function. When processing a mobius transition, it may take the NSstr structure it may be operating on and convert it to an NSjson structure. TARs embedded in the NSstr structure may no longer exist in a useful or accessible form, so the mobilus transition may be the last transition command for a given TAR to be processed. Briefly, a mobius transition may enlist NSstr structures, serialize their JSON, then store them in NSjson structures, which may be stored, transmitted, JSON serialized, collapsed, or any other valid data operation that may be performed on such structures. There may be a reverse mode of the mobius transition, but observing this transition in another way may state that it is a circular transition: whether in forward or reverse mode, it performs a particular data transition depending on the input data structure type. Table 3204 indicates the NSx structure, whose NSjson may be a variable. If in the future the demand for additional transition structures other than the one defined in fig. 31 increases and they may need to be accommodated into the mobilus transition, this table illustrates how the mobilus transition may behave for any transition structure other than NSstr. It may not be fully apparent without actually using SDFT programming, but the mobilus transition may logically imply that there is no likely TAR processing from a restored NSjson structure unless it can be manipulated to convert it to its original NSstr structure, which may retain TAR that may have folded it. To initialize this mobilus spin loop using the NSjson structure, a mobilus function call from the SDFT library may be used to recoil start the mobilus (reverse) to generate the NSstr structure, access the embedded TAR, and reverse process the embedded TAR. This may further imply that the mobilus transition command in the TAR (which by definition will be the first command to be processed in reverse mode) may be safely ignored during processing, as it may have been executed by a recoil start function call so that it may perform the mobilus function no more than once during such reverse. In this sequencing, the inability to ignore the mobilus transition in reverse mode can potentially produce infinite oscillations of the mobilus call, which can constantly convert NSstr to NSjson and vice versa. It appears to be a circuitous way of expressing such operations, but it can produce fairly compact bidirectional TARs that can be systematically embedded in the output transformed data, giving the folded data a self-describing property. This feature may be novel in that it may act to perform operations on data in a consistently reproducible manner across any language and/or operating system that may support implementation of an SDFT library as on interpreted scripts, but in forward or reverse mode.

FIG. 33 shows command specification tables 3302, 3304 for information gathering transitions, clear transitions, and key transitions and a set of sample transition commands 3310 showing their use. The cleanup transition may be a housekeeping function that removes temporary or interim fields from within the NSstr structure. Some transitions may have a need for additional temporary fields during processing and additional fields may be generated within the NSstr structure to store and access them, among other things. The generation and use of these temporary fields within NSstr can be accomplished in a deliberate manner after analyzing their coexistence within the TOP method and minimizing their interference with the proper functioning of any other transitions. The clear transition may not have a reverse mode due to its function, so it can be safely ignored. This reverse implication may be taken into account when proposing a new transient field within the NSstr structure, which may not be present in reverse mode processing of the transition, so the transition in reverse may not be made to function properly depending on its presence. An important function of clearing transitions may be to delete an internal copy of the complete key stack used in the processing of TARs; or it may simply delete the keys within the key stack and convert the KISS structure to a key-hole. This may be one of the most critical transitions in SDFT TAR processing, as failure to properly clear NSstr before it is prepared for storage may result in the storage of any and all cryptographic keys that may have been used in a particular TAR processing and which may be inadvertently stored in plaintext and folded data. This case may reveal (reveal ) the secret key and crack some or all of the encrypted data within the folded data; this may not be the intended purpose of encrypting the data.

In table 3304, the key transitions are shown with some operations of their operation. This transition may be part of the key management function of the SDFT and may operate primarily on the key stack field by referring to the tar field of the NSstr structure. The keyschek transition may test the stored TAR and may generate a key template list. If a key stack is input, it may be compared to the key templates to determine if the correct key type in the proper sequence has been provided in the input key stack. For example, if a TAR requires two different 256-bit symmetric keys for two key transitions that may require a key, it may generate two key templates of "symmetric 256" in a list, indicating that the TAR expects the key stack to contain such keys (if available). Table 3504 lists some of the various key types. An empty key stack or partially filled input key stack may also be processed as appropriate. When the key stack may not be entered (where the TAR requires some keys), it may indicate a "key generation" transition. SDFT may participate in a key generation mode whereby an appropriate key type according to a derived key template may be generated and composed into a key stack for submission into the operation NSstr structure prior to TAR processing on data stored in the obj field. A partial "key generation" mode may be engaged when a partially populated key stack may be input. Key checking and production transitions may cooperatively determine whether a partial provisioning key in a key stack may be of the appropriate type and in the appropriate sequence. It may then proceed to generate the appropriate keys for the missing keys. This procedure may be referred to as the "missing teeth" case of SDFT key stack management. There may be very few any instances of a TAR with a key-change command, as it may be considered so basic for proper operation of the SDFT library on the NSstr structure that utilizes the TAR, which may be implicitly performed by a preset in each call to spell/disassemble the operation rather than having the programmer place it in each TAR. It may prove sufficient to cause consistent, implicit, and/or automatic checking for proper key stack management by simply having the possibility to handle TARs, which may require cryptographic keys. The TAR reverse process may process the key stack in an appropriate reverse order. Complexity may rise due to the uniqueness of the derived transitions in the key stack pattern, which will be discussed in a subsequent section regarding how SDFT handles such conditions called TAR packets for dependent transitions.

Fig. 34 shows a table of key exchange specification structures or KISS. This structure can have at least two modes of operation: a key or a key hole. The attributes of a key may be specified by some or all of the fields defined in the table and additional fields may be added to extend the structure to support other key attributes as desired. The TOP method of a cryptographic operation may be the view that validating each cryptographic transition requires a matching key-hole that specifies the exact key type required for the transition. Attributes may include, but are not limited to, the actual unique ID for the key itself, a challenge or hint for a passphrase or passcode, a key description, and so forth. If there can be a key value in the KISS structure, it can simply be referred to as a key. If a key value can be missing in the KISS structure, it can be referred to as a key hole. This may be indicated by a value in the "ima" field. The domain name may be an abbreviation for "i am a" key/keyway and may be read in this manner for simplicity. The column entitled "In" may indicate the desired value for generating a blank KISS structure and inserting a key into it (for the purpose of placing it In the input key stack of the NSstr structure). The column entitled "Gen" may indicate fields that may be automatically generated and populated during key generation transitions from within the SDFT library. Throughout the SDFT discussion relating to TAR, all key references may be synonymous with the appropriate type of KISS structure. It may be apparent that this approach of the key stack may closely correspond to the characteristics of the TAR being processed and the stack transition command and stack the necessary cryptographic keys and sequences in a particular form may allow any input data to be processed iteratively through an infinite number of transition changes, transition parameter changes, and/or successive data folding. At this point in the TOP description, we may begin to understand the interleaved nature of the various components of the SDFT and may not reveal a complete understanding of any particular section in a completely linear fashion.

Fig. 35 shows a table 3502 of KISS modes of operation, a matrix 3504 showing key type/field generation mappings, and a key type definition 3506. Table 3506 lists several key types recognized by the SDFT, but may not be limited to such types, as new key types may be added and integrated as desired. At least three key types may require some explanation as these may be specifically structured for the SDFT library using well-known base key types. The key type "symmetriclist" may be an array or list of symmetric keys and may be stored as a key value within a single KISS structure. This key type may support such transitions as, but not limited to, locking and derivation. The secret sharing lock transitions referred to as sslock and sslock _ b may represent two different implementations of the Shamir secret sharing algorithm, respectively. Lock sslock transition may expect secret sharing in a particular format (including internal index numbers) and key sharing of 256-bit long keys. This may be referred to as a "ties 256" key type within the SDFT library. Lock sslock _ b converts secret sharing and key sharing of 256-bit long keys that may be expected in a particular format, including an internal index number. This may be referred to as a "tinesidx 256" key type within the SDFT library.

Table 3502 is a matrix that shows what features can be applied to the KISS structure in two modes (key (or transition) or keyhole) in which the KISS structure can exist. In transition (key) mode, the KISS structure may expect to store the actual cryptogra phic key to generate a version of the cipher text, which may include an encrypted digest and/or dign. Thus, its storage can be used on information but requires further embedding using encryption functions to permanently store it in a fixed manner. In a keyhole mode, the KISS structure may be expected to have sufficient detail to accept the appropriate cryptographic key as its value to produce a version of the ciphertext, which may include an encrypted digest, a dign, and/or a derived key. Thus, its storage may be mandatory and may not need to be further fixed by any embedding method, as it may not contain a key value as a cryptographic key hole.

Table 3504 is a matrix that shows which fields can be mandatory, related, entered and/or generated by a key type. After testing the table, it may be apparent that the KISS structure may maintain salt for various cryptographic operations. This appears redundant from the discussion of the scipher embedded header but the salt discussion may not present the entire image of salt. As shown in fig. 37, the persistence of the attributes 3704, 3714 associated with the transitions may be dispersed across several data storage areas 3732, 3734, 3736, and 3738. The TOP method may have shown that salt may be embedded in certain cryptographic operations along with the resulting output data, as it may not reveal additional information about the generated cipher text. However, when we test key derivation transitions processed in the key stack schema, we may find it convenient and logical to store the associated salt value in the KISS structure. A typical method of using a key derivation function may be to accept a passphrase as input, combine it with some salt value and generate a properly formed cryptographic key, such as (but not limited to) a symmetric key. In this case, the use of salt may be for semantic security. Thus, it is entirely possible that each cryptographic keyway that accepts the same passphrase may have a different salt, so that the resulting secret cryptographic keys may be different from each other, no matter what reasonable reason may exist. This derived key can be used in a temporary manner and discarded after use, thereby leaving only the key hole as proof of its presence. Since it is generally not possible to permanently preserve the key-derived product (because it can be used as a secret key), it can request a challenge: where can we store it? TOP may store it in the corresponding keyhole and may prefer SDFT to store this keyhole along with the folded data, so each keyhole that can accept the same passphrase may have its own instance of storage for the salt value. The programmer can store the key well of the KISS in an external manner in a completely different way. The simplified transition diagram on TOP of fig. 37 (which is identical to fig. 5) becomes more like the diagram on the bottom of fig. 37 when the various components of TOP and SDFT can be introduced. Table 3720 summarizes the setting of the attributes.

Much has been previously described with respect to syntax and various transition commands available via TOP and SDFT analysis, but what does the TAR actually look like in practice? FIG. 36 shows the structure of the TAR and lists several examples of TARs. Section 3602 specifies the general structure of the transformation audit record or TAR. The "TAR label 01" announcement indicates the name or label of the defined TAR directly below it. All TAR commands follow the TAR tag announcement and a blank row indicates the end of the current TAR definition. Thus, many TARs may be announced in a single text file. The TAR definition section may contain a TAR tag or transition command that is itself online. This may be similar to the macro features of a programming language compiler; it can be used as a convenient feature to combine well-known TAR constructs into a new TAR without actually duplicating the definition into the TAR itself. The transition command may be inserted into a particular sequence to process the target NSstr structure in a desired manner. TAR "test _ a 01" may only solicit Python data object information as an equivalent structure that lacks any Python byte data type; for other languages, the same function may or may not be performed, as the "information solicitation" may be language and/or environment specific. TAR "test _ a 02" performs the information gathering transition twice in succession. The second information symptom transition may not complete a functional change to the data. This shows the TAR extension at work. TAR "test _ a 07" performs information gathering on the data, serializes it into a JSON string, and then converts it into a byte-type binary string using utf _32 encoding. TAR "test _ a 17" shows how a terminating mobius transition may look. TAR "test _ a 20" performs a syndrome on data, serializes it into a JSON string, converts it into an utf _8 encoded binary string, encrypts it using chacha20 with a 256-bit symmetric key, and then converts the resulting binary string into a base64 encoded string. Symmetric keys for scipher transitions may be expected in a key stack containing NSstr that holds a single KISS structure of 256-bit symmetric key values. An alternative may be to not provide a key stack and the piecing function continues to generate a valid key stack with an appropriately generated random 256-bit symmetric key, use it to perform a scipher transformation and allow the programmer to fetch a copy of the key stack (and thus the keys within it) after completion. TAR "test _ a 42" shows an example of a TAR group and a dependent transition: it performs information gathering on the data, serializes into a JSON string, converts it into a binary string encoded in utf _8, derives a 256-bit symmetric key from the passphrase supplied in the key stack, and then performs chacha20 encryption on the data using the derived symmetric key. The last two transitions may have permanent dependencies because the password relies on a derived key; thus, this dependency may be grouped within the TAR as a leader < tag > with such a tag. In forward mode, there is no significant impact on the TAR groupings within the TAR definition, except that these dependencies are highlighted visually. However, the TAR group may play an important role in relation to TAR reversal. When preparing a TAR for a TAR reversal process, the TAR group may remain intact as a unit and its components may not be reversed. Fig. 41 and 42 show several examples of TAR inversion. TAR "test _ a 64" may perform five scipher transitions and a DSS dign transition. This TAR may desire a key stack that is populated with six keys of various types and lengths in a particular order. A simplified representation of a key template that may correspond to TAR "test _ a 64" is depicted in section 3610. This key template may be used by the inclusive key check and/or generate transitions to authenticate any input key stack and/or generate a valid key stack for proper processing of the TAR.

FIG. 38 shows a block diagram of SDFT operation with stitching and unstitching (or vice versa). Two central operations in the SDFT may be "piecing" and its reverse "disassembling". The stitching operation may handle a given NSstr, which may include some or all of the following: data, TAR, key stack, and/or other attributes. The spelling operation may "spell" or fold the source data within 38103802 according to the transition sequence listed in the TAR within 3802 and may ultimately produce the output as a NSstr structure 3804 or a component within NSjson structure 3806. The unpack operation may "unpack" or unwind 3820 the source NSstr 3804 or NSjson 3806 structure and may ultimately produce the output as an NSstr structure 3802 according to the reverse transition sequence listed in the embedded TAR. As will be shown, the symmetry of the piecing/unzipping may be an interesting aspect of this design. Note the consistency of terminology and viewing angle that may be used throughout TOP. The reverse splicing operation may be equivalent to disassembly. This reversibility principle may not only simplify the analysis of such functions, but it may filter modular organizational methods that may lead to higher-order concepts regarding data transitions.

FIG. 39 shows a flow diagram of an SDFT stitching operation. Given the NSx structure, a spelling function or method call may perform the following operations on the data therein using the parameters provided with the call and/or the TAR embedded within the NSx, where in this case, "x" represents any transition structure. Similar to the key check/generation transition, the mobilus transition may be considered as being so basic for this algorithm, which may be implicitly performed on any input data structure when condition 3906 is satisfied. A splice may perform its core operations properly only on NSstr structures, so if NSx structures can be passed instead of NSstr, it may attempt to convert NSstr structures 3918. Failure to generate a valid NSstr 3924 generates an appropriate error code 3978 and terminates the process 3984. There may be at least three different ways to piece together or fold the data within: first, a TAR may be contained within the valid NSstr indicating the sequence of performing the transition on the data within the NSstr structure; second, the name of the TAR tag may be passed as a parameter into the spelling call, thereby indicating a preferred set of transitions to perform on the data within the NSstr structure; again, the customized TAR list may be passed as a parameter along with its given name in the spell call, thereby indicating a preferred set of transitions to perform on the data within the NSstr structure. Preparation of the TAR 3912 may include extending other TAR tags to refer to and/or sort them appropriately for traversal patterns that may be forward or reverse. Fig. 41 and 42 show several examples of TAR inversion. Then, key check transitions can be performed efficiently on the TAR and NSstr structures. The component of the key check transition may be to derive the key template manifest 3930 by testing the TAR. Where a TAR, an input key stack (which may be empty or partially occupied), and/or a key template are used, the program may compose a key stack for the appropriate traversal of TAR 3936. This may include generating the correct type of missing keys, sequencing the keys in the appropriate order, and/or checking the input keys for the appropriate structure and type. Any mismatch in the input key type and corresponding derivative key template may generate an error condition 3942 that results in the generation of an appropriate error code 3978 and a sudden termination of procedure 3984. The program may now iterate through the various transition commands in the TAR in the appropriate sequence 3948 and perform the specified transitions 3954 on the data contained within the NSstr. Any errors 3960 encountered during execution of the transition command may generate an appropriate error code 3978 and abruptly terminate the process 3984. When the end of the 3948TAR sequence is reached without an error, then the stitching operation may be considered successful 3966 and the program may gracefully exit 3972.

FIG. 40 shows a flow chart of an SDFT teardown operation. We can illustrate the symmetry of the reversibility of the transition by comparing the flow charts in fig. 39 and fig. 40, rather than specifying the disassembly procedure in detail. The only difference between the two flow charts may be the TAR preparation steps 3912 and 4012. Since each transition may have been analyzed and structured using TOP to perform in a bi-directional manner in a well-behaved manner, the defragmentation process may not need to be very different from the stitching process except for how TAR may be present. It may be implemented as the same code but with a slight bias when a reverse flag may be indicated and perform the appropriate reverse sequencing of TARs when such is encountered. This call in Python v3.6 may take the form of "obj. Symmetry may allow the actual implementation code to become smaller and/or may present a smaller chance of programming errors. A conceptual benefit may be the simplicity and clarity of idea in constructing a new TAR for a particular purpose: the programmer may rely on an appropriate TAR sequence to be fully reversible within its limits and may not need to consider this part of the application too much. One benefit may be that the workload of a programmer to generate a particular set of data transitions may be effectively reduced by at least half, as it may no longer be necessary to generate the inverse code for such data manipulations. The establishment of complex encryption and locking mechanisms may require a significant number of data manipulations with a large number of cryptographic keys. The Transition Organizational Principle (TOP) approach may help achieve a more integrated and holistic approach that handles this complexity in a discrete, less error prone manner; thus, it may allow, but may not be limited to, more consistent, reliable, secure, portable, understandable, extensive, flexible, extensible, and/or complex encoding and/or data.

FIG. 43 shows a transition table that is mapped to a key type template that it may generate or require during TAR processing. Referring back to the discussion of key management, one of the primary operations of key management may be to analyze a given TAR and generate a corresponding list of key type templates, which may detail the types and specifications of each key that may be necessary in the successful processing of the given TAR. Table 3506 lists at least nine of the key types defined within the SDFT. Table 4300 shows an image of each transformation operation that may require a key and its corresponding key type or "keyyp" that may be required when performing a spelling/dismantling procedure. The key template may have several attributes associated with each key type, such as, but not limited to, key length or "keylen". For simplicity and simplicity of illustration, we can indicate a 256-bit long symmetric key as having a key template that can be expressed as "symmetric keylen ═ 256" or "symmetric 256," but in actual implementations any available data structure mechanism in the programming language can be utilized to store this equivalent value in an organized manner. In Python v3.6, possible structures for a key template may be represented by an array of dictionaries, where each dictionary entry in the array stores a single key template having properties corresponding to the dictionary key and property values corresponding to the values associated with that key in the dictionary. Within an SDFT, all key templates may be temporary structures and may undergo repeated regeneration via key check transitions and it may not be necessary to permanently store such key templates. In this way, the SDFT may properly analyze any keys inserted into the key stack for processing before failing the cryptogra phic transition entirely due to key type/structure incompatibility. A general theme in TOP and SDFT may be the following: confusion of data manipulation sequences may not ensure reliable components in any sensitive payload but may be attributed to the strength of the selected cipher and its operational attributes and/or characteristics.

FIG. 44 shows TAR examples and key templates generated by the examples. The left column in table 4402 lists TAR example "a". The right column indicates a key type template generated for each transition command that may require a cryptographic key as an attribute input. In this example, TAR "a" may require two cryptographic keys in the indicated sequence. The left column in table 4404 lists TAR example "B". The right column indicates the key type template generated for each transition command that requires the cryptogra phic key as input. In this example, TAR "B" may require four cryptographic keys in the indicated sequence. This process can be thought of as key template generation from the TAR.

FIG. 45 shows TAR examples and key templates generated by each example and an expected list of KISS structures to be input (put) or generated (gen). The KISS list is also referred to as a key stack. We can take the two examples from fig. 44 and show the next step in the key management aspect of a spelling/un-spelling call. A key stack may be expected or generated in the form of a list of KISS structures corresponding to each key type template as shown by 4510. When the TAR "a" process obtains the "scipher salsa 20256" transition command, the process may expect to find an input 256-bit long symmetric key in the key stack as indicated by KISS a 1. When the TAR "a" process gets a "dign dss 1024 digestlen ═ 512" transition command, the process may expect to find an input 1024-bit dsa key in the key stack as indicated by KISS a 2. The KISS list of TAR "B" can be read and understood in a similar manner. If this desired key cannot be found in the key stack, the TAR process may desire to instead find a generated key. This inclusive key generation may be beneficial to the programmer because the only requirement to generate any type of acceptable key for a given cryptographic transition is to be able to announce it within the TAR. No additional steps may be required to generate a particular key for a particular cryptographic function. Calling a spelling using the empty key stack may result in the output NSstr structure maintaining a fully compliant key stack with the appropriate generated key to match the TAR and be able to fold the data therein. It is strongly recommended and suggested that this key stack consisting of the KISS structure may then be stored separately from the folded data in a secure manner and/or that it may be further modified in some way and folded again and fixed using TAR, thus further encrypting it using cryptographic transformations. Repeated encryption and encapsulation of the key stack may be useful when processing many cryptographic keys to be managed and protected. TAR "B" may generate a key stack of four KISS's and it may facilitate the secure storage of the entire key stack to a key repository; however, a programmer may wish to encrypt a four-key stack using a single key for convenience. This can be done by the following steps: generating a new NSstr; inserting a four-key stack into the data obj field; picking up an appropriate cryptogra phic TAR; and executing a spell call to the NSstr structure. This series of steps may result in a key stack with a single KISS structure containing keys locked to a folded NSstr structure holding a four-key stack.

FIG. 46 shows three modes of key stack operation within the SDFT TAR process: generate (gen), input (put), and inject (mixed). Section 4600 depicts what may happen when the key stack 4602 is empty in the processing of TAR instance "B". The spelling program may take the key type template of TAR "B" 4508 and generate 4606 an appropriate number of randomly generated cryptographic keys of the same type and in the same order as found in the key type template as shown in 4604. Section 4610 shows what may happen when the key stack 4612 is the input (put)4616 in the process to TAR instance "B". The stitching process may take a key type template of TAR "B" 4508 and check it against the provided key stack 4612 to verify the number, type, and ordering of keys, and then it may allow it to be used during processing of TAR "B" as shown in 4614. Section 4620 depicts what may happen when the key stack 4622 is presented into TAR instance "B," where only one key KISS B3 or also referred to as a partially populated key stack or "missing teeth" case is provided. The stitching process may take a key type template of TAR "B" 4508 and check it against the provided key stack 4622 to verify the number, type, and ordering of keys. During repeated authentications of key stack entries by each key type template, any empty KISS structure may be considered a particular type of authentication failure and may be further interpreted as an implied key generation transition for that key type template. The stitching process may then inject 4626 the appropriate type of newly generated key into the empty location of the key stack and continue with the key verification iteration. After this step is completed, the hybrid key stack (which may be referred to as a mixture of input and generated keys, an edentulous case, or key injection) may be presented and used during the processing of TAR "B" as shown in 4624.

FIG. 47 shows a diagram of how the key stack is generated and used in the lifecycle of the data and its TARs. The use of SDFT on data 4700 may allow it to iteratively transition in an orderly fashion according to a set of variable transitions as defined by a particular TAR 4702. The TAR may be structured so as to allow cryptographic compilation of key types and thus generation of a key template detailing the number and types of keys required by the TAR. Then, whether all or some of the necessary keys may be present or no necessary keys are present, a key template may be referred to in the composition 4704 of the input key stack. When a desired cryptographic key may be missing, the composition process may generate a new key for use. The TAR, data, and key stack may then pass into the spell call 4706 to perform the folding of the structured data according to the TAR. The folded data may then be stored 4708 by any method. The keys in the key stack may be stored 4710 in a separate secure location. When it is desired to refer to the collapsed data, the application may retrieve the data from its storage location 4712, retrieve the key or key stack from its secure storage 4714, pass the collapsed data and key stack into a tear down call 4716, and access the data in its original form from the tear down output structure 4702. This may indicate one complete cycle of structured data folding with transitions. There may be many other paths to transform and collapse any data structure, but in essence some form of such a loop may have to be completed in order to fully retrieve the original data within the SDFT.

Storage 4710 of keys and/or key stacks may involve folding of key stacks utilizing a cryptographic TAR so that they are protected with fewer keys (only one key and/or different keys). The collapsed key stack data may become part of another structure, which may itself eventually be collapsed. The data may be iteratively collapsed in a cascaded manner to build an internal data structure, where the exact progressive collapse may result in an exact progressive encryption. This ability to direct complex cryptogra phic data transitions in an accurate, organized, and/or organized manner may result in better and/or simpler designs for sensitive data protection using more complex transition schemes. The clarity and conciseness of TARs may lead to a better understanding of the operations performed by the target data by others.

An important benefit of SDFT may be system handling that combines key management within the context of various cryptographic operations on a given piece of data as in 4704 and 4714. The programmer may be somewhat relieved of the unimportant details of generating the keys and manually manipulating their storage and/or sequencing during such processes. In cryptographic applications, these non-important details can be accumulated quickly to become a huge number of small details or attributes that the application (and hence the programmer) must track, analyze, store, and/or use. The SDFT method may allow a given application to track, analyze, store, and/or use fewer separate attributes of cryptographic functions, as it may allow the attributes to be embedded within the context of the data and/or key stack that it has operated on and generated as output, whereby it may provide pairwise coupling of the collapsed data along with transitions that may have collapsed it. Migration of data manipulation instructions from application to data may allow for simpler applications and/or more sophisticated use applications with cryptographic functionality. SDFT may implement a better alternative to express structured cryptogra phic programming (SCP) methods, as will be discussed in the nut section.

FIG. 48 shows a diagram of operations that may occur on data stored in the NSstr structure. Any data referenced and/or stored by a pointer in a variable 4802 may be encapsulated 4812 directly into the NSstr structure using exemplary methods and/or using method/function calls 4804. Next, the NSstr structure 4810 may optionally encapsulate TAR 4814 and its associated attributes 4816. Attributes may include a key stack, digest, transition parameters, and/or temporary variables. This may provide the minimum set of complete information necessary to process NSstr through SDFT stitching/unraveling operations to perform TAR on the data contained therein using attributes 4810 that may have been provided. In the TOP parlance, we can refer to this as the folding of the data. The output of the SDFT may return to the same NSstr structure 4810 or NSx structure (such as NSjson). This output may then be stored 4820 in some persistent and accessible manner, transmitted to another computing device using an inter-program communication (IPC) method 4840, and/or stored 4830 in another internal data structure. The loop may be restarted for stored data 4820 and 4830 at a subsequent point in the application. For transmitted data 4840, a loop may be initiated by receipt of such a data packet 4800.

FIG. 49 shows a flow diagram for SDFT use of iteratively folded material. The series of simplified diagrams illustrate the system folding of data called by SDFT spelling using N successive data folds. NSstr structure 4900 containing at least data 4902 and TAR 4904 may be folded by calling a splice 4906 to produce output data 4908, output data 4908 may be modified and/or further packaged into NSstr structure 4920 containing at least data 4922 and TAR 4924, NSstr structure 4920 may be folded by calling a splice 4926 to produce output data 4928, output data 4928 may be modified and/or further packaged into NSstr structure 4940 containing at least data 4942 and TAR 4944, NSstr structure 4940 may be folded by calling a splice 4946 to produce output data 4948, output data 4948 may be modified and/or further packaged … … this process may be iterated 4950 as needed. It should be noted that in this series of complex structured data folds, any TAR in any step can be modified separately from the application code by simply modifying the TAR instruction stored in some text file or its equivalent. An equivalent programmatic expression without such iteratively packed SDFT, but with the possibility of a transition sequence and/or parameter variations for the steps, may be relatively long, error prone and/or unintelligible.

FIG. 50 shows a flow chart for iteratively expanding SDFT usage of data. The series of simplified diagrams illustrate the system unrolling of data from an SDFT ripping call using N successive data unrolls. It is the exact inverted column of flow of fig. 49 and thus can be understood as such. As previously shown in fig. 39 and 40, the tear down call may be identical to the spell call, except for the preparation of the TAR and the state of the data fed to it. It should be noted that in this series of complex structured data expansions, there may be no need for an additional reverse TAR in order to achieve the expansion. All necessary TARs required to unwrap each folded data can be found embedded within the folded construct. More sophisticated testing of the NStar structure 3106 reveals an "expd" field, which is defined as a "list of TAR command extensions". This can be a key feature of reversibility in SDFT: the output of TAR preparation steps 3912 and 4012 may generate a complete set of operable transition commands lacking tag references and any other external references, and may be considered as a complete description of the transitions that the transformed data may have undergone. This can be viewed as a static snapshot of the TAR set for the folded data, thereby ensuring that proper unfolding can be performed on the folded data without any changes to the TAR definition in the outer location. It may imply that a TAR definition file may grow a larger number of TAR definitions over time, but the storage of the operating TAR definitions may be saved by the SDFT procedure to preserve their reversibility regardless of changes to such externally defined files (which may not be a recommended practice). This design may facilitate a system-wide approach to handling the temporal compatibility of stored data in a better way.

FIG. 51 shows an illustration of an SDFT API/library and the various types of TAR definition archives that it may access. The TAR definition may exist in many forms such as, but not limited to, a text file, Nut, encrypted file, database, server program, and/or on-the-fly memory. The TAR may be defined at any time by the programmer as a customized TAR definition in the spelling call and thus may be a temporary TAR. For these TAR definitions, which may be permanently stored, the diagram 5100 may depict various forms of these definitions but may not be limited to these shown definitions. Standard TAR 5102 may be a TAR definition that may be provided as a package along with an SDFT library installation for any OS/language pairing. Hidden TAR 5104 may be a TAR definition, which may be a customized TAR definition that may exist only in access-restricted locations and/or by expressed permission to access. These may be preferred methods defined for TAR within a private network or custom application installation. The use of hidden TARs may even remain hidden within the output of a spelling and the extended form of TAR is not found embedded in this folded data but is only referred to by TAR tags. The administrator of such a group may have the obligation to maintain hidden TARs, as data collapsed using hidden TARs may not necessarily contain the set of transitions needed to expand them. Hiding TARs may appear to be similar to an equivalent method of obfuscating data manipulation sequences within a program. The home user TAR 5106 may be a TAR definition, which may be a customized TAR definition that is only accessible under the account privileges of the user or programmer. These may be temporary or developing TARs that the programmer may formulate to be permanently added to one of the TAR definition stores at a later time. The remote TAR 5108 may be a TAR definition that can be accessed with or without permission to access from a remote server or storage site. This topology may be necessary due to limited local storage or due to a policy that centers key TAR definitions into a central management area. This may also be a method that continuously checks whether the standard TAR definition can be the latest version. A protected TAR 5110 may be a TAR definition that may be located in any suitably accessible location but may be encrypted for authorized access only. A separate authentication and/or authorization procedure may need to be successfully traversed in order to gain access to the protected TAR. Another form of protected TAR may be stored in a Nut container, which may require an appropriate key(s) to gain access thereto. The embedded collapsed TAR 5112 may be an extended TAR definition that is retained along with the collapsed data from the spelling call.

FIG. 52 shows an exemplary Python script that performs manual data folding. FIG. 53 shows an example of SDFT defined by TAR and its use in Python scripts. Fig. 52 and 53 may together show an example of how SDFT may differ from a more direct programming approach using pythonv3.6. Such exemplary Python scripts may use methods to draw major differences in the basic sequence of calls for tasks at hand. We can begin with a sample dataset 5210. Operations performed on the data may be specified in task 5220 expressed in plain language as shown in lines 02-06. Typically, for ease of reading, these may be entered into the program itself as headings. Section 5250 shows the actual Python code that executes the task and section 5260 shows the inverse processing of the task of restoring the original data 5210.

In the case of SDFT, data set 5310 is identical to 5210. Section 5320 expresses task 5220 as a TAR definition labeled "test _ a 70". Section 5350 splices the data and writes the folded data to a file. Section 5360 reads the folded data from a file and disassembles it.

There are 18 lines of Pyhton code in fig. 52 and only 8 lines of code in fig. 53. It may be apparent that any change in the type and number of data transitions may affect both of the sections 5250 and 5260. The method described in FIG. 52 requires the programmer to maintain several variables, task sequences, and/or appropriate calls for the functions or methods. The reverse procedure in 5260 requires the programmer to ensure that all operations are called in the correct reverse order and that the parameters are fed in the correct way for each function or method call. Any change in the tasks in 5220 can result in a change in the programming of the sections 5250 and 5260. 5220 any additional tasks may result in additional program lines for sections 5250 and 5260. More temporary variables may be generated and used as needed for these additions or changes to the task.

In the SDFT method in FIG. 53, any changes to the task can be reflected directly in TAR 5320. Thus, any further transition modification may only change the length of this section. The stitching and dismissal call lines 10 and 14 remain unchanged. The reverse process in 5360 of TAR5320 need not be specified to exceed the original TAR definition in 5320. In practice, sections 5350 and 5360 may remain undisturbed for any selected TAR definition other than row 10, with the TAR definition tag specified in the spelling method call.

The reader may prefer TAR5320 over the actual program code in sections 5250 and 5260 in terms of readability and comprehensibility of the tasks performed. 5220 the tasks specified are not coded and can be expressed generally as annotations in Python code. Any changes to the program code in sections 5250 and 5260 must be manually coordinated with the annotations by the programmer or confusion may ensue if another programmer attempts to understand the code with inaccurate annotations and vice versa. TAR5320 can be considered to be self-describing in a clear and compact manner.

The data stored by rows 15-16 in the block 5250 do not have embedded metadata (metadata) describing how it can be transformed. The transition method is hardwired into the actual code in blocks 5250 and 5260. Any such data written in this manner may depend entirely on the presence of the same or similar encoding for its proper retrieval and recovery. These encoded sections or their equivalents must be permanently maintained so that their transformed data is permanently recoverable. This can be equivalent to a hidden TAR approach.

The data stored by row 11 in section 5350 may contain an embedded extension TAR definition, which may have transformed the collapsed data. The transformation method can be paired with the folded data, thereby making it transportable. The recoverability of the folded data can be seen as independent of the encodings 5350 and 5360 from which it was generated. Any encoding of embedded TAR definitions in the folded data can be properly processed to recover the original data. This type of functionality may allow for better time compatibility for changing transition sequences over time, as the old folded data may be self-describing and thus self-specifying how it may be recovered.

Fig. 54 shows a block diagram of dynamic TAR handoff within a single communication session. In the TOP approach, the higher-order communication protocol may be viewed as passing the transformed data from one computational process to another. Since the transition may allow many of the most frequently used cryptographic functions, it may be used to generate secure messages for IPC. In theory, each message can be transformed and collapsed using a different TAR. Each different TAR definition may be viewed as its own protocol by the modern standards of protocol definition. With SDFT, TAR may be dynamically switched between the two applications on a per-collapsed message basis, as shown in fig. 54. Any mixture of TAR sources as shown and described in fig. 51 may be used, as long as each application may have access to these TAR definition sources. The rich set of embedded folded metadata (such as, but not limited to, a KISS structure, such as a keykeyhole specifying an exact key identifier for each key required in an embedded cryptogra phic transition) may allow SDFT-based communication protocols to provide security at a more complex and potentially more secure level.

TOP analysis and methods, which may result in an architecture known as SDFT, may allow stored data to contain its own portable instruction set that may have generated it. This architecture may define a data collapse and may provide the methods and/or embodiments described for collapsing data using a conceptually and logically consistent reversible transition processing method that may be expressed as a Transition Audit Record (TAR) that may be embedded in an organized manner within the stored data. The resulting folded data can then be modified in some manner and can then be repeatedly folded as necessary to achieve the desired application or dataform result. In addition to describing TARs as programming languages, they represent a set of collaborative data manipulations in a concise form that can allow infinite variation in transition sequences and/or infinite variation in transition attributes within a given TAR and/or attribute. SDFT may allow variable dataset categories in a manner similar to programming languages to isolate local variables using category concepts and techniques. Through TOP, protocol changes can be observed in a higher concept construct, which can result in data that can be self-describing and that can be accessed and read from a variety of applications that can access their methods via available SDFT libraries adapted for their programming environment. Furthermore, such features immersed in the collapsed data may allow for dynamic switching of protocols within a single communication session or a single stored data object. The TOP approach can be used as a basic building block for the Nut ecosystem and in Nut's composition. Nut may be fully implemented independently of SDFT but it may be unwise.

NUT ID

The nut design may enable identifiability of data regardless of location. This may require a universal unique ID (uuid) but it cannot be achieved in a guaranteed manner without some form of centralization, so we can choose the concept of an actual unique ID of sufficient length and entropy sensitive nature to provide a low probability of ID collisions. Figure 55 shows a flowchart of an example of a procedure for generating Nut ID 5500. Here, the home device 5502 may run an application that may invoke a function to generate an actual unique ID from a data piece, such as, but not limited to, user attributes 5504, environmental attributes 5506, and/or random attributes 5508. User attributes 5504 may include data items such as, but not limited to, user login information, a group ID, a company ID, a user ID, and/or a user passcode hash. Context attributes 5506 may include data items such as, but not limited to, MAC addresses, IP addresses, device information, system time, OS information, directory paths and/or profiles, atomic clock synchronization time values, GPS synchronization time values, declared context variables, thread IDs, CPU run times, IMEI numbers, telephone numbers, application names, and/or program IDs. Random attribute 5508 may include data items such as, but not limited to, session counters, UUIDs, clock cycle counts, randomly generated numbers, mouse movements, keyboard activity, file system state, partial or full screen region hashes, program uptime, OS uptime, and/or session duration. These data elements may be collected and stored in an ID structure 5510, which may then be serialized using JSON or alternate aggregation techniques. The resulting binary string may then be made a hash 5520 using a hashing algorithm, such as SHA-512 (the SHA-2 series from the hashing algorithm published by NIST in FIPS PUB180-2 in 2001), or an alternative hashing method that may generate practical uniqueness with a suggested minimum length of 512 bits to reduce the chance of ID collisions. For portability and readability, the binary hash may be encoded as a base64 (or alternative encoding scheme) text string 5514, which may produce a text string approximately 86 characters long. The encoding scheme may include any method that results in a printable and human-readable form and that is acceptable as a string of text words by multiple programming languages and software systems. Depending on the modality in which the function may have been called, the resulting encoded hash string may be checked for duplication against any accessible Nut ID cache 5516. If there may be a collision of ID values, the process may be repeated using new random attribute 5508 until a non-colliding ID may be generated; conflicts can be expected as rare events. The output string of this logical operation may be referred to as Nut ID 5518.

This process may be invoked locally within the running program or may be implemented within a locally resident server application or a remote server client application requesting a new Nut ID. A possible benefit of a server model implementation may be its ability to access a larger buffer of existing Nut IDs to check and may generate Nut IDs with a lower probability of collision. Nut ID duplicate checking is not mandatory, as the hash length and properly collected data components in the ID structure 5510 may provide sufficient entropy. There may be general partitioning concepts such as the internet with IPv4/IPv6 addresses, domains, directory hierarchies, and access control groups throughout some or all of the digital infrastructure. In a similar manner, the Nut ID may be virtually unique but it may be used within the context of a compartment constructed by external systems or relationships and thus the chance of collision may be many orders of magnitude less than the mathematical probability provided by the permutation in a given bit length of the Nut ID. In the event that a different length may be desired, this may be accomplished by one of ordinary skill in the art replacing the SHA-512 hash with an alternative hash algorithm in a modular parameterized manner.

What can be identified by considering the process by which the actual unique ID can be generated in the form of Nut ID? In NUTS parlance, this may be referred to as the Nut ID stamp. There may be at least two structures within a Nut that may be consistently stamped with Nut ID: lock node and Nut. The Nut ID assigned to the lock node may be referred to as the lock ID. The Nut ID allocated to Nut may be referred to as Nut ID. The lock node may create a block for Nut internally. The lock node may be a self-contained independent locking mechanism that may protect its payload, referred to as a packet. Nut may be a data structure consisting of one or more lock nodes. Thus, Nut may hold any one or several packets of data in whole or in part. Nut may be used throughout the Nut environment to identify some or all of the associated software, data, and/or hardware represented in binary form in a virtually unique manner. The consequence of the Nut ID stamp may be that each Nut may be uniquely identified, implying that each data packet stored within the Nut may be uniquely identified by the Nut ID regardless of where the Nut may be physically located.

FIG. 56 shows a simplified diagram of the Nut data structure. This figure may highlight the use and relative placement of the lock ID and Nut ID within the Nut data structure. Specific lock IDs 5614-5622 may be allocated in this Nut and they may be different values. The locker nodes 5604 through 5612 may be identified by the locker IDs 5614 through 5622, respectively. In a typical Nut data structure information (such as this example), Nut5602 may be a group of lock nodes organized into a graph data structure called a lock graph. A particular Nut5602 may be identified by its Nut ID5634, Nut ID5634 may be stored in a packet 5626 of a lock node 5606 and Nut ID may be considered the payload of this lock node, which may be different from the payload of Nut that may be stored in one or more of the other lock node packets. Each locker node 5604-5612 structure may contain a payload region referred to as a packet 5624-5632. This shows the relationship between Nut and its Nut ID and where we can find these items stored in a typical Nut container.

Fig. 57 shows an example of a relationship between Nut IDs, path names, and/or payload data. There may be several lock nodes in Nut that may be used to store metadata for Nut, metadata about Nut payloads, and/or Nut payloads. The metadata portion may be stored in packets for various lock nodes in Nut. 5702 shows a case where there may be two distinct Nut payloads D1 and D2 each stored in distinct nuts identified by NutID a3 and B1, respectively. Two character Nut IDs are used for illustrative purposes even though it may have been previously specified that Nut IDs may be encoded base64 that may produce a 512-bit hash of a string of text that is up to 86 characters long. Nut A3 and B1 also have distinct path names in the NTFS file system. 5704 shows two distinct Nuts with the same file name but different path names. 5706 shows two copies of the same Nut with the same file name in different directories. 5708 shows two copies of a Nut with different filenames in the same directory. This may not be an exhaustive list of some or all permutations of such attributes, but it may show flexibility to have metadata items permanently associated with each payload, such as Nut IDs.

Embedding data within a Nut profile identifiable by an associated Nut ID may lead to a novel feature of this approach: the ability to automatically generate dynamic filenames based on parameterized rules in the metadata. The file name may represent a custom summary of the archive's normal identification string and other attributes thereof, such as, but not limited to, the date and time of the modification and/or the number of writes for that day. This may give a more accurate and convenient way to identify a file and its state in real time without having to drill down on normal hidden properties, such as without having to look at the file properties in a directory browsing application. It may also allow archives and data attributes to be embedded into containers that hold archives rather than relying on the attribute capture capabilities of the file system (which may vary between file systems). Example (c): the user may generate a Nut with Nut ID #234 that may store a text file, which may always be identified by Nut ID #234, but the user may set up a dynamic file name such as "diameter _20151115_1. txt" that includes a base name + last modified date + number of writes for that day. On the same day, when the user saved to disk after slight modification, the filename may show "direct _20151115_2. txt" and the old filename may no longer exist in the directory. The method may automatically generate a new file name that may indicate some status information of the stored data. The nature of the NutID, which may be effectively unique and may be separate from the pathname + filename designation, may allow this feature to be implemented without any external reference. One of the benefits of this feature may be the common method of copying and saving the previous state of a work file with a date stamp. The author may find a catalog that fills up his or her daily work on his or her documents. In the case of using the dynamic filename method, it may have only one Nut file in its directory that contains the last written date stamp. The history (state) of the aspect of the manual method is kept within Nut itself using Nut history features presented in a subsequent section. This concept of Nut ID being the primary content identification can then be used by Nut servers to perform copy and sync operations on the scattered Nut.

Lock map and lock node

Nut techniques may address storage, protection, and access control of data in a hierarchical, integrated, modular, and/or iterative approach that may be defined as structured cryptogra phic programming (SCP). The overall design of a Nut internal component can be described and defined and then the defined structures can be described in detail later. Some features may be described in a hierarchical manner and an overall description may then be provided to show how the individual features may work together. SDFT may be utilized throughout the nut design to improve the organization of complex cryptographic structures and the system embedding of attributes associated with each folded data structure. It can be shown in various embodiments how SDFT enables SCP design to be implemented relatively easily (compared to an equivalent manual approach).

There may be four different ways that the access of Nut can be controlled: a key fob, a variable lock, a hierarchical access control (SAC), and/or a Nut Access Control (NAC). Some or all of these methods may be partially or completely layered and/or integrated together in a novel manner within Nut, which may provide the complete functionality of a reference monitoring system in an internal and/or independent manner. These four layers may be embodied in a complex data structure called a lock node, which may be designed to be modular, stand alone, and/or linkable.

A keyway may be a data structure that can accept any number of cryptographic keys, each of which may have an associated encrypted key image. Embodiments are not limited to the type of cryptographic key that it can currently recognize and accept: a passphrase, a symmetric key, and an asymmetric key pair. Any simple or complex method or any process by which a bit sequence can be specified as a secret key can be integrated as a cryptographic keyway. The encrypted key map may contain several sets of keys, each set for each layer of access control within Nut: variable locks, SAC and/or NAC.

The variable lock may provide different types of locking mechanisms in the normalization structure that may protect data in the lock node. These variable locks may include ORLOCK, MATLOCK, SSLOCK, XORLOCK, and HASHLOCK. The present disclosure is not limited to these predefined lock types but may be expanded or contracted to accommodate any suitable locking scheme that may be normalized to its structure.

Hierarchical access control may regulate pervasive access to individual lock nodes in a lock graph. This feature may give rise to a property in Nut called gradient opacity, which may be the ability of Nut to allow various levels of metadata to be treated as given appropriate access attributes.

NUT access control or NAC may employ role-based cryptographic access control (RBCAC) techniques to fine-control the modification and authentication of NUT internal components.

Structured cryptographic programming may be a data structure design that may allow easy and flexible interaction between different methods to express various access models. The security mechanism may be embodied entirely in the encrypted data and its associated cryptogram, and thus, there may be no external application (such as reference monitor) dependency on the access control of Nut. In some embodiments, the lock node may be used solely to protect field level data in any portion of the payload. The internal components of the Nut container may potentially utilize multiple cryptographic keys to embody a particular security model.

Nut may be a directed graph data structure called a lock graph that is composed of nodes called lock nodes. Each lock node may be identified by a lock ID, which may result from the same function used to generate the Nut ID, and therefore all of which may have the same characteristics. The lock nodes may be stored in a set of hash tables that may be referenced by their lock IDs. Each lock node may have a pointer linked to other lock IDs or have a null pointer. A lock graph can be derived from a hashed set of lock nodes using well-established programming graph extraction and traversal techniques. A lock node that does not have other lock nodes directed to it may be a keyhole lock node (an entry or an external lock node). The lock nodes that may have null indicators may be terminal lock nodes of the lock graph and may store Nut payloads or references to payloads. A lock node may have multiple lock nodes coupled thereto. In most cases, the lock node is not linked back to an earlier lock node in the lock graph or to itself. Circular linking refers to a customization process that may not be normal but can be accommodated by custom Nut when ensuring such a structure.

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

It should be noted that due to the data center nature of the present disclosure, most flow type diagrams may be a mixture of traditional flow diagram components mixed with data components, which may be referred to as dataflow diagrams or dataflow diagrams. Moreover, the interleaved nature of the lock node design layer may make it difficult to expose the logical operations of its components in a completely linear fashion without making a forward reference statement, so that some re-reading may be required on the part of the reader.

FIG. 58 is an embodiment of Nut or lock graph 5800, which includes two logical sections that employ multiple destination aspects of a modular lock node: nut lock 5802 and Nut section 5804. The Nut lock 5802 section of the lock graph may allow complex cryptographic link locks to be constructed for a given Nut using one or more lock nodes. Five types of lock nodes are currently defined in the barrel of the present disclosure, which correspond to five types of mutable locks, mentioned as: ORLOCK, MATLOCK, SSLOCK, XORLOCK, and HASHLOCK. Each lock node type may refer to a type of locking mechanism within the mutable lock that may be used at the center of a particular lock node to protect encryption keys to storage areas and other lock node metadata and parameters. The lock transition as disclosed in fig. 30 may be an embodiment of a variable lock and may be used in the establishment of a lock node. Successfully unlocking and traversing the Nut lock 5802 portion of the lock map may be directed to the Nut portion 5804 section of the lock map 5800. There may be several lock nodes that make up Nut portion 5804: hair 5820, tick 5822, seal5824, vita 5826, bale 5828, and/or bale 5830. Nut section 5804 may contain Nut payload 5830 and/or metadata 5820-5828. The number and type of Nut portions of the lock map may vary depending on the type of data that Nut may be stored and/or the design of Nut for some desired behavior and characteristics. In this example, unlocking a keyhole lock node 5806(5816) may result in an appropriate cryptographic key that may be inserted into a first level cryptographic keyhole of a connected 5818 lock node 5820. Unlocking lock node 5820 may result in an appropriate cryptographic key that may be inserted into a first-level cryptographic keyway of a connected lock node 5822. Unlocking lock node 5822 may result in an appropriate cryptographic key that may be inserted into a first-level cryptographic keyway of a connected lock node 5824. Unlocking lock node 5824 may result in an appropriate cryptographic key, which may be inserted into a first-level cryptographic keyway of the attached lock node 5826. Unlocking lock node 5826 may result in an appropriate cryptographic key that may be inserted into a first-level cryptographic keyway of a connected lock node 5828. Unlocking lock node 5828 may result in an appropriate cryptographic key that may be inserted into a first-level cryptographic keyway of a connected lock node 5830. Lock node 5830 may be tied to a null pointer, and thus may be the terminal lock node or the innermost layer of the lock graph or Nut. Unlocking of a lock node may include using an SDFT method to disassemble a collapsed data structure (unwind) representing the lock node. Each lock node may contain multiple collapsed data structures, where the act of unlocking a lock node may be equivalent to the unfolding of the applicable data structure.

Fig. 59 shows a simplified Nut diagram 5900 of a lock diagram embodiment comprising a logical segment Nut lock 5902 and Nut portion 5904. This example explores a Nut lock 5902 including four lock nodes 5908, 5910, 5912, and 5916. The lock nodes 5908-5912 may be keyhole lock nodes 5906 for this Nut, as some or all of them may be outward facing nodes and may accept an external cryptographic key called a primary key. The user may have a first level key associated with one or more of these keyhole lock nodes. The Nut ID of Nut storing the first level key as its payload may serve as a key ID that may automatically match the identifier of the keyhole to which it belongs in the mark keyhole lock node 5906. The passphrase key may be identified by a key ID or text string, which may or may not hold a challenge as its identifier. A complex multi-layer passphrase may be constructed using the appropriate keyhole identifier and the plaintext Nut metadata portion with the appropriate challenge list. The link between lock nodes (such as 5914 and 5918) may be broken in a similar manner, where successful unlocking of the lock nodes may result in output key(s) with identifiers. In this particular example, unlocking any of the keyhole lock nodes may reveal an appropriate cryptographic key that may be inserted into a keyhole of a connected lock node 5916 of 5914. Henceforth, the unlocking of the node comprising Nut portion 5904 may similarly proceed to the procedure described for Nut portion 5804. This Nut lock 5902 construction may convey the flexibility of establishing block properties of the lock node and combinations thereof by showing that there may be three distinct paths of the payload unlocking Nut 5900, where each path needs to satisfy different conditions in order to proceed with the unlocking process.

In fig. 60, lock node 6000 may be a data structure comprising the following sections: parameter 6002, input 6006, key map 6008, mutable lock 6012, derivative key 6016, key set 6020, package 6024, and/or output 6026. The parameter section 6002 may hold the metadata of the lock node, the encrypted string of the lock ID 6030 and the key map 6010, the derivative key 6014, the key set 6018, the package 6022, and the dign of the encrypted string resulting from the appropriate access role key of the lock node (forward reference may be described in the discussion of fig. 83 component 8334). The design principles may be similar to the flow in a lock graph with unlocking of each segment, which may result in a key that may help open the next segment but then each component within the lock node may provide a specific function. The dign on the encrypted string may be used by the reader (an accessing role) to authenticate the particular segment prior to the decryption attempt. The encrypted string of segments may be used by a writer (an access role) of a particular segment to generate dign when some modification may exist to preserve or instruct an appropriate writer access key holder to generate dign. Further, each of the encrypted strings described above may be embodied by use of the SDFT method to collapse a data structure from a TAR using a table containing cryptographic transformations. Given the number and type of encrypted strings described in this section, the SDFT method can greatly reduce the burden of managing cryptogra phic-related attributes by programmers when encoding.

Key hole

In fig. 61, the input section 6006 of the lock node may provide two different key keyways: a first level key hole 6102, and an access key hole 6104. Structurally, the first level keyhole 6102 can accept any number of cryptographic keys, including four different key types: symmetric, asymmetric public, asymmetric private, and passphrase. The access key hole 6104 can accept symmetric and/or passphrase key types. The first stage key keyway and the access key keyway may internally utilize one or more KISS data structures as shown in fig. 34, which each operate in a keyhole mode (ima ═ keyhole ") to represent the key keyways for each unique key that they accept.

FIG. 62 shows a single cryptographic key 6202, which may have an associated key ID, key type, and key attributes 6206, and which may also be designated as a first level key. The key ID may be any identification string. The first level key and any other keys mentioned in this disclosure may each be represented internally by a KISS data structure operating in key mode (ima ═ key ") as shown in fig. 34, with key- > value fields populated with keys and other matching attribute fields populated as needed. First level key hole 6204 may accept first level key 6202 that may decode encrypted key map 6208. The decrypted key image 6240 may be a structure that may include three sections: a primary key 6210, a tier key 6212, and an Access Key Set (AKS) 6214. Primary key structure 6210 may contain a symmetric key or trailer (which may be referred to as a primary key), an expiration date/time of first level key 6202, a countdown timer for the first level key, and/or an action instruction after expiration of the first level key. The symmetric key or tail may be used by a changeable lock of the lock node. For key hole lock nodes, the key image structure may additionally hold tier keys 6212 and/or AKS 6214. The hierarchy keys 6212 may hold a set of keys to be inserted into the hierarchy lock nodes of the lock graph, which may be identified by their hierarchy designation. AKS6214 may hold a set of keys to be inserted into its own access key well 6104 of a key well lock node. The encrypted key image 6208 may be an SDFT collapsed data structure, which may contain primary key 6210, tier key 6212, and Access Key Set (AKS)6214 structures.

FIG. 63 shows a flow diagram of a key insertion process for any lock node and for any cryptographic key. Step 6304 may be a search of some or all listed lock nodes in Nut across a given cryptographic key and its associated key ID. Once the cryptographic key is inserted 6304 into the appropriate cryptographic keyway, step 6306 may attempt to decrypt and expand the encrypted key image of the key. Decryption and expansion of the encrypted key image may be equivalent to the disassembly of an SDFT collapsed encryption key image of such embodiments.

Upon successful unlocking and expansion of an encrypted key image 6208 of the keyhole lock node, 1) the tier keys may be inserted into the first tier key keyways of each lock node to match the tier designations found in the parameter section of each lock node, 2) the Access Attribute Key Set Unlock Key (AAKSUK) of the Access Key Set (AKS) may be inserted into the access key keyways of the lock nodes. Since so many first level keys may have been inserted into the lock node, this first level key unlocking (or stripping) may occur, after which we may have a set of decrypted (or unwrapped) key images that together form a set of primary keys that may be used by the variable lock of the lock node.

Fig. 64 shows an example in which three first level keys 6402-6406 may be inserted into first level key hole 6400. Each key (→) is compatible with its identification key ID and can be inserted into a slot in a hash set or KISS keyhole configuration. 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, the user may specify any key type that may have a corresponding cryptographic method that is suitably modular for Nut integration. These key cryptographic methods may include fingerprint scans, iris scans, palm prints, voice prints, handwritten patterns, facial recognition, DNA characteristics, physical key devices, hardware security keys, software/hardware based zero-knowledge protocol keys, and/or NFC keys. If an asymmetric private key is inserted (such as may be used in RSA-2048), it may represent a public portion and a private portion, the public portion may be extracted from the private portion and may be used to encrypt an encrypted key image of the primary key, so the decryption operation may require the presentation of the private asymmetric key. As shown explicitly for one key (→) inserted into one key hole 6402, its encrypted key image 6412 can be decrypted using key type cryptography methods to reveal a key image structure 6430 that can contain three distinct sets of keys 6432, 6434 and 6436. This decryption step may be performed for each key 6404 and 6406 to generate respective corresponding key image sets 6440 and 6450. Each decryption step may also be equivalent to disassembling the SDFT folded structure of these embodiments. For a passphrase key type, the key may be a passphrase and the key attributes may indicate the passphrase derivation function used and the appropriate parameters for that function, including the number of iterations performed to generate a symmetric key that can decrypt the encrypted key image. For embodiments utilizing SDFT, such passphrase attributes may also be matched with a corresponding TAR to access the appropriate derived transition with the matching attribute. To put the example into a perspective that utilizes the lock node map 6000, the input section 6006 may contain a first level key hole 6400, the encrypted key image 6010 may be represented by 6410 and the key image 6008 section may be represented by 6420.

Variable lock

The next portion of the lock node may be a variable lock as shown in component 6012 of fig. 60. The variable lock may be a locking mechanism that may help protect the contents of the lock node stored in the packet 6024. The variable lock may allow the lock node to utilize any of a number of different types of cryptographic lock techniques that are familiar to those of ordinary skill in the art. For example, these different lock types may include ORLOCK, MATLOCK, XORLOCK, HASHLOCK, and/or SSLOCK. This can be done by normalizing the inputs and/or outputs of the locking methods to fit to a common data flow model so that the locking methods can be seamlessly replaced. Similarly, the first-level key keyhole and key mapping structure may act as a data normalizer for the number and type of keys flowing into a mutable lock. The lock node may be imprinted with a set of parameters 6002 indicating the variable lock types 6030 that it can implement. Once this value is set, the lock node may change this setting very little, but may be re-encrypted and/or reset by the RAT (the owner of Nut). The SDFT library describes an embodiment of a changeable lock as listed in fig. 30 and its accompanying specifications (which may be used in this section for convenience), but the use of lock transitions is not a necessary requirement to achieve this function of a lock node.

Continuing the traversal of the lock node in FIG. 64, we end up with three primary keys 6432, 6442, and 6452. We can explore in fig. 65 how their mutable locks can operate. The mutable lock 6502 may protect a Derivative Key (DK)6506 by encrypting the derivative key into an encrypted derivative key (eDK) 6504. Some or all of the primary keys 6432, 6442 and 6452 may be of symmetric or tail key type and may be fed into the mutable lock 6502. Depending on the variable lock types that may be specified in the lock node parameter sections 6002 and 6030, the appropriate variable lock function may be invoked to perform an encryption/decryption operation on DK or eDK. Fig. 65 shows a decryption operation of eDK6504 into DK 6506 by the mutable lock 6502 that can use the primary keys 6432, 6442 and 6452. Fig. 66 shows an encryption operation of DK 6506 encrypted as eDK6504 by the mutable lock 6502 using primary keys 6432, 6442 and 6452. In embodiments using SDFT, the DK may be data protected by TAR, which employs lock transformation by data folding; thus, expanding the structure reveals the derivative key contained therein.

The table in fig. 67 summarizes some key properties mentioned for the variable lock. As the term variable lock may imply, any lock technique that may normalize this model may be added as an additional variable lock type. Alternatively, any locking technique may be excluded. The table in fig. 30 may correspond to the table in fig. 67 and shows how the SDFT may embody a variable lock design in its lock transition.

The metadata section 6030 of the lock node may be a common component that may be involved in some or all of the mutable locks. There may be various dign (digital signatures) of lock node segments that may have been generated by an appropriate Access Role Key (ARK), such as 6040-6048 (forward reference). Some of all these digns may be generated by Nut owner, who may be any one that maintains a root access stratum (RAT) access role key (specifically RAT secret key) through its AKS. All people with valid first-level keys may have RAT public keys that may enable them to authenticate various ratdigns through the lock node to ensure that the Nut component has not been cracked. In the figure, sometimes the RAT public key may be referred to as a RAT reader key and the private key may be referred to as a RAT writer key. Further discussion of the Nut access control layer, later in this document, may explore, specify, and/or clarify these features more deeply. As previously mentioned in the section on SDFT and TAR, the dign of encrypted data may be part of the TAR specification of the collapsed data structure, which may embed the protected data, its dign, and the TAR from which it was generated. It is expressly implied that a system usage of SDFTs within lock nodes may be advantageous to programmer workloads.

The ORLOCK (also called OR key) in fig. 68 is a variable lock that can accept any number of symmetric cryptographic keys called primary keys 6808 and systematically attempt to decrypt 6814 eDK 6806 using a symmetric cryptogra phic cipher, such as AES-256 OR a substitute cipher. The parameter section 6002 may indicate a cryptographic method for this logical operation or a preferred TAR when using SDFT methods. eDK, the first successful decryption may result in Derivative Key (DK)6816 and may result in a successful unlock of ORLOCK. The flag of eDK 6804 may be authenticated using eDK 6806 and a RAT reader key 6802 prior to decryption attempts in any mutable lock. If the authentication is successful 6810, the decryption process may continue, otherwise an error 6830 may be generated and the attempt may stop. The primary key 6808 may be the same key, such as but not limited to a symmetric 256-bit key. In this arrangement, the nature of the OR lock can be isolated and normalized to a keyway and variable lock structure to make it modular. In a folded configuration, the authentication step may be part of the TAR and may be implicitly attempted by the act of disassembly.

Figure 69 depicts the encryption operation of ORLOCK from the perspective of a RAT writer or Nut owner. It may employ any primary key 6902 and may perform an encryption operation 6920 on DK 6906 using an appropriate cipher to produce eDK 6908. Then using its RAT writer keys 6904, eDK 6908 and the appropriate dig algorithm 6922, it may generate a dig of eDK 6910, which may be stored in the lock node parameter section 6044. The SDFT method can collapse many of these attributes together with eDK into a single data object to be stored in the parameter section in a compact manner. The ciphering process for the non-RAT component of the lock node may be simple; they may erase the application memory contents of the lock node because they may not generate a true dign for any content that suggests they cannot successfully change their contents and do dign for them, or they may use DK 6908 already decrypted and they may encrypt the relevant contents of the lock node but may leave eDK 6910 unaffected because the content that may be relevant to eDKdign may not be changed. This may show that only RAT writers may be able to replace or re-encrypt the value of DK 6906. When using the SDFT method, the non-RAT component of the lock node may choose to leave the original folded data containing eDK in the parameter section and erase the unfolded structure that holds the DK.

MATLOCK (also known as a matriyshka lock, level interlock or AND lock) in FIG. 70 is a variable lock that can accept a fixed number of symmetric cryptographic keys, referred to as primary keys 7006, AND can successively decrypt 357022 using each primary key 7008 in increasing order using an appropriate cryptogra phic code 7014 (such as AES-256 or an alternate code). The parameter field may indicate the exact cipher and the number of primary keys that may be needed for this logical operation or a better TAR when using the SDFT method. eDK7022 successful ordered iterative decryption of 7022 may result in DK 7024 and may result in a successful unlock of MATLOCK. Prior to decryption attempts in any changeable lock, the dign of eDK 7004 may be authenticated using eDK7022 and the RAT reader key 7002. If authentication is successful 7010, the decryption process may continue, otherwise an error 7030 may be generated and the attempt may be stopped. In this arrangement, the nature of the matriyshka lock may have been isolated and normalized to a keyhole and variable lock structure to make it modular. In a folded configuration, the authentication step may be part of the TAR and may be implicitly attempted by the act of disassembly.

Fig. 71 depicts the encryption operation of MATLOCK from the perspective of a RAT writer or Nut owner. It may take some or all of the primary keys 7102 presented and may order them in descending order 7110. Then, it may iteratively perform encryption operation 7112 on DK 7120 using the appropriate password to produce eDK 7122. Then using its RAT writer keys 7124, eDK7122 and an appropriate signing algorithm 7118, it may generate a dig of eDK7126, which may be stored in the lock node parameters section 6044. The SDFT method can collapse many of these attributes along with eDK into a single data object for storage in the parameter section in a compact manner. The ciphering process for the non-RAT component of the lock node may be simple; they may erase the application memory contents of the locking node because they may not generate a true dign for any content that suggests they cannot successfully change their contents and do it with dign, or they may use DK 7120 already decrypted and they may encrypt the relevant contents of the locking node but may leave eDK7126 unaffected because the content that may be relevant to edkddign may not be changed. This may show that only RAT writers may be able to replace or re-encrypt the value of DK 7120. When using the SDFT method, the non-RAT component of the lock node may choose to leave the original folded data containing eDK in the parameter section and erase the unfolded structure that holds the DK.

XORLOCK (also called XOR lock) in fig. 72 is a variable lock that can accept a fixed number (>1) of symmetric cryptographic keys, called primary keys 7206, and can generate a computed key by successively applying XOR operations 7224 to each primary key 7208 in increasing order 7222. It may then attempt to decrypt 7228eDK 7210 using the calculated key from 7224 with an appropriate password, such as AES-256 or an alternate password. Parameter section 6030 may indicate the exact cipher and the number of primary keys that may be needed (which may be no less than two keys) for this logical operation or a better TAR when using the SDFT method. eDK 7210 successful decryption may result in DK 7212 and may result in a successful unlock of XORLOCK. The dign of eDK 7204 may be authenticated using eDK 7210 and the RAT reader key 7202 prior to a decryption attempt in any mutable lock. If authentication is successful 7220, the decryption process may continue, otherwise an error 7230 may be generated and the attempt may stop. In this arrangement, the nature of the XOR lock may have been isolated and normalized to a keyhole and variable lock structure to make it modular. In a folded configuration, the authentication step may be part of the TAR and may be implicitly attempted by the act of disassembly.

Fig. 73 depicts the cryptographic operation of XORLOCK from the perspective of a RAT writer or Nut owner. It may take some or all of the primary keys 7302 presented and may order them in ascending order 7320. It may then iteratively perform XOR operation 7322 on primary key 7304 to generate a calculated key, which may be used to encrypt 7326 DK 7306 to generate eDK 7308. RAT writer keys 7310, eDK 7308 and an appropriate scalar dign algorithm 7328 may be used to generate dign for eDK7312, which may be stored in lock node parameter section 6044. The SDFT method can collapse many of these attributes together with eDK into a single data object to be stored in the parameter section in a compact manner. The ciphering process for the non-RAT component of the lock node may be simple; they may erase the application memory contents of the locking node because they may not generate a true dign for any content that suggests that they cannot successfully change their contents, or they may use decrypted DK 7306 and they may encrypt the relevant contents of the locking node but leave eDK7312 unaffected because the content that may be relevant to eDKdign may not be changed. This may show that only RAT writers may be able to re-encrypt the DK 7306. When using the SDFT method, the non-RAT component of the lock node may choose to leave the original folded data containing eDK in the parameter section and erase the unfolded structure that holds the DK.

Hash lock (also known as hash lock) in fig. 74 is a variable lock that can accept a fixed number of symmetric cryptographic keys, called primary keys 7406, and can generate a calculated key by concatenating 7424 some or all of the presented primary keys in a particular order 7422 and then it can apply a hash algorithm 7426 to the string. It may then attempt to decrypt 7428 eDK 7410 using the calculated key with an appropriate cryptographic cipher, such as AES-256 or an alternate cipher. The parameter section 6030 may indicate the exact cipher and hash used for these logical operations, the number of primary keys required and/or the ordering order of the primary keys, or a better TAR when using the SDFT method. eDK 7410 successful decryption may result in DK 7412 and may result in successful unlocking of the HASHLOCK. The dign of eDK 7404 may be authenticated using eDK 7410 and a RAT reader key 7402 before a decryption attempt in any changeable lock. If the authentication is successful 7420, the decryption process may continue, otherwise an error 7430 may be generated and the attempt may stop. In this arrangement, the nature of the hash lock may have been isolated and normalized to a keyhole and variable lock structure to make it modular. In a folded configuration, the authentication step may be part of the TAR and may be implicitly attempted by the act of disassembly.

Fig. 75 depicts the encryption operation of HASHLOCK from the perspective of a RAT writer or Nut owner. It may take the presented primary key 7502 and may order them in an increasing order 7520, then they 7522 may be concatenated and then a computed key may be generated by performing a hash operation 7524 on them. This calculated key may be used to decrypt 7526DK 7506 and may result in eDK 7510. The RAT writer keys 7508, eDK 7510 and the appropriate dign algorithm 7528 may be used to generate a dign of eDK 7512, which may be stored in the lock node parameters section 6044. The SDFT method can collapse many of these attributes together with eDK into a single data object to be stored in the parameter section in a compact manner. The ciphering process for the non-RAT component of the lock node may be simple; they may erase the application memory contents of the locking node because they may not generate a true dign for any content that suggests that they cannot successfully change their contents, or they may use decrypted DK 7506 and they may encrypt the relevant contents of the locking node but leave eDK 7512 unaffected because the content that may be relevant to the eDK dign may not be changed. This may show that only RAT writers may be able to re-encrypt the DK 7506. When using the SDFT method, the non-RAT component of the lock node may choose to leave the original folded data containing eDK in the parameter section and erase the unfolded structure that holds the DK.

SSLOCK in FIG. 76 (also known as a secret sharing Lock or Shamir secret sharing scheme) is a variable lock that can accept n-th of k primary keys 7606, where each can be a distinct tail or secret share and where 1> p +1 ≦ k ≦ n and p +1 can be the minimum number of keys needed (known as a threshold). To recover the secret key, some or all of the trailers from the decrypted key image 7606 may be provided to an appropriate secret sharing secret 7622, such as a Shamir secret sharing scheme or an alternate secret. Recovery may be successful if some or all of the tails may be valid and there may be a sufficient number of tails. It may then attempt to decrypt 7624 eDK 7608 using the recovered secret key with an appropriate cryptogra phic password, such as AES-256 or a substitute password. The parameter section 6030 may indicate the exact cipher used for the secret sharing and encryption operations as well as the number of shares (n) and threshold count (p +1) for the secret sharing cipher and/or a better TAR when using the SDFT method. Successful decryption of eDK 7608 may result in DK 7610 and may result in successful unlocking of SSLOCK. Dign of eDK 7604 can be authenticated using eDK 7608 and RAT reader key 7602 before a decryption attempt in any changeable lock. If the authentication is successful 7620, the decryption process may continue, otherwise an error may be generated 7630 and the attempt may stop. In this arrangement, the nature of the secret shared lock may have been isolated and normalized to a keyway and variable lock structure to make it modular. In a folded configuration, the authentication step may be part of the TAR and may be implicitly attempted by the act of disassembly.

Figure 77 depicts the encryption operation of SSLOCK from the perspective of a RAT writer or Nut owner (who may encrypt the lock node for the first time or who may be in the process of re-encrypting the variable lock). The new secret cryptographic key K may be generated 7720 and then the desired number of copies (trailers) may be generated from K using an appropriate secret sharing method that may be specified in parameter 6030. These tails may then be stored as the primary key 7702. In step 7724, key K may encrypt DK 7704, resulting in eDK 7706. The RAT writer keys 7708, eDK 7706 and an appropriate dign algorithm 7726 may be used to generate a dign of eDK 7710, which may be stored in the lock node parameters section 6044. The SDFT method can collapse many of these attributes together with eDK into a single data object to be stored in the parameter section in a compact manner. The ciphering process for the non-RAT component of the lock node may be simple; they may erase the application memory contents of the locking node because they may not generate a true dign for any content that suggests that they cannot successfully change their contents, or they may use decrypted DK 7704 and they may encrypt the relevant contents of the locking node but may leave eDK 7706 unaffected because the content that may be relevant to eDKdign may not be changed. This may show that only RAT writers may be able to re-encrypt the DK 7704. When using the SDFT method, the non-RAT component of the lock node may choose to leave the original folded data containing eDK in the parameter section and erase the unfolded structure that holds the DK.

A description of a variable lock and illustrations of its various logical operations may show how a lock node may employ a first level key hole 6102, an encrypted key image 6010, a key image 6008, a variable lock 6012, an encrypted derivative key 6014, and/or a derivative key 6016 in an input section 6006 to produce a robust data structure that may allow different locking techniques to be normalized and modularized, such that replacing one lock technique with another may require some parameter 6030 changes and/or re-encryption. The normalization of the different lock methods may ensure that the user first level key of Nut may be unaffected and that a single user first level key may be employed in different Nut that is not known to the user in many different locking techniques and these locking techniques may be considered appropriate for protecting a particular Nut payload. Segments in which the SDFT method may prove advantageous in some embodiments of such complex data structures are highlighted. There are some examples here. ORLOCK may allow multiple users to gain access to a package of lock nodes: this may be in the form of group access or one of the keys may represent a master key. MATLOCK, XORLOCK, or HASHLOCK can ensure that there can be a certain number of keys in order to unpack its packets: sensitive corporate secrets may require two particular senior supervisors to supply their respective secret keys to view their content. SSLOCK may require that a minimum number of secret keys may exist in order to gain access to its packets: corporate payment systems are accessible by a minimum number of authorized persons but may not operate independently.

By partitioning each first level key keyway using its corresponding key image, the key image may contain attributes of the first level key, such as, but not limited to, expiration date/time, countdown timers and/or expiration actions. If any of the expired attributes have been started, the corresponding expiration action may be set to be performed after the expiration of the first level key. For example, a typical expiration action may be to delete the key image of the primary key. The deletion of a key image may be due to any other registered first level keys whose partition design does not interfere with the key hole lock node. Reinsertion of an expired primary key may no longer be recognized as a valid key because there may be no key image matching it. Of course, such first level key deletion should be done carefully with respect to the type of variable lock employed: ORLOCK and some SSLOCK can accept deletes but MATLOCK, XORLOCK and HASHLOCK cannot accept deletes because they can generate a lock condition for the lock node.

The interplay of complex data structures, which may utilize multiple cryptographic techniques for the purpose of protecting their contents in various ways and layers, can pose significant challenges in implementation details due to the unusually large number of variable attributes required and/or generated per cryptographic operation. In this case, the utility and elegant appearance of SDFT and may provide convenient organizational methods and structures to help overcome such implementation challenges. For example, a single authenticated encryption of data may require the following attributes to be stored somewhere: key type, key length, cipher type, cipher mode, initial vector, key ID, pad type, pad length, block length, digital signature or encrypted MAC string (digest), matching key ID of digest, digest length, digest key length, digest method. This is multiplied by the various cryptographic operations described in the lock node specification presented thus far (the lock node has several more components discussed in the subsequent section) and it can be a huge number of attributes that are continuously tracked. In many instances, application designers and designers may be aware of such embarrassment and challenges and may choose to simplify the encoding process by selecting a small number of encryption methods and associated attribute values and using them in a global manner throughout their implementation. Such simplification may lead to undesirable consequences such as, but not limited to, less security, less flexibility, fewer features, more incompatibility, and computer code that may be more difficult to maintain or modify.

Hierarchy level

Figure 78 shows a block diagram (lock diagram) 7800 highlighting Nut for hierarchical key usage. Each lock node in Nut portion 7804 may be assigned a hierarchy ID. Lock nodes 7820-7824 are tier ID "a", lock node 7826 is tier ID "B", lock node 7828 is tier ID "C" and lock node 7830 is tier ID "D". The designation of the level may be arbitrary but may follow a grouping pattern with various Nut parts in privacy sensitivity: the deeper the hierarchy, the more sensitive the data contained in the lock node may be. With the precise use of hierarchical access control (SAC), we can enforce the gradient opacity of Nut. For illustrative purposes, the hierarchy ID depicted in fig. 78 is a simple letter but may in fact be any identifiable group of strings, such as but not limited to Nut IDs (as in the actual unique ID from fig. 55).

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

The hierarchy keys may work in conjunction with MATLOCK VARIABLE LOCK as shown in some or all of the lock nodes in the Nut portion 7804 segment. When using the SDFT method, MATLOCK may be indicated by a "locklock" transition in the preferred TAR of the segment concerned. Each hierarchical key may be a mandatory key in the MATLOCK of the lock node in question (one in fig. 79). If a lock node outputs a link key or a hierarchy key may be missing, the particular lock node may not be unlocked as defined by MATLOCK. Thus, some or all of the deeper levels beyond that level may not be opened as well. By controlling which hierarchical keys can be stored in the key map 7840 of the first level keys, the Nut owner can explicitly control how far through the lock map 7860 one can precisely penetrate. The hierarchical access control layer may operate independently of the Nut access control layer and it may operate in conjunction with the variable lock method.

The SAC and keykey enabled approach may imply that if multiple keys can be presented into a keylocker node, such as 7806, multiple key images 7840 may be displayed and possibly multiple hierarchical key sets 7850 may be inserted into various locker nodes. The level keys of a single level ID may be the same key, so inserting the same key into a lock node that may utilize MATLOCK may result in one key being inserted below the ID, essentially overwriting the same key multiple times in a keykey hole. This may be an additional access attribute property of the hierarchical key.

Both the level keys and Nut access control (discussed in the next section) may exhibit an additional access attribute property or characteristic. Inserting first level keys of different levels of access into a first level key keyway of a lock graph may result in a level of access for the lock graph that may represent a combination or union of the levels of access for all valid inserted first level keys. One powerful use of this property may be to distribute the keys of a given lock graph in a piece-wise manner, where a combination of first-level keys may be needed in order to obtain a very specific level of access to the lock graph. This may be in contrast to the mode of operation in which the primary key may present a complete image of a given access by the key holder.

Nut access control

Nut access control or NAC is an access control method that uses a cryptographic data structure that can work independently of mutable locks and hierarchical access control. NAC may use a combination of role-based access control (RBAC) and cryptogra phic access control (CAC), which we may refer to as role-based cryptogra phic access control (RBCAC) or key-based grant (KBP). The set of NAC attribute keys may be localized as internal components of a single lock node, however, there may be mechanisms in a lock node to propagate NAC attributes along the rest of the lock graph, which may allow key holders to have a consistent level of accessibility throughout the relevant interlocking nodes. These NAC attributes may be found in an unlocking or un-unlocking keyhole lock node of a first level key that may have been inserted from an external source. Like the hierarchical key, the NAC key may exhibit an additional access attribute property.

KBP can be deployed using well-known properties of public key cryptography, such as generating a digital signature (dign) and authenticating it asymmetrically over a string of data using an algorithm, such as rsasa-PSS (with an RSA parasitic signature scheme based on the appendix of the parasitic signature scheme originally invented by bellaree and Rogaway) or an alternative algorithm. The basic premise of KBP may be to give a private/public key pair, the private key holder (writer) may use the writer's private key to generate a digital signature (dign) on a data packet and then the public key holder (reader) may use the writer's public key owned by the reader to authenticate that the writer generated the dign on the data packet. If authentication fails, something may have been broken, such as a public key, a data packet, or dign, or some or all of them. The writer may be responsible for generating an update dign on the target data packet after each modification of the target data packet and the reader may be responsible for authenticating the dign and the target data packet before "reading" or decrypting the data packet. This process can reasonably ensure for the reader that it can read something that has been generated or modified by someone (writer) who may have a corresponding private key. In role-based cryptographic access control (RBCAC), each defined access role can have an asymmetric key pair and a "writer" of the role can obtain a private portion of the key and a "reader" of the role can obtain a corresponding public portion of the key. By separating the data sets by function and dign each function data set with a different key pair, the access roles can be precisely defined and can be distributed to each key holder by distributing the appropriate key portions. The RBCAC of NUTS may allow one or more symmetric keys to be coupled with asymmetric key pairs of defined roles to provide an additional layer of control over the target data set. The holder of the coupled symmetric key can decode and read the target data set for that role. This coupled symmetric key may encrypt the target data set on top of the encryption with the symmetric key shown by the variable lock in eKS and the unlocking of the subsequent key. Alternatively, the presence of the coupled symmetric key may replace the use of the displayed encryption key from eKS and may be the only key of the symmetric encryption target data set. This alternative may be preferable for larger target data sets because they will be encrypted no more than once. The coupled symmetric key may be used to control read access to a target data set.

In an embodiment of NAC, the use of SDFT can simplify the encoding quite significantly. Encryption and dign may be embedded into a logical conglomerate TAR appropriate for the function to be performed and the deconsolidation procedure of SDFT may automate much of the detailed processing of these operations. Any localized attribute associated with a TAR may be folded together with the target data or further folded with another TAR to simplify its protection and storage.

The table in fig. 80 shows how key-based allowances can work with three defined roles (reader, writer, and verifier) and five role players (A, B, V, X and Y). All role-players in possession of the coupled symmetric key S may have the ability to encrypt or decrypt data using the symmetric key S. Writer Classes (COW) X and Y may have the ability to generate dign on encrypted data using asymmetric secret key R. With the use of an asymmetric public key U, reader Classes (CORs) A and B may have the ability to verify that a corresponding digital signature was generated on encrypted data by someone from the writer class and they may have the ability to decrypt the data using symmetric key S. Thus, the ability to generate a valid dign may imply that you may have the ability to modify data and that all other readers may recognize that dign has been generated 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 method as described in fig. 80. A role-player who possesses only asymmetric public key U may be referred to as a verifier; the verifier may have the ability to traverse the entire Nut but may not be able to decrypt the target data corresponding to the role category. For example, the COR validator may only authenticate that the payload of Nut has been properly modified by an appropriate COW role actor using the COW public key on dign but that it cannot decrypt the payload because it does not have a copy of the decryption key S.

The NAC can precisely influence and control the visible and modifiable content aspects, thereby locking the content aspects of the node, thereby Nut. The table shown in figure 81 lists some portions of Nut but may contain more or fewer portions than desired: hair, tick, seal, vita, face, tale, and/or bale. There may be a forward reference in the table to the Nut log and Nut history, which may be detailed in subsequent documents. Each column may represent a lock node and the data defining the Nut portion may be held in the packet for that lock node. The column titled packet opacity may show the cryptographic pattern of the packets of the lock node, which may be controlled by the metadata of the lock node. Packets may be encrypted or not (explicitly) set based on metadata, which may be referred to as packet opacity. If some or all of the Nut portions in the table in figure 81 are present in a given Nut, then the Nut portions that may be represented by lock nodes may be concatenated sequentially from top to bottom using lock node concatenation pointers and concatenation keys. Traversing the columns of this table downward relative to the packet opacity of each Nut portion may be referred to as the gradient opacity of Nut. The holder of the appropriate external first level key may gain access to Nut by eventually unlocking the variable lock of the lock node. Depending on the SAC setting of the first-level key, key holders may be limited in how far they can traverse into Nut. NAC may affect which first-level keys may be allowed to have the ability to read, modify, and/or authenticate each Nut portion through careful placement of coupled symmetric cryptographic keys, precise use of asymmetric key pairs, and use of digital signature methods.

Figure 82 shows a table listing key-based allowed access roles defined for and for a typical Nut. The access roles may not be limited to this list, as there may be more or fewer access roles defined depending on the needs of the Nut owner. The table lists four segments of Nut, which can be identified but is not limited to: bale, Vita, Tale, and All. An All segment may refer to anything not explicitly covered by another access role. This may require some or all internal work by the lock node, such as but not limited to dign, eDK on the key image and/or encrypted packets not specified by a key pair representing a separate access role. For this discussion, the key pair may include an asymmetric key pair and a coupled symmetric key. The presence of coupled symmetric data may depend on the presence of an access category verifier role. The holder of the All private key may be referred to as the owner of the RAT (root access stratum) or Nut. Each primary key may have a key image that may contain a copy of the RAT reader public key for authentication purposes. Bale may be held in a package (such as a file) that holds the lock node for Nut's payload. This key pair may be specifically named writer Class (COW) and reader Class (COR) due to its frequent use. This key pair may control which first level key may have the ability to modify the payload of Nut. In a similar manner, the Nut log may be maintained in a packet of the Vita portion of Nut and may be controlled by a logger/log reader key pair. The Nut history may be maintained in a packet in the role portion of Nut and may be controlled by a historian/history reader key pair. The verifier role of each access role category may have access to at least one public key associated with that role in order to authenticate the dign associated therewith. The verifier role may imply that there may be coupled symmetric keys associated with access role classes for which it does not have access rights. The maintenance process may be given access to a defined combination of verifier roles within Nut to check the validity, consistency and/or authenticity of Nut parts but not to read the content of the protected data. The key pair is not limited to such settings and may be expanded or contracted based on requirements. Any encrypted and/or unencrypted string of lock nodes may have a dign generated thereon by its own particular key pair, and all lock nodes in the lock graph may adopt this level of specificity, which may result in an extreme level of access control granularity; however, this extreme level of access control granularity may diminish the effectiveness of access control for this Nut.

The parameter section of the lock node may specify the digital signature algorithm applied and the length of the asymmetric key (default to the minimum of 2,048 bits of RSA-2048). Alternatively, SDFT usage may allow specific TAR to represent such preferences and TAR tags may be stored in the parameter section instead. The encrypted packets of the lock node that may hold the payload of Nut may not be digitally signed by the RAT writer using the RAT writer key but by a key holder with COW access (which may include the RAT writer). The first level key holder may be given access to the RAT reader key via its access key settings and corresponding Access Attribute Propagation Key (AAPK) in its key image of the keyhole lock node; this RAT reader key may allow any legitimate primary key holder to authenticate any dign (exemplified by a primary key holder that may have access to a RAT writer key) that may be within a lock node in the domain of RAT authorization. Any failure to authenticate any RATdign may imply that the corresponding string or folded data may have been broken, or that the RAT reader key may be invalid, or that the first level key may no longer be valid or for some or all of the reasons mentioned. The application may show this warning and may not continue the process because the integrity of Nut may have been compromised and further decryption attempts may not be successful or may result in showing compromised data.

Fig. 83 shows how Nut obtains its initial NAC access key set. Beginning with keyhole lock node 8300, a first level key 8304 may be inserted into first level key keyhole 8306 and may decrypt or unwrap an encrypted key image, which may reveal a key image structure 8310, there may be an Access Key Set (AKS)8312 that may contain a set of keys consisting of an Access Attribute Key Set Unlock Key (AAKSUK)8314, which may be symmetric. Each individual AAKSUK symmetric key may correspond to an access role as set forth in the table in fig. 82. Each AAKSUK in the AKS may then be inserted into an access key hole 8320 in the same input section 8302 of the same lock node 8300 as the original first level key hole 8306; the key image 8310 may hold a set of keys in the AKS 8312 that may feed its own access key hole 8320. This may be a special property of the keyhole lock node (outward facing lock node) and may not be applicable to internal lock nodes in most cases. Within the access key hole 8320, each appropriately inserted AAKSUK 8314 may be decrypted or expanded to reveal a corresponding Access Attribute Key Set (AAKS)8330, which includes an access role description 8332, an Access Role Key (ARK)8334, and/or an Access Attribute Propagation Key (AAPK) 8336. The ARK 8334 may specify the key pair portion corresponding to the given role: public (reader) or private (writer). The AAPK 8336 may be a symmetric key that may act as an AAKSUK in an access key keyway to the next linked-lock node. The AAKSUK set may constitute a set of AAKS that may define the NAC access attributes of the first level key and ultimately its access in the lock node. In this figure, AAKS 8330 may specify the access attributes of the Nut owner because it contains the RAT private key and the COW key. The additional attribute properties of the AAKSUK (and thus of the NAC) can be depicted in this figure; each primary key 8304 may have an AKS 8312 that may be inserted into the primary key hole 8306, so that each insertion of the AAKSUK 8314 into the access key hole 8320 may be additional. The same AAKSUK may overwrite an existing one only by an access keyhole, which may result in a union of unique AAKS when some or all of the presented primary keys may have been processed. This may result in a cumulative access attribute effect when first level keys with different access attributes may be inserted simultaneously.

FIG. 84 depicts how AAPK may be used to propagate NAC attributes throughout the rest of the lock nodes in the lock graph. The keyhole lock node 8400 may have been properly unlocked and some or all of the AKS 8402 may have been inserted into the access keyhole 8404, which may result in the AAKS 8420. The Access Attribute Propagation Key (AAPK)8424 may then be inserted into the access key hole 8432 of the next linked-lock node. It should be noted that this may be similar to the way a keyhole may have been filled for access to a keyhole lock node, but the keys come from a linked lock node rather than from an AKS that may or may not be found in its own first-level keyhole. The first level key hole (not shown) of the internal lock node 8430 may have an empty AKS in the key image, except for the RAT access level key. By following this propagation method, the access attribute of the first level key may be present in each open lock node in the lock graph. The lock node may isolate and localize some or all or its internal control mechanisms, such as having a different set of AAKS generated within the lock node for its own use, even though the access roles may be the same (such as COW). Even the AAKSUK and AAPK symmetric keys may be different as long as they can be mapped appropriately. It may be a precondition for a well-defined Nut to allocate a complete set of AAKS for a RAT for the entire lock node and for the lock node to propagate properly through its lock graph. For reference, there may be a complete set of AAPKs and ARKs that may be encrypted by the RAT public key and stored in the parameter section of the lock node, so only the RAT may display the set when it may be necessary to re-encrypt the lock node.

FIG. 85 depicts the propagation from an external lock node 8500 to an internal lock node 8530 using the AAPK's access attributes. The figure shows where the various keys can come from to feed the first level key hole 8550 and the access key hole 8560 of the connected node. Output section 8510 may display a linked symmetric key 8512 for a first level key keyway 8550 of linked lock nodes 8530. The AAPK 8522 may be inserted 8524 into the access key hole 8560 of the linked lock node 8530.

Fig. 86 shows a flow chart for inserting a key into an access keyway, which may have been described in detail using the example in the previous section.

FIG. 87 shows a table of key-based allowances for an alternative embodiment. The table may be further defined by a write asymmetric key pair (U)_W,R_W) And a symmetric key S for encrypting each instance of data_nAnd the table presented in figure 80 is expanded. The three keys from fig. 80 may alternatively be represented as dign asymmetric key pairs (U)_D,R_D) And a preset data encryption symmetric key S₀. Further the key may allow the ARK to define a write-only access role that can write to a packet of a lock node but may not read any other part of the packet. The write-only role can have a pair key R_D、U_D、U_WAnd S_nTo access (c). When a write-only role wishes to associate a message T with_nWhen stored in a packet in a lock node, it generates a single instance of symmetric encryption key S_nBy encrypting T_nThereby generating an encrypted message E_n. Next, a single instance symmetric encryption key S_nCan use a key with U_wTo generate an encrypted key K_n。E_nAnd K_nBoth can now be stored within the lock node's packet. Role of write onlyR may be used_DThe key generates dign and saves it. Message authentication may alternatively or additionally be performed by appropriate application of an authentication SDFT TAR sequence, which may embed and automatically collapse this information for compactness and organizational simplicity. Such TAR sequences may allow for alternative message authentication methods using any cryptographic MAC transition. Once write-only role-performer can complete the write and possibly destroy S_nThe role player may no longer have access to the decrypted message E_nS of_nAccess to the key, since the write-only role may no longer possess the asymmetric secret key R_W. Only these may possess asymmetric secret keys R_WCan decrypt the encrypted key K_nTo obtain S_nAnd may use it to encrypt message E_nOperates to obtain the original message T_n. The authentication method may additionally include hashing or dign chaining in a manner similar to the way a Merkle tree works to do a more efficient authentication of a payload comprising several separate messages. Write-only role access may not prevent an unauthorized truncation or overwriting of previous messages on lock nodes operated by the home system; however, the Nut ecosystem can help prevent or highlight these occurrences in various collaborative ways by incorporating its Nut history, replication, and synchronization features. This will be discussed later in the section on the Nut server and the revision control module.

The restricted role capability of write-only and verifier presented by the table in fig. 87 can help alleviate some of the problems associated with the prevalent "master Key" (God Key) puzzle within computer system security. This may be a well known problem category, where in one case a system administrator may be given a "master key" or all access authentication to a system or group of systems in order to maintain, update, repair, install and/or troubleshoot the system(s) at hand. There is a trend in the industry to automatically correlate technical capabilities with elevated security surveys due to the relatively small number of well-competent and experienced system administrators with an appropriate security survey check. This type of practice may not handle the dynamic nature of trust relationships, where the trust level between two parties may change in a unilateral manner over time, which may not be detectable by others or may be intentionally hidden from others. Through careful use of the write-only and verifier access roles, the payload can be protected from unauthorized access of data that is in transit or idle at all times. The application of these two access roles may allow the organization to separate the combined nature of the technical capabilities and security surveys to more properly and independently fully manage aspects. The write-only role may allow people and processes to be added as handling evidence to the Nut's log component but may not allow them to read the payload or edit the log. Additionally, the write-only role may have access to the marker key and may generate and verify an authentication string. The verifier role may allow people and processes to check Nut for internal consistency and authenticity without allowing any access to the payload. The lock node may be systematically modified, adapted and inserted into any database system, such as but not limited to a noSQL or RDBMS, to take place this granularity of access control at the field, record, table and/or database level. Compactness, flexibility, features, and/or independence may allow a lock node to exist in a computerized device, such as to an embedded access gateway in the device itself. This can be discussed in more detail in a subsequent section of the internet regarding Nut.

The NAC features may cover a complete set of permutations of actions that can be performed on a target payload. A simple cross-reference matrix that is allowed to act, along with its NAC implementation, can be shown as follows:

action	Reading	Writing in	Examination of
				Reading	Reader	Writer for writing	Reader
Writing in	Writer for writing	Write only	Write only
				Examination of	Reader	Write only	Examiner

The reader and writer roles may have the inclusive capability to verify or authenticate the dign contained within the lock node's packet.

Summarizing three protection methods for lock nodes: variable locks, hierarchical access control, and/or Nut access control. A variable lock may primarily protect packets that may be used for a lock node that carries some data content. The level access control may define how deep into the lock graph level a user may penetrate. Nut access controls may specify which portions of Nut may be modified, viewed, written, and digitally signed by a user. Some or all of these layers may be controlled by an embedded or folded set of keys within the key keyhole mechanism of the lock node. The keyhole mechanism may be a flexible entry that may allow insertion and handling of a variety of cryptographic keys for various functions. Some or all of these components may work together and/or separately to provide a rich set of access controls that can be customized on a per Nut basis and can be modular-structured to exhibit the desired lock behavior for protected content. The modularity of the lock nodes may also provide simplicity in establishing many complex locking structures due to their iterative, compact, and modular design. Although many different algorithms may be used to fully unlock and utilize Nut, the information of the initialization mechanism may be represented by an encrypted data portion that may be fully stored within the lock node of Nut, so its access control mechanism may be portable and may travel with its payload independent of any external reference monitor. Such mechanisms may be further embodied by various SDFT methods and structures to help simplify implementation and better manage the complexity of the inner coding and/or data details.

The access control model for Nut may be a combination of mandatory access control (centralized), arbitrary access control (user centric), and other access controls. It may resemble any access controller model such that it can store some or all of its access attributes within itself and the owner can directly set the access level per Nut in order to facilitate transportability. It may also accommodate some or all of any access control models and may be integrated into some or all of these environments due to its flexibility provided by its cryptographic keyways, variable locks, and other mechanisms. Moreover, it may exhibit other characteristics, such as, but not limited to, gradient opacity, additional access attributes, and/or modular lock node joining (which may be novel for NUTS).

Traversal of lock nodes

Now we can traverse the entire lock node and see how things can be revealed along the path. Figure 88 depicts a simplified diagram showing the decrypted data flow within a lock node 8800. This interleaving of lock node unlocking processes may be referenced and components of other figures involved in the depiction, such as fig. 62, 78, 83, 84, 85, and 88, integrated. Reference may be made to the same lock node section numbered by different reference numerals but which may represent different views of the same section tested in a method described in a deep discussion type. The ordering of logical operations 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 thus ultimately a lock graph or Nut, may involve steps that may be described in this example, such as, but not limited to: obtaining the access authority and decryption key of the lock node by using the first-level key; authenticating the lock node; propagating access rights throughout the lock graph; performing logic operations on the variable lock and/or decrypting the stored data; these steps may be expanded, contracted, or reordered as desired. If appropriate, some mechanisms within the lock graph and lock nodes may benefit from the appropriate application of the SDFT method.

First level keys 8804 may be inserted into the input sections 8806 and each first level key may use its associated cryptographic method to attempt to decrypt its matching encrypted key map 8810 and expand it into a key image 8808 structure. Each key image 6240 may generate a primary key 6210, which may be used by the variable lock 8812. Within each key map 7840 (equivalent to 6240) may be a set of hierarchical keys 7850 and each hierarchical key (such as 7852-7858) may be inserted into a matching hierarchical lock node (such as 7820-7830) of the lock map in the first level key hole 8306 of the respective input section 8302 (in this example, the hierarchical keys such as 7852-7858 may be equivalent to the first level key in 8304); a hierarchy such as 7820 to 7830 specifies that a lock node may employ MATLOCK, which may require a minimum of two keys to open it: a tier key such as 7852 and an output join key such as 8512 may be found in the output section 8510 or 8826. For keyhole lock node 8300, within each key map 8310 may be a set of Access Attribute Key Set Unlocking Keys (AAKSUK)8314, referred to as Access Key Set (AKS)8312, and each AAKSUK key may be inserted into an input section 8302 access keyhole 8320 of current keyhole lock node 8300. Once a set of Access Attribute Propagation Keys (AAPKs) 8336 are available in this manner, they 8522 (equivalent to 8336) can be inserted into the access key hole 8560 of the next linked lock node 8540. We can now have an Access Attribute Key Set (AAKS)8332, which can contain an Access Role Key (ARK) 8334. The ARK may define the access role of the first level key 8304 for the entire lock graph. These ARKs may be used to authenticate dign for various lock node segments such as 8840-8848. The dign of the lock ID and metadata 8840 may be authenticated using a RAT public ARK 8344 (which may be a public part of a RAT asymmetric key pair, as may have been described in the NAC specification) and an authentication algorithm specified in section 8830. For authentication, the segment 8830 may be submitted to an authentication algorithm along with the corresponding dign8840 and RAT public ARK 8344. If authentication fails, the section 8830 may have been compromised and the lock node unlocking process may generate an error and may stop processing. If authentication is successful, the digns of the encrypted key map 8842 may be authenticated for each encrypted key map corresponding to a valid inserted first level key. For authentication, each eKM 8810 string may be submitted to an authentication algorithm along with the corresponding dign8842 and RAT public ARK 8344. If authentication fails, eKM may have been broken and the lock node unlocking process may generate an error and may stop processing. If all appropriate ones of eKM have been successfully authenticated, then each dign of the encrypted derivative key 8844 may be authenticated. For authentication, each eDK 8814 may be submitted into an authentication algorithm along with the corresponding dign8844 and RAT public ARK 8344. If authentication fails, eDK may have been broken and the lock node unlocking process may generate an error and may stop processing. If all appropriate eDK have been successfully authenticated, then each dign of the encrypted key set 8846 may be authenticated. For authentication, each eKS 8818 may be submitted into an authentication algorithm along with the corresponding dign8846 and RAT public ARK 8344. If authentication fails, eKS may have been broken and the lock node unlocking process may generate an error and may stop processing. If all of the appropriate eKS have been successfully authenticated, then each dign of the encrypted packet 8848 may be authenticated. For authentication, each eBag 8822 may be submitted to an authentication algorithm along with the corresponding dign8848 and COR ARK 8348. If authentication fails, eBag may have been compromised and the lock node unlocking process may generate an error and may stop processing. If all the appropriate eBags have been successfully authenticated, the lock node may be considered fully authenticated. It should be noted that eBag may be authenticated using the reader Class (COR) access role key 8348. This may be applicable to the lock node holding the payload of Nut, but for the lock node holding Nut metadata in its packet, the RAT public ARK may instead be used to authenticate it. Then, based on the variable lock type indicated in the parameter section 8830 of the lock node, an appropriate variable lock algorithm 8812 may be attempted on each encrypted derivative key string (eDK)8814 using the set of primary keys 7844 from key image 8808. Successful unlocking of the mutable lock 8812 by decrypting eDK 8814 may result in one or more Derivative Keys (DKs) 8816. Each derived key may decrypt the corresponding encrypted key string (eKS)8818, which may be stored in parameters 8802. Decryption eKS may generate a corresponding key set 8820 structure, which may hold the output section 8826 structure and the packet key. The output link key(s) that may be found in the keyset 8820 structure may be stored in an input section 8826 and may operate as keys that may be inserted into a first-level cryptographic keyway of a linked-lock node 8530 (if present). The packet key may decrypt an encrypted packet string (eBag)8822, which may be stored in the parameter section, using an appropriate cipher. The decrypted packet may hold data such as, but not limited to, the payload of Nut (lock map), metadata about the payload, metadata of Nut, metadata of the packet, any combination of these and/or other data. The packet metadata may indicate whether the packet 8824 holds a Nut portion or Nut payload. If the packet holds a Nut portion, it may indicate which Nut portion it may represent and other appropriate Nut portion metadata and/or other data. If the packet holds the payload of Nut, it may indicate whether the stored data may be actual data or a reference thereto and if so, which reference type it may be, what reference may be and/or where it may be located.

This series of steps may be repeated for each lock node in the lock graph in order to unlock Nut. Fig. 89 shows a general flow diagram for Nut unlocking. Most of the steps may have been detailed in the previous example but some steps may need to be further elucidated. Step 8902 — organize the lock nodes into the appropriate traversal levels: since the lock nodes may be stored in a list-type structure in a column-based fashion, the actual topology of the lock graph may be extracted and constructed using the link information stored within each lock node. Once the graph can be constructed, one or more additional passes can be done to properly allocate the graph levels so that the lock nodes can be traversed in the proper sequence. Step 8908-hint some or all passphrase-based keyholes: during processing of the input section, a passphrase-based keyhole may prompt passphrases if it encounters an empty key (passphrase). This preset behavior can be modified to call another function or bypass any empty passkey keyhole. Any logical step or process in the flow chart may have an error, which may be generated and may cause the process to stop and these are not specified in detail, as this is a higher order flow chart: for example, any process that attempts an operation may fail and the algorithm may be stopped. The remainder of the flow chart may follow the path of the previous example.

FIG. 90 depicts how a NUTS-based system may open a file contained in Nut. Introducing a forward reference: the NUT book 9000 may be a data set organization application that may use NUT and may essentially act as a personal PKI when it comes to storing and organizing a set of passcodes, cryptographic keys and/or certificates. File symbols such as 9002 and 9004 may be used throughout the figures to represent Nut files. There may be a primary NUT access key NUT 9002 within the NUT book system that may be unlocked to obtain some minimum functionality from an application. The key may be stored within Nut 9002 and may be referred to as the primary Nut book key and the unlocking mechanism into Nut 9002 itself may include a passphrase. There may be a one-level key relationship with primary NUT book key 9002 and file access key 9004, such that a file access key may be needed in order to access any file that holds NUT in this configuration. Thus, the hierarchy may be set to require a primary NUT book key 9002 to open and access the file access key 9004. Nut holding the file access key may have Nut ID # 339016. Thus, the key that may be stored in the payload 9020 may be referred to as key ID # 33: both the file access key and the Nut ID of the Nut holding it may be referred to by the same ID, in this case # 33. File 9040 may be stored in Nut 9030 with Nut ID # 449036. Similarly, the file may be referred to as file # 44. When the user decides to open file #44, one of the keyholes in first level keyholes 9032 may specify that it may require key ID #33 to open it. Nut # 339004 may be requested from the NUT book and in order to open it, Nut 9004 may need to be opened. To open this Nut, Nut 9002 may need to be opened. Assume that the user may have initialized their Nut book with a passphrase of Nut 9002 and that the Nut book may have cached primary Nut book keys in memory. Then, opening Nut 9004 may require only an additional passphrase for file-level access of the Nut book and once it can be opened, a concatenation of Nut unlocks may occur to eventually display decrypted file # 449050. The NUT book may cache file access keys for a limited amount of time to expedite file fetching during a session but certain events (such as inactivity, hibernation, screen lock, timeout, and/or explicit lock) may require a passphrase to re-enter file access. This section introduces the NUT book application and the hierarchical passcode concept, which can be further discussed in a subsequent section. The series of steps that may require opening a single file may be many but some or all of the logic employed may be based on the lock node and its iterator and most of it may be hidden from the user. The end result may be that the data piece may be stored in Nut homogeneous 9030 and its security may be consistent in some or all environments.

Fig. 91 depicts the common use in Nut parlance to refer to the payload of Nut by retaining its Nut ID for a Nut. Here it is shown how a keyhole 9124 labeled as key #33 can actually look for a Nut 9110 with Nut ID # 339112 and it can be expected that Nut #33 holds 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, if Nut can be stored in a file, the filename of a Nut file may be rarely referred to in most operations.

The next set of diagrams show various exemplary embodiments of lock graphs that may highlight the flexibility and expressiveness of lock nodes and lock graph models that use variable lock and lock node linkages.

FIG. 92 shows a simplified embodiment of a list of recipient locking models: any one of the keys 9210 may unlock the ORLOCK lock node 9220, which may reach the lock node carrying Nut's payload 9290. It should be noted that for simplicity, the lock node may be represented graphically as a padlock, but in practice it is a fully functional lock node that may store some metadata for Nut.

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

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

FIG. 95 shows a simplified embodiment of a locking model with master key: either key 9510 or master key 9520 may be presented together or separately, which may allow access to Nut's payload 9590.

FIG. 96 shows a simplified embodiment of a locking model with master key: either key 9610 or master key 9620 may be presented together or separately, which may allow access to Nut's payload 9690. The MATLOCK bit in lock map 9632 may indicate that there may be some level of control in the location of this Nut and it may be the Nut portion that stores some Nut metadata.

FIG. 97 shows a simplified embodiment of a safe deposit box lock model: the key 9710 and bank key 9712 may be presented together, which may allow access to Nut's payload 9790.

FIG. 98 shows a simplified embodiment of a secret shared locking model with master key: from a set of keys 9810, a number of keys that meet or exceed a secret sharing threshold may be presented together, which may allow access to Nut's payload 9890. Alternatively, master key 9820 may be presented directly to ORLOCK lock node 9822, which may allow access to payload 9890. The key 9810 may be any combination of passphrases, symmetric keys, and/or asymmetric keys, as a keykeyhole/key mapping structure may hide tails that may be required by the secret sharing scheme utilized in the SSLOCK lock node 9812.

FIG. 99 shows a simplified embodiment of a "PrivaTegrid" type locking model: user key 9920 may be presented to ORLOCK 9922, which may allow access to payload 9990. Alternatively, nine keys 9910 may be presented collectively to MATLOCK9912, which may allow access to Nut's payload 9990. The "privategroutry" model may have been proposed by David Chaum in the early 2016 to implement a text messaging system that can securely transfer messages using keys known to its users but that can have a colluding back door system that can involve up to nine different keys maintained by nine international jurisdictions to give law enforcement access to a particular message if and only if all nine jurisdictions can agree that the particular message can be vital and legally authorizable.

Fig. 100 shows a simplified embodiment of a multiple Nut configuration, where multiple payloads may be stored within a single Nut: either the user key 10010 or the master key 10012 may access one payload or both payloads, which may depend on their hierarchical access control. The master key 10020 may only access the payload 10092 due to its traversal path through the lock graph. This lock graph may show the flexibility of the modular lock nodes and their access control layers working together. Separate data packets may be protected in different ways within some or all of this single Nut. If the master keys 10012 and 10020 can be the same, the key holder may be allowed access to both payloads.

Fig. 101 shows a simplified embodiment of a multiple Nut configuration: any one of user keys 10110 may access some or all three payloads, which may depend on their level access control. The key 10120 of SSLOCK 10122 may only access the payload 10194 due to its lock node concatenation. This lock graph may show the flexibility of the modular lock nodes and their access control layers working together and/or individually. Separate data packets may be protected in different ways within this single Nut. The flexible nature of the present disclosure may allow for infinite variation in lock configurations.

FIG. 102 shows a simplified embodiment of a direct lock model with multiple payloads: this lock map may show a flat topology of Nut rather than the usual linear one. ORLOCK 10212 may be a node of interest because there may be several ways to implement the multiple join keys needed 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 is a key map that may be embedded in a keykey hole and then may be propagated into the output section. In addition, hierarchical keys may also play a role as to which keys are accessible to various nodes.

Fig. 103 showsA simplified embodiment of an ordered messaging instance is shown: it can be a collusion resistant design using Nut and relationship-based key (rbk — forward reference). Data 10310 may have relationships to Alice, Bob, Charlie, and Danny, respectively. Some or all of the participants may be aware of each other. Their relationships can be synchronized by having a relationship-based key with each person. Data may wish to send a secret set of instructions to individuals but it may wish to read messages in a certain sequence without prior peeking through collusion among participants. Data can thus have particular content built into each of these four Nut. Nut sent to Alice 10320 may be opened only by Alice because it may use a RBK group lock between Alice and mr. 10320 internal can be a message for Alice and a secret key K for Bob_Bob. She can read her message and can use the key K_BobAnd sending the data to Bob. Nut sent to Bob10330 can employ MATLOCK, which can only be opened using two keys at the same time: data and Bob's RBK key and Alice's key K between Bob and mr_Bob. 10330 inside can be a message for Bob and a key K for Charlie_Charlie. He can read the message and can use the key K_CharlieAnd sending to Charlie. Nut sent to Charlie 10340 may employ MATLOCK, which can only be opened using two keys at the same time: RBK key of Charlie between Charlie and mr. data and key K from Bob_Charlie. 10340 may internally be a message for Charlie and a key K for Danny_Danny. He can read the message and can use the key K_DannySent to Danny. Nut sent to Danny10350 may employ MATLOCK, which can only be opened using two keys at the same time: danny's RBK key between Danny and mr. data and key K from Charilie_Danny. 10350 may internally be a message for Danny. He can read the message and the plan of mr. data to sort messages that may have worked.

In the field of network security, the "backdoor" feature can have a negative meaning in various conversations around a topic. Traditionally, the backdoor mechanism may have been implemented at the application level, which may have allowed free access to the data processed by the application. This type of application level access may have been constructed as a serious compromise to the security of the data processed by the application, depending on which party gains access to the back door entry. The perception of compromise in these situations may be well-founded due to the popularity of such applications primarily dealing with unencrypted data within their own application memory, thereby potentially granting access to plaintext data to back door users. In Nut and in particular in the lock-in model of Nut, some may observe the use of the master key as a backdoor type into Nut; however, it can be quite different in technology, since in all locking models of Nut, all doors (keyways) are front doors and appropriate cryptographic keys are required to obtain access to Nut. The nut API or any nut related application embodiment may not have an expected backdoor designed at the application level. There may be several legitimate reasons for having a master key entry available for Nut, but all such entries may be defined by only one secret key and may be directly noticed by a rough test of the input section of any lock node. Thus, any application attempting to install a back gate type function within a Nut-related application may do so only after first gaining access to the master key of the target set Nut, and it may only be applicable to Nut where that master key is valid. This may depict the flexibility, compartmentalization, protectiveness, and/or resiliency of the data center approach to Nut security.

In some or all access control methods in nut, a pattern may be involved that hides the cryptographic keys within the encapsulating data structure, the expansion of which may reveal other keys that may allow access to the target data set. In the embodiments depicted in this disclosure, most of these key hiding methods may use data encapsulation and/or data folding methods. The method of hiding the access key may be a preference formed by the implementer or it may be parameterized within each nut. These methods may include data folding, data encapsulation, attribute-based encryption, function encryption, authorization tokens from a reference monitor, or any other method that can provide selective cryptographic display of subsequent access keys when provided with access material to decrypt or unlock its cryptographic mechanisms. The illustrative embodiments in this disclosure may be chosen for their simplicity and straightforward mechanism and their well-known properties. Other equivalent mechanisms may streamline or more efficiently certain aspects of the embodiments but they may still provide essentially the same functionality, controlling access to access attributes that may be granted access to a target data set and may be independent of any reference monitor by default. Any equivalent access attribute of the display method may be replaced with the method so far depicted as providing the same level of protection for the content of nut.

This can be inferred about the segments of Nut containers and their internal workings. The internal mechanism may be embodied directly or by the use of an SDFT method that may readily encode and manage this embodiment. The payload of Nut may be what Nut ultimately may protect, which may be any storable digital data such as, but not limited to, a text archive, a binary application, an image archive, an access key for a remote system, an executable script, an authentication to securely establish a computer-to-computer connection, an entire database, an operating system, a link to other nuts, streaming data, and/or a text message. Because Nut describes what they can hold through its rich configurable metadata, the standard list of common profile types may be far less than they can hold. The lock node architecture may allow the payload to span Nut, which may result in an unlimited logical container size. If a solid state Nut compatible chip or circuit is available, it is possible to transform a physical device into Nut itself, so the device can only be accessed by a key holder. A series of such devices may constitute an entire network and an internal network that can only operate under proper authentication. The flexible nature of the modular lock node design may allow for infinite variation in the lock configuration of Nut. In the following section, various systems and/or methods may be introduced that may use Nut as a basis for secure storage to show how some common services and methods may be extended, improved, and redesigned to provide capabilities that may already appear to exceed the scope of an average user.

Modular I/O

A programmer may expend a great deal of effort to ensure that data is properly brought into a program, transformed, computed, and/or edited in its running memory space, and then properly permanently stored. An undesirable side effect of this application development model may be the eventual degradation of the file format and its various versions. Having, owning, and controlling our own data may be a useful and desirable goal, but with the use of whether or not you can read it properly? The read format, write format, ability to act on read data, and/or display read data may constitute some of the basic components of a typical program. Modular I/o (mio) may be a system and/or method that modularizes this logical operation into a repository of modular components that may be used by any of them that may be accessed. A side effect of the MIO may be the ability to generate a file format conversion module that may allow a user to access past versions of the archive read and write routines so that their old data may be read. This may be referred to as backward compatibility. A concept of forward compatibility may also be provided, but the utility of this feature may depend on the skill of the programmer that may design the application module. A preferred embodiment of the MIO system may be that some or all modules may be encapsulated in Nut, thus providing authentication, protection and/or access control of each module upon default recognition. FIG. 104 shows typical components in a modular I/O. The element 10450 may be a modular I/O repository (MIOR), which may be a server program that stores and organizes 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 of the user. In other embodiments, the MIOR may have a local cache on the local device, so it may be better to facilitate commonly requested MIO modules. A typical application 10402 that can read and/or write to a file 10404 can be conceptually and programmatically divided into modules to read 10406 and write 10408 files. Archive 10404 may be formatted in a particular format "A" that may be specific to application 10402. Similarly, this figure shows two other applications 10410 and 10418 with corresponding data files 10412 and 10420 and their respective read and write modules 10414, 10422, 10416, and 10424, which may be stored in a special format (which may be "B" and "C") in the MIOR 10450. The MIOR may contain other modules that may perform different tasks or programs of the application. Depicted by 10426-10432 can be an archive conversion module that can perform the conversion from one file format to another as specified by their respective tags: the module Convert _ a _ B10426 can Read data from the File format "a" into the memory of an application through the File reading module 10406 and then it can Convert the memory structure into a memory structure similar to that which can be generated by the reading module File _ Read _ B10414.

Modular I/O: reading and writing

FIG. 105 shows a simple read and write operation using MIOR 10500. The application 10502, which can process files that can be stored in the File format "A", can Read the File F _ A10504 formatted in the format "A" by requesting a File Read module File _ Read _ A10506 from the MIOR 10500. Module 10506 (if found) can be transferred 10510 to App _ a 10502, at which point App _ a 10502 can install and can execute File Read module File _ Read _ a 10506 on File F _ a 10504. The module File _ Read _ A10506 can perform a File Read on the File F _ A10504 and can construct an internal memory structure that can represent the contents of the File F _ A10504. This memory structure, which may represent the contents of the file F _ a 10504, may then be passed 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 be present in its running memory space. In other embodiments, once the contents of the File may have been Read by File Read _ a 10506 (if there may be a facility), the memory structure may not need to be transferred to App _ a 10502, so that the File Read module 10506 and the application module 10502 may share the same memory space.

When the application App _ A10502 is ready to store the modified contents of File F _ A10504 back in File form, it may contact MIOR and may request a File Write module of File format "A" (referred to as File _ Write _ A10508). After receiving 10512 module 10508, App _ a may install and execute the module using the same method for transferring application memory structures as the read program. The write module 10508 may perform write operations to persistent storage, which may generate a modified file F _ A10520. The requests for the MIORs of the read and write modules 10506 and 10508 may be done in any sequence deemed appropriate by the application developer. In one embodiment, the application may pre-request some or all of the relevant I/O modules before starting in order to ensure that some or all of the necessary I/O operations may be performed by the application, which may prevent any undesired failure that follows. In another embodiment, there may be a local cache MIOR through a previous fetch module of a previously running application that may be maintained in order to speed up the request and fetch process.

There may be many ways of transferring and/or sharing memory structures between two or more logical programs to one of ordinary skill in the art, such as, but not limited to, shared memory segments, memory mapped files, databases, inter-program messages, binary memory dump files, and/or translated memory dump. A preferred method of application memory transfer in an MIO system may be to use a translated memory dump between programs. The JSON read and write functions may be modified to recognize binary data and may automatically convert it to base64 encoding and from base64 transcoding or other binary to text encoding schemes. FIG. 106 shows data translation and transfer that may be involved in a typical MIO file read operation. The MIO Read module File _ Read _ a10604 can Read 10620 the File named F _ a 10602 in format "a" into its run memory 10606. Thus, the relevant contents of profile 10602 may be represented 10630 in application memory structure 10606. The application memory may be stored into a JSON-compatible data structure 10606 and may be tied to a set of function calls using JSON write to a text form 10610. Optionally, the JSON output can be embedded into Nut container 10608 to add security. Thus, the application memory 10606 may have been converted and stored 10608 external to the read module 10604. Nut 10608 can then be opened and read into memory by App _ a 10612 and JSON reads can be performed on data packet 10610. Thus, the data is reconstructed into the run memory of App _ a 10614. Data transfer methods 10622 and 10624 may include, but are not limited to, command line arguments, inter-program messages, and/or data file(s). The read 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 dynamic capability to modify its running code in real time.

Modular I/O: backward compatibility

An application may undergo gradual changes over time by publishing version changes with enhancements throughout its lifetime. Many of these version changes may include format changes for the storage file that holds the user's work. Historically, this can lead to two problems: encumbrance and degeneration. Encumbrance may be when software becomes bloated in every version of every format change due to adding backward compatibility capabilities to the life of the production line. This may involve a large number of format version changes. Furthermore, if there may be other third parties or open formats that an application may wish to handle, it may result in larger software blooms. FIG. 105 illustrates how an application may utilize any version of any format, and if a modular read and write module is available in a MIOR, a file may be read and processed without any oversize. Furthermore, FIG. 105 shows how newer read and write modules can be added separately to the MIOR and each application that can communicate with the MIOR can now have access to additional formatting modules without any program modification. These newer modules may be the ability to read different versions of the archive format of the same application production line or they may be compatible modules that read and write third party file formats written by either, including the application developer.

Fig. 107 shows a backward compatibility example, where the version of the application App _ B10702 may be newer and may use a corresponding newer format version "B" of the data file but the user may desire to read and write the older version "a" of the file format 10704. Data conversion modules such as 10708 and 10710 may be generated and stored in the MIOR 10700 for such cases. The conversion module may be responsible for reading one format and generating another: in this example, conversion module 10708 can read the "A" formatted file and can convert it to a "B" formatted file; the conversion module 10710 may read the "B" formatted file and may convert it to an "A" formatted file. File F _ a 10704 may be presented to App _ B10702, where it may be determined that the file may be in an incompatible format from the metadata and the MIOR 10700 may continue to be requested to obtain the sequence of read modules necessary to read "a" and a "B" file may be generated. The MIOR 10700 can send the following modules to App _ B10702 mode response: file _ Read _ A10706, File _ Write _ A10712, Convert _ A _ B10708 and Convert _ B _ A10710. App _ B10702 may call File _ Read _ a10706 to File F _ a 10704, File _ Read _ a10706 may then call Convert _ a _ B10708 and may transfer its memory structure in "a" form to module 10708, then module 10708 may Convert the received data to "B" form and may transfer it to App _ B10702. When App _ B is ready to save the modified data back to File F _ A in "A" format, it can then call Convert _ B _ A10710 and transfer its memory structure in the form "B" into module 10710, then Convert _ B _ A10710 can Convert its memory structure to the form "A" and can call File _ Write _ A10712 and can transfer its memory structure in the form "A", then File _ Write _ A10712 can overwrite File F _ A10714 with its modified content in the form "A" and can format the File Write in File format "A". A more complex example may be to call several conversion modules in sequence to perform an iterative conversion procedure on an appropriately older format version or a developer may have added frequently used version change converter modules such as Convert _ B _ F and Convert _ F _ B in order to streamline such requests.

Software bloat can be plotted using a simple calculation: assuming a popular application may have been subject to 5 major revisions, 3 format versions across 3 operating systems have major version changes each within 10 years. It is also assumed that each of these changes may have required a different version of the applied I/O routine. This can potentially result in most current versions of an application carrying up to 135 versions of its I/O functionality within itself. Given that this can be an extreme case, we can understand the proliferation of program code that can be generated in order to maintain backward compatibility in an application over time. This characteristic may be referred to as the cumbersome nature of the software.

A properly maintained MIOR 10700 with consistent update modules added to its repository may act as a historical I/O format repository and may allow users to access older versions of their data files at any time in the future: this may solve the problem of software and data format degradation. When an application may no longer be produced, sold, and/or maintained, its lifetime may be drastically reduced because newer versions that may be allowed to run on newer operating system versions may not be forthcoming. Data files formatted by an application may be difficult to access when the application is no longer running on a modern computer due to incompatibility. Smart users and developers may have found various solutions to these problems but may require more effort and/or expertise in their part. Using the MIOR may require that at least one developer may maintain modules that may be associated with non-existing applications and that may periodically add newer versions of modules that may be compatible with newer versions of various operating systems. This type of routine maintenance can be automated in a timely manner using automated unit test tools and self-generated OS type and version appropriate modules. The updated modules may be inserted into the MIOR and may have access to the MIOR each may benefit from the developer's work; if a particular MIOR is accessible by each on the Internet, some or all users on the Internet may automatically benefit from it without requiring the user to have knowledge of lower-level problems and procedures that may be invoked to automatically resolve the problems. Software backward and forward compatibility issues may be referred to as the degenerate nature of the software.

Modular I/O: forward compatibility

Users may sometimes experience a situation in which they may have brought, installed, and/or used an application many years ago, but they may have not purchased a subsequent update of the application within these years. However, the user can still run the application but it can only read and write file formats that are compatible with older versions of the application. The latest version of the application may have introduced a newer file format with additional features at some time in the past. This situation may present two problems to the user: 1) the application version of the file can not read the file formatted as the latest format version; and 2) other programs that can read the latest format from this application cannot access their older formatted data. The solution to the first problem may be referred to as a forward compatibility read operation, whereby its older application may load a set of modules directly from the MIOR that may perform progressive conversions on data, which may allow a user to read a file formatted as a newer version using its older program. The solution to the second problem may be referred to as a forward compatibility write operation, whereby its older application may load a set of modules directly from the MIOR that may perform progressive conversions on data, which may allow users to write a file formatted as a newer version using their older program. Procedures established in view of forward compatibility may make this type of transition easier and seamless using an MIOR with minimal or no loss of functionality. Newer features provided as newer format versions may be optimally mapped to less complex application constructs or may simply be replaced with the original data and allow the user to modify it at a later time. Fig. 108 depicts these two different logical operations using an example.

Forward compatibility read operation: app _ a 10802 may be compatible with files formatted as version "a" but the user may wish to read a newer file format "C". This request may be communicated to the MIOR 10800 and it may perform a sequence of modules of this regression transformation in return: file _ Read _ C10806, Convert _ C _ B10808 and Convert _ B _ A10810. The module File _ Read _ C10806 can Read the File F _ C10804, which can be formatted as version "C". Module 10806 may then call the regression conversion function Convert _ C _ B10808 and may transfer its memory structure to that function. Module Convert _ C _ B10808 may perform a conversion on the data in memory and may generate a memory structure compatible with format "B" (a previous file format version of the application). Module 10808 may then call the regression conversion function Convert _ B _ a 10810 and may transfer its memory structure to that function. Module Convert _ B _ a 10810 may perform the conversion on the data in memory and may generate a memory structure compatible with format "a" (the expected file format version compatible with the older application App _ a). Module 10810 can transfer its memory structure in format "a" to the calling application App _ a 10802 and App _ a can process it. Thus, newer versions of a file format may be read through older versions of an application without modifying the application.

Forward compatibility write operation: app _ a 10840 may be compatible with an archive formatted as version "a" but the user may wish to write a newer file format "C" that may exceed their original capabilities. This request may be communicated to the MIOR 10800 and it may reply with a sequence of modules that may perform these progressive transformations: file _ Write _ C10816, Convert _ B _ C10814 and Convert _ A _ B10812. App _ a 10840 may call Convert _ a _ B10812 and may transfer its memory structure to the function. Module Convert _ A _ B10812 may perform transformations on the data in memory and may generate a memory structure compatible with Format "B". Module 10812 may then call the gradual conversion function Convert _ B _ C10814 and may transfer its memory structure to that function. Module Convert _ B _ C10814 may perform the conversion on the data in memory and may generate a memory structure compatible with format "C". Module 10814 may then call the File Write function File _ Write _ C10816 and may transfer its memory structure to that function. The module File _ Write _ C10816 can Write to File F _ C10818, which can be formatted as version "C" (the desired File format version). Thus, newer versions of a file format may be written by older versions of an application without modifying the application.

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

Modular I/O: display device

Fig. 109 shows a diagram of the MIOR display module in operation. Once the application App _ a 10902 can have successfully read data from the profile F _ a 10904 into its memory, it can continue to use the functionality of the module Display _ a 10908 to Display the contents of the profile F _ a 10904 to the user. In a display module, the functional aspects of the module may vary greatly depending on the application, the data content, and/or the design of the developer. Some modules may be designed to use a shared memory approach, which may allow the display module to directly access data in the application storage, other modules may transfer data to the display module and the display module may allow it to show the data. Other embodiments of the display module may be screen formatting instructions and/or templates for showing and possibly editing data types. This modularization of display functions may allow custom display modules to be generated for a variety of hardware and OS platforms while allowing the caller to remain relatively unchanged.

The collection directory architecture subsequently discussed in the NUT book section may take advantage of the lightweight aspect of the modular display. Instead of building a larger monolithic application to handle, display, and/or edit different sets of data sets, the NUT book may leverage the MIOR architecture, which may allow the NUT book to be customized one by one based on the payload type in the NUT under test.

Modular I/O: applications of

In fig. 110, MIOR11000 may store modular application modules such as 11022. NUT browser 11020 (forward reference) may be an application that may be similar in appearance and behavior to most archive and directory browsers but it may recognize NUT and may work on it by looking at NUT's extensive metadata. Within Nut 11030, metadata 11002 may be information about the type of payload that it may protect and store. When the user selects NUT from NUT browser 11020 and double-clicks open it, the NUT browser may open NUT and may read the metadata to indicate which modules may be needed to open the archive. The metadata may include data such as, but not limited to, an application version, a file format version, and/or a display version. The NUT browser may then request 11004 MIOR11000 to find applications App _ a 11022, File _ Read _ a 11024, and Display _ a 11026. MIOR11000 may return some or all of the modules and may invoke application App _ A11022 by NUT browser 11020. Once App _ A is running, it can call File _ Read _ A11024 in order to Read the contents of Nut payload F _ A11028, which can be stored in Nut 11030. After passing the memory structure from 11024 to the calling module App _ a 11022, it may call Display module Display _ a11026 to show the data F _ a 11028 to the user.

Modular I/O application modules can vary greatly in their maintainability and accomplishment: in some embodiments, it may be a complex logic computation module; in another embodiment, it may store the entire software installation package; in another embodiment, it may contain some or all aspects of I/O, display, and/or application functionality; in another embodiment, it may contain information including a Genesis Nut that may recoil start the regeneration of the user's environment in a remote manner. The functionality of the modular I/O application module is not limited to such cases.

Modular I/O features such as read, write, display and/or application may be overlaid with access control mechanisms at the MIOR or container level so that only appropriately authorized users can access it. Such access control mechanisms may include, but are not limited to, access control policies, ownership requirements, and/or DRM mechanisms for enumeration purposes. Most access control can be derived from the nature of the Nut container in which the module can be stored. As the present invention is discussed in further detail, the mechanisms by which such MIOR requests can be derived are apparent. 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 that may specify details of the data format, such as, but not limited to, the application version from which it was generated, the display version, the file format version, the size, the time of generation, the time of last modification, the author, the file type, and/or the summary. The environment attributes, such as but not limited to OS version, application version, hardware manufacturing and/or version, may be provided by the application that opens Nut. With such pieces of information about the environment, the data content, and/or the requested operation, the MIOR may look up the appropriate module and may satisfy the set of modules of the operation or an error message in return. These modular I/O modules may run as a single or separate program on the same machine, across different machines, across different chips or cores, across networks, and other modes of running a logic program(s) on a computing device. Through these modules, degradation, encumbrance, adaptability, compatibility, and/or flexibility issues may be partially or fully addressed.

NUT history

The Nut container may be constructed to store a history of the payload. The form of history may include periodic snapshots, progressive increments, a complete sequence of events, or any combination of the three or any other disk storage methods. The form of the history may vary depending on the type of data stored and the application and/or preference and design of the data. The nut ecosystem may include methods and systems that support such data history save mode. These three methods of saving may be well established methods known to those of ordinary skill in the art. The physical location of the Nut history may be in the Nut part called Tale (figure 81) and its opacity may be controlled by Nut RAT.

FIG. 111 shows a simplified Nut diagram illustrating the progressive change in history structure over three points in time for two editing sessions covering a file. At time T1, Nut 11102 may hold data D111110 and its history may be null 11112. The user may edit 11126 data D111110 at time T2 and may generate a new version D211114. The application may employ a snapshot storage method and may store the original version of data D111110 as a snapshot of the data in Nut's history section 11116 at time T111118. Subsequently, the user may edit 11128 data D211114 at time T3 and may generate a new version D311120. The application may employ a snapshot save method and may store the older version of data D211114 as a snapshot of the data in the history section 11122 of Nut at time T211124. At time T3, the history section 11122 may now hold two distinct snapshots 11118 and 11124 of the previous version of the data D311120. The user can freely browse and extract Nut's history 11122 at any time using a simple history extraction method, allowing for the recovery or generation of entirely new files therefrom. There may be Nut metadata parameters that may control the type, frequency, and/or age of the history section in order to set a reasonable history growth of the data at hand. For some text files, it may be practical to keep some or all changes forever, as their size may be relatively small when using a save-by-save-delta approach. This may allow Nut to generate some or all saved versions of the file at any time thereafter. The binary file may be saved as a snapshot or delta depending on the application. Some event driven applications may archive a complete set of event sequences as their history. It should be noted that the Nut history may be stored within the Nut itself and may be independent of an external program and/or storage system. Any payload may be historically archived in this manner as long as there may be an archiving method that can be used for the type of payload in a nut environment.

NUT logs

The Nut container may be constructed to store an event log of Nut. Since a computer process can read, manipulate and/or write Nut, it can generate and leave an audit trail of the logical operations performed on Nut within Nut itself. The audit trail may exist essentially on a per object basis from the object perspective. Thus, between the Nut history and the Nut log, the chronological history of events since the start of the data object may be stored in a single container for further review at a later time. The accuracy, content, and/or granularity of the Nut archive may depend on the rigor and methodological use of such features by the developer of the application operating on Nut. The physical location of the Nut log may be in the Nut section called Vita (fig. 81) and its opacity may be controlled by Nut RAT.

Fig. 112 shows a simplified Nut diagram showing the progressive change of its event log structure over three points in time covering two events occurring on Nut. This example can continue the case from figure 111 for Nut history. At time T1, Nut 11102 may hold data D111110 and its log 11212 may hold one log entry 11218 that may indicate event E1 that generated Nut 11102 at time T1. The user may edit 11226 data D1 at time T2, which may produce a new version of data D211114 in Nut 11104. The editing application may record an event log entry into Nut log 11216 at T2, as may be indicated by component 11222. Subsequently, the user may edit 11228 the data D211114 at time T3 and may generate a new version D311120. The editing application may record an event log entry into Nut log 11230 at T3, as may be indicated by element 11224. At time T3, log section 11230 may now hold three distinct event log entries 11218, 11222, and 11224. The user can freely browse and extract the journal 11230 of Nut at any time using a simple journal extraction method, which can allow auditing on Nut. There may be a Nut metadata parameter to control the type, frequency, and/or age of the journal segment in order to set a reasonable and appropriate journal growth for Nut.

System managers and application developers may know the effort and effort involved in tracking errors and errors on their systems when more than one application may be involved in modifying a data object, as they may have to browse event logs for some or all participating applications (if they may have access to all of these) and may filter out event log entries for problematic objects and then may manually reconstruct such events in a sequence in which they may occur on the object. With the use of Nut logs, this collection, filtering, and reconstruction of event logs may have been done at the object level from the object perspective. In addition, the metadata for Nut may specify the working application to an event granularity of event log message details that the object owner may expect. This granularity may range from a compact debug level to a detailed debug level in order to track the various lines of investigation. The highest sensitive confidential payload may require the highest level of granularity of event log details in order to perform an audit trail on its access history. In short, this can be an auditable past consistent and customized method of controlling objects on a per-object basis per granularity level required by an object by any application. The term consistent may refer to consistent design and operation of available journal features and the term customized may refer to per-object preferences that the design can accommodate.

Relationship-based Key (RBK)

The description of how a relationship-based key (RBK) can be established should be overtaken by anyone who can have used encryption tools manually: bob and Alice may wish to communicate privately and therefore they may trade randomly generated asymmetric cryptographic keys (only the public part) with each other or may use the keys in a tool such as PGP or its effects to exchange encrypted messages and files. The protection and management of the key pair by Bob and Alice may depend entirely on them. This can lead to the deliberate and difficult task of properly establishing, maintaining, and utilizing relationships, potentially requiring Alice and Bob to have access to the password, its proper use, and/or key protection. This type of key exchange may occur when Bob or Alice does not have an established public key certificate via a centralized directory or a trusted web site. It may also occur when the participant feels that creating a fully private communication channel may require an additional layer of privacy.

What may happen if RBK is a preset communication method for Alice and Bob, etc.? What the consequences may be and what may be needed to make it happen in a painless manner? System aspects of the establishment, maintenance, and/or use of RBKs may be automated. It is constructive to explore some properties and consequences of the consistent application of RBKs before exploring how to systematically accomplish their details.

Characteristics of relationship-based keys

The trust level between the two parties may be a dynamically adjustable parameter. This can be an observation of a real-life relationship between any two parties: trust may be relative. Which may flourish over time based on events and communications.

One-sided adjustment of trust level. Any party in a relationship can change the trust level of its relationship, either unilaterally, with or without notifying the other party, as desired.

The relationship channel health can be determined from the message context. Either can crack the system and keys from time to time. The preset use of the RBK may allow either party to test the communication content and may determine the likelihood that the system or key of the other party has been compromised. In the simplest case, a message from Bob without RBK encryption may be a broken token.

The true nature of the relationship can be evaluated over time. If a message of unusual nature is transmitted via the RBK and the sender's key may not have been broken, the sender may have changed the nature of the relationship.

Loss of a relationship may be permanent and some or all of the history of the relationship may lose commercial and/or meaningful value. Unilaterally, any party can break the relationship by blocking their messages or erasing their RBK group. This logical operation of the relationship channel may present a deterministic one-sided message blocking capability for each user.

The parties may strictly adhere to the basic principles of mutual compliance or risk bearing loss relationships-the basic principles may change over time. Digitally, violation of the implication ground rule can result in a one-sided opening of the relationship in a permanent way.

It may allow for a tighter expression of real-world relationships in a form of digital cryptography. Public key cryptography in its most widely used form can be a centralized model that can be contrasted with how people form relationships. The RBK may be distributed and may be cryptographically encoded using a public key in a private manner.

Destroy the insulation. The RBK destruction on Bob's environment may be isolated from the RBK channels that Bob and it may have established with his contacts (i.e., Alice). Damage to Alice's environment can be isolated from his channels with Bob and his mutual history bulletin. Some or all of the other relationship channels of Alice may be secure and may not be breached by a hacker that breaches the Bob environment.

The personal information manager or PIM may be 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. The PIM may provide tools such as, but not limited to, calendars, address books, contact management, passcode holders, notes, email managers, chat functions, project management, key managers, calculators, task lists, and/or activity recorders. The PIM may be a combination of any of these functions or it may provide only a single function. PIM may be designed to operate locally in an isolated manner or in only the PIM web server, or in any combination thereof. In the discussion that follows, reference to such functionality of a PIM (such as an address book or chat or email manager) may be understood as a PIM that provides any of that functionality as its offering or it may be its sole functionality.

Fig. 113 shows how digital address book entries between Alice and Bob can be constructed to support RBKs in a consistent manner for some or all relationships in the address book. Alice's address book 11310 (which may be a function provided by her PIM) may have two entries: an entry 11320 for itself and an entry 11330 for Bob information. In Alice's own entry 11320, it may have listed its own basic contact data 11322 and some personal details 11324. The address book entry 11320 for Alice may be stored and may be fixed as a payload in a Nut file on Alice's system. On Bob's contact card 11330, Alice may have some contact information 11332 for Bob, such as his name and email address. Bob's address book entry 11330 may be stored and may be fixed as a payload in the Nut file on Alice's system. Bob's address book 11350 (which may be a function provided by his PIM) may have two entries: an entry 11360 for itself and an entry 11370 for Alice information. In Bob's own entry 11360, he may have listed his own basic contact data 11352 and some personal details 11354. Bob's address book entries 11360 may be stored and may be fixed as payloads in the Nut file on Bob's system. On Alice's contact card 11370, Bob may have some contact information 11372 for Alice, such as its name and email address. Alice's address book entry 11370 may be stored and may be fixed as a payload in the Nut file on the Bob system. When Alice and Bob decide to establish an RBK with each other, they may decide to establish a private two-way communication channel between them. Alice may begin the process by generating an asymmetric key pair 11334 and 11336, storing it under Bob's address card 11330, and transmitting 11344 the public portion of the key 11334 to Bob. Transport 11344 may be accomplished by a passphrase security Nut, a message written on paper, a telephone call made to Bob, a message using Bob's public key known externally, or any version of a secure key exchange protocol known to those of ordinary skill in the art. When Bob receives this message with the key 11334 within it, it can store the message in Alice's address card entry 11370 as a key 11334 to send the message privately to Alice. Bob may then generate an asymmetric key pair 11374 and 11376, store it under Alice's address card 11370 and transmit 11346 the public portion of key 11374 to Alice using the public key 11334 that Alice sent to it to encrypt the message. When Alice receives this message, it can decrypt the message from Bob using its private key 11336 for Bob messages. She can extract the internal key 11374, she can store the key in Bob's address card entry 11330 to send the message privately to Bob's key 11374. She may generate a confirmation message for Bob encrypted using key 11374 from card 11330 and may send the message to Bob over any working communication medium. Bob may receive the message, which may then decrypt the message using key 11376 from card 11370 and may mark that its RBK group was created and interacted with Alice.

The steps in this RBK setup between Alice and Bob may be automatic and may be initiated using a single action button or command. This may be the basis for the operation of how the NUT book manages its set of contacts and may be discussed later in the NUT book portion of this document. Bob or Alice can repeat this process separately for some or all of the contact cards in their respective address books in their PIM. Finally, each person can establish an RBK channel for each of their contacts, which can be considered a private communication channel for each of their relationships. If Cathy is a common good friend between Alice and Bob, the RBK relationship of Cathy and Bob may be different from the RBK relationship of Cathy and Alice and the RBK configuration may reflect this reality.

What can we do for Alice or Bob, since we can have defined the context of the RBK and its system usage? The consistent use of an RBK to send messages between two entities may allow monitoring of the health of their communication channels. An example of a practical use may be SPAM email reduction. It is estimated that the global internet bandwidth and significant capacity of data storage can be occupied by SPAM email of both malicious and/or commercial types. We can venture that not many people welcome this SPAM capacity. Some common approaches to SPAM reduction may be to use filtering techniques based on content pattern recognition, domain exceptions, address exceptions, and/or actually law enforcement shutdown rich SPAM servers. In a mode where RBK encryption may be the default communication mode, SPAM may be detected in a more deterministic manner.

One of the major obstacles in the process of automation programs such as RBKs may be the significant lack of user affinity, user accessibility, and/or user control of personal Public Key Infrastructure (PKI) applications. The use of NUT books along with NUT may attempt to fill in PKI gaps. It may provide a flexible, secure and/or user controllable method to store, manipulate and access this information in a seamless manner.

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

Fig. 115 shows a flow diagram for reducing SPAM between Alice and Bob that may now have established an RBK communication channel and which may be their default communication method and which may use an unpublished private-anonymous email address. If the email is encrypted via the RBK between Alice and Bob, it may be a valid email from Alice to Bob or vice versa 11514. If either person receives an email from another person that is not encrypted using the RBK, the email is likely SPAM and can be filtered out and stored in SPAM grid 11512. This example may assume that the set of private email addresses may only be used between Alice and Bob to send RBK encrypted messages to each other, thus also extending the RBK channel concept to the email address level. We can define this type of communication channel directed email address as an anonymous email address.

The communication channel between Alice and Bob, which may consistently use the RBK via anonymous email addresses, may exhibit certain characteristics that may be analyzed to determine the health of the relationship itself. We may have removed some or all unencrypted SPAM messages from the channel by default, as may be described in fig. 115. We can now test the context of the appropriate RBK encrypted message. The table in FIG. 116 lists the healthy deterministic context-based state matrix of the Alice-Bob communication channel. It may require a certain evaluation of the content by Alice to indicate what their relationship may be happening? This shows Alice's one-sided action matrix, which may be based on Bob's behavior, as evidenced by messages sent by Bob to Alice.

The last symptom listed in fig. 116 may create an interesting case when Bob's role can be replaced with a website provider (i.e., Alice may have established an anonymous RBK communication channel with a provider). The table in FIG. 117 shows a deterministic context-based state matrix of the health of the Alice-vendor communication channel. Alice may now have the ability to track whether this provider may have sold its information to spammers through the channel identifiable aspects of the anonymous e-mail address and RBK set. It can provide a level of transparency to the internal workings of the supplier's marketing department with a clear audit trail. This type of vendor can be made accountable by a general user in a system-specific manner. The consequences of a provider violating Alice's trust can be tragic as the provider may permanently lose the way to contact it. In fact, proper and consistent use of anonymous e-mail addresses and/or RBKs may allow Alice's digital equivalent to go out of a store and no longer come back; this may act as a deterrent to vendors not abusing their clients' personal information.

Figure 118 shows a deterministic context-based state matrix of the health of an Alice-vendor communication channel from the vendor's perspective. Channel characteristics may provide a provider with the same type of unilateral action that it can take to protect its business and possibly its clients. The use of this approach by a vendor may enhance its reputation for privacy and data security. It may also be implicitly stated that the provider may not participate in the wholesale unlimited resale of client data.

FIG. 119 shows how the use of RBKs can help isolate the breaking of sensitive data on a user's system. Bob11900 may have RBK channels with Alice 11910 and Dave 11920. Bob may have clicked on a trojan horse (Trojanhorse) website and may have infected a key recorder or equivalent malware and then the hacker may have been able to penetrate the secure data store of his RBK, such as his NUT book. Thus, the RBK group of Bob with some or all of its contacts may have been broken 11900. Bob may contact some or all of his friends and notify them of this breach or some of his friends may have inferred that Bob or his system is in error from the SPAM message sent to him using his private channel with Bob. If we look at Alice's NUT book 11910 (where she can store some or all of her RBK sets), she can mark her RBK set with Bob 11912 as having been compromised and can generate a new RBK set when Bob acts in concert to remove the virus on her system. This can be the degree of damage to Alice and it does not propagate to other RBK relationships that Alice has established. This is especially true when it also always uses anonymous email addresses with its contacts. Alice may receive SPAM from a hacker but the SPAM may be automatically ignored when it marks the channel as cracked or deleted. When Bob is ready, Alice can create a new set of RBKs and a new anonymous email channel and he can continue his digital conversation privately. Dave's procedure may be the same as its RBK store 11920.

Anonymous relationships

Digital relational topologies and conventions that have been promoted and enforced for the internet over the past few decades can be unnatural and unrealistic. Anonymity can be a strong relational construct and can be a level of relationship at which we can enjoy most casual interactions on a daily basis, such as but not limited to going to a pharmacy to purchase personal products, going to a dining room to purchase food, calling a taxi to go to a pocket, and/or appearing at a meeting. In contrast to this physical reality, almost every provider on the internet may wish to know who Alice is at all, including some or all of the personal information that it can obtain from Alice. Many suppliers may themselves remain relatively anonymous by not disclosing direct telephone numbers and may service customers through email, transaction systems, and/or remote outsourcing customer service representatives at remote customer service centers. The most common use of anonymity may be people who may wish to hide, such as hackers. There may currently be a dummy generation website for people who may wish to remain anonymous on the internet but who may have to keep track of anonymity in a very difficult way and may have to purposefully make prudent decisions dually. The use of RBKs and anonymous email addresses can bring some equality to this anonymity imbalance on the internet for general users and can authorize them to have more meaningful two-way relationships with providers and each other without relying on fake personalities and occasional duality.

FIG. 120 is a simplified diagram of the pre-packed personal data Nut. Nut may store detailed personal information about a person 12000. It may automate the pre-packaging of different subsets of this personal information for different purposes. 12010 may be a simple profile Nut that may contain only the name and email address. The anonymous profile Nut 12020 may only show an alternate email address. Shopping profile Nut 12030 may contain information fields typically required by a shopping website to purchase items. Protection of this subset of data from the master information 12000 may be accomplished via simple rules and filters and may optionally be generated during a registration process on the internet. Regardless of whether the vendor or service can accept the data Nut, the information can be used to insert into the correct field when needed by other methods. If the user utilizes an anonymous e-mail service (forward reference), the data Nut as in 12020 may dynamically provide the anonymous e-mail address generated for the particular relationship established.

Figure 121 plots a sequence of events in an automated registration process that can use Nut. A provider on the Internet can use and accept personal data Nut and can allow RBK channels to be established with its customers in an automated fashion. The user may access the provider's website and may wish to register 12100. The user may begin the process by directing their NUT book to be automatically registered with the vendor's website and may enter the URL of the registered website. The NUT book may query the vendor to extract information 12102 that the vendor may need to register for. The NUT book may constitute a subset of the user's personal information that the vendor may request and may show a preview for the user. The user may decide that the registration requested information may be acceptable and the NUT book may have collected relevant information and may proceed with procedure 12104. The NUT book may be extracted and a prepackaged NUT containing preview information may be generated and sent to the vendor's web site. The provider may accept the registration request and may send a query to the user's email address 12106 specified in the pre-packaged Nut. The user may receive a query from the provider asking him to provide evidence that he may not be a website bot (he may engage in trivial registrations) for his email by asking him to go to a specific URL to enter a verification code 12108 or other possible verification form. Upon successful entry of the verification code, the vendor can be confident that the request can come from one person and can proceed to establish an automatically generated login authentication, login key, and/or RBK set with the user. The NUT book of the user may automatically generate a login card for the vendor, its associated website information, login authentication, login key, and/or RBK group 12112. The registration process can be accomplished using user interaction at several points in the process: initialization, personal data package viewing/editing, and/or human inspection. The hassle of choosing a login name, passcode, entering personal information, and/or generating an entry in a passcode holder for the supplier may be undesirable and may be automated. When a user's NUT book is launched, it may seamlessly have real-time access to the provider in a full authentication mode, since the NUT book may automatically record it when required. It should be noted that this procedure may be accomplished using any vendor that employs this approach that may benefit from both the user and the vendor. Less trouble for users and providers may obtain more accurate information from their databases and possibly more possibilities for transactions between them.

Fig. 122 plots a sequence of events in an automated registration process using Nut and an anonymous e-mail address. A provider on the internet can use and accept Nut and can allow the establishment of RBK channels with its customers in an automated fashion using anonymous email addresses. The user may access the provider's website and may wish to register 12200. The user may begin the process by directing their NUT book to be automatically registered with the vendor's website and may enter the URL of the registered website. The NUT book may query the vendor to extract information 12202 that the vendor may need to register for. The provider may accept anonymous registrations so the NUT book may contact the NUT mail service and may request a pair of anonymous email addresses under its account. The NUT book may constitute and may show a preview of the data to be sent to the vendor registration, which may include the newly generated anonymous email address. The user may decide that it may be acceptable to register the requested information and the NUT book may continue with process 12204. The NUT book may generate a prepackaged NUT containing preview information and may send it to the vendor's web site. The vendor may accept the registration request and may send a query to the new anonymous e-mail address 12206 of the user specified in the pre-packaged Nut. The user may receive a query from the provider asking him to provide evidence that he may not be a website bot (he may engage in trivial registrations) for his anonymous e-mail address by asking him to go to a specific URL to enter an authentication code 12208 or other possible verification form. Upon successful entry of the verification code, the vendor can be confident that the request can come from one person and can proceed to establish an automatically generated login authentication, login key, and/or RBK set with the user. The NUT book of the user may automatically generate a login card for the vendor, its associated website information, login authentication, login key, anonymous e-mail address, and/or RBK group 12212. The registration process can be accomplished using user interaction at several points in the process: initialization, personal data package viewing/editing, and/or human inspection. The hassle of choosing a login name, passcode, entering personal information, generating an email address, and/or generating a new entry in a passcode holder for the vendor may be undesirable and may be automated. When a user's NUT book is launched, it may have seamless access to the vendor in a full authentication mode, since the NUT book may automatically record it when required. This procedure may not require personal user information and an email address that may have been generated specifically for this relationship, only suggesting that relevant emails between the user and the vendor may reach this anonymous email address. As various NUT-based services may be discussed later, some or all of which provide anonymous registration.

The communication channel that can be established using the RBK and anonymous email address can minimize SPAM in a deterministic manner due to its default mode of encrypting anything via the RBK. Furthermore, it may give bi-directional control of the channel to the parties that may be involved, so that there may be mutual respect to the relationship and its scope of implications. This implies that deviations from the relationship boundaries may pinpoint the relationship change event and may incur a one-way reaction ranging from self-checking to cutting off common relationships in a deterministic manner. For a third party attempting to corrupt Bob or Alice's data, in addition to retrieving the pair of correct anonymous email addresses, the third party may also have to crack the encrypted messages and files.

Websites that are acceptable and can process automated registrations can add additional services such as, but not limited to, age filtering. A parent may store a pre-packaged Nut on the Nut server of their child's device to indicate some sibling identifying characteristics such as, but not limited to, gender, age, and/or approximate location. This pre-packaged Nut may be automatically used to register the child on any child affinity or parent pre-approved website that can accept Nut. The provider may accept or deny access attempts based on this information and the services it may provide, such as, but not limited to, wine websites, tobacco websites, movie preview websites, adult content websites, and/or firearm websites. In addition, the Internet activity log Nut may be deployed on the NUT server of the child's device to monitor its activity and digital whereabouts. Parents can also manage restrictions on internet use by using this Nut across some or all devices in the home so that device switching is not critical to the child's daily cumulative internet use. Blocking or entry of certain websites may be accomplished by using this child identification Nut on the device itself and/or in conjunction with specific configuration settings on a Nut-based WiFi router (forward reference).

NUTS core applications

The table in FIG. 123 lists applications that may include a NUTS core application group. These applications may reside in most systems that may utilize Nut technology and which may handle Nut archives, as shown in this simplified diagram of the operating computing device in fig. 124. As previously mentioned, some or all such applications may have been referred to by the materials previously discussed in this disclosure. Such applications cannot be detailed earlier in this disclosure due to their dependencies on some or all of the core basic functions and capabilities of the nurs, such as, but not limited to, lock nodes, lock maps, Nut parts, Nut histories, Nut logs, MIOs, MIORs, Nut IDs, RBKs, gradient opacities, and/or anonymous relationships. Some or all of these core applications may refer to utilizing Nut as the basic unit of storage, which may be embodied by a general file but is not so limited. This may imply that some or all of the data touched, stored, and/or manipulated by such systems may be highly secure and access controlled by default. The design philosophy that may have been used in lock node design, which may assist the reader in understanding this core application more fully, may be a concept of iteration, integration, independence, and/or identifiability.

Nut core application: NUT server

The NUT server may be schematically depicted in the simplified diagram of the user device in fig. 125. There may be several key functions that NUT servers may perform to organize and maintain NUT compatible environments in the background. NUT server 12510 may run in the application space of a user computing device 12500. The device may have some storage 12520 in which Nut files 12522 may be maintained. The NUT server may be responsible for providing APIs and communication channels that start with various applications, including NUT books 12512, NUT browsers 12514, and/or other applications 12516 that include the device OS. The NUT server may also be responsible for maintaining external connections to other devices that may belong to users that may be running NUT server 12530 and possibly talking to NUT cloud 12540. NUT servers may not be a replacement for the file system of user device 12500 but may work through the native operating system and file system to access and process any NUT files.

FIG. 126 shows a simplified diagram of the NUT server and its main internals for function. The user device may have an operating system 12600 that manages hardware and software. The device may have external communications serviced by network interface 12602 and its associated drivers running through OS 12600. The device may also have a file system 12604 that may be attached to and managed by OS 12600. Data storage stored on the file system, which may be a MIOR 12610, and user data may be included in Nut 12606 and 12608. OS 12600 may also serve as an application environment in which a number of applications may run, including the applications depicted in the figures: NUT server 12620, NUT book 12642, NUT browser 12644, MIOR server 12646, and other applications 12648. NUT server 12640 may run on another device but application programming interface 12636 may also handle the communication.

Within the NUT server 12620, a module 12622 may exist that may perform authentication into the NUT server and may maintain a key cache. When the NUT server starts, it may not have any authority to peek at any security layer in any NUT. The user and/or hardware may provide the necessary authentication, which may allow the NUT server authentication module 12622 to gain access to certain key sets. This can be as simple as having a passphrase protected Nut that holds the key set and requires the user to provide the passphrase, open Nut, and cache the key set in its payload to protected/unprotected memory; or it may provide keys for secure hardware as found in many computing devices; or it may be a hardware token such as, but not limited to, a USB key available to the user. The key set may contain at least a NUT server authentication key and/or keys for NUT core applications that may be installed on the local device. There may be a cache 12624 that may be maintained by the NUT server for organizational purposes and efficiency. A portion of the cache may be an index of Nut IDs 12626. This index may contain some or all of the Nut IDs that the user may wish to keep track locally and remotely. Looking up a Nut ID in the index may indicate where the Nut ID can be found. Another portion of cache 12624 may be attributed to Nut cache 12628 in memory that holds frequently accessed Nut.

The NUT server may be responsible for synchronizing the contents of two or more NUTs having the same NUT ID 12630. Once a NUT server can be properly authenticated and it can have enough keys to access some or all NUT owned by the user, it can open various NUT to test its content and manage it. Each Nut may hold a version number and a last updated or modified timestamp. If an update occurs on Nut and the Nut server can inform it or the Nut server can notice it, it can notice the update and can look up the index 12626 to see some or all of the locations where a copy of this updated Nut may exist locally or remotely. The propagation and synchronization 12630 of the changes in the affected Nut may then begin systematically. This procedure may be quite simple due to the metadata embedded within each Nut (such as, but not limited to, Nut ID, version number, internal dign, history, and/or logs). If various modification criteria can be met, the latest version may simply overwrite the existing version. It may not be necessary for the NUT server to be able to partially or fully peek at a NUT because it depends on visual metadata as allowable by the gradient opacity of NUT as to whether a synchronization update can occur. Sufficient plaintext metadata may allow a NUT server without a key to synchronize some NUT to NUT in question. In cases where there may be a possibility of version forking or branching, the user may be involved in deciding which version is currently being made. Copy function 12630 may allow peer NUT servers to automatically propagate these types of changes across user control devices. When a user can install and connect multiple NUT servers to their device, the functionality provided by 12630 may constitute a personal NUT cloud for the user. The user can enjoy synchronization and/or repetition Nut on any of their devices in an automated fashion. When more complex versioning issues occur or some historical version of Nut may be requested, the revision control module 12632 may handle these requests. It may take advantage of the version-specific delta approach taken by Nut and may perform finer version granularity control to generate the desired version of Nut. These Nut-specific version-specific increment methods and the content read/write methods of Nut may or may not be present in the local MIOR, so a MIOR interface 12634 may be present to supply these functions when they may be needed.

Access Nut may be defined as a secure Nut that may contain authentication credentials for other systems or containers, such as, but not limited to, website login, database login, corporate system, personal device, software system, other Nut, Nut server, email system, chat system, and/or any digital system that requires a secret passkey and/or login ID. The NUT server may present an application interface 12636 for other applications to access its functionality. NUT servers may be identified by their application type and installation details, and additionally, may be assigned a NUT ID. The NUT configuration profile of the user device may point to a configuration directory or region in the file system 12604 where it may find an access NUT that maintains information for applications that it may need to know, such as, but not limited to, remote and/or local NUT servers. For example, the local NUT server 12620 configuration directory may hold an access NUT that contains the NUT ID, type and/or access key of the remote NUT server 12640. Successful opening of this access Nut may give the local Nut server 12620 enough information to attempt to contact the remote Nut server 12640 and authenticate it so that it can open a trusted communication channel and send Nut to each other. In a similar manner, there may be a configuration NUT for various applications that the NUT server may interact with. Since access Nut is Nut, it may remain synchronized, replicated, and/or propagated in peer Nut servers.

From this description of how NUT servers may operate, the iterative design methodology inside NUT may be extended to applications and how data associated with configuring and authenticating them may be stored and accessed. As much sensitive data as possible may be stored in Nut. The consequences of this simple statement become far-reaching when we consider the built-in functions and features of Nut and the functions provided by Nut servers. An unauthenticated NUT server may provide sufficient functionality to replicate, propagate, and/or synchronize NUTs that it may not have internal access to. This can be attributed to the gradient opacity property of a Nut: many Nut portions that make up the non-displayed metadata may be saved as plaintext and may provide sufficient information for many normal maintenance actions performed by the Nut server on Nut. Due to the security features that may be built into Nut, the security of the communication channel used to transport Nut between applications across a WAN or an internal network may be of less significance.

Using this approach to accessing Nut may solve several problems associated with software design, programming, and/or usage. For example, a drawback to software developers may be when they hard-code the entry and passcodes into their program code in the program that develops their program code in order to expedite the project into a test system, such as a test database or test application server. The transition to QA and the production mode of testing and development may be accomplished by adding an additional authentication program into the program code just prior to the stage where minimal testing may have occurred. In the case of using the access Nut, it may be integrated into the development program at the earliest stage and the program may never need to be changed, only the access Nut may be changed. The manager can assign and generate the appropriate access Nut for a developer, QA engineer, and/or production user. These access Nut may seamlessly integrate into their respective Nut book sets and may allow them to connect to their application resources without ever being separately signed. The manager may actually maintain ownership of the access Nut and change ownership as needed and the Nut server may eventually copy and/or synchronize ownership so that the end user may never be disturbed by it, whereby the project manager may remotely and securely manage the relationship between the user and its applications. Efficient use of access Nut may allow any user to configure their system for single sign-on (SSO): the SSO on its local NUT server can be automatically authenticated, if needed, and everything else. Hierarchical passcodes (forward reference) may allow for additional security for certain accesses and subsets of information.

Figure 127 is an alternative embodiment of the NUT server in which NUT cache 12628 may be replaced with the functionality of the NoSQL database 12728. NoSQL databases can be viewed by some as a subset of object-oriented databases and many of them can handle Nut-like containers that can be non-table structures very efficiently. Some NoSQL databases (such as CouchBase) may provide built-in replication and other features that NUT servers may employ to perform some of their duties.

Nut core application: MIOR server

The modular I/O repository or MIOR may be a server-based service as depicted in FIG. 128. This may be a typical embodiment of a MIO system and method. The computing device 12810 may have a local MIOR server running on the device with its own local MIOR cache 12812. If the local MIOR server may not satisfy a request, it may contact the well-known Internet-based MIOR server 12820 or its mirror 12830. Their respective caches 12822 and 12832 may be searched to obtain the appropriate MIO module in the request. If found, it may be sent back to the origin MIOR server on the user computing device. If the requested module is not found at the first MIOR server 12820 on the Internet, the MIOR server 12820 may contact other MIOR servers on the Internet to find the module. The original request may have a timeout or a cascading limit on the number of cascading requests that they may collectively form. In some embodiments, requests may be completed asynchronously rather than in a blocking mode (if appropriate).

A close examination of this procedure can be depicted in fig. 129. Application 12918 may be running on local device 12910, which may need to read Nut file 12908 into its memory. Nut 12908 may indicate that it may require some set of read and write modules for its payload from MIOR server 12914. The application may contact its home MIOR server 12914 and may request read and write modules for this Nut. The MIOR server 12914 may look up its local MIOR cache 12916 to see if it can have these modules. If the module is found, the position information of the module or the module on the local system or the network can be replied to the application. If not, MIOR server 12914 may contact other networks across WAN 12900 or MIOR server to request a module from a larger MIO repository such as 12920. MIOR server 12920 may be a dedicated server optimized to service requests from the internet for various modules. Once the MIOR server 12922 receives the request from the MIOR server 12914, it may check its local MIOR buffer 12924 for these modules. If found, the module in the request may be returned to the MIOR server 12914. If not, it may contact other MIOR servers in its peer group to search for the module. At the same time, it may send a "not found but continue searching" message back to the MIOR server 12914. When the remote request comes back to the requested module, the home MIOR server 12914 may authenticate the module before storing it in its home MIOR buffer 12916. As before, when an application 12918 instantiates and uses a module, it may also authenticate content using normal NUTS internal mechanisms.

FIG. 130 shows a flow diagram for fetching an MIO module from an MIOR server.

Authentication between the remote MIOR server and the home MIOR server may be established via a session key or an anonymous account, if so desired. Higher level services may include access to exclusive modules with custom encryption Nut, such as a company may wish to use a wide mix network distribution for its employees using custom development software but employees may only open and authenticate the custom module when they have an access key in an access Nut that may come from the company, so ownership information may always be fixed on a relatively open service platform.

A typical embodiment of the internal organization of a MIOR cache is shown in fig. 131. The cache 13100 may have a set of indices 13110 that may contain references to various modules that may be cross-referenced and indexed. The MIOR structure is not limited to this embodiment and may contain some or all of these organizational structures and techniques. Since each module can be stored in Nut, the primary Nut ID index 13112 can contain some or all of the Nut IDs of the modules and their locations in the cache. Archive I/O module index 13114 may list some or all modules of that type by description and Nut ID. Archive application module index 13118 may list some or all modules of that type by description and NutID. Archive display module index 13120 may list some or all of the modules of that type by description and Nut ID. The set module index 13116 may list some or all modules belonging to a set by description and Nut ID. Other indices may be established to allow efficient searching of the cache. Aggregate groups (forward reference) 13130-13150 are depicted in the figure to visually show how the relevant modules may be grouped together. The aggregate grouping method may play an important role in the operation of the NUT book.

Nut core application: NUT browser/NUT shell

FIG. 132 shows a diagram of a NUT browser application. A NUT browser may be essentially a Graphical User Interface (GUI) that may run on the functionality of a NUT shell Command Line Interface (CLI) application. Commonly known shell programs may be a bash shell, csh, cmd. Commonly known archive manager programs may be Windows, Apple seekers, and others. The user-oriented behavior of these two programs may be very similar to their commonly known counterparts; however, the difference may be that the NUT browser and NUT shell can recognize NUT and can process it more fully to take advantage of the rich metadata that can be stored in each NUT file. Each Nut file can be identified by two methods: the name of the surface 'Nut' file extends and/or explores more deeply as the content of a Nut. Most file systems can accommodate the archive name extension method. The Nut read attempt may be used when attempting to confirm that a-Nut file may actually be a Nut or when introducing new files into the home system from an untrusted source.

Most popular operating systems, such as Mac OS, Windows, and/or Linux, may use several methods to identify file types, including file name extensions, magic numbers, Uniform Type Identifiers (UTIs), file system attributes, and/or others. File name extension may be the most superficial approach, since the link between content type and identification may be cut off when a file name may be changed. Magic numbers and UTIs may be a compact but limited form of metadata embedded at the file header and may require access to a file type index to cross-reference what the content may be. This file type index may exist in the OS, file system, or other external system. File system properties may be represented as properties of an archive object that may be attached to an instance within an indexing mechanism of a file system. This information may only be valid in the domain of the file system/operating system combination where it can be recorded and recognized. Nut metadata may specify not only the payload type but also how it may be read, written, displayed, and/or run. Which may specify some or all versions of various modules that may be necessary to successfully process the content. Indeed, it may remove some or all dependencies on any and all external reference tables used to process content, such as, but not limited to, Windows registry entries and/or Mac OS property lists. This may allow Nut to self-describe and specify the necessary components that may be needed to access its contents and may allow the MIOR server to automatically install any components that it may lack at the time of access.

The NUT browser/NUT shell may read the metadata of any selected NUT and may communicate with various other NUT core applications to attempt to open, display and/or run the appropriate application for the content of NUT by accessing 13232m ior server 13250. If the user has properly authenticated in the NUT server 13240, the NUT browser/NUT shell may have access 13234 to some or all of the necessary access NUT to open NUT even further. In fact, a NUT browser/NUT shell may function the same as any application that can properly handle a NUT.

Depending on the persistent storage available on the local system, the NUT browser/NUT shell may allow multiple NUTs with the same file name to exist in the same storage area, as long as the NUT IDs may be different. Some storage systems, such as databases and object file systems, may not be sensitive to file names. For most cloud-based storage systems, the Nut ID identification method may fit more naturally than the traditional pathname method.

Nut core application: NUT book

A schematic diagram of the NUT book is shown in fig. 133. To date, typical Nut processing applications can look like similar components; which may form the basis of the more generalized Nut processing architecture in diagram 134 and may run similar to how Nut browser applications may work in diagram 132. The NUT books may have the necessary interfaces to the NUT server 13334 and the MIOR server 13332. It may optionally process the MIOR modules 13326-13330 to provide the functionality provided thereby, as indicated by 13322 and 13324. The main function of the NUT directory may be to maintain a set of organized caches 13336 called a card directory. The NUT book may be a catalog of electronic cards comprised of a collection of data as shown in fig. 135. NUT books may provide some of the functionality found in a typical personal information manager. Why is NUT directory a card directory? Here is a list of various reasons why it makes sense:

the inability of the user to easily collect, process and organize any data set

It can usually be done informally in spreadsheets, text files or simple databases

There is no general utility of easy access to acquire, organize, and/or register different data collections in a secure manner, where a repository may include data files per item in a collection.

PKI certificates, contact cards, RBK groups, website logins, baseball statistics, VPN login and authentication, automobile history, DVD collections, stamp collections, book collections, child's case history, and the like. These may be considered different data or card collections.

Nut can safely store item types in a secure manner that can be easily used and transported.

Therefore, we can also store some or all of the encryption keys that may be needed to make the Nut work seamlessly into Nut.

We can access this card collection by indexing its Nut ID and any optional search index metadata within the Nut book application.

The NUT server may be aware of certain important card types and may prioritize its processing among its many tasks.

NUT that may exist in a multi-NUT server environment may have copy, sync, login, full history, encryption, and/or access control encapsulated into a single file per item by default for ease of shipping.

The NUT book may contain a key cache 13520, which may be in the form of protected or unprotected memory depending on the available hardware. The key cache may store frequently used access keys with attached appropriate attributes, such as, but not limited to, the number of times they are available prior to expiration, expiration time, and/or expiration event. Its primary directory cache 13550 may have a primary Nut ID index that it can hold the tracked Nut. The cache may be comprised of different sets of data, such as, but not limited to, PKI certificates 13562, contact cards 13564, NUT server access cards 13566, file control cards 13568, and/or any other defined set 13570. These sets may be stored in memory, in a database, on a file system, or other storage mechanism, depending on the configuration of the NUT books and available hardware. The database and file system storage may be located remotely, so long as they are accessible locally via a network interface. Fig. 136 may be an example of a layout of how NUT directory caches may be organized.

The data stored in the NUT book may be a PIM, passcode holder, PKI certificate manager, keyring, address book, note taking application, recipe book, DC set index, stamp set index, book set index, medical record, and/or an aggregation of any other data set that may be expressed as a collection. Current existing technology for the average user may not offer them many options to digitally organize different pieces of their life into a functional digital form. The address book applications may be numerous but may lack seamless easy cross-compatibility. Most intelligent users may not store sensitive passcodes in their address books and may evaluate and use a passcode holder application for that particular purpose. Even with only these two simple applications, the address book and passcode holder, the decision matrix may have been extended by several dimensions if the user were to consider features such as operating system compatibility, synchronization, cloud footprint, backup, web browser integration, etc. Moreover, it is not possible to ensure good integration between the password holder and the address book. If a user wishes to keep track of their family members' medical records, car service records, house maintenance plans, school logins on child courses, pet veterinary records, digital device information, and/or other data sets, they may have to track in a variety of different formats using different applications for each data type. A common use of spreadsheets may be to organize this different data set and may act as a general database for the user. NUT books may allow users to systematically store some or all information types in NUT form and may integrate data usage into any NUT-compatible application. Data that may be appropriately formed and identified may be run by an application that may utilize its defined structure. Some or all of the features of the NUT environment may be used for each NUT in the NUT book, such as, but not limited to, security, synchronization, replication, backup, and/or non-degenerate.

Non-degenerate and/or temporal compatibility may be an important characteristic of using MIORs. By using NUT books along with collections within the MIOR, the user can obtain several advantages: the data that it may produce may be their, the data may be secure, and it may have a reasonable expectation to be able to access its data indefinitely (or as long as the NUTS is functional and supported). The NUT book may also serve as a bridge between the world of the database user and the world of the archive user. It can provide the benefit of a database in the form of records stored as a file format. The MIO module for a particular set of read/write functions may be an organizational specification field set related to retrieving user-imaginable details of a particular set but may not be limited to this model. In some embodiments, the read/write module may be an interface to various databases and may provide field mapping and conversion functions for calling applications. In other embodiments, it may be a proprietary binary format read/write module that decrypts payloads using a privileged key from a software company. The various ways in which modules may be used to access data may be quite different and may have many permutations depending on the goals of the application developer. The infrastructure of a particular collection can be customized by a user with very little programming knowledge, starting with a simple existing template. New and useful sets can be added to their home MIORs for their personal use and shared with others via Nut profiles. It may also be submitted to an Internet MIOR server for use by either after some approval process.

Since we may have covered some motivations and design goals of NUT books, we may focus on how NUT books may act as PKIs and may ultimately provide SSO-level services for general users. FIG. 137 summarizes the concept of hierarchical passcodes. In Nut parlance, the passcode may be equivalent to passcode, in that Nut may accept both forms and, instead of any passcode, the user may use a hardware token, an encoded binary key, or any other method that can provide a secret key. Weed-like spreading of passcodes and their associated differentiators (such as, but not limited to, two-way authentication, login rules, custom passcode rules, custom web pages, and/or hard tokens) can quickly lose control and can leave users in a mental state where they can resort to passcodes that are extremely easy to remember across many websites, thereby users can counteract the efforts of individual vendors to make their systems safer for their clients. A preferred solution for NUTS may be to use as few passcodes as possible to allow efficient SSO access and hierarchical passcodes may embody this approach. There may be a primary passcode 13710 that may allow basic authentication into the NUT server and NUT book. The primary passcode may open Nut containing a key that may be cached in the key cache 13520 and may be configured to automatically delete upon completion of the session or a predetermined event. This primary key may be sufficient to effectively use most NUT server and NUT book functions. There may be a second level passcode such as, but not limited to, shopping 13714, work 13716, finance 13718, and/or communications 13712. These passcodes can only be entered after a successful entry of a valid primary passcode, so that they can respect a hierarchy of passcodes. This second level may allow users to separate and isolate different security levels for different data groups. Each passcode in the second level may be configured to have a different age in the key cache 13520 so that users can control their exposure. For example, a user may have an internet bank account login information in a bank aggregated card and may pin it with a financial key that may have a single life span. Then, whenever it may wish to access the banking website by accessing the login and pass code stored in the bank card, it may have to enter the financial pass code. Within each bank card, the website passcode may be randomly generated to maximize entropy and stored for use in automatic login of NUT books. More levels may be added, but they depend on the complexity of the user information and how much the user may wish to remember. There may be a master passcode 13720 that may bypass some or all of the hierarchical passcodes. The master passcode may be carefully selected or randomly generated for maximum protection and may be held in a secure location. With this hierarchical passcode approach, a user may only need to carefully select a set of passcodes that may be difficult to guess, but may be easier to remember simply due to a reduction in the number of passcodes they may need to remember, and this may form the basis for their SSO access.

Fig. 138 undergoes a passcode entry procedure for opening a personal file Nut 13806. This file may be protected only by the primary level key, so entering the primary passcode 13710 to access the primary key to authenticate to NUT in NUT server 13804 may be sufficient to open NUT holding personal file 13806. In fig. 139, the master passcode 13720 route may be identical to the master passcode route.

Fig. 140 shows how a work file protected by a second level work passcode 13716 may be opened. The primary passcode 13710 may be supplied to access the first level key, then the work passcode may be entered to gain access to the work level key 14008, which may unlock the work file Nut 14010. In fig. 141, the master passcode 13720 of the unlock route may remain the same as in fig. 139, which is still accessible in a single step, thus allowing the master passcode to be generated in a more secure manner.

Fig. 142 shows a more detailed diagram of NUT book key cache 13520. It may have a section divided for keys associated with NUT server 14210 and it may have a section divided for use on its various card sets 14230.

FIG. 143 shows a flowchart of how a NUT book may view a catalog card.

Preserving ownership is the concept of Nut mixing for different owners. Assume that Alice gets a new job at Acme corporation and that both of them can use nut-based applications to manage and organize the unimportant details of their respective contacts and/or digital keys. In addition, Acme may use Nut to control access Nut and carefully lock company files by department and/or by employee access levels. When Alice is employed, the HR department of Acme may issue a general company visit Nut to Alice: which may be an access Nut that may allow Alice to look up information such as an internal corporate contact list, a customer list, and/or various corporate files. The Nut system of Acme may have been customized and/or configured to give access to sensitive files that may be stored in Nut by wrapping a copy of the payload into a wrapper Nut that is locked by the employee's specific access Nut and the company's master key. The ownership (RAT) of these company Nut may always be Acme. Similarly, Alice's personal Nut may always make it the RAT. The ability to explicitly define owners in a cryptographic manner may allow Nuts to be handled appropriately by respective owners within their NUTS environment. This reserved ownership feature of Nut may allow Alice to combine and maintain control of Nut of his Nut and Acme on any device that it may use. The same operation can be applied to Nut of Acme on Alice device. Both Alice and Acme may set the lifetime of their respective access Nut to a relatively short period. For example, the life time may be set at 60 days for Nut stored on an external system. Thus, every 60 days, the keys may be updated by the respective owners of Nut owned by the keys or may be automatically deleted by an external Nut server that manages the keys. If a delete command is sent to the appropriate Nut server in an appropriate access Nut, the delete may be forced and may be coded to systematically delete some or all of the affected NUTs of the owner. Thus, parties may have the ability to maintain control of their Nut, either directly or indirectly in an external system. Thus, if Alice leaves a new job, she can know that her personal contact information, which she may have left a copy on her corporate desktop computer, can be automatically deleted in 60 days or less. The same operation can be applied to Nut owned by any Acme left on Alice's personal device: if there is no updated access Nut, then there is no associated Nut on the system. This type of Nut mixing may be intended to address the old problem of tampering with two or more separate contact lists and different sets of security measures for bringing work home. Alice may now always use his personal NUT book as a major contact source in his personal and professional lives and he may reasonably ensure that the source may be secure.

In another embodiment, the NUT book contact card may carry a reference to or embed external NUT containing personal information of an acquaintance. The external Nut from Bob may not be owned by Alice but by Bob. Bob may send Alice a pre-packaged limited contact Nut on its own and may maintain his ownership in Alice's Nut environment. The NUT book entry for Bob by Alice may embed this NUT directly or by reference into its contact entry for Bob. Whenever Bob changes some or all of the information about itself (such as a new mail address, a new work address, a phone number, or other affected information), it can send an update to her pre-packaged contact Nut to Alice by any available method and once Alice's Nut server recognizes the update, it can automatically update the appropriate embedded external Nut in Bob card in Alice's Nut book. Then, Alice's NUT book may run a contact application to process the updated card, which may result in an update in Alice's Bob card. This last step can ensure that Alice's Bob card entry can never lose its past history about Bob information and Alice can track various historical changes to Bob information when desired. Some or all of this step may occur automatically without intervening in a well-established trusted RBK relationship. This may mean that some or all of Alice's trusted RBK relationships may have updated contact information with little or no human intervention, which may result in significant savings in time and effort for each of Alice and their friends. If Alice has 99 RBK contacts and 50 updates can occur, then only 50 changes may have to be initiated by the affected person themselves and the rest may be automatically handled by the NUT servers of the affected persons. In a phonebook setting, 50 updates may become 50 updates by the affected individual, a notification sent to 99 buddies to notify them of the change, up to 50 updates by each of the 99 buddies to their own address book along with some level of transcription errors within the nearly 10,000 events that can be generated by the 50 updates, not to mention the collective time that can be spent by 100 people. This embodiment may alternatively be addressed by having a centralized service but such services may provide limited privacy, access, ownership, and/or control. The nut solution may emphasize diversification as much as possible while attempting to maintain a high level of privacy, history, audit background, and/or ownership at all times.

NUTS-based services

Nut-based services may extend Nut usage to a broader network, such as the internet, so that Nut may be utilized between multiple remote parties. The table in fig. 144 lists examples of various web-based services that nut may support and provide and fig. 145 shows a simplified network layout for such services. Some or all of the services may provide a multi-layered service package having a lowest level that is provided without constraints. Further layers of packaging can be paid directly or anonymously via separately purchased service credit vouchers. Some or all of the services may be used anonymously to varying degrees.

Nut-based services: NUT mail

The NUT mail server depicted in fig. 146 shows a web-based email service that delivers some or all of its messages via NUT among its registered users. Further, it may support automatic registration, anonymous channels, and/or RBK-based communication. The server may interact with the NUT directory and/or NUT server applications. NUT mail may have a client component that may run on a user device to enable it to manage, edit, display, compose, send and/or receive email.

FIG. 147 shows a process for establishing an anonymous registration on a NUT mail server in an automated fashion. The user may use a prepackaged Nut contact 14700 server, which may contain a preferred existing contact method such as, but not limited to, an email address, a text-capable phone number, and/or a web browser. The server may accept the request 14702 and may send a request to the user using the preferred contact method 14704. The user may enter the desired information from the request and the server may generate a randomly generated login ID and passcode that may employ the maximum entropy of the password method in 14706. The server may also generate RBK pairs with the user, which may be employed in some or all communications between the user and the server/administrator. The user may store the login authentication and RBK pair in their NUT book in the card of their own contact information 14708. Thus, a user may anonymously register using the NUT mail server in a primarily automated fashion 14710.

The login ID and RBK, which may have been generated during the registration procedure, may only be used by the user to communicate to the NUT mail server; to some extent, it can be considered a private channel between the user and the server. When a user wishes to communicate with another person who may also use NUT mail, a communication channel may need to be established with the person on the NUT mail server, as depicted in diagram 148. The communication channel may include a pair of randomly generated email aliases that may be attached as aliases to the registered accounts of the respective users. Once a pass-through channel may have been established and verified to better preserve relationship anonymity, the NUT mail server may not keep track of this alias pair. These aliases may be similar in function to RBKs in that they may be used by only two participants in the channel. The random nature of alias generation may not reveal the identity of the participant during email transport across the internet. The email content itself may be loaded into Nut protected by the RBK method that further protects the payload. This may provide two separate layers of confusion and methods based on the relationship described, which may minimize some or all of the undesired SPAM and/or third party email. Once the communication channel can be properly established, the exchange of emails can be fairly standard, as shown in fig. 149.

The security rationale behind NUT mail servers can be summarized as follows:

anonymous registration may mean that a destruction server may display very infrequently registered users and/or their email content.

The encapsulation of e-mail within the RBK encrypted Nut may provide another independent layer of content security. A hacked server may only display messages fixed by Nut.

The NUT mail communication channel using the alias pair may obfuscate the email metadata.

The server may not store the alias pairing data permanently, but only long enough to check the channel.

The server may store the email messages for a very short period of time. Which may be user configurable but preset to delete messages after the server may receive information from the user's NUT mail client or NUT server that at least 2 copies may exist outside the server or after a pre-configured duration.

A short history of emails may allow the server to have very small long-term data storage requirements.

Randomly generated logins, aliases, passcodes, and/or RBKs may leverage available data entropy that may lead to additional security.

NUT mail servers may not be readily available without an integration facilitation of a NUT book, although they may be possible. The login ID, passcode, and/or alias may be generated using maximum entropy methods and may appear as a patchwork of a long string of random characters. There may be a 1:1 correspondence between relationships and alias pairs, so the number of aliases that a user may have to keep track of can grow quite rapidly. One benefit of this method of communication may be that the data generated by the participants may be useless as such and may only draw some meaning via targeted data monitoring and/or complex reconstruction techniques.

The data storage requirements of a NUT mail server may be different from a normal email server: which may use less space per user on a continuous basis. The NUT mail server may permanently delete email NUT when the user's NUT server or NUT mail client may indicate that at least two copies of the email may exist outside the NUT mail server. This type of simple rule may allow each participant in the channel to establish two or two copies of their communiques at each minimum. The NUT mail server may utilize the NUT server of each registered client to offload as much long-term storage as possible, thereby reducing its own per-user continuous storage requirements. The NUT mail server may only have new email messages for registered users because each user may have downloaded and copied previous email on their own NUT mail client/NUT server system.

Nut-based services: NUT chat

NUT chat may be a NUT-based anonymous chat service. It may provide the following chat features:

it can support anonymous registrations, pairwise random aliases and/or RBKs

It may be able to provide the local NUT chat hub phone number for anonymity

It can support simultaneous phone number and non-cellular phone chat

It can support both SMS/MMS and Internet-based chat sessions

It can support historical features similar to NUT mail servers

The chat history may be saved within each contact entry store or it may be stored in Nut and it may be referred to by the target contact entry rather than just by the phone number or chat address.

Chat history can be permanently saved for personal use without NUT chat services.

NUT chat may be a dedicated service for chat messages that may be contained in a NUT.

Randomly generated logins, aliases, passcodes, and/or RBKs may leverage available data entropy that may lead to additional security.

It can multitask communication routes to ensure message delivery and show virtual chat sessions.

An example of a network diagram is shown for the NUT chat server in diagram 150. Its registration process may be similar to the approach taken by NUT mail servers and may provide some or all of the anonymity features for its users. There may be a Nut-based Nut chat client running on the user device and the basic dataflow configuration is shown for a chat session between three participants in fig. 151. This may be a standard text messaging topology where the NUT chat server acts as a coordinator for the middle 15100. Since NUT chatting may be based on NUT, the entire chatting history of the session may be kept in NUT and thus the NUT server replication/propagation/synchronization feature may be automatically utilized when properly configured. The NUT server may be configured to prioritize NUT chat NUT so that it can be handled in a more timely manner due to the nature of real-time interactivity in chat sessions. A close-up view of fig. 151 shows that the same chat Nut exists in multiple locations; it shows that a chat topology can be equivalent to a streamlined synchronization of data states in multiple physical locations. Fig. 152 is an example of a data flow that may replicate a program of a NUT chat session using a NUT server of a user. Since each chat participant may store some or all of the chat session history in Nut 15122-15126, Nut server 15238 may propagate changes to Nut across its peer Nut servers (such as 15242). By properly synchronizing the data in this way, when a user brings a NUT chat client 15260 on his device # 415240, it can see the same session history as he can leave on device #2 and the NUT chat server is not involved in having his device #4 updated. When a chat session is initialized, and when the chat NUT on either side of the channel is determined to be asynchronous by testing of the respective NUT chat clients, a forced synchronization procedure may be automatically initiated to update the session to the latest version (note that the classification of the chat history may be considered essentially a newer state of the payload, also known as NUT history). For example, Alice may have a long-term anonymous NUT chat channel with Bob but it may somehow lose or delete the chat NUT storing this session history on his smartphone. When she assumes this NUT chat session with Bob and contacts through the NUT chat server, the server may receive session version numbers from both Alice and Bob and it may show that Bob may have an updated session version than Alice. At this point, a copy of Bob chat Nut may be automatically requested and may be sent to Alice via the NUT chat server and Alice's NUT chat client may accept Bob's session history as owned by itself and the chat session may continue with a common view of his history and thus his context. Very little storage may be used in this case by the NUT chat server and some or all of the session information may be stored by the end user under his control. Once the chat session versions may have been synchronized, the chat messages sent to each other may thereafter be included in Nut holding only the new chat messages in the session rather than the entire history and Nut chat clients on each terminal may be responsible for updating their cumulative chat sessions individually so that they may reduce the size of data transfers in a persistent chat session.

In addition, Alice's NUT book may reference its Bob contact entries to reference or indicate chat Nut and email Nut, so that some or all of the relevant historical communications with Bob may be programmed under the information indexed to Bob, which may cause systematic proofreading of context stored in a relationship under Alice control.

NUT chat clients may participate in a conversation that may involve path agnostic chat sessions for reliability, redundancy, and/or confusion. FIG. 153 shows a typical dataflow pattern of three separate chat sessions between Bob and Alice, which may use up to three different chat services and/or chat IDs. Sometimes, this type of separation and isolation may be desirable and convenient for the parties that may be involved. At other times, the user is forced by selections made by other participants: for example, Bob may only wish to chat an account on service B, so Alice may be forced to make a login on service B to chat with Bob. However, to the extent that a NUT chat client can interface with other chat services, it can allow multiple separate chat sessions between the same two people to be aggregated into a path-agnostic chat session as shown in diagram 154, which may be referred to as a conversation. Chat Nut may be the basic medium of a message so that some or all may have version numbers and a copy of Nut may be sent on three chat session paths simultaneously. Whichever chat Nut may reach other Nut chat clients, the first may be processed and others ignored (or may be consolidated by Nut server Nut and then discarded). Sometimes, due to the nature of the transportation restrictions, chat Nut may be converted into a concise secure text message suitable for the transportation platform. In this approach, the conversation can be retained over multiple paths and only the latest version can be presented to each participant and the program can rely on its transport mechanism alone, without relying on the storage and/or organization functions of individual chat service providers. Redundant paths may minimize or virtually eliminate transport failures for conversations. The history that each transport service may store may be useless because it may be protected on a per message basis by Nut, so the content may be opaque. The transport mechanism may be any channel that may allow for the delivery of Nut, such as, but not limited to, an email server, an ftp server, a networked file system, a peer-to-peer connection, a Wifi protocol, a Bluetooth protocol, and/or any other digital transmission method. The synchronized nature of Nut may allow participation in a chat session using only shared Nut, which is configured to have at least two writers and a common method for a user to access Nut. This embodiment may demonstrate how the functionality of a chat system may be de-mediated relatively simply, while protecting the user's data independent of the service and enhancing the overall reliability of the transport mechanism by the user.

Nut-based services: NUT cloud

The NUT cloud may be an internet-based storage server available to any NUT user, as depicted in fig. 155. The NUT cloud may support anonymous registrations, pairwise random aliases, and/or RBKs. Which may be seamlessly integrated with personal NUT servers to extend the reach and availability of personal NUT networks. The NUT cloud may store NUT and its storage and bandwidth limitations may be affected by the service level and user configurable policies. NUT cloud accounts can interoperate with other NUT-based services to supply more permanent and/or accessible storage: that is, it may back up NUT mail and/or NUT chat messages.

At the basic level of service, it can provide a sufficient level of storage and bandwidth for general personal use. The primary purpose of which may be to facilitate access to the data stored in Nut from any access point on the internet. It may integrate seamlessly with the NUT server to synchronize some or all of Alice's data in the home and on the road.

The NUT cloud together with the personal NUT server may provide a level of synchronization that is the same as or better than any internet-based centrally managed cloud service; however, unlike popular freely available cloud synchronization services, NUT clouds may provide full anonymity, user-controlled privacy, full history, full audit backing, and/or secure data ownership.

Nut-based services: NUT network

The NUT web may be a NUT-based web site server available to NUT users, as depicted in diagram 156. NUT networks may support anonymous registrations, pairwise random aliases, and/or RBKs. NUT networks may store NUT and their storage and bandwidth limitations may be affected by service level and user-configurable policy settings. NUT web accounts may interoperate with other NUT-based services to access more permanent and/or accessible storage: for example, it may extract NUT from NUT cloud and/or NUT server.

The shared web page content stored in Nut may allow the user to control who can view the content and it may be done at the cryptogra phic level. A person may have an RBK pair with the content owner in order to view the billboard page. We can say this can be an anti-social network, a private social network, and/or an authenticated social network. A NUT web server or other unauthorized third party may not mine any of the content because it may not have any of the keys for the content. The owner can retain control of the content as long as it can be stored and fixed in Nut. The owner may also view some or all of the history associated with the advertisements in its local Nut store (if it can be configured to also copy and synchronize Nut locally). Sometimes, people feel that sharing pictures and videos among close friends and family can be a private event and third parties do not have the right to have copies for their use without the knowledge and/or permission of the promoter. NUT networks may be generated for situations that require privacy within a group of users.

Professional photographers can set up private web pages for potential clients to view copyrighted pictures with a lot of detail and control who issues keys and for how long. The web page Nut may record some or all of the activity on the picture to generate an audit trail for the photographer. The project manager may establish private web pages for coordinating activities among project members. From a security perspective, the registration procedure may be unnecessary due to access controls built into Nut but it may serve as an organization and partitioning function at Nut web servers.

Nut-based services: NUT concentrator

Currently, there may not be a generally accepted standard for how the internet of things (IoT) may communicate and/or function. An IoT may be a growing area of a hardware product that may have built-in networking capabilities and may allow users to control and monitor the functions of the product remotely from various personal computing devices. Many IoT products may send a constant data stream from their sensors back to the manufacturer vendor for them to collect and analyze, sometimes unknown to the user-owner of the product. The operating mode of some or all such IoT devices can create many invasions of privacy issues based on their data collection scope and methodology, as products can be expected for the most private areas of a person's home. An IoT architecture for some purpose may be offered by an IoT hardware vendor of a product family. The NUT hub may serve a packet forwarding service to facilitate the handling of NUT-based messages that may be generated by NUT-compatible IoT-type devices of the internet (IoN), referred to as NUT. As depicted in the network diagram on fig. 157, IoN may be a nut-based standard for secure and private communication with IoN compliant devices in our home. The lowest service layer on the NUT hub may be used for any one who may have a registered account using any NUT-based service. The account may be anonymous. NUT hubs can work with NUT and they can queue some amount of messages. The NUT hub may seamlessly interface with the NUT cloud and/or NUT server to access additional storage.

The NUT hub topology may be configured to work in several ways. A direct topology is shown in diagram 158, where each IoN device in a user's home can be independently connected IoN vendor servers 15804, NUT hubs 15802, and/or user control devices 15806, 15822, and 15824. This topology may allow a vendor to have direct access to devices in our home and a user may only filter output Nut packets to the extent that each device's ability is filtered: this may be the primary communication method used by IoT devices today.

The preferred NUT hub topology may be an indirect topology as depicted in diagram 159. Some or all of the IoN devices may communicate through a designated NUT server hub 15930 before leaving the LAN 15920 and then traversing the NUT hub 15902. This topology may allow fine tuning of the filter rules of the IoN message, leaving her home based on Alice's comfort level. NUT server hub device 15930 may comprise a desktop PC, a dedicated device, or even be part of WiFi router 15920. If the designated NUT server hub 15930 is turned off or unavailable, the IoN device cannot communicate with the outside world.

The configuration of a NUT server hub is shown in fig. 160. Within a NUT server 15930 like may be present a component referred to as NUT hub/IoN interface 16032. This module may be responsible for communicating with NUT hubs 15902, IoN device 15922 and/or other NUT server hubs 16052. The interface module 16032 may record, arrange, forward, relay, process, and/or filter IoN Nut messages from both IoN appliances and IoN control devices.

A close-up view of the NUT hub/IoN interface is shown by FIG. 161. Interface 16032 may include some or all of these seven functions or other additional functions. IoN the device index 16112 may keep track of some or all IoN devices registered by the user. IoN device authentication 16114 may authenticate and may encrypt messages to and from IoN devices. The interface may keep track of the user's message filters and rules 16116. Message recorder 16118 may record some or all of IoN messages for permanent storage. Message queue 16120 can temporarily store undeliverable messages. Device key cache 16122 may store some or all access keys for use in authenticating and encrypting IoN messages and may be embodied within protected memory hardware (if available). The remote control interface 16124 may be a module that may allow remote activation IoN of a particular function of the device.

A close-up view of the NUT hub/NUT server/IoT interface on any IoN device is shown by diagram 162. Interface 16210 may include some or all of these seven functions or other additional functions. Nut index 16212 may keep track of some or all of the Nut stored on the device associated with implementing and managing IoN the device. The authentication module 16214 may authenticate and may encrypt messages to and from devices of the vendor, NUT hub, and/or NUT server hub. The interface may keep track of the user's message filtering and rules 16216. Message recorder 16218 may record some or all of IoN messages for permanent storage. Message queue 16220 may temporarily store undeliverable messages. Device key cache 16222 may store some or all access keys for use in authenticating and encrypting IoN messages and may be embodied within protected memory hardware (if available). The remote control interface 16224 may be a module that may allow remote activation IoN of a particular function of the device. IoN devices may have a limited set of functions for custom filtering due to their hardware limitations. It may also have a storage limit that may limit the amount of messages that it can record and queue. Thus, if history and audit backups may be important, users may be strongly advised to use an indirection IoN topology as depicted in diagram 159, which may allow users to access enhanced functionality that may be provided by NUT server hubs. This interface 15922 is not limited to IoN/IoT specific devices, any computing device may have a similar interface (if a developer can generate an interface for it) and follow the operational mode of IoN device; additionally, any device that may have a version of the NUT server running thereon may be able to function as the IoN device itself.

When Alice purchases a new IoN device for him, he may need to add the device to his network and configure the device. The flow chart on fig. 163 shows the steps that Alice may take to properly register his new IoN device with his nut-based network. The method of configuring IoN the device may be to establish an RBK relationship with Alice through its NUT book. Steps 16302 and 16304 may allow the NUT server hub to relay device specific information to its NUT book and then the NUT book may generate IoN/IoT device directory cards, fill in the model, version and/or sequence number, generate RBK pairs and send them back to IoN devices via the NUT server hub. The act of generating IoN a directory card for the device may generate a Nut, which may generate a Nut ID for the Nut; thus, the IoN device may be imprinted thereafter with the Nut ID of its catalog card Nut. This step may be similar to picking an IP address for a new device on our home network, but the potential advantage of using Nut ID may be broad-reaching. IoN the assigned Nut ID of the device may also serve as a permanent way of referring to the device regardless of its actual IP address and/or location. IoN can be reset to factory conditions so that a new Nut ID can be imprinted thereon by a new or the same owner.

Once the IoN directory card is saved in Alice's NUT book, the configuration process may proceed to step 16306 and it may check if there may be configuration data for the decryption device, the MIO components necessary to display the configuration data, and/or to set the configuration data. Once the configuration screen can have been appropriately set, Alice can save the settings into his IoN directory card for the device and can submit it to the NUT server hub interface for forwarding to IoN device 16314. The device may receive the configuration Nut, may authenticate it, may decode it, may verify it, and may then apply the changes to its internal system. Once completed, it may send Nut back to Nut server hub, indicating its status. Alice can monitor this device and it can automatically see the message from the device.

IoN the device may operate in a mode where some or all of the messages may be Nut and thus the same level of privacy and control over Nut may be obtained as preset. Since Nut may utilize MIO components, the likelihood that software configurations, firmware, and/or software updates to a device may be submitted through the same MIOR mechanism and be outdated may be low. The NUT hub may be configured to ensure for the user that anything may be monitored, recorded, and/or controlled by the user when necessary and that some or all of the output information that may be collected by the IoN device may be filtered to respect the user's privacy preferences. In this embodiment, the nut core philosophy may be extended into physical devices so that devices that you own may be under your control at times or all of the time and some or all of the data that you may produce may also be your. The strength of the MIO and its functionality may be evident in this case, as any data format with an appropriate MIO component may be detected by the user rather than by many proprietary protocols.

This can bring us an important module called the remote control interface shown in 16124 and 16224. This may be the method that a user or vendor may take as opposed to the IoN/IoT device and may have it act remotely on a command (we call command Nut). The RBK authentication command Nut may be processed and any available commands may be executed thereon by a device owner (RAT). This authentication requirement may allow the user to fully control the relationship of the vendor by adjusting its access rights. The user may allow the device vendor to have full access to it, a subset of it, and/or no access. This may prevent unauthorized access to Alice's home network using the IoN/IoT device as an entry point: the IoN/IoT access points may now harden nut-based security. Since we can have mentioned the extended nature of how Nut can propagate and be sent along internal networks and/or the internet, essentially IoN commands that Nut can be sent to IoN devices from anywhere there may be an appropriate route. The flow chart in fig. 164 shows how the remote control interface can process the command Nut.

The nature of the NUT hub and its remote control interface may give Alice the ability to fully control some or all of their NUT compatible devices wherever connectivity may exist. It may present a security protocol by which custom messages may be sent while controlled by the NUT book relationship of Alice represented by the RBK pair. It may present Alice with a central view of all of her IoN devices but it may be installed, configured, and/or maintained in a decentralized manner. If Alice controls her Nut, she may control some or all of her devices. This may be another reason Alice should very carefully choose their passphrase or use a hardware-based key when he can decide to use the SSO capabilities of NUTS. In such an embodiment, the role of the vendor may be abbreviated as that of the hardware manufacturer rather than that of a non-invited remote administrator for personal devices that belong to Alice and may be located in a private area in Alice's home. The security of nut environments may present a more uniform, hardened, and/or user-controllable barrier than current IoT protocols that favor the preferences and/or advantages of manufacturers (developers).

Nut-based services: NUTS authentication server

Since the integrity of NUT server programs and protocols may be necessary to trust that they may perform as expected, a NUT authentication server (NCS) may be present to verify NUT server installations on a continuous basis. As depicted in diagram 165, the NCS may be used for any nut user and may support anonymous registrations, pairwise random aliases, and/or RBKs. It may have a service level rating where the highest rating is officially certified by the NCS corporation as "nut certification". The primary function of the NCS may be to monitor the NUT server for proper NUT removal and/or to detect unauthorized tampering using NUT server protocols, behaviors, and/or procedures. The architecture of how anonymous registration works may allow the NCS probe NUT server to be virtually undetectable since the smart programmer can identify the probe and circumvent it. The user may choose to launch on their NUT server to be a voluntary level of service. There may be an automatic procedure initiated by the NCS to inject a target Nut server with a test Nut and detect if certain actions may have been applied to it according to the Nut server protocol. At higher service levels, active participation of the tester may allow for an even more comprehensive assessment of the status of the remote NUT server.

Vendors may subscribe to the NUT certification level test to constantly maintain a NUT server compliance level that their customers may know and thus ensure that their NUT can be handled for them. The test program may also highlight any unauthorized modifications to the client NUTS environment that are unknown to the client. From the client side, any vendor that may use the Nut system and method, but may not be "Nut certified," may require more investigation regarding the policy of handling Nut. Users may configure their NUT servers and/or NUT books to interface with a look-up table on a publicly available NCS database to evaluate their authentication status or lack thereof prior to engaging with an online vendor.

In fig. 166, the NCS 16520 may perform functions that may allow it to evaluate the behavior of remote vendor NUT servers (or personal NUT servers) 16620-16624. Expired integrity probe 16602 can be a method where Nut can be injected 16604 into the system and can be probed by the remote control interface 16610 for the presence on the system after expiration. For example, if an expired NUT is found on a remote NUT server, the NUT server may not have compliance and may not be "NUT certified. The long duration injection test 16608 may test the NUT server for a longer amount of time and on a continuous basis. The results analysis and certification 16606 may evaluate the compliance of the remote NUT server with various injection tests and may score NUT server installations. Checking versions and patching versions of installed NUT servers may be integrated with ensuring that NUT servers may be updated and have compliance. A lengthy outdated version may indicate that loose maintenance of the nut security protocol and/or unauthorized custom modifications may have been performed, and thus adoption may be slower. Testing may also include, but is not limited to, checking hash signatures and/or self-anonymous internet address injection of various sensitive binary code fragments. Anonymous registration of NUT servers to NCS services may ensure that RBKs may be set for deeper tests in a more secure manner.

The NCS cannot guarantee that NUT servers may not have been hacked because with sufficient knowledge and resources, anyone or a group can eventually circumvent the testing performed by the NCS. Live testing may result in a higher level of nut authentication. For a typical user, not interfacing with any commercial NUT server that may not have been authenticated at the highest level may be a good policy. To interface with a personal NUT server, the base level of automatic free testing from the NCS may be a minimum requirement before interfacing with it.

NUTS-based networking for WiFi/Ethernet routers

Fig. 167 shows an embodiment of a network topology for a personal nut-based WiFi/ethernet router 16710. The router may operate using conventional protocols that may be involved in WiFi communications as well as using Nut-based messaging as an alternative protocol. The NUT WiFi router may be installed and configured as any IoN device whereby the owner establishes an RBK relationship with it and can store information in its IoN directory card via its NUT book. During the configuration procedure, since the user may have most of his devices represented by the directory card entries, he may be able to register some or all of the devices on the router that he may wish to access with the Nut ID. The origination Nut message may contain the Nut ID of the sending device and thus may be properly reviewed against the registration list for access. The router may then be instructed to establish relationships between the various devices and itself, so it may allow secure communication of the content of the Nut message. A flow diagram for processing messages at a nut WiFi router is shown in diagram 168. Some or all messages that may pass through the router may be authenticated by the registered devices. Step 16818 demonstrates interesting features that may be used on nut-based routers. Unregistered devices may contact the router for access without using the RBK. When this happens, it can look for owner specific configuration settings of bandwidth allocation and restrictions of different categories of WiFi access: registered, IoT, and/or object. The registered device may be set to have no restrictions on the type of use and the requested bandwidth. IoT/IoN devices may have their own class and may need to be the same level of authentication as registered devices but may be managed separately as a group. The table on fig. 169 shows the defined classifications and access types that it can have through the router. The guest device may obtain access using a conventional but constrained protocol. A sample configuration of attribute limits based on classification is shown in diagram 170. The owner may specify per-device limitations such as, but not limited to, expiration, bandwidth, aggregated bandwidth, maximum connection for class type, destination, and/or message mode. In this way, the guest device may have internet access through unknown nut WiFi routers within certain limits, while authenticated nut internal networks may be protected by nut-level security methods. This approach effectively separates the generation of manageable channel classifications within a WiFi communication architecture.

Some or all of the user's registered devices can now be identified independently of the internally assigned IP address rather than by the Nut ID in the directory card. This may be a nut property that makes data and hardware more tangible and functional across some or all networks in a more general manner. The router may keep track of dynamic IP address assignments against Nut ID maps of registered devices. In future iterations and other embodiments, the hardware manufacturer may allow the use of Nut IDs along the IP address and/or MAC address side to access ethernet network interfaces on various devices. The device that identifies the Nut ID may be considered equivalent to an OS installation that assigns a system name to a PC but it may be a system and practice unique, so changing an ethernet card or adding an ethernet card to a system may present a new IP address and/or MAC address but it may not change the Nut ID associated with the device.

Supervision of parents' internet access to their children may be monitored and limited at the router level, rather than or in addition to the device and user levels, using nut-based WiFi routers. The message Nut, which may encapsulate registered device traffic, may include user identification information, which may be used to further filter traffic by parent preferences.

Application package with Nut

The advent and development of cloud services, application storage, and/or their associated applications may have allowed some form of modularity and/or transferability of applications across different devices. However, this may not be the case for desktop or laptop computers. Most applications that may be run on them may require manual installation and/or maintenance. This may also be the case in a well-maintained institutional environment, where a mix of preselected application packages may be rolled into a custom installation package by a system administrator for ease of machine set-up. Or it may produce a mock preinstalled application on a disk swapped into the computer. For a runtime environment, it may be very difficult for an individual and/or administrator to monitor and authenticate each program that may be installed on a particular device. Very strict account rules may result in reduced productivity for the user or increased personnel requirements for the system department.

Applications packaged in a well-constructed Nut can solve many of these problems. The native operating system may be modified to allow only the Nut wrapper application to run. There are numerous implications. This may prevent some or all unauthorized installation and execution of unauthorized and unchecked applications. Policies may be enforced in a regulatory environment through centralized management of access keys. Virus infection vectors, which may involve execution of naked binary, may be drastically reduced. NUT server replication and synchronization features may allow for easy propagation of newer versions of installed software across some or all devices. Nut, properly packaged, can be commanded remotely to self-install using a remote control interface after successful synchronization. The NUT server automation device environment backup and replication as depicted in fig. 171 may be used. Computing device 17100 can store a Nut backup for devices that may have failed. After obtaining a new device 17140 ready for installation, the application that may need to be properly installed may be the NUT server 17144 and its access key. Then, a copy command from any computing device with the correct key may initiate a duplication of some or all of the relevant Nut from device 1 to device 2 and then may perform the necessary installation of some or all Nut wrapper applications.

Ostensibly, this approach may not look different from a mock hard disk or with a well-obtained installation script but there may be some significant differences. Nut wrapper application may be a specification of the application rather than the specific binary itself. The binary may be stored in a system MIOR and then the MIO mechanism may take over during the opening process of the Nut wrapper application specification to fetch the correct version of the application for the current operating system of the device (which may or may not be the same as its original device as it was substituted). Such MIOR usage may be a way to control application versions within a computing environment that includes heterogeneous operating systems and/or hardware. The use of nut technology may allow some or all of these programs to emerge virtually anywhere from the internet, so that new machines may be installed and maintained remotely on behalf of a facility.

An example of this could be that a salesperson's laptop, who is traveling for a week, may be stolen, which may contain 20 custom presentations and confidential client reports that they may wish to use in a client meeting. Assuming that the company utilizes nut, the salesperson may go to the nearest computer store and purchase a replacement laptop computer under the direction of the system administrator. It can then install a standard NUT server downloaded from the internet on the laptop. The administrator can send it a special code access/installation Nut called a Genesis Nut via email and the salesperson can download this Genesis Nut onto their new laptop from the web browser based corporate email page. The administrator can call the salesperson and tell the salesperson that the secret passphrase of Genesis Nut can be unlocked. Once unlocked using the local NUT server/NUT browser, Genesis Nut may initialize some or all of the necessary programs across the Internet to copy applications and data from the lost laptop computer from its latest synchronization with the corporate server. On the order of minutes to hours depending on the amount of backup data, the salesperson may fully operate some or all of his contacts, applications and/or Nut reinstalled on his new laptop and this may be done on a different laptop brand and a different operating system as long as the company MIOR can be properly inoculated and maintained. Concurrently with this replication effect, the administrator may send a self-delete command to the stolen laptop for a Nut owned by some or all companies stored on the stolen laptop to prevent the thief from starting the laptop to connect to the internet. This can be a precautionary measure because the Nut on the laptop can be separately fixed using the company Nut expiration policy.

In another embodiment, the hardware embedded NUT server may be integrated into an uninitialized computing device that may have a connection to a network including accessible source NUT servers and MIOR servers. Genesis Nut may be loaded onto a device and accessed, which may initialize programs to cause a computing environment including an OS, drivers, applications, application configuration data, and/or user data to be fully installed on the uninitialized computing device. After testing of the device and the contents of the MIOR cache accessible, the OS selection may be left to the user. The applications may be installed incrementally as the user accesses different Nut or all applications may be installed simultaneously by querying the source Nut server for a complete list of required applications for accessing the user Nut.

Event Processing Service (EPS)

The NUT hub may allow NUT-based communication using IoN/IoT devices and NUT servers. The Event Processing Service (EPS) may operate as a coordinator for events that the inventory may generate by IoN devices and applications that may wish to generate an event or event response, as depicted in diagram 172. Since some or all events may be included in Nut, any event may be communicated across any network as long as there may be a traversable route between devices. This may allow users to monitor desired events in the local and remote IoN/IoT devices and/or NUT server systems. Which may allow a user to trigger scheduled or specific events on the local and/or remote devices. The event may be replicated across some or all of the user devices, if so desired. The EPS may work with a remote control interface to allow device specific commands to be initiated based on events. Fig. 172 embodies a case where a local calendar application 17208 on device 17200 can trigger a timed event through the local EPS 17204 to execute on device 17220 IoN reachable by NUT server 17212 on device 17210. The home EPS 17204 may relay the event to another EPS 17214 that may have access to the target IoN device 17220. The EPS 17214 may then relay the event/command to its local NUT server 17212 and then it may use its IoN/IoT interface to communicate the event/command NUT to the IoN device 17220. Upon receiving the event/command Nut, the IoN device 17220 may authenticate and may then execute the command via its remote control interface. Examples of such events may vary but are not limited to starting the remote server on a schedule, sending an email on a schedule, sending chat messages regarding the status of the system, brewing coffee on an IoN compliant coffee machine in the morning, changing the temperature setting on an intelligent thermostat, and/or warming up the cart twenty minutes after coffee brewing can have been completed on a cold winter morning.

The EPS may store past events that it may have received and generated on each device it may operate in an event Nut storage area 17216 and 17206. This may serve as an event repository and event queue for communication and device failures. The user or administrator may browse these events at a later time and may analyze them for any subsequent use. Users with NUT cloud accounts may also copy their events to a repository so that the events can be viewed from any internet access. Some or all events may be Nut protected and may be owned by the user. The NUT hub may seamlessly interface with it to take advantage of the queuing capabilities of the EPS.

An example of an application that utilizes an EPS and its repository may be that the battery level of some battery operated sensors that the home alarm system begins to alert to may be low. The home alarm system may generate a low battery event specifying the units that may be involved and may request an alarm to maintain the company's service calls. The alert company may suggest various times at which it can service the user's questions via email and the user may make a different time suggestion or accept their suggested time. Upon acceptance, both calendars on the alert company and user device may be automatically updated with the appointment information. The alarm system may have a restricted RBK relationship with the alarm company so that it can be diagnosed in a secure manner using the homeowner's implicit approval.

Context calculation using application Nut

The website company may unmask some or all facets of the user's digital debris, such as, but not limited to, search habits, search history, device specifications, website viewing habits, shopping trends, clan content, social networks, commercial networks, email content, text messages, photographs, and/or even digital analysis of their DNA. The vast majority of this user-generated data may not be owned, accessed, viewed, changed, deleted, and/or controlled by the user who may have generated it. Nut technology may make it easier for application developers to store user-generated data and may more easily give copies to users for their own use and archiving. It may provide a common secure container that can be changed in content format via the MIO to allow customization. Very few web service providers may be generally sufficient to cover most aspects of a user's digital footprint; for example, Amazon may only know some of our shopping preferences and Google may only know some of our search history. Thus, a website provider may typically aggregate partial pieces of one's habits based on the services that it provides. The best advantage of collecting some or all of the user's digital whereabouts and activities may be provided to the user by the user. A typical network layout of a vendor and user applications is shown in figure 173, where the vendor can use home browser based cookies to tag the user or their current session and can use a big data collection server to record some or all of the activity from the applications and applications.

If the user interfaces with an application that can provide a full session record in Nut for its own inventory and use, the user may eventually be able to collect the various facets of their numbers, as depicted in diagram 174. These session histories can provide a context, and thereafter analysis can be done by context sensitive applications to provide more convenience to the user, as shown in diagram 175. The application may save its session history in application Nut 17414 and this may then be used by some or all other applications that the user may have installed to benefit the user as appropriate. Appropriate analysis of the context may derive the nature of the task that the user may wish to accomplish. Accounting application 17524 may record its session in application Nut 17414 for some or all bill payments and check account activity that the user may have completed. A pattern recognition application 17520 that can read this session history can analyze it and recommend the historical steps taken to pay the monthly bill and can present a preview of the actions it can take on behalf of the user. If the user agrees to their analysis, they may perform these steps to automatically pay some or all of the relevant bills using the various accounts under the user name. This application NUT may be available to the user across the internet if the user synchronizes his NUT via NUT cloud 17500.

Another useful aspect of the context saved by the application Nut may be a repeatable program. This may be a common feature in command line interfaces that developers may prefer, where previous commands may be saved for optional re-execution as needed. Application Nut may provide the same type of procedure call-back as needed for a user on virtually any compatible application. Storing a context of the travel application may provide the required nature of a proposed journey in application Nut after the user has initially searched for the website. The user may then automatically resume such searches for some or all of their preferred travel itineraries by re-executing the sanitization requirements using a context-sensitive travel search application. This may reduce the time it takes to re-enter various forms on each travel website and may produce an automatic summary of some or all of their options. Furthermore, since the program may be fully controlled by the user and some or all of the sensitive information may be stored by their NUT book, queries to vendors that the user may have mileage privileges and/or members may be suitably applied by the context-sensitive travel search application to obtain the most personal and meaningful results thereto. This type of deep context-sensitive search is virtually impossible to accomplish by a single vendor unless the user is at times or at all times willing to give the vendor and trust it completely free access to some or all of its sensitive digital information; this can be a highly suspect suggestion for general digitally sensitive users.

In another embodiment, fig. 176 shows a network topology of a user's IoN/IoT device and its various utilities and services that may be subscribed to for daily life in their home. A single company cannot digitally collect the user's entire family life. However, if some or all of the devices of the user generate an application Nut and the user has applications that can analyze their various digital contexts, the user may do so. An energy saving context sensitive application may analyze the power usage of various electronic devices in a user's home and may combine it with peak and off-peak charges of an electronics company to suggest energy saving measures that may be automatically enacted by the application on behalf of the user. It may analyze the user's personal usage habits of each device to coordinate the user's convenient combinations when they recognize a set of situations from the past. If running the self-diagnostics periodically shows a failed portion of a sub-optimal operating reading, the IoN/IoT device may notify the user of the maintenance requirement.

There may be security concerns about IoT devices containing various environmental sensors that may not be fully controlled by the owner of the device but rather controlled by the manufacturer and/or a potential hacker. Fig. 177 shows an example of a network layout of two IoN devices and their respective manufacturers. When applications Nut 17734 and 17744 may be generated by each IoN device 17730 and 17740, they may be archived locally in local storage 17724 by Nut server 17722. The user may then review and filter this inventory application Nut to remove any sensitive information that the user deems inappropriate for collection by third parties before sending it to the manufacturer. In fig. 178, the context analysis application 17808 may provide specific routine filtering of some or all IoN/IoT generated messages of the user to minimize unknowingly exposing their privacy to third parties. In this way, a third party may still collect some data from each sold device only to the extent allowable by each owner; thus, it can infer what personal information a typical purchaser may be willing to give to it.

Theory of knot and philosophy

The various embodiments and case examples that have been detailed may be based on the core nut philosophy that the data belongs to the user who generated it and that the user may have a way to precisely control their exposure. The design may be flexible enough to accommodate changes and/or alternatives, such as but not limited to alternative secret methods, keys having different lengths, different data transitions, and/or different locking mechanisms. SDFT provides a set of useful tools for programmers to translate data at the lowest level and can help implement structured cryptogra phic programming to build nut structures and other complex cryptogra phic structures. SDFT allows data portability, paired with its transition commands in a flexible and generic manner. Various embodiments of the NUTS may be customized to fit into existing organizations and security infrastructure or they may be stand-alone devices for a single user. Data formability may be an important philosophy proposed by nurs and may enable users the ability to store, manipulate, and/or view data that may be generated in a simple manner, while providing features that benefit most complex managed systems. In summary, NUTS may give each user an alternative to the current method of organizing their digital work and data.

Claims (75)

1. A method of processing data, comprising:

at least one processor accessing a data storage unit providing at least one input data object and at least one transition command to be performed on the at least one input data object; and

causing the at least one transition command to act on the at least one input data object in a forward mode to generate at least one output data object to be stored in the data storage unit.

2. The method of claim 1, further comprising: causing the at least one transition command to act on the at least one output data object in a reverse mode to produce the at least one input data object.

3. The method of claim 1, wherein the at least one transition command acting in a reverse mode comprises: processing the at least one input data object in the forward mode to produce a second at least one output data object, and comparing the mentioned first at least one output data object with the second at least one output data object to produce a verification result.

4. The method of claim 1, wherein the at least one transition command acting in the forward mode requires at least one attribute to process the at least one input data object to produce at least one output data object.

5. The method of claim 4, wherein the at least one transition command acting in a reverse mode requires the at least one attribute to process the at least one output data object to produce the at least one input data object.

6. The method of claim 4, wherein the at least one processor generates at least one attribute required for the at least one transition command to act in the forward mode to process the at least one input data object to produce at least one output data object.

7. The method of claim 5, wherein the at least one transition command acting in the reverse mode requires the at least one attribute to process the at least one input data object to produce at least one output data object comprising a verification result.

8. The method of claim 4, further comprising the at least one processor verifying a form of at least one attribute proposed for use by: the at least one transition command acting in the forward mode requiring a particular form of the at least one attribute to process the at least one input data object to produce the at least one output data object.

9. The method of claim 8, further comprising the at least one processor verifying a form of at least one attribute proposed for use by: acting in the reverse mode, requiring a particular form of the at least one attribute to process the at least one output data object to produce the at least one transition command for the at least one input data object.

10. The method of claim 1, wherein the at least one transition command transitions the data storage unit to 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 transition command is a mobius transition.

12. The method of claim 1, further comprising: the data storage unit provides a plurality of transition commands in a logical order that act on the at least one input data object in a forward mode to generate the at least one output data object to be stored in the data storage unit.

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

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

At least one processor accesses the second data storage unit to process the second data storage unit.

15. The method of claim 12, wherein two or more transition commands within the plurality of transition commands in logical order form a dependent group; and is

Processing each transition command within the dependent group acts in the same order in either the forward mode or reverse mode.

16. The method of claim 12, wherein one or more transition commands acting in the forward mode within the plurality of transition commands in logical order require one or more corresponding attributes to process the at least one input data object to produce the at least one output data object.

17. The method of claim 16, wherein the one or more transition commands acting in the reverse mode within the plurality of transition commands in logical order require the one or more corresponding attributes to process the at least one output data object to produce the at least one input data object.

18. The method of claim 12, further comprising the at least one processor generating one or more corresponding attributes for use in: the one or more transition commands acting in the forward mode and requiring the one or more corresponding attributes to process the at least one input data object to generate the at least one output data object.

19. The method of claim 16, further comprising the at least one processor verifying a form of the one or more corresponding attributes proposed for use by: the one or more transition commands acting in the forward mode requiring the one or more corresponding attributes each having a particular form to process the at least one input data object to produce the at least one output data object.

20. The method of claim 19, further comprising the at least one processor verifying a form of the one or more corresponding attributes proposed for use by: the one or more transition commands acting in the reverse mode, each requiring the one or more corresponding attributes in a particular form, to process the at least one output data object to produce the at least one input data object.

21. The method of claim 12, wherein at least one transition command within the plurality of transition commands in logical order transitions a first data storage unit to a second data storage unit having a different structure than the first data storage unit.

22. The method of claim 21, wherein a last transition command within the plurality of transition commands in logical order is a mobilus transition.

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

At least one processor accesses the second data storage unit to process the second data storage unit.

24. The method of claim 12, wherein at least one transition command within the plurality of transition commands in logical order, acting in the reverse mode, processes the at least one input data object to produce at least one output data object comprising a verification result.

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

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

each of the plurality of computers processing a message using the method of claim 12.

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

28. A method of processing data, comprising:

at least one processor running a cryptographic function requiring one or more keys, the cryptographic function provided with at least one input plaintext data object and zero or more input keys; wherein:

the cryptographic function, to which the input key is not provided, operates in an encryption mode to generate a set of required appropriate form keys to encrypt the at least one input plaintext data to produce at least one output ciphertext data and the generated set of required appropriate form keys;

the cryptographic function provided with a set of partial input keys operates in an encryption mode to generate a desired set of missing proper form keys and combines the desired set of missing proper form keys with the set of partial input keys in logical order to encrypt the at least one input plaintext data to produce at least one output ciphertext data and a set of combined keys;

the cryptographic function provided with a set of required input keys operates in an encryption mode, validating the structure of each input key to encrypt the at least one input plaintext data using the validated set of required input keys to produce at least one output ciphertext data;

the cryptographic function provided with the set of required input keys operates in a decryption mode, verifying the structure of each required input key to decrypt the at least one output ciphertext data using the verified set of required input keys to produce the at least one input plaintext data.

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

30. The method of claim 28, further comprising: the set of required appropriate forming keys is generated by accessing a key generation service or function.

31. The method of claim 29, further comprising: indicating a preference for a particular cryptographic method and mode that requires one or more keys to act on the at least one data object.

32. A method of collapsing data, comprising:

at least one processor processing at least one input data object using at least one logical operation to produce at least one output data object, wherein the at least one logical operation encapsulates at least one essence of the at least one logical operation within the at least one output data object; and

at least one processor processes the at least one output data object using the at least one essence of the at least one logical operation encapsulated within the at least one output data object to produce the at least one input data object.

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

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

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

36. 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 of the folded data.

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

each of the plurality of computers processing a message using the method of claim 32.

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

39. A lock node for storing data, comprising:

an input section providing a plurality of key images, each key image corresponding to a respective one of a plurality of first level keys applied to the input section, each key image comprising at least one primary key;

a variable lock section that generates a derived key from a logical operation on the primary key corresponding to the first level key applied to the input section; and

an output section that generates the data in response to the derived key.

40. A protected data storage unit comprising:

a plurality of lock nodes for storing data, the lock nodes comprising:

an input section providing a plurality of key images, each key image corresponding to a respective one of a plurality of first level keys applied to the input section, each key image comprising at least one primary key;

a variable lock section that generates a derived key from a logical operation on the primary key corresponding to the first level key applied to the input section;

and

an output section that generates the data in response to the derived key;

a keyhole lock node of the plurality of lock nodes having a key image for each of the specified first level keys, the keyhole lock node further capable of containing at least one access attribute key that provides role based cryptographic access control based on the corresponding first level key within the protected data storage unit; and

at least one of the lock nodes providing an output key that is capable of acting as a specified first level key for another one of the lock nodes.

41. The lock node of claim 39 wherein each key image contains at least one access key, the input section further utilizing the at least one access key to provide at least one access role key that defines an operational allowance for the data, wherein the access role key is based on an allowance associated with the specified primary key that caused a particular key image.

42. The lock node of claim 40 wherein the input section further provides at least one access key for another lock node.

43. The storage unit of claim 40, wherein at least one key image includes at least one hierarchical key that is enabled by an input section of at least one lock node different from the lock node that includes the key image to provide a different key image for at least one different lock node.

44. The storage unit of claim 43 wherein the at least one hierarchical key and the input section of the lock nodes in the storage unit control which lock nodes within the storage unit are accessible to a particular specified first level key.

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

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

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

48. The storage unit of claim 45 wherein a parameter controls a level of detail of an event provided in the log.

49. The storage unit of claim 40 wherein the storage unit stores a revised history of the data in the data storage unit.

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

51. The storage unit of claim 49 wherein a parameter controls how revisions are provided in the history.

52. The storage unit of claim 49 wherein the history further includes a source of each revision.

53. A method of processing data, comprising:

at least one processor accessing a data storage unit, the data storage unit providing identification of at least one application to be applied to the data in the data storage unit;

the at least one processor retrieving the at least one application from a set of applications; and the at least one processor acting on the data in the data storage unit using the at least one application.

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

55. 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. The method of claim 53, wherein the at least one application causes the data to be displayed.

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

58. The method of claim 53, wherein the at least one application acts on information associated with the data in the data storage unit.

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

each of the plurality of computers generating a different public key/private key pair for each of the other computers from which communications are to be received;

each of the plurality of computers secretly sending the generated public key to the computer corresponding to the public key; and

each of the plurality of computers encrypts a communication using the public key of the computer to which the communication is to be sent.

60. The method of claim 59, further comprising:

each of the computers stores the received public key in a personal information manager that only authorized computers can access.

61. The method of claim 60, further comprising: the personal information manager provides a key management function; and

the personal information manager provides storage management functions.

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

63. The method of claim 62, wherein the at least one protected data storage unit comprises a lock node comprising:

an input section providing a plurality of key images, each key image corresponding to a respective one of a plurality of first level keys applied to the input section, each key image comprising at least one primary key;

a variable lock section that generates a derived key from a logical operation on the primary key corresponding to the first level key applied to the input section; and

an output section that generates the data in response to the derived key.

64. The method of claim 62, wherein the at least one protected data storage unit comprises:

a plurality of lock nodes for storing data, the lock nodes comprising:

an input section providing a plurality of key images, each key image corresponding to a respective one of a plurality of first level keys applied to the input section, each key image comprising at least one primary key;

a variable lock section that generates a derived key from a logical operation on the primary key corresponding to the first level key applied to the input section;

and

an output section that generates the data in response to the derived key;

a keyhole lock node of the plurality of lock nodes having a key image for each of the specified first level keys, the keyhole lock node further capable of containing at least one access attribute key that provides role based cryptographic access control based on the corresponding first level key within the protected data storage unit; and

at least one of the lock nodes providing an output key operable as a specified first level key for another of the lock nodes.

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

66. A method of storing data, comprising:

storing data in a protected data storage unit, the storage unit further storing a revised history of data in the storage unit or storing a log of events involving the storage unit or storing both the revised history and the log of events;

deleting a protected data storage unit of the data when an updated version of the data is stored in the storage unit; and

replaying an earlier version of the data using either the history or a log of events or both the history and the log of events of the storage unit storing the updated version.

67. A plurality of protected data storage units, each said protected data storage unit comprising:

a data storage section constructed and arranged to store data; and

a log section to store a log of events involving individual storage units across applications accessing the individual storage units.

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

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

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

71. A protected data storage unit comprising:

a data storage section constructed and arranged to store data; and

a history section storing a history of revisions of the data stored in the storage unit across applications accessing the storage unit.

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

73. The storage unit of claim 71 wherein a parameter controls how revisions are provided in the history.

74. The storage unit of claim 71 wherein the history further includes a source of each revision.

75. A method of processing data, comprising:

at least one processor running an access control function on the data using the at least one input key; and

the at least one input key each reveals a corresponding at least one access key that cryptographically authorizes a particular access attribute to the data; and

each disclosed corresponding at least one access key is combined in a logical operation with other disclosed corresponding at least one access keys available and applicable to the data to form a union of all cryptographically authorized specific access attributes to the data.