Inserting blockchains to protect digital files in protocols having mulitple points of control

Abstract

A method and arrangement for converting a digital file into a cryptographic challenge-response-pair mechanism is disclosed. The digital file may include a hash reflecting previous states of the file, as with a Merkle tree. An encrypted digital file is concatenated with a random nonce and subject to one-way cryptographic functions and / or extended output functions such that a result C* is obtained having a known bit length. This result is organized into a series of addressable segments. A random seed is generated and is used to derive a random bit stream that is parsed into segments, each of which is read as an address in C*. These segments are applied as challenges to C*, and the corresponding responses may be used as or to generate or store an encryption key.

Description

ATTORNEY DOCKET NO. 2025-013 (133502.00249)INSERTING BLOCKCHAINS TO PROTECT DIGITAL FILES IN PROTOCOLS HAVING MULITPLE POINTS OF CONTROL FOR A DISTRIBUTED OR CLOSED- LOOP NETWORKCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims priority to U. S. Provisional Application 63 / 728,458 entitled " INSERTING BLOCKCHAINS TO PROTECT DIGITAL FILES IN PROTOCOLS HAVING MULITPLE POINTS OF CONTROL FOR A DISTRIBUTED OR CLOSED-LOOP NETWORK,” filed on December 5, 2024, the entirety of which is incorporated herein by reference.STATEMENT REGARDING FEDERALLY-SPONSORED RESEARCH

[0002] Not Applicable.BACKGROUND

[0003] Blockchains are a known method for authentication and controlling changes to large data structures. Generally speaking, a blockchain is a list or distributed ledger of records, each of which contains a cryptographic indicia generated from one or more other blocks in the list. The cryptographic indicia is typically the output of a one way function such as a cryptographic hash of one or more previous blocks in the chain. In a block chain, a hash of the previous state of the ledger is included in the next block (e.g., a transaction block) in the chain, along with other information (e.g., a time stamp, and the data payload of the block). The blocks of a blockchain are arranged sequentially or in some other hierarchy such as in a Merkle tree. This sort of arrangement is described in U. S. Patent No. 4309569 entitled “Method of providing digital signatures”, which issued on January 5, 1982, and which is incorporated herein in its entirety.

[0004] Blockchains are conventionally used to ensure the integrity of sensitive digital data, such as medical records and financial transactions, where it is essential to prevent unauthorized modifications and maintain a verifiable record. Blockchain technology addresses this challenged by utilizing an immutable, tamper-evident ledger where recorded data cannot be changed without detection. Merkle trees are a key component of blockchain systems that enable efficient data verification. In a Merkle tree, each leaf node contains a1QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)hash of data, and internal nodes contain hashes of their children. The Merkle root represents the entire tree of data. Verifying the Merkle root allows for efficient and secure validation of large datasets, making them useful for applications like blockchain. Much research focuses on applying this technology to protect and verify digital files. In the prior arts, several systems utilize blockchain technology to validate digital files.

[0005] The use of distributed ledger and blockchain technology for managing medical data has been explored previously. For instance, US Patent No. 11244059B2, entitled, “Blockchain for managing access to medical data” describes a method that leverages blockchain to store medical information as metadata, ensuring privacy by concealing sensitive data.

[0006] Other conventional data security methods use Merkle trees for file protection. For example, U. S. Patent No. 9705730 entitled “Cloud storage using Merkle trees” discloses storing data by maintaining a single copy of each unique item, using Merkle trees for tracking, which ensures file integrity and prevents alterations.

[0007] U. S. Patent Publication No. US20210160053 entitled “Merkle tree construction methods and apparatuses and simplified payment verification methods and apparatuses” also uses blockchain and Merkle trees. That reference describes managing concealed data in the blockchain with Merkle trees for transaction verification and simplified payment verification (SPV).

[0008] The use of blockchains and Merkle trees has been extended to safeguard financial transaction data. For example, U. S. Patent No. 10841082 entitled “System and method for blockchain smart contract data privacy” discloses the use of blockchain technology to manage secure data and ensure transaction privacy. U. S. 10841082 addresses blockchain transaction privacy through encryption methods to secure private data within smart contracts. The focus of the reference is on securing individual transactions rather than digital file protection.

[0009] Non-blockchain systems based on encryption have also been suggested to secure file systems. For example, U. S. Patent No. 7320076 entitled “Method and apparatus for a transaction-based secure storage file system” describes methods for securing files via encryption and managing access control. The system described in that reference manages2QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)user read and write access control through encryption where data is encrypted with a symmetric key, and this key is encrypted with the user’s public key and also stored.

[0010] Other references have proposed various methods for securing digital file that rely on blockchain technology and encryption to various degrees, for example, U. S. Patent Nos.11063767, 11803664, and 11196569. The systems described in these references use blockchain technology to enable secure data sharing or management across distributed file systems, ensuring data integrity. 11063767 focuses on using blockchain to securely store and share event data. 11803664 classifies data as critical or non-critical, and discloses a method to store critical data on the blockchain and non-critical data on a distributed file system.11196569 focuses on using a trusted entity validator to verify data accuracy. These references generally use blockchain for security and traceability.

[0011] Additional conventional disclosures exist that describe various methods for integrating blockchain technology with authentication, access control and data integrity. For example, U. S. Patent Publication Nos. US20220239467A1 and US20200313897A1 focus on authenticating devices or users using blockchain combined with cryptographic challengeresponse mechanisms. U. S. Patent No. 10297094B2 and U. S. Patent Publication No.US20210255993A1 also disclose enhancing data security with blockchain.

[0012] Where the aforementioned references describe certain improvements in security for digital files, the advent of quantum computing and the desire for multi-point access control mean that further improvement in the area of secure storage and authentication of digital files is warranted.BRIEF SUMMARY

[0013] The instant disclosure represents a plurality of improved arrangements and methods over those described in co-owned U. S. Patent Publication No. US20250274289A1 (Application No. US19 / 064,331) entitled “Protocols for Protecting Digital Files”, which published on August 28, 2025, and which is incorporated herein by reference in its entirety. That reference describes a method and arrangement for encapsulating a digital file and its abstract with an ephemeral key which is protected through a challenge-response-pair (CRP) mechanism. The method is agnostic as to the specific CRP mechanism used, but that CRP mechanism, and the CRP mechanism described in the instant disclosure may comprise a onetime pad, a physical unclonable function (PUF) or PUF-array, or the use of the digital file3QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)itself as the CRP mechanism as described in the aforementioned reference. The use of PUFs and PUF arrays as a CRP generation mechanism is set forth in numerous co-owned U. S. Patents, including U. S. Patent Nos. 11477039 (“Response-based cryptography using physical unclonable functions”), 10432410 (“Encoding data for cells in a PUF that corresponds to a challenge in a challenge response pair”) and 11533300 (“Encryption schemes with addressable elements”), all of which are incorporated by reference herein in their entirety.

[0014] As stated, U. S. Patent Publication No. US20250274289A1 describes an arrangement for converting a digital file into a CRP mechanism, which may be used for the generation of cryptographic components such as public or private encryption keys and verification of the authenticity of the file. To summarize that method, a file F is encrypted to generate a ciphertext C. Ciphertext C is converted to a digital bitstream of known length C* after concatenation with a nonce co. The length of C* may be d=2D, where D is a number of digits (for example, d may be 1024, which requires that D=10). The resulting d bits are located at addresses varying from 1 to d. A fixed length of C* may be achieved by hashing and extending C with an extended output function (XoF). The combination of SHA-3 and SHAKE is usable for this purpose and compliant with current NIST standards.

[0015] A challenge is generated, where the challenge has the form as the digital information needed to point at a particular position in the d-bit long stream C*. Challenges may be generated by generating a stream of S* bits by hashing and extending with a XoF a randomly selected seed S. The stream S* is segmented (sequentially or non-sequentially) into N challenges (ql,..., qi,....qN), each of which is D bits long. The D bits of each challenges qi are converted into a number xxi, with xxi G { l,d=2D}, which is turned into an address in C*. From each address xxi, P-bit long responses are generated from the content of C*. In total, the N challenges are pointing at N addresses in C* to generate N times P-bit long responses. In this manner, a digital file F may be converted into and used as a cryptographic CRP generator, which may be used for file authentication and secure file storage.

[0016] The key generation methods just described can be extended to implement a method of protecting digital files, such as medical files, in a distributed computing environment with multiple control points. In these arrangements, confidential files are stored in a distributed, networked environment (e.g., stored in the cloud). Each file has an abstract description of the content of the file. During an enrollment cycle, two complementary subkeys are generated directly from each digital file with a challenge-response-pair4QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)mechanism (CRP), one from the responses (the subkey Kr), and one from the challenges (the subkey Kc). Both the file and the abstract are encrypted concurrently as part of the CRP processing. As done with blockchain technology, the file is subjected to one-way functions (e.g., a hashing function) to ensure that a single bit change in the file totally changes the resulting data streams of the CRP mechanism. During a verification cycle, the subkey Kc from the challenges can decrypt the abstract; however, both subkeys are needed to decrypt the file, which can be distributed to several parties. The subkey Kr from the responses can also be cut into separate segments, thereby enabling multiple points of control of the files.

