Computer-implemented method and system for encrypting data

Abstract

A method for encrypting data is disclosed. The method includes: providing a first private key (V A ) and the first public key (P A ) determines a public secret (S1) shared by the first node and the second node at a first node associated with a first public key and a private key pair of the cryptographic system, wherein the second node has a second private key (V B ) and the second public key (P B ). A public secret is determined based on the first private key and the second public key, and the characteristics of the cryptographic system enable the public secret to be determined based on the second private key and the first public key. An encryption key based on the public secret is determined for use in encrypting data (M), and the data is encrypted based on the encryption key, wherein the step of encrypting the data includes an exclusive OR (XOR) operation.

Description

Technical Field

[0001] The present disclosure relates to computer-implemented methods and systems for encrypting data, and particularly, but not exclusively, to such methods for use on a blockchain. The present disclosure also relates to a method of applying authentication data to a message. Background Art

[0002] In this document, we use the term "blockchain" to include all forms of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and variations thereof. Although other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. Although Bitcoin may be mentioned herein for convenience and illustrative purposes, it should be noted that the present disclosure is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols fall within the scope of the present disclosure. The term "user" herein may refer to a person or a processor-based resource.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a decentralized, distributed computer system composed of blocks, which in turn are composed of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and consists of at least one input and at least one output. Each block contains a hash of the previous block, so blocks are chained together to create a permanent, unchangeable record of all transactions entered into the blockchain since its inception. Transactions contain small programs called scripts embedded in their inputs and outputs. These programs specify how and by whom the transaction's outputs can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] In order for a transaction to be written to the blockchain, it must be "validated." Network nodes (miners) perform work to ensure that each transaction is valid, and invalid transactions are rejected by the network. The software client installed on the node performs this validation work for unspent transactions (UTXO) by executing their locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to true (TRUE), the transaction is valid and written to the blockchain. Therefore, in order for a transaction to be written to the blockchain, it must: i) be validated by the first node that receives the transaction – if the transaction is validated, the node relays it to other nodes in the network; ii) be added to a new block constructed by miners; and iii) be mined, that is, added to the public ledger of past transactions.

[0005] While blockchain technology is widely known for its cryptocurrency implementations, digital entrepreneurs have begun exploring new systems that leverage the cryptographic security underlying Bitcoin and the data stored on blockchains. It would be highly advantageous if blockchain could be used to automate tasks and processes beyond the cryptocurrency realm. Such solutions would leverage the benefits of blockchain (e.g., permanent, tamper-proof recording of events, distributed processing, etc.) while offering greater versatility in their applications.

[0006] In systems where communication between parties occurs over an insecure network, an important issue is the establishment of a shared private key. Secure key distribution protocols have been developed to address this problem, including the Diffie-Helman (DH) symmetric key exchange [Merkle, Ralph C. (April 1978), "Secure Communications Over Insecure Channels", Communications of the ACM. 21(4):294–299, and Diffie, Whitfield; Hellman, Martin E. (November 1976), "New Directions in Cryptography", IEEE Transactions on Information Theory. 22(6):644–654] and the three-pass protocol [Menezes, A.; van Oorschot, P.; Vanstone, S. (1996), "Handbook of Applied Cryptography", CRC Press. p. 500]. While these methods achieve secure encryption, generating and sharing large key sets or continuously generating keys is computationally expensive.

[0007] International patent application WO2017 / 145016 discloses a method for establishing a series of shared secret keys using only public keys, deterministic keys, and elliptic curve algebraic properties. The shared secret keys do not need to be transmitted over a public network, making them immune to man-in-the-middle attacks. From this shared secret key, it is almost trivial to derive any number of additional shared private keys using elliptic curve arithmetic or the key generation extensions proposed in this work. It should be noted that the protocol is agnostic to key length, as keys can be concatenated or truncated to reach the desired length.

[0008] It is desired to provide a more computationally efficient extension to the protocol disclosed in international patent application WO 2017 / 145016, but maintaining the same level of security. Summary of the Invention

[0009] Thus, according to the present disclosure, there is provided a method as defined in the appended claims.

[0010] A method of encrypting data may be provided, the method comprising:

[0011] Determining, by a first party, an encryption key for encrypting data based on a common secret shared by the first party and a second party;

[0012] encrypting the data based on the encryption key to provide encrypted data, wherein encrypting the data comprises at least one exclusive-OR (XOR) operation; and

[0013] The encrypted data is incorporated into a blockchain transaction.

[0014] A method of generating an encryption key for encrypting data may be provided, the method comprising:

[0015] An encryption key for encrypting data is determined by a first party, wherein the encryption key is based on at least one exclusive OR (XOR) combination of first data and second data, the first data being based on a common secret shared by the first and second parties, and the second data being based on applying a one-way function to data based on the common secret.

[0016] A method of applying authentication data to a message may be provided, the method comprising:

[0017] Message authentication data is determined by a first party for a message to be transmitted to a second party, wherein the message authentication data is determined by applying a function known to the first party and the second party to the message and a common secret shared by the first party and the second party.

[0018] There may be provided a system comprising:

[0019] processor; and

[0020] A memory comprising executable instructions that, upon execution by the processor, cause the system to perform any embodiment of the computer-implemented method described herein.

[0021] A non-transitory computer-readable storage medium having executable instructions stored thereon may be provided, the executable instructions, which upon execution by a processor of a computer system, cause the computer system to perform at least any embodiment of the computer-implemented method described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Various embodiments according to the present disclosure will be described with reference to the accompanying drawings, in which:

[0023] Figure 1 It is a schematic diagram of the encryption and decryption protocol;

[0024] Figure 2 shows the processing of blockchain scripts for redemption of blockchain transactions;

[0025] Figure 3 Shows the block data encryption and decryption scheme;

[0026] Figure 4 A blockchain transaction incorporating message authentication data is shown;

[0027] Figure 5 shows a message authentication code protocol; and

[0028] Figure 6 is a diagram illustrating a computing environment in which various embodiments may be implemented. DETAILED DESCRIPTION

[0029] XOR-based encryption scheme

[0030] By symbol The XOR operation represented by is an operation between two binary bits that returns 1 if and only if one of the input bits is equal to 1. Otherwise, the operation returns the value 0. This can be summarized by the following truth table:

[0031]

[0032] Given a message M and a secret key S, the derived ciphertext of the message is given by For example, for message M = 011110 and secret key S = 101010, the encrypted message is calculated using a bitwise XOR operation:

[0033]

[0034] The decryption process uses the associative properties of the XOR operation and to retrieve the original message. That is, Therefore, to retrieve the original message (M), one only needs to compute the bit-wise XOR of the shared secret key (S) with the ciphertext message (M′):