[0017] The use of digital files as CRP mechanisms as summarized above has certain advantages. The challenge-response-pair (CRP) mechanisms described in this disclosure enable parties operating in a distributed network to rapidly verify the authenticity of digital files with relatively low computing load. An example practical use case is when a client wishes to provide proof of authenticity of an older financial transaction. According to the methods and arrangements disclosed here, the file can be manipulated to yield a CRP mechanism that has the same key advantages of PUFs, i.e., that have a high degree of uniqueness. This uniqueness is achieved by concatenating the files with randomly picked nonces. Most files are cloneable, therefore the nonces may be only used once, and may be erased after verification cycle. During an enrollment process, the input data, the “challenges”, generates with CRP mechanisms the output data, the “responses”, which can encrypt a proof of authenticity. After enrollment, the client can keep secret the nonce, erase the responses, and release the file, the challenges, and the encrypted proof of authenticity. The latter is recovered during a subsequent verification cycle when the client elects to disclose the nonce.

[0018] In the embodiments described herein, building on the disclosure of U. S. Patent Publication No. US20250274289A1, Multi -Factor Authentication (MFA), Challenge-Response Pair (CRP) encapsulation and blockchain verification are combined to provide secure storage and access to digital files. In an encapsulation cycle, two complementary subkeys are generated using a CRP mechanism as just described: one from the responses (the subkey Kr) and one from the challenges (the subkey Kc). The recovery cycle has two steps: i) a verification cycle requiring only Kc to allow the decryption of the abstract of the file, and ii) a decapsulation cycle in which the ephemeral key is uncovered allowing the decryption of the file.5QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)

[0019] To further protect the digital files, the history of the files is captured in a blockchain that includes a set of sequential events which are hashed, and concurrent events that are also hashed through a Merkle tree. The outcome of this chain of events is a short message digest of 256 bits that can be altered by changing a single bit in the history of the file. The blockchain process thereby offers a verifiable proof of file integrity and non-alterability. The disclosure describes ways to insert the message digest in the file, or / and the abstract in the CRP mechanism described in the referenced patent application to further enhance security. Such a combination offers the following features and mitigates the following vectors of attacks:

[0020] Prevents a concurrent alteration of the chain of events and the message digest.

[0021] The two-step cycle replaces the signature cycle of conventional blockchain-based protocols.

[0022] The verification of the non-alteration of the information can only be done after recovery and decapsulation cycles.

[0023] All background information can be either provided separately or can be combined with the file for encapsulation with the same ephemeral key.

[0024] For certain applications the background information could replace the abstract.

[0025] After decapsulation, the verification of the integrity of the information can be totally public, open to third parties, miners, smart contracts, and others.

[0026] The cryptography schemes needed by the protocols can be the ones used in current implementation of blockchains, or standardized post quantum cryptographic schemes.

[0027] Thus, in one embodiment, a computerized method of storing and managing access to a digital file is disclosed. The method combines blockchains with a CRP mechanism. The method begins with an enrollment process for one or more digital files. In the enrollment process, a blockchain comprising a digital file and the information describing the relevant chain of prior events (e.g., previous versions, access events, saves, etc.). The file and information is hashed to generate a unique message digest. The unique message digest is generated with methods such as, not to be limited to, the hashing of multiple digital files resulting from sequential and parallel events with hash functions and Merkle trees. In some cases, the unique message digest may be the root hash of a Merkle tree.6QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)

[0028] An ephemeral data stream is then generated, for example, with an RNG or PRNG process, to yield an ephemeral key. In certain cases, the ephemeral key may be a 256-bit long data stream. The digital file with the relevant chain of prior events and the unique message digest are separately encrypted with the ephemeral key yielding two sets of cipher text.

[0029] A reference table (i.e., a CRP mechanism) is then constructed from the cipher text of the unique message digest. By way of a non-limiting example, a 32 kbit table may be generated by applying the cipher text of the unique message digest to an extended output function (XOF) such as SHA-3 or SHAKE. The reference table is organized into addressable segments.

[0030] A randomly generated number is converted into a data stream, which is organized into segments that may be parsed or read to indicate addresses in the reference table. This is a set of challenges, which are recorded as a first subkey. In one embodiment, 256 challenges may be generated.

[0031] The challenges (first subkey) are applied to the reference table (The CRP mechanism derived from the encrypted message digest, which may be the root hash of the Merkle tree of the file blockchain) to yield a first set of responses. For example, the response set may be 256256-bit long responses.

[0032] The ephemeral key is used to filtrate this first response set to generate a response subset corresponding to address positions in the response set that correspond to the positions of “l”s in the ephemeral key. The responses corresponding to a state of “0” of the ephemeral key are erased. On average, the size of the subset of responses is half the size of the full set. The ephemeral key is also erased, while the subset of responses is recorded as the second subkey. It is important to note that the ephemeral key may be re-generated by comparing the subset of responses with the full set of responses. The ephemeral key will include a “1” at sequential positions in the full response set for which there is a matching response in the subset, and the ephemeral key will include a “0” at all other positions.

[0033] An abstract describing the purpose of the digital file, or containing some other useful but non-confidential information, and which does not disclose the content of the file is encrypted using one of the responses of the full set of responses. This may be done with any suitable encryption algorithm.

[0034] To conclude the enrollment cycle, both subkeys are distributed to controlling parties, and the cipher texts of the digital file with relevant chain of prior events information,7QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)the unique message digest, as well as the cipher text of the abstract are distributed to a storage node.

[0035] The controlling parties may be the same user or device, or may be different parties who control, separately, the two subkeys. In this last case, the controlling parties of each subkey can be further divided into separate parties that control only a portion of the subkey. Collaboration among all parties will be required in the distributed key or key fraction case for recovery.

[0036] The method then includes recovery and verification cycles. As is done during enrollment, the same reference table is generated from the cipher text of the unique message digest by retrieving it and subjecting it to the same XOF until a response string of the necessary length is achieved. The first subkey is used to generate the same full set of responses with the same CRP mechanism (i.e., the reference table). The full response set may be used to decrypt the abstract, to verify that the enclosed encrypted digital file is the correct one.

[0037] The second subkey is used to decapsulate the ephemeral key, thereby allowing the holder to decrypt the digital file, the information relevant to the chain of prior events, and the unique message digest. The digital file and the information describing the relevant chain of prior events are hashed with the same hash function and according to the same Merkle tree structure and the result is compared to the message digest to verify the correctness of the message digest and non-alterability.

[0038] The basic method just described is subject to numerous permutations, alterations and specific embodiments. For example, the reference table may be constructed from the cipher text of the digital file or the cipher text of the information relevant to the chain of prior events, or the combined cipher text of these data streams rather than the cipher text of the unique message digest. The unique message digest and the abstract can be combined, and then jointly encrypted by using a response as a cryptographic key. The methods may be simplified by keeping the information describing the relevant chain of prior events unencrypted.

[0039] In another embodiment, the method can be simplified in the following manner: During an enrollment cycle, the digital file is the only information encrypted by the ephemeral key while the relevant chain of prior events and unique message digest are kept un-encrypted. The reference table is constructed with the encrypted file rather than the ciphertext of the unique message digest. The ephemeral key is encapsulated with the CRP8QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)mechanism. The abstract is encrypted as described in claim 1 with one of the responses. The cycle will result in the distribution of the two subkeys, and the storage of the cipher texts of the digital file and the abstract. The relevant chain of prior events, and unique message digest are stored in clear. During verification, the reference table is generated from the cipher text of the digital file, the rest of the verification cycle follows a similar sequence to the one described above.

[0040] Further alterations are possible. For example, in an enrollment cycle, the unique message digest can be the only information encrypted by the ephemeral key while the digital file the relevant chain of prior events is kept un-encrypted. The reference table is constructed with the ciphertext of the unique message digest. The ephemeral key is encapsulated with the CRP mechanism. The abstract is encrypted as described in claim 1 with one of the responses. The cycle will result in the distribution of the two subkeys, and the storage of the cipher text of the unique message digest. The digital file and the relevant chain of prior events are stored in clear. During the verification cycle, the reference table is generated from the cipher text of the unique message digest; the rest of the verification cycle follows the same sequence as described above.

[0041] In one method, a protocol is provided in which the unique message digest is concatenated with a password to generate the reference table by using a XOF function.During enrollment the CRP mechanism converts the challenges into responses. The responses directly generate cryptographic keys that are used to encrypt the digital file. The unique message digest, password, the challenges and the cipher text of the digital file are distributed to the controlling parties and storage nodes. During recovery cycle, the same reference table is generated from the same unique message digest and password; the same CRP mechanism finds the same reference, thereby generating the cryptographic key needed to decrypt and verify the digital file.

[0042] In some embodiments, the randomly picked ephemeral data stream is used directly as a cryptographic key; or is a seed generating a private-secret key pair for asymmetrical cryptography; or a key for symmetrical cryptography.

[0043] The encryption schemes used by inventive embodiments can be based on any asymmetrical or asymmetrical cryptographic methods such as AES, Ascon, DES, RSA, Elliptic curve, Dilithium, Kyber, Falcon, SPHINCS, classic McElice, NTRU, Lattice cryptography, LWE, LWR, Code based cryptography, or hash-based cryptography.9QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)

[0044] The digital files that are secured and managed according to the methods described herein may be health and medical records, legal, administrative or real estate documents, financial or crypto-currency transactions.

[0045] The method described herein may use passwords and multifactor authentication schemes. The methods described herein may include recording each time the encrypted file is accessed on the blockchain. This record contains a unique digital identifier, such as a cryptographic hash, representing each access event, ensuring an immutable access history without exposing sensitive file details. Additionally, the embodying methods may be further enhanced by requiring multiple parties to work together for decryption of the file. In these embodiments, a fourth party, along with selected keyholders, holds components of the decryption key, making it impossible for any single party to access the file independently, thereby adding an additional layer of security and shared control. The method may be modified to require approval from multiple authorized parties for every file access. This decentralized approval mechanism bolsters security by preventing unauthorized access and ensuring that file access is controlled by consensus among authorized parties.

[0046] In certain embodiments, the method includes tracking file access using the blockchain’s decentralized structure. Each access event is recorded immutably on the blockchain, guaranteeing that all file access interactions are visible, verifiable, and secure, with no ability to alter or erase historical access records.

[0047] In certain embodiments, ephemeral key generation utilizes multi-factor entropy sources, combining inputs such as random data, hardware-based random values, and usergenerated inputs, to further enhance key security and ensure that each generated key is highly unpredictable and unique.

[0048] In certain aspects, the method may incorporate both Multi -Factor Authentication (MFA) and a Challenge-Response Pair (CRP) mechanism to verify user identity before granting access to digital files, constructing a multi-layered protocol that is secure against unauthorized access and tampering.

[0049] In certain embodiments, a message digest is used to generate a unique cryptographic reference table for each file access event, guaranteeing that each interaction is10QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)individually verified and tied to the blockchain's immutable history for enhanced security and traceability. In certain embodiments, dynamic interaction tracking is provided by generating a unique reference table for each access request, with the table structure based on a message digest, which minimizes key compromise risks and securely linking each access event to the blockchain ledger.

[0050] Methods and arrangements according to inventive embodiments have certain advantages. For example, while the use of blockchain technology and Merkle trees to secure digital files is known, the work described here focuses on utilizing blockchain technology incorporated with an encapsulation mechanism while also storing immutable file access histories and providing verifiable proof of file integrity. Furthermore, the work described in this disclosure employs a challenge-response pair (CRP) mechanism, which introduces an additional layer of security and robustness against attacks such as replay and man-in-the-middle attacks. Further, the embodiments to be described here provide tamper-evident file storage and tamper-proof credentials for accessing control through the blockchain immutable ledger, ensuring comprehensive traceability and preventing unauthorized decapsulations. By implementing Multi-factor authentication (MFA) as another layer, disclosed embodiments restrict access to only verified users who can regenerate ephemeral keys, protection not commonly found in traditional blockchain-based security protocols. These novel features make the disclosed protocol more suitable for applications requiring high levels of security and traceability than existing solutions.

[0051] Additionally, disclosed embodiments provide an ability to track interaction with a file at a higher level of detail, and provide file integrity validation by using a message digest as a seed for generating a dynamic cryptographic table. This feature provides a better resilient system by using the blockchain’s message digest to create a unique reference table for each access event, minimizing key compromise risks and linking each interaction to the blockchain’s immutable history.

[0052] Additionally, disclosed embodiments offer a method that requires multiple authorized parties to cooperate for decryption, enhancing security and access control.Moreover, the present invention tracks the file history and modifications via blockchain technology, providing an immutable audit trail, which is not addressed in the prior art. A distinct security layer is added using CRP encapsulation, which offers selective access11QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)control and prevents unwanted decryption by creating ephemeral keys for every file based on challenges and answers. A further protection not found in conventional smart contract data privacy solutions is that only verified users can regenerate or access these ephemeral keys thanks to our integration of MFA as an access gateway. These components work together to create a thorough and impenetrable security protocol that surpasses the encryption and data obfuscation methods outlined conventional systems.

[0053] In short, inventive embodiments integrate blockchain with a key encapsulation and encryption protocol and a CRP mechanism for multi-point access control. Such features provide a unique combination of data history tracking, encryption, and access control that is not addressed in the conventional art.

[0054] Additional advantages and features will be apparent upon review of the following detailed description.BRIEF DESCRIPTION OF THE DRAWINGS

[0055] The drawings described herein constitute part of this specification and includes example embodiments of the present invention which may be embodied in various forms. It is to be understood that in some instances, various aspects of the invention may be shown exaggerated or enlarged to facilitate an understanding of the invention. Therefore, drawings may not be to scale.

[0056] FIG. 1 schematically illustrates process flow through a computing system by which a digital file may be converted to act as a challenge-response-pair mechanism.

[0057] FIG. 2 schematically illustrates an alternative process flow through a computing system by which a digital file may be converted to act as a challenge-response-pair mechanism, in which a subset of responses is selected.

[0058] FIG. 3 schematically illustrates a process flow for secure storage, verification and decryption of a digital file and its abstract.

[0059] FIG. 4 schematically depicts an enrollment and key distribution process according to an embodiment.

[0060] FIG. 5 schematically depicts transfer and multipoint access of a file enrolled according to the process of FIG. 4.12QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)

[0061] FIGs. 6-7 show an enrollment process for a digital file according to an embodiment, at a higher level of detail.

[0062] FIGs. 8-9 show a verification and decryption process, at a higher level of detail.

[0063] FIG. 10 schematically illustrates a process flow carried out to construct a blockchain resulting from interactions with digital files.

[0064] FIG. 11 depicts a diagram of an exemplary implementation of the enrollment cycle including blockchain data.

[0065] FIG. 12 depicts one example of an implementation of the recovery cycle of the file processed according to the enrollment cycle of FIG. 11.DETAILED DESCRIPTION

[0066] The described features, advantages, and characteristics may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize that the invention may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments.

[0067] Reference throughout this specification to “one embodiment,” “an embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, appearances of the phrase “in one embodiment,” “in an embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment. References to "users" refer generally to individuals accessing a particular computing device or resource, to an external computing device accessing a particular computing device or resource, or to various processes executing in any combination of hardware, software, or firmware that access a particular computing device or resource. Similarly, references to a "server" and a “client” refer generally to a computing device acting as a server, or processes executing in any combination of hardware, software, or firmware that access control access to a particular computing device or resource.

[0068] Embodiments of the invention are directed to systems and methods for secure storage, verification and authentication of and tracking interaction with digital files. The13QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)methods described herein may be implemented in various computing environments, e.g., with multiple users or in client-server relationships and communicating with one other over a wired or wireless data communication network. Each computing device in the computing environment being used by a user (e.g., a client or server) may have various features. For example, a computing device may one or more programmable processors. These processors may be quantum or non-quantum processors. They may be native binary or native nonbinary (e.g., ternary) processors. Computing devices may also have one or more input / output devices that are typically found with computing devices such as keyboards, mice, network communications adapters, touch screens, stylus pads, cameras, microphones, speakers and monitors or other visual displays. Computing devices may also have volatile memory (e.g., RAM), in electronic communication with their respective processors.Computing devices may also have non-volatile storage (e.g., SSD drives, disk drives, flash storage, etc.) in electronic communication with their respective processors. Non-volatile storage may store computer code embodying computer executable instructions capable of being executed by the processors to carry out the various method steps discussed herein, including the method steps described below. Non-volatile storage may also store digital files, keys, hashes, ciphertext generated from digital files, and other data elements described herein. Computing devices may also include communication interfaces (e.g., network interface cards), which are data transceivers supporting communications via a data network (e.g., a LAN, WAN or the internet) with other computing devices. The data networks may be a wired or wireless data communication network and interfaces may be wired or wireless interfaces, or may include both wired and wireless interface components. Computing devices may also include random number generators, or pseudo-random number generators, as ASICs or preferably as software processes running on the device processors.

[0069] Disclosed herein is a method of interaction with and storing a digital file, which may be a set of medical records, records pertaining to a series of financial transactions, etc. The disclosed method includes three primary components: a blockchain component, enrollment, and recovery. In the blockchain component the file’s history is stored and a representative element of this history is stored for use in the enrollment and recovery processes. The enrollment process involves encrypting and encapsulating the digital file along with an associated message digest, distributing keys to multiple parties, and incorporating a CRP mechanism and blockchain file history to enhance security and14QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)traceability. The recovery process involves using a reference table and CRP mechanism to decrypt the file, verify the message digest, and validate the chain of prior events for integrity.

[0070] In this disclosure, the use of an encrypted or unencrypted digital file as a CRP mechanism for securing and authenticating the file will be discussed in reference to FIGs. 1-2. Then, an extension of that scheme to a distributed control scenario will be discussed in reference to FIGs. 3-9. The distributed control scenario relies on the example of a patient medical record as the digital file to be securely transmitted, but the invention is not so limited. Finally, the incorporation of blockchain technology to improve the described arrangements will be described in reference to FIGs. 10-13.

[0071] FIG. 1 shows a schematic arrangement for deriving a CRP mechanism for a digital file F, which preferably is stored in non-volatile data storage as described above. The method illustrated in FIG. 1 is preferably executed by one or more programmable processors in one or computing devices, where the one or more processors execute computer readable program code stored in non-volatile storage, which embodies computer-executable instructions.

[0072] Referring now to FIG. 1, a file F is received. The file is encrypted with a secret encryption key Sk, that may be generated according to any public-private key asymmetrical encryption algorithm (e.g., DSA, RSA, ECC, Diffie-Hellman, etc.). The result of encrypting file F is a ciphertext C. A nonce co is generated, preferably with a random number generator or PRNG running as a process on one of the programmable processors of the computing device. C and nonce co are concatenated and the resulting bitstream is subject to a one-way function process that generates a fixed bit length output. For example, C and the nonce may be concatenated, then hashed, then provided to an extended output function (XoF). For example, the concatenation of the nonce and C can be provided to a NIST-compliant hash function (e.g., SHA-3, SHA-1, SHA-2, or ASCON.) and the result fed to SHAKE (e.g., SHAKE-128 or SHAKE-256) to generate an output bitstream of a predetermined bit length. This output bitstream will be denoted as C*, and will have a bit length of d bits, where d=2D. C* may then be segmented into d, addressable segments.