[0035] Assuming that neither the secret key nor the message is known to any intercepting party, this provides a completely secure one-time-pad (OTP) communication method, provided that each secret key is used only once. One risk of transferring ciphertext over a public network is the malleability of the binary string in the event of an intercepting attack. However, this can be circumvented by exploiting the immutability of the public blockchain, as shown below.

[0036] Securely establish a shared private key

[0037] As established in international patent application WO2017 / 145016, a shared private key can be derived between two parties (e.g., Alice (A) and Bob (B)) using their public keys, a pre-agreed elliptic curve (e.g., scep256k1), and a generator point G. A and V B ). They each begin by computing their public key using elliptic curve arithmetic:

[0038] P A =V A ·G

[0039] P B =V B ·G

[0040] and continue to exchange their public keys. Alice uses her private key (V A ) and Bob's public key (P B ) to calculate the shared private key (S AB ):

[0041] S AB =V A ·P B

[0042] Bob uses his private key (V B ) and Alice’s public key (P A ) to calculate the shared private key (S AB ):

[0043] S AB =V B ·P A

[0044] Using the associative and commutative properties of elliptic curve point addition, it is known that the two calculated values are the same:

[0045] V A ·P B =V A ·(V B ·G)=(V A·V B )·G=(V B ·V A )·G=V B ·(V A ·G)=V B ·P A

[0046] Since the result of the calculation of the shared private key is a point on the elliptic curve (x AB ,y AB ), so they can agree, for example, to take S1 = x AB This has the same hierarchical structure and the same set of procedures as the arrangement described in International Patent Application WO2017 / 145016, but instead of using the generated secret as a symmetric key, it uses it as a one-time password (OTP) in an XOR-based sense. As in International Patent Application WO2017 / 145016, each of the procedures in this work can be extended to incorporate deterministic keys using a similar hierarchical key generation scheme.

[0047] Figure 1 A key generation and XOR message encryption protocol embodying the present disclosure is shown for communication between two parties over an unsecured public network. Public keys P are exchanged between Alice and Bob. A and P B Afterwards, they each use elliptic curve multiplication to compute a shared secret key S1. Alice encrypts message M using secret key S1 and includes the resulting ciphertext M′ in a transaction on blockchain 2. Bob reads ciphertext M′ and decrypts it using the shared secret key. Figure 1 The solid boxes in represent private parameters, while the dashed boxes represent publicly shared information.

[0048] Non-malleable XOR cryptography using blockchain

[0049] The immutability of public blockchains can address the scalability issues associated with transferring binary ciphertext across insecure networks. Ciphertext can be included within a Bitcoin transaction, which is sent to the network and immutably recorded on the blockchain. If the ciphertext is included in a transaction output, signed by the sender and verified by mining nodes, it will only be recorded on the blockchain if the ciphertext has not been altered since signing. Similarly, anyone reading ciphertext from the blockchain can ensure the integrity of the transaction data by verifying that the transaction hash equals the transaction ID. This ensures the end-to-end immutability of the ciphertext. Furthermore, because the signature is unique to the public key, the identity of the sender can also be verified. However, if the data is included in an input script, authenticity cannot be guaranteed, as this part of the transaction is not signed by the sender.

[0050] There are two options for inserting ciphertext in a transaction's outputs.

[0051] 1. Unspendable Output (OP_RETURN)

[0052] If the data is included in an OP_RETURN, it cannot be used in future locking scripts, but can be used as storage for the ciphertext. For example, if the address of the recipient Bob is included in the transaction, Bob's wallet can scan the blockchain to reference his address (e.g., using a smart wallet such as the one used in the tokenization protocol [William H, Brian P, Flannery P, Saul A et al., Numerical recipes in C: The Art of Scientific Computing (1992) Cambridge]) and locate the ciphertext. Bob can then calculate the shared private key (S1) using the protocol established above, and then use Retrieve the original message locally. Figure 1 Using this method, data transmission can resist man-in-the-middle attacks.

[0053] It should be noted that since the process only requires XOR calculations, this can be easily performed on devices with low processing power.

[0054] As a use case, suppose that service provider Alice (A) wishes to send a one-time session key to user Bob (B). This session key can be included as a message addressed to Bob and used to verify login credentials, initiate a communication channel, or be used in any other application requiring authentication, replacing the conventional username and password-based system.

[0055] When two parties establish a one-time session key, K, the process proceeds as follows. To enable reuse of the shared secret key, it should not be used directly in obscuring messages. By encrypting the session key using the hash value of the shared secret (H(S1)), a single exposed session key does not reveal the secret key.

[0056] 1) A calculates S1 = x AB .

[0057] 2) A calculation

[0058] 3) A creates a transaction to B and Included in the script as public text.

[0059] 4) B receives Tx. When receiving, B does not need to spend tx to check

[0060] 5) B calculates S1 = x AB .

[0061] 6) B calculation

[0062] 7) B now has the session key, which is private and can be used on other systems for authentication or access (e.g. for control and proof tokens).

[0063] Alice can then request the hash puzzle solution h(K) in order to gain access to her system. Since there is no risk of exposing S1, it is safe to continue reusing the same shared secret.

[0064] 2. Spendable Outputs

[0065] A similar approach to the above can be used to insert ciphertext as a spendable output using OP_DROP instead of OP_RETURN. However, in Bitcoin Script, the opcode OP_XOR allows spending conditions to be imposed by decrypting the ciphertext, thereby opening up interest in masked data until it is spent. For example, the XOR operation can be used to obfuscate inputs or exchange OTP keys that Alice and Bob can use to create a more private and secure script. Without any interaction with Bob, Alice can use this secret value (S1) to hide the payment to him while the payment remains unspent.

[0066] To do this, Alice uses a locking script of the following form:

[0067] OP_DUPOP_HASH<h(S1)> OP_EQUALVERIFY

[0068]

[0069] OP_DUPOP_HASHOP_ROTOP_EQUALVERIFYOP_CHECKSIG

[0070] This is solved with the following input:

[0071] <SigP B > <P B > <s1>

[0072] The first line of the locking script is a hash puzzle that ensures the correct shared secret is used. The second line uses the secret to decrypt <h(P B )>. The third line then checks the signature as in a standard transaction. The redemption process is evaluated in Figure 2 Shown in detail.

[0073] Note that when the above transaction is spent, the shared secret is exposed. This can be circumvented by replacing S1 with S′=h(S1) in the above script, which both Bob and Alice can calculate.

[0074] For example, Alice can create a transaction redeemable by either Bob or a third party, Charlie. Charlie's redemption conditions can be included in the locking script in the same manner using the shared secret key between Alice and Charlie. Using the properties of the hash function and XOR operation described above, the identities of Bob and Charlie can be completely hidden until the transaction is redeemed. When the transaction is redeemed, only the identity of the redeeming party is revealed.

[0075] This can be useful if two (or more) parties are anonymously competing to be the first to satisfy a condition or wait for one party to redeem (this can include the outcome of a sporting or other event). If there are multiple parties (e.g., Bob and Charlie), Alice can set a transaction in the same script to be redeemable by either Bob or Charlie, without the other party knowing. That is, Alice constructs a locking script using the conditional OP_OR, which is redeemable by either Bob or Charlie. This is a scenario where Bob and Charlie can calculate the XOR value of their own public key hash to redeem, but the other party cannot.

[0076] multi-party communication

[0077] The versatility of the XOR scheme allows for easy expansion of communication networks to include many members, each with a secure means of communicating among themselves. Using the aforementioned key distribution protocol or master key derivation method, it is straightforward to establish a decentralized communication network using XOR encryption and a one-time password. XOR-based encryption allows for secure and fast decryption even on devices with low processing power. For centralized systems where a service provider verifies identity and grants access rights to selected parties, additional challenges must be addressed.

[0078] For example, imagine a company or organization consisting of a manager named Alice (A). Alice (A) may want to provide encrypted communications between employees while also keeping a record of these communications. For example, Alice is sending a message to Bob (B), and Bob is sending a message to Charlie (C) (A→B, B→C). Alice may want to keep a record of all transactions to have a complete record of events on her network. Alice and Bob can use their shared key (S AB1 ) to communicate. When Bob sends a message to Charlie, they use their shared key (S BC1 ), but the message also uses the derived private key (S AB2 )Forwarded to Alice.

[0079]

[0080] This then links Alice to all other parties onwards, ensuring she is always aware of actions on the network. This allows for private communication between users who don't trust each other, while not being completely hidden from the service provider.

[0081] Key derivation scheme

[0082] Using the initial shared secret key derived from the above process, additional keys can be generated securely and efficiently without establishing a new set of private keys. By exploiting the infeasibility of inverting the hash function, the one-time password (OTP) restriction of the XOR encryption scheme can be relaxed without compromising security. This can be extended to very large numbers of keys to enable secure encryption of large data formats (e.g., multimedia files), as described below.

[0083] Using the single elliptic curve calculation above, the two parties establish the private key S1 = x AB A set of keys can be derived from this message to encode a predetermined number (e.g., n) of messages. The key set can be derived as produce:

[0084] S1=x AB

[0085]

[0086]

[0087]

[0088]

[0089] This key set is generated using only the initial shared secret and only a single initial elliptic curve point computation. These keys can then be used to encode n messages to S n Start. That is,

[0090]

[0091]

[0092]

[0093]

[0094] The initial shared secret is never used alone to encrypt a message, so that a single leaked message does not compromise the security of all encrypted messages. In addition, the use of hash functions in key calculations prevents reversal of the calculation. Therefore, by using the reverse order (S n+1 →S2) Use to find S n+1 Will not damage S n Since S1 and S i is infeasible, so even if a message M (n-i+1) , keys can also be reused safely.

[0095] Large data encryption using block ciphers

[0096] In order to efficiently encrypt large data sets (e.g., multimedia files), the data can be divided into blocks of fixed length and the same operation is performed on each block. It has been shown previously that additional security can be provided to block cipher schemes by exploiting the properties of matrix multiplication [Sastry, VUK; Anup Kumar, K. (2012) "A Modified FeistelCypher Involving XOR Operation and Modular Arithmetic Inverse of a Key Matrix", International Journal of Advanced Computer Science and Applications (IJACSA). 3(7): 35-39]. In the cited work, large strings are encoded by adding the ASCII value of each character to a matrix and multiplying the matrix with a key matrix randomly generated using a Feistel cipher (where a single string is typically encoded using repeated permutations and XOR operations). In this application, it is shown how to derive a deterministic key matrix to extend this process using XOR operations to securely and efficiently encode large data sets.

[0097] In this document, we outline the process derived in the following paper: [Sastry, VUK; Anup Kumar, K. (2012) "A Modified Feistel Cypher Involving XOR Operation and Modular Arithmetic Inverse of a Key Matrix", International Journal of Advanced Computer Science and Applications (IJACSA). 3(7): 35-39]. Large data sets are divided into 8-bit blocks, called words, and padded to ensure that the data fits exactly into the 2m 2 words. These words are then inserted as entries into a 2m×m matrix P. The prime modulus N is chosen to provide sufficient security for the desired application. To encrypt the data stored in P, a randomly generated key matrix K of size m×m is constructed. After this, the data matrix P is divided into two m×m matrices P=(P0,Q0). The algorithm for encrypting and decrypting these data matrices is shown below. The encryption (and corresponding decryption) algorithm is iterated n times, thereby providing additional security parameters. As the data is permuted with each iteration, the data becomes more chaotic as the number of iterations increases. This structure is used in the Data Encryption Standard or DES (n=16) and the Advanced Encryption Standard or AES (n=10-14).

[0098] Exploiting the nonlinearity of the encryption process ensures that even if multiple text-ciphertext pairs are exposed, the key cannot be determined using Gaussian elimination. Therefore, a single key matrix K can be used to encrypt multiple data files. Furthermore, the similarity between the encryption and decryption processes reduces the code size, thereby reducing the amount of hardware required for computation.

[0099] encryption

[0100] Input: P = (P0, Q0), n, K, and N

[0101] 1. For i = 1 to n:

[0102] conduct

[0103] P i =(K·Q i-1 K)mod N

[0104]

[0105] Finish

[0106] 2. Return C = (P n ,Q n )

[0107] Decryption

[0108] Input:C=(P n ,Q n ),n,K,and N

[0109] 1. Calculate K using Gauss-Jordan elimination method -1 [8]

[0110] 2. For i = 1 to n:

[0111] conduct

[0112] Q i-1 =(K -1 ·P i ·K -1 )mod N

[0113]

[0114] Finish

[0115] 3. Return P = (P0, Q0)

[0116] Construction of Feistel Cipher Key Matrix

[0117] Now we propose an improved Feistel encryption scheme that uses only the key S1 and Figure 3 As shown in detail in , the key S1 is generated using the above process. The key matrix K is constructed by repeatedly hashing the secret S1 and then performing a bitwise XOR with S1.

[0118] Using the above key generation protocol, we first derive m(m+1) unique keys from S1 as described above:

[0119] 1)

[0120] 2)

[0121]

[0122] i)

[0123]

[0124]

[0125] These elements are used to construct two matrices with linearly independent columns and rows (and therefore invertible).

[0126]

[0127]

[0128] K is then restricted to K=K1K2, which ensures that K is also reversible (necessary for the decryption process).