[0073] The same bitstream C* is used to generate a series of N challenges. This may done by generating a random seed number S, again preferably with a RNG or PRNG, but this process may be supplemented with other data like time, location, user supplied passwords, etc. Seed S is again subject to a one-way process that results in a fixed bit length output (e.g.,15QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)hashing with a hash algorithm and then subjecting the resulting hash to an XoF, as described above for the generation of C*). The result is S*, and the XoF resulting in S* is chosen such that S* has a bit length of NxD. S* is then segmented into N, D-bit long segments, each of which encodes an address (i.e., a bit position) in C*. C* may be challenged by reading a challenge, looking at the position in C* indicated by the challenge, and reading the response. Each response will be P bits long. For example, each response will be the bit located at position XXi, and then the next P-1 bits calculated according to the method set forth in (5) below.(1) Let C = encrypted file F with key Sk(2) From C and nonce co generate C*, a file of constant length d, with d = 2D(3) Organize C* with bits located at addresses 1 to d.(4) Generate N challenges from C*.• Pick random seed S• Hash and extend S to form S* a N x D long stream of bits• Segment S* into D-bit long challenges {qi,...,qi,...,qx}; i£{l, N}.• From {qi,...,qi,...,q\ } point at the positions {xxi,...,xxi,..., XXN} in C*; xxi G {1, d=2D}(5) From positions {xxi,.,.,xxi,..,, X N} generate N responses {n,..,,n,..., FN}• Let {xxji,i),...,xx(ij),...,xx(i,p)} be the P positions computed from any of the xxi with:o jG { 1, P}; a and P are prime numberso Ifj=l: x%(i,i) = xxio Ifje {2, P}: X(ij) = a xx(ij-i)+ P mod(2D).• Read in C* the P bits at position {xx(i,i),...,xx(i,j),...,xxi,p)} to generate stream n • Generate the resulting stream of responses consisting of N x P bits.

[0074] The probability to get twice to the same position during step (5) is non-negligeable, but this is acceptable for certain protocols. One of the remedies is to add an index to modify the responses during recurrent challenges. For example, during the second pass, the [3(3 can be replaced by PP+1 which is enough to generate a distinct response; the [3(3 is replaced by ft ft + 2, during the third pass, et cetera.

[0075] Note that the algorithm for generating responses disclosed above is exemplary only. Other ways of generating responses are possible. For example, a challenge, qi may be16QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)used as a seed to some one-way function, which may then produce an output of other locations within C* from which to assemble the bits of the response. Other variations are possible, the significant requirement be that the challenge is parsed or used in some way to identify bits in C* that will be the responses.

[0076] The response bitstream may be used as an encryption key to encrypt a file M attesting to the authenticity of F and or C, according to any encryption algorithm described in this disclosure. Alternatively, the response bitstream may be used as an input to a keying algorithm, for example, a keying algorithm used by any of the encryption algorithms disclosed in this disclosure. Alternatively, as is described more fully below, a key K may be randomly generated, and then the response bitstream may sub-selected to retain values at positions that correspond to a first digital symbol (e.g., a “1”) in K. K may then be used for encryption, and then deleted. The sub-selected response bitstream may be retained. In the future, to recover K, another full response bitstream is generated and is compared to the retained, sub-selected response bitstream. Matching positions in the full response bitstream correspond to “1” is K, and the remaining positions correspond to “Os”. In this manner, K can be recovered.

[0077] The CRP mechanism generation method described above and illustrated in FIG. 1 is highly secure because three totally independent streams are required in order to uncover the responses: C, m, and S. The responses cannot be generated if any of these inputs are missing, thus, keeping secret just one of the three provides enough security. The computing power needed to run the CRP mechanism is extremely low. In the example of the 256-bit long responses, the 256 bits randomly located in file C* can be quickly retrieved. For example, if N=16 and P=16, the CRP mechanism generates responses containing 256 bits. When d= 1024, D=10, a 16xl0=160-bit long random seed is needed.

[0078] The security of the technique set forth above may be expanded by using a subset of responses. After generating N responses having P bits each, an ephemeral key K may be picked randomly with a random number generator (RNG). Only the positions in the response bitstream corresponding to positions in K with a state of “1” (or generally, a first binary symbol) are retained, and these responses are used to later rebuild K by placing Is (or the first binary symbol) at the positions of matching responses, and then 0s elsewhere. This technique for key recovery is described in detail in U. S. Patent Publication No. US20250023736A1 entitled “Protocols with noisy response-based cryptographic subkeys” (published on January17QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)16, 2025), and that reference is incorporated herein by reference in its entirety for all purposes. Implementation of this technique for key generation results in retaining a response subset averaging N / 2 responses. The resulting subset of the sequence of responses is kept for future operation, and the key can be used to encrypt various files, and messages verifying authenticity. Fig. 2 shows a block diagram summarizing this scheme.

[0079] Such a CRP mechanism is more secure than the one presented above because four totally independent streams are requested to uncover the responses, which are C, m, S, and the subset of responses (derivable from K). The computing power needed to run the CRP mechanism could be higher than the simpler protocol, but remains low. For example, about 128 responses that are 32-bit long are generated when K is 256-bit long. Therefore, 4 Kbytes randomly located in file C* are retrieved, rather than 256 bits in the simpler protocol. This protocol eliminates the concatenation cycle of K as done in section 1.1, which accelerates the CRP process.

[0080] Various extensions and practical applications using the CRP generation mechanisms described above will now be disclosed.

[0081] A first example of use case is to validate the authenticity of ciphertext C in a distributed network (i.e., a network having two or more networked computing devices). C could be am encrypted contract describing a financial transaction with crypto-currencies. A client device should have the ability to involve an Agent to validate the authenticity of the contract as needed. Two protocols are presented below: a first protocol based on the CRP mechanism originally described (i.e., in FIG. 1) and a second protocol based on using K to select a response subset (i.e., in FIG. 2).

[0082] Using the responses as ephemeral keys

[0083] For this computer implemented method, a CRP mechanism is used such as the one described above and illustrated in reference to FIG. 1. The method starts with an enrollment process, during which Ciphertext C is used, nonce a> is chosen, and a randomly picked seed S is chosen to generate the responses. The responses are concatenated to generate an ephemeral encryption key K, which is used to encrypt an authenticating message M. During verification, the same CRP mechanism retrieve the key K to decrypt M from C, a> and S. In this simplified example d (length in bits of C*) =1024=210, D (length in bits of each address18QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)in C*) =10, N (number of challenges and responses) =32, P (bit length of each response) =8. The protocol is summarized as follow:

[0084] Initial set up - Enrollment

[0085] The initial set up can be initiated by a client computing device, with the objective of putting in place the mechanism protecting an authenticating message M with an ephemeral key K. The key K is generated according to the following algorithm, in which the Client computing device has access to an encrypted digital file C, and may generate two other random numbers (e.g., with an RNG or PRNG), the nonce and the seed S.(1) Generate C* from ciphertext C and nonce co(2) Organize the d-bit long file C* with bits located at addresses 1 to 1024.(3) Generate 32 challenges from C*• Pick random 320-bit long seed S• Segment S into 32 challenges {qi,...,qi,...,q32} that are 10-bit long each; i£{l, 32}.• From {qi,...,qi,...,q32} point at the positions {xxi,...,xxi,..., XX32} inC*; xxi E {1, 1024}(4) From positions {xxi,..,,xxi,.,., XX32} generate N responses {n,..,,n,...,r32}• Let {%X(i,i),...,xx(ij),...,xx(i,8)} be the 8 positions computed from any of the xxi with:o jG { 1, 8}; a and P are prime numberso Ifj=l: (i,i) = io Ifje {2, 8}: X(ij)= a xx(ij-i)+ P mod(1024)• Read in C** the 8 bits at position {x (i,i),...,x (ij),..., (i,8)} togenerate stream n Remark: The resulting stream of responses consistsof 32 x 8 = 256 bits(5) The responses are concatenated into an ephemeral 256-bit long key K.(6) Let M* = encrypted M with key K and symmetric encryption scheme(7) Memorize nonce co, and File F(8) Distribute C, the seed S, and M*

[0086] After completion of the initial set up, the client preferably erases the responses, and the ephemeral key, which can only be recovered with a CRP mechanism from the file C,19QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)nonce m and seed S With d= 1024, and N=32 the number of possible CRPs is 4.6 x1060; the entropy is 200.

[0087] Verification of the authenticity of C

[0088] Third parties seeking to verify the authenticity of C by recovering M need to get access to nonce m, the seed S, and M*. This may be done in a distributed system where the file C, the seed and cipher text of M are provided at a single storage node, while the client provides nonce a> to the party seeking to verify C. The verification protocol is the summarized as follow:(1) Recover C* from C and nonce co(2) Form 32 challenges from seed S(3) From the challenges, and C* generate 32 responses that are 8-bit long each (4) The responses are concatenated into an ephemeral 256-bit long key K.(5) Let M = decrypted M* with key K and symmetric encryption scheme

[0089] The computing power needed for verification is light. The CRP mechanism only requires the computing power to read 256 bits in file C*. The concatenation, and symmetrical encryption can be done with light methods that can be implanted in encryption specific hardware (e.g., asics). As discussed below, variations of the protocol can make the file C or the seed S secret instead of nonce a>.