[0129] Secure multimedia transfer

[0130] Using more efficient methods for encrypting large data sets, multimedia files can be encrypted with end-to-end encryption to be securely sent across public networks (e.g., via the Internet and mobile phone service providers). The Coppersmith-Winograd algorithm can be used to encrypt large data sets in O(m 2.376 ) to perform both matrix multiplication and Gauss-Jordan matrix inversion with a computational complexity of 100%. This allows for sub-second encryption and decryption even on most modern mobile devices. Pre-dividing data into uniformly sized chunks facilitates including large files in the blockchain as a single stream or partitioning them across multiple transactions. Using the messaging protocol from the previous section, it can be easily integrated into peer-to-peer communications.

[0131] Big Data Encryption Using Stream Cipher

[0132] An alternative to block cipher protocols is a stream cipher scheme, where a key is continuously generated and the data is encoded rapidly, one bit at a time. Using a securely generated private key S1 and a derived key S2, a stream cipher seed can be generated using the concatenation (conc()) operation, starting with:

[0133] Seed = SHA 256 (conc(S1,S2))

[0134] Using a seed as input to a standard PRNG (pseudorandom number generator) and encoding the data using an XOR operation, a stream cipher can be shared as a fast encryption and decryption system. This type of protocol is necessary for secure streaming of media files or audio / video calls between two parties. The details of this protocol are discussed in relation to the Hash-based Message Authentication Code (HMAC), described in detail below.

[0135] Message Authentication Code (MAC)

[0136] Using a key distribution protocol, a message authentication code (MAC) can be created. A MAC allows the recipient of a message to verify the sender's identity and ensure the message has not been tampered with. The MAC is generated using a publicly known function of a shared secret key, known jointly to Alice (A) and Bob (B), along with the message being sent.

[0137] Blockchain-based message authentication code

[0138] Alice and Bob can establish a shared secret key (S1) using the protocol described above. That is:

[0139] S A ·S B G=P A S B

[0140] =P B S A

[0141] =(x AB ,y AB )

[0142] S1=(x AB )

[0143] A MAC is calculated from the shared secret key (S1 or some derived key from S1) and the message M using a known public function f (e.g., one that includes an XOR operation). Alice calculates the value y = f(M, S1) and sends the (M, y) pair to Bob. In the context of a blockchain, this information can be included in the transaction from Alice to Bob in an OP_RETURN or as metadata within the transaction. Bob can then retrieve this information from Alice's transaction and recalculate y to check its validity. If the message is not from Alice or has been altered, the function f will produce a different value for y and can be ignored.

[0144] For example, by limiting the message M to all transaction data before OP_RETURN, this provides a way to verify offline that the transaction data has not been changed during transmission without the need for miner verification. Figure 4 This is schematically shown in Figure 1, which shows a message authentication code (MAC) using blockchain transaction data. By incorporating transaction data into the MAC, it can be used as a transaction verification scheme to provide additional security without the need to connect to the network. This is crucial for extremely low-power mobile devices.

[0145] Figure 5 A message authentication code (MAC) protocol embodying the present disclosure is shown for communication between two parties using a public blockchain. After establishing a shared secret key (e.g. Figure 1 As shown in Figure 2, Alice uses the agreed-upon function f to calculate MAC(y) using the message M. Alice includes the message and MAC in her transaction to Bob. Bob calculates the MAC himself using his secret key and compares it with the MAC read from the blockchain. If they are equal, Bob can confirm the integrity of the message and the identity of the sender.

[0146] This verification method can be performed offline between two parties, where Bob can use information M and the shared secret S1 from Alice to receive a value offline and then accept the value y as authentication. That is, after calculating the secret key S1, Alice sends a transaction tx, which includes the message (M) as metadata. Alice sends the message pair (y, M) to Bob offline to authenticate the remote system, which views the transaction on the blockchain.

[0147] The process is as follows:

[0148] 1) A sends a transaction (including M) to B.

[0149] 2) A sends y to B directly or includes it in a transaction and sends it to B.

[0150] 3) The host calculates y = f(M, S1) using the shared secret S1. If the message changes, then y′ = f(M′, S1) will be different.

[0151] A MAC can also be used as a CRC (Cyclic Redundancy Check) to detect random errors in encoding or transmission. By verifying that the same MAC can be reproduced after transmission, it can be determined that the correct message was retrieved. This can also be used as an offline method of authenticating to a remote system.

[0152] Confidentiality

[0153] The MAC can be encrypted to increase the confidentiality of the transaction and authentication (e.g., to hide the values y and M when the MAC is sent to the server). A second generated key can be used to encrypt the MAC and provide additional privacy. This can be extended by using a hash to generate a second MAC key, allowing both authentication and confidentiality. To authenticate multiple items, a new key must be used for each item Alice wants to authenticate to the server.

[0154] Subkeys can be used to add additional complexity if desired. For example, if T A is a timestamp using the last valid block hash, which can be incorporated to form a key hierarchy:

[0155] P A →P A(1) =P A +T A G.

[0156] Then the key pair (S2, S3) derived from S1 can be used as coefficients and define the function as

[0157] f(M,K)=S2M+S3

[0158] f(M,K) can be made even stronger when, for some agreed-upon suitable integer N, y = (S2M+S3) mod N. If an attacker sees a pair (M,y), they still retain that pair when determining y′ for the next message N′.

[0159] Short MAC

[0160] A small amount of security can be sacrificed while still having a sufficiently secure MAC. In Bitcoin, the key length for only a single coordinate (S1) is taken to be 256 bits. For low-power devices, this can be reduced by using low-order values for the modulus, allowing the process to be performed in a reasonable time with moderate computing power. If a small N is chosen (e.g., 64 bits), then y≡S2M+S3modN is now restricted to a 64-bit value.

[0161] Alternatively, M can be divided into blocks of length less than or equal to N, M = M1, M2, ..., M t , where 0≤M i ≤ N. Using the above proposed protocol, a corresponding number of unique keys k = (S2, S3, ..., S t+1 ), where 0≤S i <N。

[0162] f(M,K)=∑S i M i S2(mod N)

[0163] Finally, there is a less secure but much simpler way of sending only the low-order bits:

[0164] y=S2M+S3(mod N).

[0165] Streaming Hash-based MAC (HMAC)

[0166] If the application requires additional security beyond that provided by a standard MAC, a hash-based MAC (HMAC) can be used. Unlike MAC, HMAC can be easily scaled to large files (exceeding the key size of the SHA256 hash, which is a requirement of the arrangement disclosed in International Patent Application WO2017 / 145016) using the stream or block encryption schemes proposed in Section 3. This can be done by breaking the file into 256-bit parts:

[0167] B0,B1,…,B n

[0168] Where n = (file size) / 256. n Pad with zeros to ensure that all B i The sizes are even.

[0169] protocol

[0170] Starting with the derived secret S1 using the method disclosed in international patent application WO2017 / 145016 and explained above, various operations including modular addition (+), XOR Hashing (h(x)) and concatenating (conc(a,b))) securely derives subsequent keys. Five valid alternatives to using a pseudo-random number generator (PRNG) are to use:

[0171] 1.S i =S i-1 +h(conc(i-1,S1,B0))

[0172] 2.S i =S i-1 +conc(h(B0),h(S i-1 ))

[0173] 3.

[0174] 4.

[0175] 5.S i =h(conc(S i-1 ,B i-1 ))

[0176] Now, using the method of deriving subsequent keys, the value S i With B i The XOR combination is performed to act as an OTP (One Time Password) to secure the stream or channel. Specifically, the cipher block (C i ) can be calculated as:

[0177]

[0178] All derived keys can be calculated using S0 and the initial block hash (for the initial 256 bits) to ensure data integrity.

[0179] Use Cases

[0180] Secure point-to-point messaging service

[0181] The peer-to-peer communication with end-to-end encryption described in detail above is extended to incorporate multimedia files and streaming data, as examined above. The ability to freely integrate these protocols on a blockchain system provides application developers with additional flexibility to provide tamper-proof security for their users. By incorporating a message authentication code (MAC), users can be provided with additional assurance that a message originates from the claimed identity and that no attempt has been made to obfuscate or alter the message. This is a crucial feature for transmitting highly sensitive information.

[0182] This disclosure provides an efficient and secure cryptographic system using the XOR operation. The simplicity of the required computations allows for easy integration with even the most basic blockchains (e.g., Bitcoin (BSV)). These schemes allow for the expansion of security and general application across many different systems and devices.

[0183] Now turn Figure 6 , provides an illustrative simplified block diagram of a computing device 2600 that can be used to practice at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 can be used to implement any of the systems shown and described above. For example, the computing device 2600 can be configured to function as a data server, a network server, a portable computing device, a personal computer, or any electronic computing device. Figure 6 As shown, computing device 2600 may include one or more processors (collectively referred to as 2602) with one or more levels of cache memory and a memory controller, which may be configured to communicate with a storage subsystem 2606 including a main memory 2608 and a permanent storage device 2610. As shown, main memory 2608 may include dynamic random access memory (DRAM) 2618 and read-only memory (ROM) 2620. Storage subsystem 2606 and cache memory 2602 may be used to store information, such as details associated with transactions and blocks as described in this disclosure. Processor(s) 2602 may be used to provide the steps or functionality of any embodiment described in this disclosure.

[0184] The processor(s) 2602 may also communicate with one or more user interface input devices 2612 , one or more user interface output devices 2614 , and a network interface subsystem 2616 .

[0185] The bus subsystem 2604 may provide a mechanism for enabling the various components and subsystems of the computing device 2600 to communicate with each other as intended. Although the bus subsystem 2604 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple busses.

[0186] The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may serve as an interface for receiving data from and transmitting data to other systems other than the computing device 2600. For example, the network interface subsystem 2616 may enable a data technician to connect the device to a network, allowing the data technician to transmit data to and receive data from the device while being located at a remote location (e.g., a data center).

[0187] The user interface input devices 2612 may include one or more user input devices, such as a keyboard; a pointing device such as an integrated mouse, trackball, touchpad, or graphics tablet; a scanner; a barcode scanner; a touch screen incorporated into a display; an audio input device such as a voice recognition system, a microphone, or the like; and other types of input devices. In general, the use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computing device 2600.

[0188] The one or more user interface output devices 2614 may include a display subsystem, a printer, or a non-visual display such as an audio output device. The display subsystem may be a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a light emitting diode (LED) display, or a projector, or other display device. In general, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. The one or more user interface output devices 2614 may be used, for example, to present a user interface to facilitate user interaction with an application that performs the described processes and variations therein, when such interaction is appropriate.

[0189] The storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data structures that may provide the functionality of at least one embodiment of the present disclosure. When executed by one or more processors, applications (programs, code modules, instructions) may provide the functionality of one or more embodiments of the present disclosure and may be stored in the storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. In addition, the storage subsystem 2606 may provide a repository for storing data used in accordance with the present disclosure. For example, the main memory 2608 and cache memory 2602 may provide volatile storage for programs and data. The permanent storage device 2610 may provide permanent (non-volatile) storage for programs and data and may include flash memory, one or more solid-state drives, one or more magnetic hard drives, one or more floppy disk drives with associated removable media, one or more optical drives (e.g., CD-ROM, DVD, or Blue-Ray) with associated removable media, and other similar storage media. Such programs and data may include programs for performing the steps of one or more embodiments as described in the present disclosure and data associated with transactions and blocks as described in the present disclosure.

[0190] The computing device 2600 can be of various types, including a portable computer device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 2600 can include another device that can be connected to the computing device 2600 via one or more ports (e.g., USB, a headphone jack, a lightning connector, etc.). The device that can be connected to the computing device 2600 can include multiple ports configured to accept fiber optic connectors. Thus, the device can be configured to convert optical signals into electrical signals that can be transmitted through the port connecting the device to the computing device 2600 for processing. Due to the ever-changing nature of computers and networks, Figure 6 The description of the computing device 2600 depicted in FIG is intended only as a specific example for the purpose of illustrating a preferred embodiment of the device. Figure 6 Many other configurations of the depicted systems with more or fewer components are possible.

[0191] Enumerated Example Embodiments

[0192] Examples of embodiments of the present disclosure may be described in terms of:

[0193] 1. A method for encrypting data, the method comprising:

[0194] Determining, by a first party, an encryption key for encrypting data based on a common secret shared with the first party and a second party;

[0195] encrypting the data based on the encryption key to provide encrypted data, wherein encrypting the data comprises at least one exclusive-OR (XOR) operation; and

[0196] The encrypted data is incorporated into a blockchain transaction.

[0197] By providing an encryption process that includes at least one exclusive-or (XOR) operation, this offers the advantage that, by using a bit-by-bit XOR encoding of a binary message string with a secret key of the same length, an XOR cipher can be derived and freely shared over a public network. The ciphertext can then be decrypted using a bit-by-bit XOR operation on the message and the same secret key. The simplicity of the protocol has the added benefit that it can be incorporated into any cryptography-based system. The computational efficiency of the present invention enables the session key generation proposed in International Patent Application WO 2017 / 145016 to be used in low-power devices (mobile devices or smart cards) and included within scripts in Bitcoin. It also offers the advantage of minimizing the risk of data alteration or making data alteration detectable.

[0198] 2. The method of clause 1, wherein the encrypted data is included in an output of the blockchain transaction.

[0199] This provides the advantage that the data in the output of a blockchain transaction has a verifiable digital signature so that the recipient can check the identity of the sender of the data and can check that the data has not been altered since it was signed.

[0200] 3. A method according to clause 1 or 2, wherein the encrypted data is included in publicly accessible data in the transaction.

[0201] This offers the advantage that access to the data can be gained for decryption without requiring a redemption / spending blockchain transaction.

[0202] 4. The method according to any of the preceding clauses, wherein a session key and / or a password can be derived from the encrypted data by means of the common secret.

[0203] 5. The method of any of the preceding clauses, wherein the blockchain transaction is redeemed with the aid of a script based on the public secret.

[0204] 6. The method of clause 5, wherein the transaction is redeemed by means of a script containing data based on applying a one-way function to data based on the public secret.

[0205] This offers the advantage that the public secret is not exposed upon transaction redemption and can therefore be reused.

[0206] 7. The method of clause 6, wherein the one-way function is a hash function.

[0207] 8. A method according to any of the preceding clauses, wherein the redemption of the transaction exposes data.

[0208] 9. A method according to any preceding clause, wherein redemption of the transaction causes the party redeeming the transaction to be identified.

[0209] This provides the advantage of maintaining privacy until the transaction is redeemed, but enables identification of the spender of a transaction in the presence of more than one public key.

[0210] 10. The method according to any of the preceding clauses further comprises: as a result of sending the encrypted data to the second party, causing the data to be encrypted with the aid of an encryption key based on a second common secret shared by the first party and the third party.

[0211] This provides the advantage of enabling multi-party encrypted communication with communication records.

[0212] 11. A method according to any of the preceding clauses, further comprising causing data to be sent to the first party as a result of data being sent from the second party to the third party.

[0213] 12. The method according to any of the preceding clauses, further comprising determining a plurality of said encryption keys by means of repeated application of a one-way function to data based on said common secret.

[0214] This offers the advantage that the common secret only needs to be established once and then used as a seed to generate multiple keys without requiring further online data exchange.

[0215] 13. The method of clause 12, wherein the one-way function is a hash function.

[0216] 14. A method according to clause 12 or 13, wherein a first encryption key used to encrypt first data is related to a second encryption key used to encrypt second data after encrypting the first data by applying the one-way function to data based on the first encryption key.

[0217] This provides the advantage of maintaining the confidentiality of the shared secret.

[0218] 15. The method according to any of the preceding clauses, wherein encryption is performed by applying at least one encryption key to the portion of the data.

[0219] This provides the following advantages: Improved efficiency in case of large data sets.

[0220] 16. A method according to any of the preceding clauses, wherein at least one of the encryption keys is a matrix.

[0221] This offers the advantage of enabling more secure encryption due to the non-linear nature of matrix multiplication.

[0222] 17. A method according to clause 16, wherein the elements of the matrix are generated by repeatedly applying a one-way function to data based on the public secret.

[0223] 18. A method according to clause 16 or 17, wherein at least one of the matrices is derived from the product of two matrices having linearly independent columns and rows.

[0224] This offers the advantage that an invertible matrix is provided, enabling the calculation of the decryption key.

[0225] 19. A method according to any of the preceding clauses, wherein the encryption is performed by repeatedly applying at least one of the encryption keys to at least a portion of the data.

[0226] This offers the advantage that further security is provided due to the non-linear nature of such repeated encryption.

[0227] 20. The method according to any of the preceding clauses further comprises determining the common secret at the first party, wherein the first party is associated with a first public-private key pair of a cryptographic system having a first private key and a first public key, wherein the second party is associated with a second public-private key pair of a cryptographic system having a second private key and a second public key, wherein the common secret is determined at the first party based on the first private key and the second public key, and wherein the characteristics of the cryptographic system enable the common secret to be determined at the second party based on the second private key and the first public key.

[0228] 21. The method of clause 21, wherein the cryptographic system is elliptic curve cryptography.

[0229] 22. A method according to any of the preceding clauses, wherein the first party has a share of a public secret, and the public secret is accessible for a threshold number of the shares and inaccessible for less than the threshold number of the shares.

[0230] 23. A method for generating an encryption key for encrypting data, the method comprising:

[0231] An encryption key for encrypting data is determined by a first party, wherein the encryption key is based on at least one exclusive OR (XOR) combination of first data and second data, the first data being based on a common secret shared by the first and second parties, and the second data being based on applying a one-way function to data based on the common secret.

[0232] This provides advantages in computational efficiency, enabling the method to be used with devices having low processing power.

[0233] 24. The method of clause 23, further comprising determining a plurality of said encryption keys by repeatedly applying said one-way function to data based on said common secret.

[0234] 25. A method according to clause 23 or 24, wherein the one-way function is a hash function.

[0235] 26. A method according to any one of clauses 23 to 25, wherein the first encryption key used to encrypt third data is related to the second encryption key used to encrypt fourth data after encrypting the third data by applying the one-way function to data based on the first encryption key.

[0236] 27. A method according to any of clauses 23 to 26, wherein encryption is performed by applying at least one encryption key to parts of the data.

[0237] 28. A method according to any of clauses 23 to 27, wherein at least one of the encryption keys is a matrix.

[0238] 29. The method of clause 28, wherein the elements of the matrix are generated by repeatedly applying a one-way function to data based on the public secret.

[0239] 30. A method according to clause 28 or 29, wherein at least one of the matrices is derived from the product of two matrices having linearly independent columns and rows.

[0240] 31. A method according to any of clauses 23 to 30, wherein said encryption is performed by repeatedly applying at least one said encryption key to at least a portion of said data.

[0241] 32. The method according to any one of clauses 23 to 31 further comprises determining the common secret at the first party, wherein the first party is associated with a first public-private key pair of a cryptographic system having a first private key and a first public key, wherein the second party is associated with a second public-private key pair of a cryptographic system having a second private key and a second public key, wherein the common secret is determined at the first party based on the first private key and the second public key, and wherein the characteristics of the cryptographic system enable the common secret to be determined at the second party based on the second private key and the first public key.

[0242] 33. The method of clause 32, wherein the cryptographic system is elliptic curve cryptography.

[0243] 34. A method according to any one of clauses 23 to 33, wherein the first party has a share of the common secret, and the common secret is accessible for a threshold number of the shares and inaccessible for less than the threshold number of the shares.

[0244] 35. A method for encrypting data, the method comprising:

[0245] generating a cryptographic key by means of a method according to any one of clauses 23 to 34; and