[0090] Randomly selected ephemeral key generating a subset of responses

[0091] The protocol now described uses the method described above in regard to FIG. 2, which uses a randomly selected subset of responses, such that the final ephemeral key is generated using a random number. This results in the generation of a subset of the sequence of responses. The levels of security are higher. In this simplified example d=1024, D=10, N=256, P=32. The protocol is summarized as follows:

[0092] Initial Set Up / Enrollment

[0093] An initial set up is again initiated by a client with the objective of protecting an authenticating message M with an ephemeral key K. The enrollment procedure is as follows:20QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)The initial set up is again initiated by the client with the objective of protecting an authenticating message M with an ephemeral key K.(1) Generate C* from ciphertext C and nonce co(2) To organize the d-bit long file C* with bits located at addresses 1 to 1024.(3) Generate 256 challenges from C*• Pick random seed S• Hash and extend S to form S* a 256 x 10 long stream of bits• Segment S* into 10-bit long challenges {qi,...,q256}; i£{l, 256}.• From {qi,...,qi,...,q256} point at the positions {xxi,...,xxi,..,, 256} in C*; xxi 6 {1, 1024}(4) From positions {xxi,..,,xxi,.,., XX256} generate 256 responses {n,..,,n,..,,r256} • Let...,xx(ij),...,xx(i,32)} be the 32 positions computed from xxi with:o j G { 1, 32}; a and P are prime numberso Ifj=l: xx(i,i) = xxio If je {2, 32}: X(i,j)= a xx(i,j-i)+ P mod(1024)• Read in C** the 32 bits at position {xx(i,i),...,x (i,j),...,xxi,32)} to generate stream n (5) Pick randomly the ephemeral 256-bit long key K.(6) Keep the responses located at positions of K with a state of “1”(7) Delete the responses located at positions of K with a state of “0” Remark: this results in a subset of sequence averaging 128 responses.(8) Randomly inject up to 25% bad bits in the subset of responses.(9) Let M* = encrypted M with key K and symmetric encryption scheme(10) Memorize and keep secret nonce co, and File F(11) Distribute C, the seed S, the subset of responses, and M*

[0094] It will be noted that the probability to get twice to the same challenge during step (4), is non-negligeable, which potentially disadvantageous as it reduces entropy. One of the remedies is to add an index to modify the responses during recurrent challenges, as described above.

[0095] After completion of the initial set up, the client preferably erases the responses that are not part of the subset, and the ephemeral key K, which can only be recovered from C,21QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)nonce m and seed S. For example, if d =1024 bit, the number of possible CRPs is 3.4x 10^248; the entropy is greater than 256.

[0096] Verification of the authenticity of C

[0097] A party wishing to verify the authenticity of C needs to recover (i.e., decrypt) M. To do so, that party must obtain access to C, m, S, the subset of responses, and M*. In a distributed system, C, S, M*, and the subset of responses can be provided by a storage node, while the client may provide nonce a>. The verification protocol is the summarized as follows:1. Recover C* from C and nonce co2. Form 256 challenges from seed S3. From the challenges and C* generate 256 responses that are 32-bit long each 4. Recover K by comparing the 256 responses with the subset of responses.5. Let M = decrypted M* with key K and symmetric encryption scheme

[0098] A criteria may be applied to judge a matching response (i.e., when a response in the subset of responses matches a response in the generated responses). One match criteria determines a match when at least 25% of the bits are matching, which is higher than the rate of bad bits added during noise injection

[0099] The computing power needed for such a verification is higher, but still light for a distributed network. Step (8) of the enrollment cycle is to be considered as an example of additional security. The injection of bad bits in the subset of response, a process that can also be called “noise injection”, has no effect in the outcome of the protocol, as long as the noise level is below the threshold that can disturb the recovery of K. However, having noisy responses can increase the one-wayness of the CRP mechanism, by obfuscating the cryptoanalysis after verification cycle. Without such a feature, the crypto-analyst can keep track of the challenge- response-pairs for future analysis. An alternate method is the one in which the subset of responses is controlled by the client. Intentional errors can be injected on purpose into the key K, by making the subset excessively noisy. In such a case the retrieval of K may require data helpers, and fuzzy extractors.

[0100] In the following disclosure, the basic schemes described in reference to FIGs. 1-2 are extended to embodiments involving multi-point control and access of secured digital files in a distributed environment. These embodiments are described in reference to FIGs. 3-9,22QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)using the example of a patient medical record and a non-confidential header or abstract relating to that record. In the arrangement of FIGs. 3-9, we assume that there are three users or three computing devices, each of which has different levels of access and control of the record, a “doctor”, a “patient” and a secure electronic storage node.

[0101] The protocol, which is summarized in Fig 3, is handling a digital file F, and associated abstract M. The abstract can for example briefly describe the content of F, without the information that is judged confidential. The protocol has three cycles, enrollment, verification, and file retrieval through decryption:

[0102] During enrollment the files F and M are processed through a CRP mechanism to generate ciphertexts F° and M°. The first subkey Kc is generated from randomly picked challenges, and a second subkey Kr: {r’ 1,...,r’f} from f responses that are computed with the CRP mechanism. Any changes in F totally modify the ciphertexts, and Kr.

[0103] During verification cycle the abstract M is decrypted. The CRP processing is based on both the encrypted file F°, and subkey Kc. Therefore, a successful decryption of M only occurs by pairing M° and F°, which provides proof of authenticity of F.

[0104] During the retrieval of F through decryption both subkeys Kc and Kr are needed. This requires a collaboration between the parties keeping these subkeys. The f responses of Kc can be distributed to multiple control points to enhance security.

[0105] Variations of the protocol include the combination of both verification and decryption, as shown in the right side of Fig. 3. The protocol can also be simplified by eliminating the abstract, and verification cycle, as shown in the central bottom side of Fig. 3.

[0106] The protocol described above in reference to FIG. 3 will now be applied, as an example, to the protection of medical files archived in a storage node of a publicly distributed network. An abstract for each file is useful to avoid retrieving the wrong document.

[0107] Enrollment of the medical files: As shown in Fig 4, during the enrollment cycle, a set of k medical files Fi with their respective abstracts Mi are going through the encryption process, each file being also used to generate their unique key pair Kci - Kri. For each file the doctor keeps the abstract Mi and the subkey Kci while the patient keeps the same abstract and the subkey Kri. The cipher text of the file F°i and the abstract M°i are archived in a publicly available storage node. The overall enrollment cycle, which is fast and does not require a lot23QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)of gas (low computing power), can be done by the doctor, or a designate such as a smart agent. Both doctor and patient have a small app downloaded in their computing system to organize and store the abstracts and corresponding subkeys, which have small sizes, typically less than 10 Kbytes.

[0108] Transfer of the medical files: The protocol to transfer the file Fi to a new doctor has two steps: i) verifying that this is the right file, then ii) decryption of the ciphertext retrieved from the storage node, as shown in Fig. 5. The new doctor downloads in its computing environment the ciphertexts F°i and M°i from the storage node. The CRP processing can be an app that is available to the new doctor, or a service provided online by a smart contract.

[0109] To verify authenticity of Fi, the doctor transmits the subkey Kci to the new doctor. The CRP mechanism allows the deciphering of the abstract Mi after inputting the ciphertexts F°i and M°i. The new doctor can read openly Mi, confirming that it is what is needed. The deciphering of the file requires the second subkey Kri, which has to be provided by the patient. Every time a file has been decrypted, the ciphertexts F°i and M°i can be erased and replaced by new ciphertexts through a new enrollment cycle, and new pairs of subkeys can be generated. The subkey Kri can also be cut into smaller pieces and distributed to several control points to enhance security.

[0110] In this section, an example of the protocol described in reference to FIGs. 3 and 4 is provided in more detail. This embodiment is only an example, and its disclosure is not intended to be restrictive.

[0111] Enrollment cycle.

[0112] The block diagrams of the enrollment cycle of a file and its abstract are shown in Fig. 6, with details in Fig. 7.

[0113] To achieve one-wayness an ephemeral key is picked with a random number generator (RNG), shown in yellow in the top left of Figs. 5 and 6. This key is used to encrypt file F. In this embodiment, the RNG generate a seed L that is used to generate a publicprivate key pair through asymmetrical algorithms such as CRYSTALS Kyber or Dilithium, Falcon, NTRU, Classic Me Ellice, SPHINCS, RSA or Elliptic Curve Cryptography.24QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)

[0114] A second RNG, shown in top right of Figs. 5 and 6, generates random challenges that are part of the CRP processing, and form the subkey Kc.

[0115] The challenges are driving the F°-based CRP mechanism to generate a full set of responses in the following way:

[0116] Kc consists of two 256-bit long streams co and S.

[0117] The stream S is extended with an extended output function (XOF) to form the challenges of the CRP mechanism.

[0118] The stream co is a nonce concatenated with F° to prepare a file F°° of constant length d that feeds the CRP mechanism.

[0119] Each P-bit long response is generated from a challenge, the CRP, and a linear congruent random number generator with prime numbers α and β.

[0120] The first response is used as a cryptographic key to encrypt abstract M.

[0121] All other responses are processed to generate a subset of responses Kr:{r’l,...r’f } by re-using the ephemeral seed L in the following way:

[0122] The full set of responses is set to be the same length as L.

[0123] The subset of responses are the f responses from the full set corresponding to positions of L with a state of “1”. All other responses correspond to positions of L with a state of “0” and are erased.

[0124] The subset of responses Kr become the second subkey.