[0246] Data is encrypted based on the encryption key to provide encrypted data, wherein encrypting the data comprises at least one exclusive OR (XOR) operation.

[0247] 36. The method of clause 35, further comprising: incorporating the encrypted data into a blockchain transaction.

[0248] 37. The method of clause 36, wherein the encrypted data is included in an output of the blockchain transaction.

[0249] 38. A method according to clause 36 or 37, wherein the encrypted data is included in publicly accessible data in the transaction.

[0250] 39. The method according to any of clauses 36 to 38, wherein a session key and / or a password can be derived from the encrypted data by means of the common secret.

[0251] 40. A method according to any of clauses 36 to 39, wherein the blockchain transaction is redeemed by means of a script based on the public secret.

[0252] 41. The method of clause 40, wherein the transaction is redeemed by means of a script containing data based on applying a one-way function to data based on the public secret.

[0253] 42. The method of clause 41, wherein the one-way function is a hash function.

[0254] 43. A method according to any one of clauses 36 to 42, wherein redemption of the transaction exposes data.

[0255] 44. A method according to any one of clauses 36 to 43, wherein redemption of the transaction causes the party redeeming the transaction to be identified.

[0256] 45. A method of applying authentication data to a message, the method comprising:

[0257] Message authentication data is determined by a first party for a message to be transmitted to a second party, wherein the message authentication data is determined by applying a function known to the first party and the second party to the message and a common secret shared by the first party and the second party.

[0258] This provides the advantage of enabling the message authentication data to be recalculated at the second node to check that the data has not been corrupted since the message authentication data was initially determined.

[0259] 46. The method of clause 45, wherein the message is included in a blockchain transaction.

[0260] 47. The method of clause 46, wherein the message includes data related to a previous blockchain transaction.

[0261] This provides the advantage of enabling an offline check that the transaction data has not been altered in transit. This is particularly useful in the case of low-power devices.

[0262] 48. A method according to clause 46 or 47, wherein the message authentication data is included in the blockchain transaction.

[0263] 49. The method according to any one of clauses 46 to 48, further comprising the step of transmitting at least the message authentication data to the second party separately from the blockchain transaction.

[0264] 50. A method according to any of clauses 45 to 49, wherein the message authentication data comprises a plurality of data items based on the common secret.

[0265] 51. The method of clause 50, wherein a plurality of the data items are applied to respective portions of the message.

[0266] This offers the advantage that in the case of large data items, the message data can be processed more efficiently.

[0267] 52. A method according to any of clauses 45 to 51, wherein the function comprises at least one exclusive-OR (XOR) operation.

[0268] 53. A method according to any of clauses 45 to 52, wherein the message authentication data comprises a plurality of data items determined by repeatedly applying a one-way function to data based on the public secret.

[0269] 54. The method of clause 53, wherein the one-way function is a hash function.

[0270] 55. A method according to clause 53 or 54, wherein a first said data item applied to a first message is related to a second said data item applied to a second message after applying the first data item to the first message by applying the one-way function to data based on a common secret.

[0271] 56. The method according to any one of clauses 45 to 55 further comprises determining the common secret at the first party, wherein the first party is associated with a first public-private key pair of a cryptographic system having a first private key and a first public key, wherein the second party is associated with a second public-private key pair of a cryptographic system having a second private key and a second public key, wherein the common secret is determined at the first party based on the first private key and the second public key, and wherein the characteristics of the cryptographic system enable the common secret to be determined at the second party based on the second private key and the first public key.

[0272] 57. The method of clause 56, wherein the cryptographic system is elliptic curve cryptography.

[0273] 58. A method according to any one of clauses 45 to 57, wherein the first party has a share of a common secret, and the common secret is accessible for a threshold number of the shares and inaccessible for less than the threshold number of the shares.

[0274] 59. A computer-implemented system comprising:

[0275] processor; and

[0276] A memory comprising executable instructions that, due to execution by the processor, cause the system to perform any embodiment of the computer-implemented method of any of clauses 1 to 58.

[0277] 60. A non-transitory computer-readable storage medium having stored thereon executable instructions, said executable instructions, when executed by a processor of a computer system, causing the computer system to perform at least an embodiment of the method according to any one of clauses 1 to 58.

[0278] It should be noted that the above embodiments illustrate rather than limit the present disclosure, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present disclosure as defined by the appended claims. In the claims, any figure signs in brackets should not be interpreted as limiting the claims. The words "comprising, comprise" and the like do not exclude the presence of elements or steps other than those listed in any claim or the entire specification. In this specification, "comprise" means "include or consist of..." and "comprising" means "including or consist of..." The singular form of an element does not exclude the plural form of such elements, and vice versa. The present disclosure can be implemented by hardware comprising several different elements and by a suitably programmed computer. In a device claim that lists several components, several of these components may be implemented by one and the same hardware. The fact that certain means are recited in mutually different dependent claims does not mean that a combination of these means cannot be used to advantage.

[0279] References

[0280]

[0281]

Claims

1. A method for encrypting data, the method comprising: Determining, by a first party, an encryption key for encrypting data based on a common secret shared by the first party and a second party; encrypting the data based on the encryption key to provide encrypted data, wherein the step of encrypting the data comprises at least one exclusive-or (XOR) operation between a session key and / or a password and a one-way function of the data based on the public secret; and Incorporating the encrypted data into a blockchain transaction; deriving, by the second participant, the session key and / or password from the encrypted data with the aid of the common secret, wherein the session key and / or password is derived by an exclusive-OR (XOR) operation between the encrypted data and the one-way function of data based on the common secret; wherein the transaction is redeemed by a script containing data based on applying the one-way function to data based on the public secret.

2. The method according to claim 1, wherein The encrypted data is included in an output of the blockchain transaction.

3. The method according to claim 1 or 2, wherein: The encrypted data is included in the publicly accessible data in the transaction.

4. The method according to claim 1, wherein The one-way function is a hash function.

5. A method according to any one of the preceding claims, wherein Redemption of said transaction exposes the data.

6. A method according to any one of the preceding claims, wherein Redemption of the transaction causes the party redeeming the transaction to be identified.

7. The method according to any one of the preceding claims, further comprising: As the encrypted data is sent to the second party, the data is encrypted by an encryption key based on a second common secret shared by the first party and the third party.

8. The method according to any one of the preceding claims, further comprising: As a result of data being sent from the second party to the third party, the data is sent to the first party.

9. The method according to any one of the preceding claims, further comprising: A plurality of the encryption keys are determined by repeatedly applying a one-way function to data based on the common secret.

10. The method according to claim 9, wherein: The one-way function is a hash function.

11. The method according to claim 9 or 10, wherein: The first encryption key used to encrypt first data and the second encryption key used to encrypt second data after encrypting the first data are related by applying the one-way function to data based on the first encryption key.

12. A method according to any one of the preceding claims, wherein Encryption is performed by applying at least one encryption key to portions of the data.

13. A method according to any one of the preceding claims, wherein At least one of the encryption keys is a matrix.

14. The method according to claim 13, wherein Elements of the matrix are generated by repeatedly applying a one-way function to data based on the public secret.

15. The method according to claim 13 or 14, wherein: At least one of the matrices is derived from the product of two matrices having linearly independent columns and rows.

16. A method according to any one of the preceding claims, wherein Encryption is performed by repeatedly applying at least one of the encryption keys to at least a portion of the data.

17. The method according to any one of the preceding claims, further comprising: The common secret is determined at the first party, wherein the first party is associated with a first public-private key pair of a cryptographic system having a first private key and a first public key, wherein the second party is associated with a second public-private key pair of the cryptographic system having a second private key and a second public key, wherein the common secret is determined at the first party based on the first private key and the second public key, and wherein characteristics of the cryptographic system enable the common secret to be determined at the second party based on the second private key and the first public key.

18. The method according to claim 17, wherein The cryptographic system is an elliptic curve cryptographic system.

19. A method according to any one of the preceding claims, wherein The first party has a share of a common secret, and the common secret is accessible for a threshold number of the shares and inaccessible for less than the threshold number of the shares.

20. A method of generating an encryption key for encrypting data, the method comprising: Determining, by a first party, an encryption key for encrypting data, wherein the encryption key is based on at least one XOR combination of first data based on a common secret shared by the first party and the second party and second data based on applying a one-way function to data based on the common secret; The method comprises: encrypting data based on the encryption key to provide encrypted data, wherein the step of encrypting the data comprises at least one exclusive-or (XOR) operation between a session key and / or a password and a one-way function of the data based on the public secret; The method further comprises: incorporating the encrypted data into a blockchain transaction; deriving, by the second participant, the session key and / or password from the encrypted data with the aid of the common secret, wherein the session key and / or password is derived by an exclusive-OR (XOR) operation between the encrypted data and the one-way function of data based on the common secret; wherein the transaction is redeemed by a script containing data based on applying the one-way function to data based on the public secret.

21. The method according to claim 20, further comprising: A plurality of the encryption keys are determined by repeatedly applying the one-way function to data based on the common secret.

22. The method according to claim 20 or 21, wherein The one-way function is a hash function.

23. The method according to any one of claims 20 to 22, wherein The first encryption key used for encrypting third data and the second encryption key used for encrypting fourth data after encrypting the third data are related by applying the one-way function to data based on the first encryption key.

24. The method according to any one of claims 20 to 23, wherein Encryption is performed by applying at least one encryption key to portions of the data.

25. The method according to any one of claims 20 to 24, wherein At least one of the encryption keys is a matrix.

26. The method according to claim 25, wherein Elements of the matrix are generated by repeatedly applying a one-way function to data based on the public secret.

27. The method according to claim 25 or 26, wherein At least one of the matrices is derived from the product of two matrices having linearly independent columns and rows.

28. The method according to any one of claims 20 to 27, wherein Encryption is performed by repeatedly applying at least one of the encryption keys to at least a portion of the data.

29. The method according to any one of claims 20 to 28, further comprising: The common secret is determined at the first party, wherein the first party is associated with a first public-private key pair of a cryptographic system having a first private key and a first public key, wherein the second party is associated with a second public-private key pair of the cryptographic system having a second private key and a second public key, wherein the common secret is determined at the first party based on the first private key and the second public key, and wherein characteristics of the cryptographic system enable the common secret to be determined at the second party based on the second private key and the first public key.

30. The method according to claim 29, wherein The cryptographic system is an elliptic curve cryptographic system.

31. The method according to any one of claims 20 to 30, wherein The first party has a share of the common secret, and the common secret is accessible for a threshold number of the shares and inaccessible for less than the threshold number of the shares.

32. The method of claim 20, wherein: The encrypted data is included in an output of the blockchain transaction.

33. The method according to claim 20 or 32, wherein: The encrypted data is included in the publicly accessible data in the transaction.

34. The method of claim 20, wherein: The one-way function is a hash function.

35. The method according to any one of claims 20 to 34, wherein Redemption of the transaction causes the data to be retained.

36. The method according to any one of claims 20 to 35, wherein Redemption of the transaction causes the party redeeming the transaction to be identified.

37. A method of applying authentication data to a message, the method comprising: determining, by a first party, message authentication data for a message to be transmitted to a second party, wherein the message authentication data is determined by applying a function known to the first party and the second party to the message and to a common secret shared by the first party and the second party; wherein the message is included in a blockchain transaction; Wherein, the function includes at least one exclusive-or (XOR) operation; The message authentication data includes a plurality of data items determined by repeatedly applying a one-way function to data based on the public secret.

38. The method of claim 37, wherein: The message includes data related to the previous blockchain transaction.

39. The method according to claim 37 or 38, wherein The message authentication data is included in the blockchain transaction.

40. The method according to any one of claims 37 to 39, further comprising: The step of transmitting at least the message authentication data to the second party separately from the blockchain transaction.

41. The method according to any one of claims 37 to 40, wherein The message authentication data includes a plurality of data items based on the public secret.

42. The method according to claim 41, wherein A plurality of the data items are applied to corresponding portions of the message.

43. The method of claim 37, wherein: The one-way function is a hash function.

44. The method according to claim 37 or 43, wherein A first said data item applied to a first message is related to a second said data item applied to a second message after applying the first data item to the first message by applying the one-way function to data based on a common secret.

45. The method according to any one of claims 37 to 44, further comprising: The common secret is determined at the first party, wherein the first party is associated with a first public-private key pair of a cryptographic system having a first private key and a first public key, wherein the second party is associated with a second public-private key pair of the cryptographic system having a second private key and a second public key, wherein the common secret is determined at the first party based on the first private key and the second public key, and wherein characteristics of the cryptographic system enable the common secret to be determined at the second party based on the second private key and the first public key.

46. The method of claim 45, wherein The cryptographic system is an elliptic curve cryptographic system.

47. The method according to any one of claims 37 to 46, wherein The first party has a share of a common secret, and the common secret is accessible for a threshold number of the shares and inaccessible for less than the threshold number of the shares.

48. A computer-implemented system comprising: processor; and A memory comprising executable instructions that, due to execution by the processor, cause the system to perform any embodiment of the computer-implemented method according to any one of claims 1 to 47.

49. A non-transitory computer-readable storage medium having executable instructions stored thereon, wherein the executable instructions, when executed by a processor of a computer system, cause the computer system to perform at least an embodiment of the method according to any one of claims 1 to 47.

Images