[0125] The output of the enrollment protocol for F and M consists of the two ciphertexts F°i and M°i, and the two subkeys Kc and Kr. All other elements used during the protocol are erased, such as the seed L and the public-private key pair, the first response used to encrypt M, and all responses corresponding to position of L with a state of “0”.

[0126] In the embodiment presented here, seed L can be a 256-bit long stream, and Kc consist of two 256-bit long streams co and S. It is preferred to select standardized algorithms for all the cryptographic schemes used in Algorithm 1; this includes the hash functions, XOF, and asymmetrical algorithms.25QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)

[0127] The fixed input data integers d and D, P and prime numbers α and ββ could be disclosed publicly in the storage node. To reduce collisions, d should be large enough, for example around one million. Lengthy responses P proportionally increase the latency, values in the 64 to 126 range have been preferred.

[0128] The algorithm just described is summarized in the table below.6.1: Enter fixed input data: integers d and D with d = 2D; P; prime numbers α and β;• Concatenate message digest with ω;• Form F°° by extending the concatenated stream with SHAKE;• Organize F°° with bits located at addresses 1 to d;6.3: Form S°: hash and extend S to (256+1) x D-bit long stream of bits:• Each D-bit long steam is a challenge qiwith i ∈ {0, 256]• When converted to a digital number each challenge qi∈ {1, d=2D}6.4: Point at positions {x0,...,xi,...,x256} in F°° from {q0,...,qi,...,q256}; xi∈ {1, d=2D} 6.6: Let xipoints at positions {x(i,1),...,x(i,j),...,x(i,P)} in C* with j ∈ {1, P}• Generate P bi I long r: For each x read in F°° the positions {x..jl)(......vy / t),....x,.V-1 o if i< N go back to 6.66.7: Combine the 256+1 responses to get {r0,...,ri,...,r256}

[0129] Verification and decryption cycles:26QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)

[0130] The block diagrams of the verification and decryption cycles are shown in Fig. 8, with details in Fig. 9, and the algorithm is summarized in the Algorithm 2 table below.

[0131] For verification only, i.e., to recover the abstract or certificate of authenticity M, Kr is not needed. The challenges are generated from Kc, then drive the F°-based CRP mechanism to generate a full set of responses in the following way:

[0132] Kc consists of two 256-bit long streams co and S.

[0133] The stream S is extended with a XOF to form the challenges of the CRP mechanism.

[0134] The nonce co is concatenated with F° to prepare file F°° for the CRP mechanism.

[0135] Each P-bit long response is generated from the linear congruent RNG.

[0136] Only the first response is used as a cryptographic key to decrypt M°, showing in clear M as a proof of authenticity of F°.

[0137] For decryption, both subkeys Kc and Kr are needed. The ephemeral seed L is retrieved by comparing the full set of responses with the subset of f responses Kc:{r’ 1,..,,r’f} in the following way:

[0138] The positions of a full set of responses with a matching response from the subset carry a state of “1” in seed L.

[0139] The positions of a full set of responses without any matching response from the subset carry a state of “0” in seed L.

[0140] From seed L a public-private key pair is generated, allowing the deciphering of F.

[0141] The output of the verification cycle is abstract M, and the output of the decryption cycle is file F. The security is enhanced by distributing the responses of Kc to multiple participants.

[0142] The decryption algorithms are summarized below:27QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)Algorithm 2: Decrypt {M°; F°} with Kc and Kr→ Step 1 – Decrypt the summary M with subkey KcStep 2 – Decrypt file F with subkey Kr5.1: Start with j=1 and i=15.2: If i=N+1 → Go to 5.41115.3: If i< N + 1: Compare r';with ro The bit position i of L is a 1, then go back to 5.2 with j=j+1 and i=i+1;o The bit position i of L is a 0, then go back to 5.2 with same j and i=i+1;5.4: Generate key pair Pk / Sk from L;

[0143] The detailed protocol presented in section 5 is an efficient embodiment of the generic protocol presented in sections 3 and 4, however variations can be more appropriate for certain applications. Additional examples follow:

[0144] Combination with multi-factor authentication (MFA):

[0145] The nonce co can be replaced by an MFA factor such as, not limited to, a pin code, password, biometric print, or a PUF. In this case the subkey Kc can be reduced to the challenge generating seed S.

[0146] The seed S, nonce co or seed L can be concatenated with an MFA factor.

[0147] The protocol can be simplified by eliminating nonce co.

[0148] Ephemeral seed L can be used as a symmetrical cryptographic key to encrypt and decrypt F. The symmetrical algorithm could be AES, DES, or lightweight codes such as Ascon.28QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)

[0149] The CRP mechanism can be based on a PUF, and the ciphertext F° can be concatenated with seed S to generate the challenges.

[0150] The seed L can be memorized as a backup key to be used if the doctor loses subkey Kc or if the patient loses subkey Kr.

[0151] The subset of responses can be replaced by a second response with the following method:

[0152] The CRP mechanism generates only two responses {r0, rl }.

[0153] The second response rl is XORed with seed L.

[0154] The subkey Kr is the resulting stream: Kr = rl © L.

[0155] During the decryption and the recovery of seed L, rl is generated again with the CRP mechanism, and XORed with Kr: L= rl © Kr.

[0156] The public-private key pair is computed from L, which allows the deciphering of F.

[0157] The subset of response protocol can be replaced by the XORing of one of the responses with seed L. The resulting stream is turned into the subkey Kr kept by the patient. During decryption cycle, the XORing of Kr with the same response reveal seed L, thereby allowing the deciphering of F.

[0158] The subkey Kr can be subjected to the injection of bad bits. The recovery of seed L has then to include error management schemes.

[0159] The f responses of Kr can be XORed or encrypted with one additional response generated by the CRP mechanism to obfuscate each. During the recovery cycles the f responses are XORed again with the same additional response.

[0160] Kr can be encrypted with Kc.

[0161] In order to give access to multiple parties, multiple responses can be generated with the following method:

[0162] The CRP mechanism generates several responses: {r0, rl,..., ri,..., rm}.

[0163] Seed L is extended to generate m seeds Li.29QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)

[0164] Each response ri is XORed with seed Li.

[0165] The sub key Kri is given by: Kri = Li = ri © Kri.

[0166] Each subkey Li can then be used to encrypt digital files related to file F.

[0167] Another way to spread the control of the deciphering of the files is to generate q subkeys to form Kc, for example in the following way: Kc = KcO ©... © Kcq. The q subkeys are then distributed to several parties, requested to establish a consensus between them.

[0168] It should be noticed that all variations provided above follow the general method described in above in connection with FIGs. 3-9, thereby not limiting the number of possibilities to embody the invention.

[0169] The remainder of this disclosure describes how the concepts introduced above may be extended to provide additional security and traceability when combined with blockchain technology. This section outlines an example implementation of a blockchain component for the present invention. It highlights its role in securely storing the file's history and generating a representative element of this history to be incorporated into the enrollment and recovery processes. The blockchain component provides an immutable, tamper-evident ledger of file history. Here “tamper” may include but is not limited to modifications and accessing the information in the file. Below is described a sequence of method steps for constructing a blockchain according to an embodiment of the invention, and FIG. 10 presents an example of the blockchain component’s structure.

[0170] The following steps outline an example implementation of the blockchain component and structure referring to FIG. 10 as reference.

[0171] Chain of Events:a. Each Block (Ml, M2, M3,... Mn) represents an event and its associated message digest within the blockchain.b. Events are captured sequentially (from Ml to Mn) to establish a chronological order, while also allowing for aggregation of concurrent data.

[0172] Event Aggregation / Hashing:a. Each block (Ml, M2, M3,...) contains a set of events labeled A, B,... F. These are individual data items or events associated with each block. An example of an event would be an alteration to the file, i.e., an edit and save process.30QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)b. Aggregation is performed on these events to consolidate and prepare them for hashing in the next step.

[0173] Merkle Tree Construction:a. The hashed events from each block are organized into a Merkle Tree. b. The Merkle Tree structure helps in creating a Merkle Digest (MD back) by combining the hashed values of sequential and concurrent data.c. This digest, MD back, acts as a cryptographic representation of the entire chain of events up to this point, preserving integrity and detectability of alterations.

[0174] Message Digest MD back:a. MD back is the Message Digest generated by the Merkle Tree and acts as a compressed representation of the entire chain of events and associated data. b. MD back helps ensure the data’s integrity; any change in the events would result in a different MD back, immediately signaling tampering.

[0175] Final Verification and Output:a. MD_f: This message digest is generated from a final combination of MD back and File F.b. MD_f serves as a unique, final message digest that represents the current state of the blockchain with respect to the file F and its historical context.c. This structure allows for a traceable, immutable chain that can verify the integrity of the file F against its entire event history.

[0176] Enrollment Description

[0177] This section provides a general implementation description of the enrollment cycle for the disclosed protocol. The enrollment process involves encrypting the file along with its message digest, distributing keys to multiple parties, and incorporating a CRP mechanism. Additionally, the blockchain component is used to store the file's history, enhancing security and traceability. A step-by-step breakdown of the enrollment cycle is provided. Fig. 11 illustrates an example of the enrollment process. Additionally, an algorithm is provided to further detail the implementation of the enrollment process.

[0178] Step-by-Step of Enrollment Process

[0179] The following steps outline an example of enrollment cycle referring to FIG. 11 as reference.31QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)

[0180] Encapsulation Phase:

[0181] Generate Message Digest (MD f):

[0182] Start with MD f, which represents the message digest of the file and its background information (historical data). This step hashes the digital file along with any associated historical records to generate a unique message digest, ensuring data integrity.

[0183] Form Abstract Message (M'i):

[0184] The digest MD f is combined with M i (the original message with file) to create M'i = M_i + MD f, serves as a representation of the data, which will be used as an encapsulated form for additional security.

[0185] CRP Processing:

[0186] M i and F_i (the original file and message) are passed into a Challenge-Response-Pair (CRP) Processing mechanism.

[0187] The CRP processing is employed to derive two components essential for secure access to regenerate the ephemeral key:

[0188] Kc: a random number associated with generating challenges

[0189] Kr: subset of responses filtered from the full set with the ephemeral key

[0190] Generate Encapsulated Output:

[0191] The encapsulated output consists of M'°i; F°i where M'°i is M’i encrypted using one of the responses in the full set and F°i is the encrypted file.

[0192] Distribution Phase:

[0193] To Doctor and Patient:

[0194] Distribute M l; K_C1; B_C1 (Doctor) and M l; K_R1; B_C1 (Patient), where:

[0195] M l represents the file or message to be shared.

[0196] K_C1 and K_R1 represent control and recovery keys, ensuring secure access.32QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)

[0197] B_C1 indicates a blockchain-based integrity reference (e.g., a block identifier or code).

[0198] To Storage Node:

[0199] The encapsulated and encrypted M'i° and F°i are stored in the Storage Node as immutable data, ensuring long-term retention and integrity.

[0200] To Blockchain Node:

[0201] The Blockchain Node receives M; F°i entries with identifiers to store this data immutably, making it verifiable and tamper-evident.

[0202] Algorithm 1: Enrollment for file F and its abstract M using blockchain

[0203] Let subkey Kc be two randomly picked ephemeral streams {co; S} of length 256 bits

[0204] Let L be a randomly picked 256 bit long stream with f states of “1” and 256-f states of “0”

[0205] 1: Input data: {F; M; co; S}

[0206] 2: Compute M _i=M+MD_f

[0207] MD_f represents the message digest from the file history stored on blockchain

[0208] 3: Generate ephemeral key pair Pk / Sk using L

[0209] For example, this can be done by using post-quantum cryptography algorithms

[0210] 4: Define F°= file F encrypted with key Pk

[0211] 5: CRP Module: Generate a set of 256+1 responses from F° and Kc:

[0212] 5.1 Fixed input data: integers d and D with d = 2AD; P; prime numbers a, P

[0213] 5.2 Generate d-bit long F°°

[0214] Hash F° with SHA-256

[0215] Concatenate message digest with co33QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)

[0216] Form F°° by extending the concatenated stream with SHAKE

[0217] Organize F°° with bits located at addresses 1 to d

[0218] 5.3: Form S°: hash and extend S to (256+l)*D-bit long stream of bits:

[0219] Each D-bit long stream is a challenge q_i with i G {0,256 }

[0220] When converted to a digital number each challenge q_i£{l,d]

[0221] 5.4: At positions {xo,..., Xi,..., X256} in F°° {qo,...,qi,...,q256}; XiC{l,d=2D}

[0222] 5.5: Let Xi points at positions {x_((i,l)),...,x_((i,j)),...,x_((i, P))} in C* with j e {l, P}

[0223] Start with i = 0, j = 1: x_(i,j=l) =Xi

[0224] Iterate: x_(i,j) = (a * x<i,j-i) + P) mod (2D)

[0225] Generate P-bit long n: For each Xi, read in F°° positions{x_((i, 1 )),...,x_((i,j )),...,x_((i, P)) }

[0226] i = i + 1

[0227] if i < N, go to 5.5

[0228] if i =N, go to 5.6

[0229] 5.6 Combine the 256 + 1 responses to get {ro,...,ri,...,r256}

[0230] 6: Concatenate r_0 to get ephemeral key K O

[0231] 7: M°=Encrypt(M',r_0) encrypt M' with the first response r_0

[0232] 8: Generate sub key Kr

[0233] Let Kr be the f responses at positions in the full set of responses where the same position in L is a “1”, denote these responses as Kr ={ r_(l ),...,r_(i ),...,r_f }

[0234] 9: Erase {r_0; [ K] _0; L; Sk; Pk]

[0235] 10: Distribute:

[0236] { M'; K_r } to the 1st party (e.g., patient);34QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)

[0237] { M'; K_c } to 2nd party (e.g. doctor);

[0238] { M°; F° } to the storage node

[0239] 11: End

[0240] The encrypted file is hashed using a cryptographic hash function such as SHA-256. This hash serves as a digital fingerprint of the file, representing its contents without revealing any private medical data. Multiple party permission can be required for any changes to the file history, including file creation, to ensure access control. Other forms of access control can also be added to include other parties. Any modifications are recorded on the blockchain, ensuring that it remains immutable and resistant to alteration or deletion.

[0241] The abstract is then securely combined with the message digest derived from the blockchain, such as the proof of work (hash) from the most recent block or Merkle root. The blockchain can be implemented in various ways such as a Merkle tree, sequential chain, or other configurations, ensuring that each node contains comprehensive file history information.

[0242] After this initial step, the protocol is identical to Steps 2-8 in the original disclosure’s enrollment algorithm, which details the CRP Module and methodology for generating a set of responses from given challenges for the encapsulation process. The first response is used as a cryptographic key to encrypt the abstract integrated with blockchain M'. The next steps follow Steps 10-12 in the original disclosure enrollment algorithm to generate the subkey K_r.

[0243] The output of the enrollment protocol for F and M includes the two ciphertexts F°i and M°i, and two subkeys K_c and K_r. All other elements used during the protocol are erased to ensure security, such as the seed L and the public-private key pair, the first response used to encrypt M', and all responses corresponding to the position of L with a state of “0”.

[0244] Recovery Description

[0245] Herein is a general implementation description of the recovery cycle for the disclosed protocol. The recovery process involves decrypting the file and validating the file’s integrity. A step-by-step breakdown of the recovery process is provided, and FIG. 12 shows an example implementation of the recovery cycle. An algorithm is provided to further detail the implementation of the recovery process.35QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)

[0246] Step-by-Step of Recovery Process

[0247] 1. Input Components:

[0248] F°: Represents the encrypted original file that needs to be recovered and verified.

[0249] M'°: Represents abstract message associated with the original file, typically containing a previous message digest that provides context for verification.

[0250] 2. Reconstruct Background Data:

[0251] Historical Data: This step involves reconstructing historical data by retrieving the sequence of events related to the file recorded on the blockchain, denoted as Fl, F2,... Fn. This reconstruction ensures that all past modifications, accesses, or updates associated with the file are accounted for.

[0252] Sequence of Past Events: The system organizes these historical records in a chronological or logical sequence, ensuring that the original context and integrity of past events are accurately represented.

[0253] 3. Hashing and Verification:

[0254] Generate MD back: The reconstructed background data is hashed to create MD back, a message digest that represents the cumulative history of events for the file. This digest acts as a fingerprint for the historical data, ensuring that it hasn’t been altered since the file was initially stored.

[0255] This hashing process verifies the background and events associated with the file, setting the foundation for integrity checking in the next steps.

[0256] 4. Validate Integrity:

[0257] Comparison with MD back: The generated MDback is compared with previously stored message digests to ensure that no tampering or unauthorized changes have occurred in the file's history.

[0258] Confirm F°, M'°, and Historical Data: This step ensures that the original file (F°), its encapsulated abstract (M'°), and all historical data (from the sequence of events) are consistent and unchanged. Any mismatch would indicate an alteration, breaking the chain of trust.36QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)

[0259] 5. Output - Confirmed Integrity and Non- Alterability:

[0260] Upon successful validation that MDback matches the original, confirm that the file and its historical records have maintained their authenticity, integrity and accuracy without unauthorized alterations.

[0261] Algorithm 2: Recovery: De-encapsulation and file verification using blockchain

[0262] First, decrypt M° with sub key K_c; M° is the encrypted abstract integrated with blockchain. The result is a decrypted abstract integrated with blockchain M' and responses { r_(l ),...,r_(i ),...,r_256 }. Next, use MD_L to derive the abstract M and blockchain element MD back such as the hash of the most recent block. The integrity can be verified by examining MD back which should match the hash of the most recent block. Once the validation is confirmed, decrypt the associated file using subkey K_r in order to complete the secure retrieval of the original file.

[0263] Step 1 - Decrypt the encrypted abstract integrated with blockchain M° with subkey Kc

[0264] 1: Input data: {M°; F°] and Kc

[0265] 2: Use CRP Module (Algorithm 1) to generate 256+1 responses from F° and Kc

[0266] 2.1 Fixed input data: d, P, a, P

[0267] 2.2: Output data: 256 P-bit long responses { r_(l ),...,r_(i ),...,r_256 }

[0268] 3: Concatenate r_0 to get ephemeral key K O

[0269] 4: Let M' = encrypted file integrated with blockchain M°, decrypted with r_0

[0270] 5: Output: M' and responses { r_(l ),...,r_(i ),...,r_256 }

[0271] 6: Derive M and MD back

[0272] 7: Validate that MD back

[0273] Step 2 - Decrypt file F with subkey K_r

[0274] 8: Find L using Kr: {r'i,...,r'j,...,r'n} and {n,...,ri,...,r256}

[0275] 8.1 Start with j = 1 and i = 137QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)

[0276] 8.2: if i =N + 1: Goto 8.4

[0277] 8.3 if i < N + 1: Compare r'j with n

[0278] if r'j = n: L_i=l, and go to 8.2 with j = j + 1 and i = i + 1

[0279] if r'j n: L_i=0, and go to 8.2 with the same j and i = i + 1

[0280] 8.4: Generate key pair Pk / Sk from L

[0281] 9: Let F = file F° decrypted with Sk

[0282] 10: Output: F, Pk / Sk

[0283] 11: End

[0284] Examples of Variation Cases for File F

[0285] Case 1: In the described embodiment, the message digest MD is defined as the cryptographic hash of both the file and its file history represented as h(F+X_i F_i)=MD where S_i F_i is the sequence of events related to the file history which may include but is not limited to the times and methods by which the file was accessed, modified, or otherwise interacted with. MD incorporates both the present content of the file and its entire interaction history, providing a tamper-evident means of verifying both. Any alteration to the file or its history would result in a different MD, thereby revealing any unauthorized modifications to either the file itself or the history.

[0286] Case 2: In another variation, F' is defined as F combined with the message digest MD where F-F+MD. The inclusion of MD makes the file tamper-evident because any modification to F would result in a different MD.

[0287] Case 3: Similar to Case 2, in another variation, F' can be defined as the combination of F, message digest MD, and S_i F_i the sequence of historical events associated with the file (such as modifications, accesses, or other interactions), represented by F'=F+E_i F_i+MD.

[0288] Case 4: MD' can be defined as the combination of the abstract M with the message digest MD and the sum of file histories, represented by MD'=M+MD+X_i F_i.38QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)

[0289] Case 5: The message digest MD can be used to generate the cryptographic table, which is the basis of the CRP mechanism. MD can be derived from the equation MD=h(F+X_i F_i) or any other example cases as presented. This variation links the cryptographic table CRP mechanism with the file and its history.

[0290] Case 6: In this variation, F is encrypted using an ephemeral key K, and a modified version of the file, F', is also encrypted with an ephemeral key, which may be the same or different than K. This ensures that both the original file and its variations, whether through modification or other alterations, are securely encrypted.

[0291] Case 7: Blockchain as a Fourth Party to the File Access Process: In this variation, blockchain serves as a fourth party in the decryption process, holding a portion of the key. It leverages the decentralized and immutable properties of blockchain to securely track and verify the file’s history in the decryption process. This enhances transparency and adds an additional layer of security, ensuring that decryption can only occur when verified conditions are met.

[0292] Examples of Applications

[0293] This disclosure has many applications where maintaining privacy, integrity, and accountability of data is essential. The implementation of blockchain technology, due to its decentralized and immutable properties, guarantees the security and integrity of sensitive information against tampering. The following are some notable areas where this invention can be applied:

[0294] Medical Files: The tamper-evident methodology presented in this disclosure can help provide a verifiable way to track changes to medical files, preventing unauthorized alterations that could result in harm such as incorrect treatments.

[0295] File Systems: The invention may be applied to secure file systems using the immutable features of blockchain technology. This is essential because organizations and individuals must protect files from tampering in order to maintain record integrity, security, and accountability in file storage applications.

[0296] Financial Transactions: The invention incorporates immutable file history which guarantees transparency, effectively safeguarding against fraudulent modifications and creating reliable auditable trails for financial institutions and regulators.39QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)

[0297] Election Information and Voting Systems: The invention can be applied to elections and voting, allowing authorities to secure and verify voting records. Due to the incorporation of blockchain technology, the file cannot be accessed or changed, consequently reducing fraud risk and providing immutable records, enhancing the integrity of the voting process.

[0298] Public Camera Data Integrity and Facial Privacy Protection: The invention can protect private data captured by public cameras by requiring multiple users to decrypt the file, and using blockchain technology to create an immutable file history. It is essential to ensure the authenticity and immutability of footage from public cameras, such as traffic and retail surveillance, while protecting individuals' privacy by safeguarding facial recognition data from unauthorized access or alteration.

[0299] Police Files and Forensics: The invention can be applied to protect police and forensic files. Law enforcement agencies must ensure the secure handling of case files and forensic evidence to protect the integrity of investigations.

[0300] Supply Chain Management: Ensuring the traceability and authenticity of goods is essential. The invention tracks file history and can be used to deliver a transparent and auditable trail that confirms the integrity of supply chain data, thereby building trust.

[0301] Internet of Things (loT) and Sensor Networks: loT devices and sensors can be interfered with or tampered with. By using multiple access control and temper-evident file history, the invention can help keep the collected data accurate, verifiable, and secure, even in large-scale deployments.

[0302] Intellectual Property (IP) Protection: The invention can track digital ownership and access records using the incorporation of blockchain technology, which provides an immutable and transparent ledger to protect copyrighted works, patents, and other intellectual property assets. This ensures secure ownership verification and prevents unauthorized use or modification.

[0303] Digital Identity Verification: The invention can be used to securely record and protect user identity, ensuring it remains immutable and verifiable. This reduces the risk of identity theft. Additionally, requiring multiple parties for file access enhances user control over personal data.40QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)

[0304] Academic and Research Data Integrity: The invention can assure the integrity of academic research data by using blockchain technology to provide a verifiable, tamper-evident record for data collection, analysis, and publication. This ensures the authenticity and reliability of research.

[0305] Legal Document and Contract Authentication: The invention can be applied to secure legal documents and contracts by using blockchain technology such as Merkle Trees to maintain a transparent and verifiable history of modifications and access, providing reliable evidence for legal disputes and audits.

[0306] Health Insurance Claims and Records: The invention can be used to protect and track health insurance claims, policies, and changes using blockchain, preventing scams and fraud while maintaining a transparent claim history.

[0307] Automotive and Property Leasing: The invention can be applied to record leasing terms and service records for automotive or property leases, guaranteeing transparency and accountability between all parties involved.

[0308] Digital Art: The invention can be applied to authenticate and verify ownership of digital assets, ensuring their origin and preventing counterfeits.

[0309] Real Estate Transactions: The invention can be applied to track ownership, transaction history, and property documents, providing verifiable and tamper-resistant records to enhance trust.

[0310] Government Records Services: The invention can be applied to secure sensitive government records, such as property titles and licenses, while providing citizens with verified access to their personal records.

[0311] Pharmaceutical Supply Chain and Drug Authenticity: The invention can be applied to verify pharmaceutical supply chain steps and drug authenticity, reducing the risk of counterfeit products and enhancing public health safety.

[0312] It should be understood that, unless explicitly stated or otherwise required, the features disclosed in embodiments explicitly described herein and elsewhere in this disclosure may be used in any suitable combinations. Other embodiments and uses of the above inventions will be apparent to those having ordinary skill in the art upon consideration of the specification and practice of the invention disclosed herein. It should be understood 41QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)that features listed and described in one embodiment may be used in other embodiments unless specifically stated otherwise. The specification and examples given should be considered exemplary only, and it is contemplated that the appended claims will cover any other such embodiments or modifications as fall within the true scope of the invention.42QB\99804667.1

Claims

ATTORNEY DOCKET NO. 2025-013 (133502.00249)CLAIMSThe invention claimed is:

1. A method of securing and managing a digital file on one or more computing devices, wherein the digital file is organized as a blockchain comprising one or more payloads (F), an abstract comprising a record of past events regarding the one or more payloads (M) and a unique message digest (MD_f) comprising hash of F and M, the method comprising:receiving F, M and MD_f;generating M’ as a combination of M and MD_f;generating a random bitstream L and generating an ephemeral key;encrypting F with the ephemeral key resulting in FO;generating an addressable reference table with FO;generating a random bitstream Kc and parsing Kc into a set of challenges indicating addresses in the addressable reference table;apply the set of challenges to the addressable reference table resulting in a full set of responses;selecting a subset of responses (Kr) within the full set of responses that have positions in the first set of responses corresponding to the positions of a first binary symbol in the ephemeral key;encrypting M’ with one of the full set of responses resulting in M’O;distributing Kc and Kr to controlling parties, andstoring FO, M’O and MD_f at a storage node.

2. The method of claim 1, wherein generating an addressable reference table comprises subjecting FO an extended output function.

3. The method of claim 2, wherein the extended output function is one of SHA-3 or SHAKE.

4. The method of claim 1, wherein the unique message digest comprises an iterative hash of data reflecting past events regarding one or more portions of F.43QB\99804667.1ATTORNEY DOCKET NO. 2025-013 (133502.00249)5. The method of claim 4, wherein the unique message digest comprises one or more elements of a Merkle tree of the digital file.

6. The method of claim 1, wherein, generating Kc comprises generating two random bitstreams.

7. The method of claim 1 wherein one or more of the encryption steps are based on AES, Ascon, DES, RSA ECC, Dilithium, Kyber, Faison, SPHINCS, classic McElice, NTRU, Lattice Cryptography, LWE, LWR, Code based cryptography or hash based cryptography.

8. A method of accessing and authenticating a digital file stored according to the method of claim 1, comprising:generating the reference table from FO;using Kc to generate the full set of responses from the reference table;using a response from the full set of responses to decrypt the M’O;using the full response set and Kr to regenerate the ephemeral key;using the ephemeral key to decrypt FO.

9. The method of claim 8, further comprising deriving a version of MD_f derived from the decrypted M’O with the version of MD_f stored at the storage node.

10. The method of claim 8, wherein generating the reference table from FO comprises using the same process that was used to generate the reference table initially.

11. The method of claim 1, wherein the digital file comprises one of a health and medical record, legal, administrative or real estate document, or a financial or crypto-currency transaction.44QB\99804667.1

Images