Electronic contract encryption method, device, medium and product

Abstract

The application provides an electronic contract encryption method, device, medium and product, relates to the technical field of information encryption, and the method comprises the following steps: dividing an original text of an electronic purchase and sale contract into a set of plaintext data blocks according to a byte length threshold; performing a hash tree operation on the set of plaintext data blocks to obtain an overall check hash value, and sending the overall check hash value to a timestamp server to obtain timestamp certificate data; calculating a sequential permutation matrix according to the timestamp certificate data, and rearranging the initial physical order of the plaintext data blocks to obtain a disordered data block sequence; performing local private key signature operation on the sending end to obtain a sequential binding signature; encrypting the timestamp certificate data according to the public key of a receiving end node to obtain encrypted timestamp certificate data; and sending the disordered data block sequence, the sequential binding signature and the encrypted timestamp certificate to the receiving end node. The physical form concealment and data security of the original text of the electronic purchase and sale contract in the network transmission process are improved.

Description

Technical Field

[0001] This application relates to the field of information encryption technology, specifically to an electronic contract encryption method, device, medium, and product. Background Technology

[0002] With the rapid development of e-commerce and the digital economy, electronic sales contracts have become the primary evidence for commercial transactions and rights confirmation between enterprises. The transmission and storage of electronic contracts in a network environment greatly improves the efficiency of business transactions and reduces the physical circulation and management costs of traditional paper contracts. To ensure the legal validity, confidentiality, and tamper-proof nature of electronic contracts during open network transmission, cryptographic techniques are typically used to securely process contract data, ensuring that the legitimate rights and interests of both parties are not infringed.

[0003] Existing secure electronic contract transmission schemes typically combine standard hash algorithms with digital signature technology. Specifically, the sender first treats the complete electronic contract as a continuous data unit and uses a hash algorithm to calculate a fixed-length hash digest of this entire file. Then, the sender uses their private key to sign this hash digest, generating a digital signature. Finally, the sender packages this digital signature along with the complete contract data, or further encrypts and encapsulates the entire continuous data packet using a symmetric encryption algorithm, before sending it to the recipient over the network. Upon receiving the data, the recipient follows the corresponding decryption and signature verification process to recover and verify the complete original contract.

[0004] With the increasing prevalence of zero-trust network architectures and the growing frequency of advanced network traffic analysis attacks targeting high-value business secrets, higher security requirements are being placed on the physical concealment of electronic contracts during transmission. In the existing solutions mentioned above, the original electronic contract text maintains its initial, continuous physical byte order throughout the entire processing and transmission cycle. Under this implementation, when faced with deep packet sniffing or the degradation and cracking of outer encryption protocols, the business logic structure within the data packets still maintains its complete continuity. Attackers can directly extract semantics and reconstruct the structure from the intercepted continuous byte stream, leading to a significant risk of direct exposure of core business transaction details. Summary of the Invention

[0005] This application provides an electronic contract encryption method, device, medium, and product to solve the technical problem in the prior art that electronic contracts, after their transmitted data is intercepted or cracked, are easily extracted for semantics and their structure restored, resulting in the leakage of core secrets.

[0006] Firstly, this application provides a method for encrypting electronic contracts, including: Obtain the original text of the electronic purchase and sale contract to be signed, and divide the original text of the electronic purchase and sale contract into a set of plaintext data blocks according to the byte length threshold. The set of plaintext data blocks includes several plaintext data blocks with an initial physical order. Perform hash tree operations on the plaintext data block and extract the root node hash value as the overall verification hash value; The overall verification hash value is sent to the third-party timestamp server, and the timestamp credential data returned by the third-party timestamp server is received. Extract the timestamp signature sequence from the timestamp voucher data, and generate an order permutation matrix based on the timestamp signature sequence; By using a permutation matrix, the initial physical order of plaintext data blocks is rearranged to obtain a sequence of out-of-order data blocks. The sender's local private key is invoked to perform a signature operation on the out-of-order data block sequence, generating a sequential binding signature. Obtain the public key of the receiving node, encrypt the timestamp credential data based on the public key, and generate an encrypted timestamp credential; The out-of-order data block sequence, sequential binding signature, and encrypted timestamp certificate are encapsulated to generate the target electronic contract data packet, which is then sent to the receiving node.

[0007] Optionally, before rearranging the initial physical order of the plaintext data blocks using a sequence permutation matrix to obtain the out-of-order data block sequence, the following steps are also included: Based on the sender's local private key and public key, perform key negotiation operations to generate a shared symmetric key; Generate encryption parameters for each plaintext data block; Based on a shared symmetric key and encryption parameters, an authentication encryption algorithm is used to encrypt each plaintext data block to obtain an independent encrypted data unit corresponding to each plaintext data block, and the independent encrypted data unit is used as the plaintext data block.

[0008] Optionally, based on the sender's local private key and public key, a key negotiation operation is performed to generate a shared symmetric key, specifically including: The shared key value is obtained by multiplying the sender's local private key and public key by a dot product. Convert the shared key value into an initial byte sequence; Divide the initial byte sequence into a first segment and a second segment according to their length; The folded sequence is obtained by performing an XOR operation on the byte-by-byte sequence between the first segment sequence and the second segment sequence. Use the folded sequence as a shared symmetric key.

[0009] Optionally, encryption parameters are generated for each plaintext data block, specifically including: Based on the sequential permutation matrix, query the index value of the target permutation position corresponding to each plaintext data block; The initial physical order includes the initial sequence number corresponding to each plaintext data block. The target permutation position index value, the initial sequence number, and the preset random number of each plaintext data block are concatenated to obtain the concatenation parameters. Perform a hash operation on the concatenation parameters to generate the encryption parameters corresponding to each plaintext data block.

[0010] Optionally, extract the timestamp signature sequence from the timestamp voucher data, and generate an order permutation matrix based on the timestamp signature sequence, specifically including: Perform a hash operation on the timestamp signature sequence to obtain a fixed-length signature hash value; Divide the signature hash value into several hash segments, and convert each hash segment into a numerical value; The initial sequence number of all plaintext data blocks is XORed bit by bit with each value to obtain the perturbation value corresponding to each plaintext data block. The plaintext data blocks are arranged in ascending order of perturbation values ​​to obtain a permutation sequence. When there are the same perturbation values, the plaintext data blocks with the same perturbation values ​​are sorted in ascending order according to the initial physical order. Construct a sequential permutation matrix based on the permutation sequence.

[0011] Optionally, the original electronic purchase and sale contract can be divided into a set of plaintext data blocks based on a byte length threshold, specifically including: The original text of the electronic purchase and sale contract is sequentially segmented according to the byte length threshold to obtain several first standard plaintext blocks, and the first original length data of the first standard plaintext blocks is calculated. Select a non-standard plaintext block whose byte length is less than the byte length threshold, generate a padding sequence whose length is equal to the difference between the byte length threshold and the non-standard plaintext block length according to the preset byte generation, and calculate the second original length data of the non-standard plaintext block; The padding sequence is merged with the non-standard plaintext block to obtain the first padded plaintext block; The first padded plaintext block and the second original length data are combined to generate the second padded plaintext block. The first standard plaintext block and the first original length data are combined to generate the second standard plaintext block. The second padded plaintext block and the second standard plaintext block are combined to form a set of plaintext data blocks.

[0012] Optionally, the first padded plaintext block and the second original length data are combined to generate the second padded plaintext block, and the first standard plaintext block and the first original length data are combined to generate the second standard plaintext block, specifically including: Divide the first padded plaintext block into a first pre-segment and a first post-segment based on byte length; Insert the second original length data between the first pre-segment and the first post-segment, and then concatenate them sequentially to generate the second padded plaintext block; The first standard plaintext block is divided into a second preamble and a second postamble according to the length of bytes. Insert the first original length data between the second pre-segment and the second post-segment, and then concatenate them to generate the second standard plaintext block.

[0013] In a second aspect, embodiments of this application provide an electronic contract encryption device, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the electronic contract encryption device to perform the method described in the first aspect and any possible implementation thereof.

[0014] Thirdly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on an electronic contract encryption device, cause the electronic contract encryption device to perform the method described in the first aspect and any possible implementation thereof.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on an electronic contract encryption device, cause the electronic contract encryption device to perform the method described in the first aspect and any possible implementation thereof.

[0016] In summary, one or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. By adopting the above technical solution, the original text of the electronic sales contract to be signed is obtained. It is then divided into a set of plaintext data blocks with an initial physical order according to a byte length threshold. The overall verification hash value is extracted to obtain timestamp voucher data. An order permutation matrix is ​​generated based on the timestamp signature sequence in the timestamp voucher data. This order permutation matrix is ​​then used to rearrange the initial physical order of the plaintext data blocks to obtain a sequence of out-of-order data blocks. Using the timestamp signature sequence to generate the order permutation matrix ensures that the out-of-order rule for each transmission has a unique time dimension. Rearranging the initial physical order breaks the structural continuity of the original electronic sales contract. This prevents attackers who intercept the target electronic contract data packets from directly extracting the semantics of the continuous byte stream and reconstructing the structured data, thus improving the physical concealment and data security of the original electronic sales contract during network transmission.

[0017] 2. By adopting the above technical solution, a shared symmetric key is generated by multiplying the sender's local private key and public key and then XORing the result along the length. The target permutation position index, initial sequence number, and preset random number of the plaintext data block are concatenated and hashed to generate encryption parameters. An authentication encryption algorithm is then used to encrypt the plaintext data block, resulting in independent encrypted data units. The use of XOR folding to generate the shared symmetric key increases the non-linearity of the key. Combining the target permutation position index with the initial sequence number to generate encryption parameters binds the encryption state of the independent encrypted data unit to its dual position in the initial physical order and the disordered data block sequence. This ensures that plaintext data blocks with the same content will generate different ciphertexts at different positions, preventing attacks that reverse-engineer the plaintext data block content through ciphertext frequency analysis and improving the anti-decryption capability of the independent encrypted data units during disordered rearrangement.

[0018] 3. By adopting the above technical solution, a hash operation is performed on the timestamp signature sequence to obtain the signature hash value. This hash value is then divided into hash segments and converted into numerical values. The initial sequence number of the plaintext data block is sequentially XORed with each numerical value to obtain a perturbation value. The plaintext data blocks are then arranged in ascending order of the perturbation values ​​to obtain a permutation sequence, thereby constructing an order permutation matrix. Using the hash segments of the timestamp signature sequence as input, a unique perturbation value is introduced into each plaintext data block by performing a bitwise XOR operation with the initial sequence number. This XOR-based perturbation calculation method maps the originally continuous initial sequence number to a discrete set of perturbation values. This ensures that the generated order permutation matrix is ​​discrete, causing the rearrangement result of the plaintext data blocks to deviate from the linear law of the initial physical order, increasing the structural complexity of the disordered data block sequence, and preventing reverse derivation of the rearrangement rules.

[0019] 4. By adopting the above technical solution, a first standard plaintext block and a non-standard plaintext block are obtained by segmenting according to a byte length threshold. The non-standard plaintext block is then merged using a padding sequence to obtain a first padded plaintext block. The first padded plaintext block or the first standard plaintext block is then divided into a pre-segment and a post-segment according to byte length. The second original length data or the first original length data is inserted between the pre-segment and the post-segment and concatenated sequentially. Padding the non-standard plaintext block with the padding sequence eliminates the length difference between different plaintext data blocks. Inserting the original length data between the evenly divided pre-segment and post-segment changes the fixed structure of placing the length data at the edge of the data block. This hides the physical locations of the first and second original length data, preventing attackers from extracting length information from the packet header and stripping the padding sequence without knowing the evenly divided insertion rules, thus ensuring the concealment and integrity of the internal structure of the plaintext data block set. Attached Figure Description

[0020] Figure 1This is a flowchart illustrating an electronic contract encryption method in an embodiment of this application; Figure 2 This is another flowchart illustrating the electronic contract encryption method in the embodiments of this application; Figure 3 This is a schematic diagram of the physical device structure of an electronic contract encryption device in the embodiments of this application. Detailed Implementation

[0021] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0022] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0023] In the description of the embodiments of this application, the term "multiple" means two or more. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first," "second," or "third" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized. It should be noted that all data collection in this scheme is conducted after obtaining user consent.

[0024] This application provides a method for encrypting electronic contracts, referencing... Figure 1 , Figure 1 This is a flowchart of an electronic contract encryption method provided in an embodiment of this application. The method includes: Step S101: Obtain the original text of the electronic purchase and sale contract to be signed, and divide the original text of the electronic purchase and sale contract into a set of plaintext data blocks according to the byte length threshold. The set of plaintext data blocks includes several plaintext data blocks with an initial physical order. In this context, the original electronic sales contract refers to a digital contract document generated during a commercial transaction that has not yet been encrypted or scrambled, such as a PDF-formatted original electronic sales contract containing a purchase list and transaction terms. The byte length threshold represents a pre-defined fixed byte size standard for truncating data, such as a threshold of 512 bytes. The plaintext data block set represents a collection of multiple truncated data blocks, such as a set of 100 plaintext data blocks. The initial physical order refers to the inherent sequential arrangement of data within the original file before truncation, such as the initial physical order of 0 to 99 from the beginning to the end of the file. A plaintext data block represents an unencrypted segment of data truncated to a specific length, such as a plaintext data block of 512 bytes.

[0025] In the initial stage of the contract signing process, this step is executed when the sending system receives the contract documents submitted by the business personnel. Specifically, after obtaining the original electronic sales contract to be signed, the system reads the total byte size of the original electronic sales contract and, according to the set byte length threshold, segments the original electronic sales contract according to the reading rules from beginning to end. The segmentation results in a set of plaintext data blocks. During the segmentation process, because the data is truncated according to the original data flow of the file, each plaintext data block generated retains its relative position in the original electronic sales contract within the plaintext data block set. The plaintext data block set includes several plaintext data blocks with an initial physical order.

[0026] Alternatively, S101 may refer to the following more specific solutions; The original text of the electronic purchase and sale contract is sequentially segmented according to the byte length threshold to obtain several first standard plaintext blocks, and the first original length data of the first standard plaintext blocks is calculated. The byte length threshold refers to a pre-defined fixed byte size standard used for truncation of data, such as a byte length threshold of 1024 bytes. The first standard plaintext block represents a data segment precisely divided according to the threshold, with a length exactly equal to that threshold, such as a first standard plaintext block of exactly 1024 bytes. The first raw length data refers to the numerical information recording the actual number of valid bytes in the standard data block, such as recording a first raw length data of 1024.

[0027] This step is executed when the system obtains the complete contract document and prepares to perform underlying data block segmentation. Specifically, the system reads the total byte stream of the original electronic sales contract and, strictly according to the set byte length threshold, sequentially segments the data stream from the beginning. Each time, a data segment reaching the threshold length is extracted, resulting in several first standard plaintext blocks. Simultaneously, the system performs length statistics on each segmented first standard plaintext block, calculating the first original length data of the first standard plaintext block. For example, for an original electronic sales contract with a total size of 2500 bytes, segmented sequentially according to a byte length threshold of 1024 bytes, the system first segments the first 1024-byte data segment as the first first standard plaintext block and calculates its first original length data as 1024; then, continuing to read, it segments the second 1024-byte data segment as the second first standard plaintext block and calculates its first original length data as 1024.

[0028] Select a non-standard plaintext block whose byte length is less than the byte length threshold, generate a padding sequence whose length is equal to the difference between the byte length threshold and the non-standard plaintext block length according to the preset byte generation, and calculate the second original length data of the non-standard plaintext block; Among them, the preset byte refers to the character or byte template pre-configured at the system level for generating meaningless data, such as a preset byte composed of hexadecimal 0x00 or random characters. The padding sequence refers to the byte stream generated based on preset rules to fill in the length difference, such as a padding sequence with a length of 572 bytes. The second original length data represents the numerical value of the actual number of valid bytes in the record's tail data segment, such as a second original length data with a record value of 452.

[0029] Specifically, when the system reaches the end of the file during sequential segmentation, it selects a non-standard plaintext block whose byte length is less than a byte length threshold. The system first counts the actual number of bytes in this non-standard plaintext block and calculates its second original length. Then, the system calculates the difference between the byte length threshold and the actual number of bytes, and calls the underlying preset bytes to continuously generate a byte stream without actual business semantics according to this difference length, thereby generating a padding sequence with a length equal to the difference between the byte length threshold and the non-standard plaintext block length. For example, after splitting the aforementioned 2500-byte contract into two 1024-byte segments, a 452-byte data segment remains. The system selects these 452 bytes as the non-standard plaintext block and calculates its second original length as 452. The system calculates that 1024 minus 452 equals 572, and then generates a 572-byte meaningless character sequence as the padding sequence based on the preset bytes.

[0030] The padding sequence is merged with the non-standard plaintext block to obtain the first padded plaintext block; Specifically, the system allocates a buffer in memory with a size equal to a byte length threshold. A non-standard plaintext block containing the actual contract's end content is written to the first half of this buffer. Then, the generated padding sequence is directly appended to the second half of the buffer. Through this low-level byte stream appending operation, the system merges the padding sequence with the non-standard plaintext block, physically expanding the originally insufficient data segment to the standard length, ultimately obtaining the first padded plaintext block. For example, the system concatenates a 452-byte non-standard plaintext block (such as actual data containing the contract's signature and date) with a 572-byte padding sequence (such as a continuous string of 0x00 characters) in memory, resulting in a first padded plaintext block with a total length of exactly 1024 bytes. From an external perspective, its size characteristics are completely consistent with the preceding standard data block.

[0031] The first padded plaintext block and the second original length data are combined to generate the second padded plaintext block. The first standard plaintext block and the first original length data are combined to generate the second standard plaintext block. Specifically, the system embeds length metadata, recording the actual number of valid bytes, into the corresponding data block. The system combines the first padded plaintext block and the second original length data according to a preset structured format to generate the second padded plaintext block. Similarly, the system uses the exact same structured format to combine the first standard plaintext block and the first original length data to generate the second standard plaintext block. For example, the system specifies that the length data uniformly occupies 4 bytes and is appended to the header of the data block. The system appends the 4-byte second original length data recording the value 452 to the header of the 1024-byte first padded plaintext block, generating a 1028-byte second padded plaintext block; simultaneously, the system appends the 4-byte first original length data recording the value 1024 to the header of the 1024-byte first standard plaintext block, generating a 1028-byte second standard plaintext block.

[0032] Combine the second padded plaintext block and the second standard plaintext block into a plaintext data block set; Specifically, the system aggregates all processed independent data units according to the initial data flow logic of the original electronic purchase and sale contract. The system logically arranges and combines all second standard plaintext blocks in the middle of the sequence and the second padded plaintext blocks at the end of the sequence according to their order in the original file. The second padded plaintext blocks and the second standard plaintext blocks are combined into a plaintext data block set. For example, the system combines the two previously generated 1028-byte second standard plaintext blocks with the last generated 1028-byte second padded plaintext block into the same array structure. At this point, these three data blocks constitute a plaintext data block set, where each element exhibits absolute consistency in physical length (1028 bytes), thus completely eliminating the risk of flow analysis based on differences in data block length.

[0033] Optionally, the steps of combining the first padded plaintext block and the second original length data to generate the second padded plaintext block, and combining the first standard plaintext block and the first original length data to generate the second standard plaintext block, can be found in the following more specific scheme. Divide the first padded plaintext block into a first pre-segment and a first post-segment based on byte length; Specifically, the system reads the total byte length of the first padded plaintext block and divides it by two to calculate the precise intermediate truncation index. Then, the system performs a data slicing operation in memory based on this intermediate truncation index, dividing the first padded plaintext block into a first pre-segment and a first post-segment based on byte length. For example, if the total byte length of the first padded plaintext block is 1024 bytes, the system calculates a truncation index of 512, and then divides it into a first pre-segment from byte 0 to byte 511, and a first post-segment from byte 512 to byte 1023, ensuring that the two segments are absolutely equal in data size.

[0034] Insert the second original length data between the first pre-segment and the first post-segment, and then concatenate them sequentially to generate the second padded plaintext block; Specifically, the system rearranges the physical write order of the data stream in the memory buffer. First, the system writes the first pre-segment to the beginning of the buffer. Then, it inserts the second original-length data between the first pre-segment and the first post-segment; that is, it writes the second original-length data immediately after the end of the first pre-segment. Finally, it appends the first post-segment to the end of the second original-length data. Through this low-level memory pointer offset and data copying operation, the system sequentially concatenates and generates the second padded plaintext block. For example, the system first writes a 512-byte first pre-segment, then writes 4 bytes of the second original-length data (such as the binary code recording the value 452), and finally writes a 512-byte first post-segment, ultimately concatenating and generating a second padded plaintext block with a total length of 1028 bytes, so that the length metadata is deeply hidden in the very middle of the data block.

[0035] The first standard plaintext block is divided into a second preamble and a second postamble according to the length of bytes. Specifically, to ensure that all data blocks have completely consistent internal structure logic in the final plaintext data block set, the system performs the same segmentation logic as the padding block for each first standard plaintext block. The system reads the byte length of the first standard plaintext block and locates its absolute center point in physical storage. Based on this center point, the system executes a memory slicing instruction, dividing the first standard plaintext block into a second pre-segment and a second post-segment according to byte length. For example, for a 1024-byte first standard plaintext block segmented from the contract body, the system strictly cuts it in half, generating a second pre-segment of 512 bytes and a second post-segment of 512 bytes, reserving intermediate physical insertion space for subsequent embedding of its own length metadata.

[0036] Insert the first original length data between the second pre-segment and the second post-segment, and then concatenate them sequentially to generate the second standard plaintext block; Specifically, the system calls the underlying data concatenation function to reassemble the byte stream in a specific order. The system inserts the first original length data between the second pre-segment and the second post-segment; that is, it first reads the second pre-segment and writes it to the target memory area, then writes the first original length data to that area, and finally appends the second post-segment to the end. The system generates the second standard plaintext block through this strict sequential writing mechanism. For example, the system first writes a 512-byte second pre-segment, then writes the 4-byte first original length data with a value of 1024, and finally writes the 512-byte second post-segment, ultimately generating a 1028-byte second standard plaintext block. Thus, whether it's a standard block or a padding block, its length metadata is uniformly and implicitly embedded in the physical center of the data block, completely eliminating differences in external structural characteristics.

[0037] Correspondingly, for this scheme, the receiving system, during decryption, sequentially reads the second standard plaintext block from the plaintext data block set. Because the sending end employs strict even-division insertion logic during encapsulation, the receiving system first reads the total byte length of the second standard plaintext block and, combined with the preset length data byte size in the underlying protocol, precisely locates the physical starting offset of the first original length data through mathematical calculation. The system calculates the difference between the total byte length and the preset length data byte size, then divides this difference by two to obtain the byte length of the second pre-segment, which is the starting reading position of the first original length data. The system then extracts the data stream corresponding to the preset length data byte size from this starting reading position, successfully extracting the first original length data inserted between the second pre-segment and the second post-segment. After extracting the first original length data, the system directly merges the second pre-segment (located before the starting reading position) and the second post-segment (located after the extraction end position) in memory as byte streams. The system then concatenates the second pre-segment and the second post-segment sequentially to reconstruct the first standard plaintext block. For example, the receiving system reads a second standard plaintext block with a total length of 1028 bytes. The system knows that the preset length of the data is 4 bytes. The system calculates 1028 minus 4 to get 1024, and then divides 1024 by 2 to get 512. Based on this, the system determines that bytes 0 to 511 are the second preamble, the four consecutive bytes starting from byte 512 are the first original length data, and bytes 516 to 1027 are the second postamble. The system accurately extracts these four bytes of the first original length data from byte 512 and parses out the recorded value as 1024. Subsequently, the system concatenates the first 512 bytes of the second preamble with the last 512 bytes of the second postamble, perfectly reconstructing a first standard plaintext block with a total size of 1024 bytes, removing the metadata used to hide the physical structure during transmission.

[0038] Step S102: Perform hash tree operation on the plaintext data block and extract the root node hash value as the overall verification hash value; In this context, hash tree operation refers to a process of merging the hash results of multiple bottom-level data nodes pairwise upwards and performing cryptographic hash calculations again, such as Merkle hash tree operation using the SHA-256 algorithm. The root node hash value is a unique hash result generated at the top of the tree-like data structure, aggregating the characteristics of all bottom-level nodes; for example, a fixed-length root node hash value of 256 bits. The overall verification hash value represents the final characteristic value indicating the overall data integrity and tamper-proof properties of the entire plaintext data block set; for example, it is used in subsequent processes to verify that the original text of the entire electronic sales contract has not been altered.

[0039] Specifically, the system first independently calculates the one-way hash value for each plaintext data block in the set of plaintext data blocks. These initially generated hash values ​​serve as the bottom-level leaf nodes of the hash tree structure. Then, following the initial physical order of the plaintext data blocks, the system concatenates the hash values ​​of adjacent leaf nodes pairwise, and performs hash calculations again on the concatenated data to generate the hash values ​​of the internal nodes at the next higher level. The system continues to perform this layer-by-layer recursive hash tree operation until a unique top-level hash value is calculated by merging the results at the highest level of the tree structure. The system extracts the root node hash value as the overall verification hash value. Due to the avalanche effect of hash tree operations, even a small change in any plaintext data block will cause a complete change in the final extracted overall verification hash value. Therefore, this overall verification hash value can accurately and rigorously reflect the global data state of all plaintext data blocks.

[0040] Step S103: Send the overall verification hash value to the third-party timestamp server and receive the timestamp credential data returned by the third-party timestamp server; In this context, a third-party timestamp server refers to an authoritative server system with legally recognized time verification qualifications, independent of both the sending and receiving nodes, such as a third-party timestamp server authorized by the National Time Service Center. Timestamp credential data is used to represent trusted proof document data containing authoritative time information and a digital signature from a third-party institution, such as timestamp credential data containing a precise timestamp of March 26, 2026, and a signature with the institution's private key.

[0041] After the local system completes the hash tree operation and successfully extracts the root node hash value as the overall verification hash value, this step is executed when preparing to introduce a legally valid and credible time proof for the data state of the original electronic purchase and sale contract. Specifically, the sending system sends the extracted overall verification hash value to a third-party timestamp server through a secure encrypted network communication protocol. Upon receiving the overall verification hash value, the third-party timestamp server calls its internal high-precision standard time source to obtain the current accurate objective time data and strictly binds and combines this time data with the received overall verification hash value. Subsequently, the third-party timestamp server uses its institution-specific private key to digitally sign the bound and combined data, thereby generating unforgeable timestamp certificate data. Finally, the sending system receives the timestamp certificate data returned by the third-party timestamp server through the network communication interface. This timestamp certificate data not only solidifies the content state of the plaintext data block set at a specific point in time but also provides a crucial data foundation for the subsequent generation of the sequential permutation matrix.

[0042] Step S104: Extract the timestamp signature sequence from the timestamp voucher data, and generate an order permutation matrix based on the timestamp signature sequence; The timestamp signature sequence represents a string of characters extracted from the credential and generated by a cryptographic signature, such as a 1024-bit RSA timestamp signature sequence. The order permutation matrix represents a mathematical matrix containing row and column mappings, specifically used to change the arrangement of data; for example, a 10x10 two-dimensional order permutation matrix.

[0043] This step is performed after receiving timestamp credential data from a third-party timestamp server and before reordering the plaintext data block. Specifically, the system first parses the timestamp credential data to locate and extract the timestamp signature sequence. Since the timestamp signature sequence contains cryptographic signature information generated based on a specific time point and the overall check hash value, it possesses a high degree of randomness and uniqueness. Based on the timestamp signature sequence, the system uses a preset matrix generation algorithm to transform the data features in the timestamp signature sequence into multi-dimensional matrix elements, thereby generating a permutation matrix. Regarding the preset matrix generation algorithms, for example, a matrix generation algorithm based on a linear congruential generator can be used. The system extracts the first 16 bytes of the timestamp signature sequence as a random number seed to generate a pseudo-random number sequence, which is then used to perform multiple elementary row and column transformations on an N×N standard identity matrix to finally obtain an ordered permutation matrix. Another example is a matrix generation algorithm based on Logistic chaotic mapping. The system converts the timestamp signature sequence into the initial values ​​of a chaotic equation, generates a one-dimensional real number sequence through multiple iterations, sorts this real number sequence in ascending order to obtain the position index mapping relationship, and then constructs the ordered permutation matrix. Yet another example is a matrix generation algorithm based on hash block modulo. The system divides the timestamp signature sequence into multiple data blocks with a fixed bit width, calculates the integer value of each data block, performs a modulo operation on the total number of plaintext data blocks, and directly arranges the column coordinates of the non-zero elements in each row of the matrix according to the modulo result, thereby generating an ordered permutation matrix. The generated ordered permutation matrix contains a complete and unpredictable set of permutation mapping rules.

[0044] Alternatively, S104 can refer to the following more specific solutions; Perform a hash operation on the timestamp signature sequence to obtain a fixed-length signature hash value; Specifically, the system reads the complete byte stream of the timestamp signature sequence and passes it as input to the underlying one-way hash function. The system performs a hash operation on the timestamp signature sequence, using complex non-linear transformations and compression to eliminate potential length differences and format characteristics in the original timestamp signature sequence. The final output is a hash result with a defined number of bits, thus obtaining a fixed-length signature hash value. For example, the system reads a 1024-bit timestamp signature sequence, performs a hash operation on it using the SHA-256 algorithm, and outputs a signature hash value with an absolute length of 256 bits. This signature hash value possesses extremely high pseudo-randomness and cannot be reverse-engineered from the original timestamp signature sequence.

[0045] Divide the signature hash value into several hash segments, and convert each hash segment into a numerical value; Specifically, the system determines the number of segments to be divided based on the total number of plaintext data blocks. The system cuts the signature hash value into equal-length segments along the byte stream direction of the signature hash value, using a fixed bit width. Then, the system reads the underlying binary data of each hash segment and performs mathematical radix conversion according to a preset unsigned integer encoding rule, converting each hash segment into a numerical value. For example, the system divides a 256-bit signature hash value into 32 hash segments in units of 8 bits each. Next, the system converts one of the hash segments, whose binary content is "10101010", into the decimal value 170, providing a standard integer operand for subsequent XOR calculations.

[0046] The initial sequence number of all plaintext data blocks is XORed bit by bit with each value to obtain the perturbation value corresponding to each plaintext data block. Specifically, the system iterates through all plaintext data blocks and extracts their respective initial sequence numbers. The system then matches these extracted initial sequence numbers with the values ​​generated in the previous steps. After matching, at the underlying binary level, the system performs a bitwise XOR operation between the initial sequence numbers of all plaintext data blocks and each value. Due to the non-linear nature of the XOR operation, this calculation completely alters the original incrementing property of the sequence numbers, thus obtaining the perturbation value corresponding to each plaintext data block. For example, if the initial sequence number of a plaintext data block is decimal 5 (binary 00000101), and its corresponding value is decimal 170 (binary 10101010), the system performs a bitwise XOR operation on these two binary numbers, calculating the binary value 10101111, which is decimal 175. This 175 is the perturbation value corresponding to that plaintext data block.

[0047] The plaintext data blocks are arranged in ascending order of perturbation values ​​to obtain a permutation sequence. When there are the same perturbation values, the plaintext data blocks with the same perturbation values ​​are sorted in ascending order according to the initial physical order. Specifically, the system uses the calculated perturbation value as the primary sorting weight, calls the underlying quicksort algorithm, and arranges the plaintext data blocks in ascending order of perturbation value. During the sorting operation, the system performs numerical conflict detection. When there are identical perturbation values, the system extracts the inherent initial physical order of these conflicting plaintext data blocks during the cutting process as the secondary sorting weight, and sorts the plaintext data blocks with the same perturbation value in ascending order according to their initial physical order. Through this dual-weight sorting mechanism, the system finally obtains the permutation sequence. For example, there are three plaintext data blocks with initial physical orders of 1, 2, and 3, and calculated perturbation values ​​of 89, 45, and 45, respectively. The system first arranges them in ascending order of perturbation value, with the two plaintext data blocks with a perturbation value of 45 at the beginning. Since there is an identical perturbation value of 45, the system compares their initial physical orders (2 and 3), sorts them in ascending order according to their initial physical order, and finally obtains the internal order of the permutation sequence as follows: plaintext data block with initial physical order 2, plaintext data block with initial physical order 3, and plaintext data block with initial physical order 1.

[0048] Construct a permutation matrix based on the permutation sequence; Specifically, the system reads the final position index of each plaintext data block in the permutation sequence. The system initializes a standard identity matrix in memory with a dimension equal to the total number of plaintext data blocks. Then, the system traverses the permutation sequence, performing elementary position transformations on the row or column vectors in the standard identity matrix according to the position mapping relationships recorded in the permutation sequence. This transforms the one-dimensional sequence index into two-dimensional matrix element coordinates, ultimately constructing an ordered permutation matrix. For example, if the system reads a permutation sequence containing 100 elements, it initializes a 100x100 identity matrix. If the permutation sequence indicates that the first plaintext data block should be placed at the 50th position, the system swaps the first and 50th rows of the identity matrix. After traversing all elements and performing row transformations, a 100x100 two-dimensional ordered permutation matrix is ​​finally constructed, providing a rigorous mathematical foundation for subsequent random reordering.

[0049] Step S105: The initial physical order of the plaintext data blocks is rearranged using a sequence permutation matrix to obtain a sequence of out-of-order data blocks; Among them, the disordered data block sequence refers to a completely new data sequence in which the internal data block arrangement order has been completely disrupted after the position transformation, such as a disordered data block sequence arranged according to a non-continuous index like [73, 12, 89, ..., 5].

[0050] Specifically, the system treats the set of plaintext data blocks as a one-dimensional vector and performs matrix multiplication on this vector with a permutation matrix. During the operation, the coordinates of the non-zero elements in the permutation matrix directly map to and change the position index of each plaintext data block. Through this rigorous mathematical mapping, the system rearranges the initial physical order of the plaintext data blocks. Because the generation of the permutation matrix depends on an unpredictable timestamp signature sequence, the rearranged data blocks completely lose their original semantic coherence, ultimately resulting in a sequence of out-of-order data blocks.

[0051] For example: Suppose that Company A's original computer purchase contract was split into 3 plaintext data blocks: Data block 1: "Buyer: Company A", Data block 2: "Purchase Item: 100 computers", Data block 3: "Total Amount: 500,000 yuan".

[0052] The initial normal physical order is [block 1, block 2, block 3].

[0053] In S104, a permutation matrix is ​​generated. Suppose that the shuffling rule represented by this matrix is: "Place the 1st in the middle, the 2nd at the end, and the 3rd at the beginning." After this matrix operation, the original order becomes [block 3, block 1, block 2].

[0054] At this point, the obtained out-of-order data block sequence becomes: "Total amount: 500,000 yuan, Buyer: Company A, Purchase target: 100 computers." The semantics of the data are completely disrupted. If an attacker intercepts the data at this stage, they will see illogical gibberish fragments.

[0055] Step S106: Call the sender's local private key to perform a signature operation on the out-of-order data block sequence and generate a sequential binding signature; In this context, the sender's local private key refers to the private key for an asymmetric encryption algorithm stored in the sender's secure environment, such as a 2048-bit RSA sender's local private key. Signature operations represent the process of using the private key to perform cryptographic calculations on data features to generate a counterfeit-proof marker, such as a signature operation performed using the ECDSA elliptic curve algorithm. Sequentially bound signatures refer to digital proofs that strongly bind the disordered data state to the sender's identity, such as a fixed-length sequentially bound signature that includes disordered state features.

[0056] After rearranging the plaintext data blocks to obtain a sequence of out-of-order data blocks, this step is performed to prevent malicious tampering of the out-of-order state during transmission and to verify the sender's identity. Specifically, the system first calls the sender's local private key and reads the entire data stream of the out-of-order data block sequence. The system performs a hash digest calculation on the out-of-order data block sequence to extract its current out-of-order state feature value, and then uses the sender's local private key to perform an asymmetric encryption signature operation on this feature value. After the signature operation, a sequence-bound signature is generated. This sequence-bound signature not only proves that the data was sent by the legitimate sender holding the sender's local private key, but also cryptographically locks the current arrangement order of the out-of-order data block sequence. Any slight movement of the data block positions in the out-of-order data block sequence will cause the signature verification to fail.

[0057] For example: Company A needs to prove to Company B that the out-of-order data [block 3, block 1, block 2] was indeed sent by Company A and that it was absolutely not tampered with during its journey.

[0058] Therefore, Company A's financial system calls the USB key plugged into the computer (which contains Company A's local private key) to perform cryptographic calculations on the data stream in the specific order of [block 3, block 1, block 2], generating a string of anti-counterfeiting characters, such as Sign_A_778899. This is the sequential binding signature.

[0059] If a hacker secretly changes the order to [block 1, block 3, block 2] during transmission, Company B will receive the data and immediately report an error when using Company A's public key to verify Sign_A_778899, thus discovering that the data has been tampered with.

[0060] Step S107: Obtain the public key of the receiving node, encrypt the timestamp certificate data based on the public key, and generate an encrypted timestamp certificate; In this context, a public key refers to the publicly available key of an asymmetric encryption algorithm belonging to the recipient, such as a public key containing the recipient's identity information issued by an authoritative certificate authority. Timestamp credential data represents a certificate document containing time information and a signature returned by a third-party timestamp server, such as timestamp credential data in Base64 encoding format. Encrypted timestamp credentials represent timestamp credentials that have been encrypted with a public key and can only be decrypted with a specific private key; for example, an encrypted timestamp credential that appears as random gibberish.

[0061] This step is performed to ensure the confidentiality of the timestamp credential data, which contains crucial information for reconstruction, during transmission over public networks before transmitting it to the recipient. Specifically, the system obtains the public key through a secure Public Key Infrastructure (PKI) directory or a pre-established key exchange protocol. Then, the system takes the timestamp credential data as plaintext input and encrypts it using a standard asymmetric encryption standard (such as RSA-OAEP padding mode) based on the public key. The encryption process transforms the original timestamp credential data into an unreadable ciphertext format, generating an encrypted timestamp credential. Due to the mathematical properties of asymmetric encryption, even if intercepted during transmission, attackers cannot read the timestamp signature sequence, thus protecting the core parameters of the subsequent reconstruction of the permutation matrix.

[0062] For example, after receiving out-of-order data, Company B needs to use "timestamped voucher data" (which contains the seed password for restoring the order) to restore the sequence to [block 1, block 2, block 3]. This voucher data is extremely important and must never be transmitted in plaintext over the network.

[0063] Therefore, Company A downloaded Company B's public key from a publicly available Certificate Authority (CA) (essentially a padlock that only Company B can open). Company A used this padlock to lock the "timestamp credential data" into a digital black box, turning it into a bunch of gibberish that no one could understand (such as Encrypted_X8f9A...), which is the encrypted timestamp credential.

[0064] Because only Company B possesses the corresponding private key, even if this black box is taken by an attacker on the internet, the attacker cannot open it and obtain the recovery password.

[0065] Step S108: Encapsulate the out-of-order data block sequence, sequential binding signature, and encrypted timestamp certificate to generate the target electronic contract data packet, and send it to the receiving node; This step is executed after all core data components have been processed and the system is ready for final network data interaction. Specifically, the system encapsulates these three parts in a structured manner, using the out-of-order data block sequence as the data body, the sequentially bound signature as a verification attachment, and the encrypted timestamp certificate as a decryption key attachment, according to a predefined communication protocol format. The encapsulation process adds necessary message headers, data length identifiers, and checksum fields to generate the target electronic contract data packet. Finally, the system establishes a network connection with the recipient and sends the target electronic contract data packet to the receiving node via transport layer protocols such as TCP / IP, completing the entire secure processing and outgoing process of the original electronic sales contract at the sending end.

[0066] In addition, the following steps can be used as a reference for the decryption process of the receiver corresponding to the S101-S108 scheme.

[0067] Upon detecting the arrival of network data, the receiving node first receives the target electronic contract data packet and parses it according to a pre-agreed communication protocol, accurately extracting the out-of-order data block sequence, sequentially bound signature, and encrypted timestamp credential. Subsequently, the receiving system uses its local private key to perform asymmetric decryption on the encrypted timestamp credential, successfully recovering the timestamp credential data containing plaintext time information and the authoritative institution's signature. After obtaining the decrypted data, the receiving system retrieves the sending node's public key from the trusted infrastructure and performs rigorous verification operations on the extracted out-of-order data block sequence and sequentially bound signature based on the sending node's public key to confirm the authenticity of the data source and the integrity of the transmission process.

[0068] After successful signature verification, the receiving system parses the timestamp certificate data and extracts the timestamp signature sequence. The system inputs this sequence into a pre-defined algorithm identical to that used by the sending end to regenerate a permutation matrix to guide data position reconstruction. Next, the system inverts the permutation matrix to calculate the reverse mapping rule. Based on this rule, the system performs position swapping and reverse rearrangement on each data block in the out-of-order data block sequence, completely eliminating the out-of-order state and accurately reconstructing the set of plaintext data blocks with their initial physical order.

[0069] After recovering the plaintext data block set, the receiving system performs a layer-by-layer pairwise hash tree operation on each plaintext data block in the set, extracting the calculated hash value of the current root node. Simultaneously, the system extracts the overall verification hash value initially submitted by the sender from the timestamp certificate data and compares the current root node hash value with the overall verification hash value bit by bit. Once the comparison and verification are completely consistent, confirming that the current data state absolutely matches the original state, the receiving system's file processing module merges all the independent data blocks in the plaintext data block set according to the initial physical order, ultimately restoring the complete original text of the electronic sales contract to be signed.

[0070] Optional, see reference Figure 2 Steps S109-S111 can be executed before step S105; Step S109: Based on the sender's local private key and public key, perform key negotiation operation to generate a shared symmetric key; Among them, a shared symmetric key refers to a unified key generated locally after negotiation and computation, used for subsequent high-strength bidirectional encryption and decryption of data, such as a 128-bit AES shared symmetric key.

[0071] Specifically, the system first extracts the sender's local private key from a local hardware encryption device or secure storage area, and then downloads the public key from an authoritative certificate authority via a secure network request. Subsequently, the system uses the sender's local private key and public key as core input parameters and calls the underlying cryptographic operation module to perform key negotiation operations. Through complex mathematical calculations such as discrete logarithms or elliptic curve multiplication in asymmetric cryptography, the system can unilaterally derive an absolutely secure key sequence known only to the sender and receiver locally, thereby generating a shared symmetric key. For example, Company A's system extracts its local SM2 private key and obtains Company B's publicly available SM2 public key. Through underlying dot product operations, Company A calculates a 256-bit shared symmetric key locally. Due to the mathematical symmetry of cryptography, Company B can subsequently calculate the exact same shared symmetric key using its own private key and Company A's public key, without needing to send the key itself over the network.

[0072] Alternatively, S109 may refer to the following more specific solutions; The shared key value is obtained by multiplying the sender's local private key and public key by a dot product. Convert the shared key value into an initial byte sequence; Divide the initial byte sequence into a first segment and a second segment according to their length; The folded sequence is obtained by performing an XOR operation on the byte-by-byte sequence between the first segment sequence and the second segment sequence. Use the folded sequence as a shared symmetric key.

[0073] Specifically, the system calls the underlying cryptography module, using the sender's local private key as a scalar and performing a dot-matrix operation on an elliptic curve with the public key. Due to the mathematical symmetry of elliptic curves, this operation can unilaterally calculate a mathematical point that is consistent between both parties, thus obtaining the shared key value. Next, the system extracts the coordinate data of this shared key value and converts it into a computer-processable low-level binary stream according to a preset serialization standard, obtaining the initial byte sequence. To adapt to the key length requirements of standard symmetric encryption algorithms and increase the non-linear confusion of the key, the system reads the total length of the initial byte sequence and physically cuts it in memory from the very center, dividing the initial byte sequence into a first segment and a second segment. Subsequently, the system uses the first and second segments as two operands and performs a byte-by-byte XOR operation. This physical-level data folding and logical operation deeply fuses the data features of the two segments, obtaining a folded sequence. Finally, the system assigns values ​​to variables in memory and uses the folded sequence as the shared symmetric key, directly inputting it into subsequent authentication encryption algorithms. For example, Company A's system extracts its local SM2 private key and performs a dot-multiplication operation with Company B's publicly available SM2 public key to calculate a shared key value on an elliptic curve. The system extracts the X-coordinate of this shared key value and converts it into an initial byte sequence of 32 bytes (256 bits). This 32 bytes are then split in half, into a first 16-byte sequence and a second 16-byte sequence. Next, the system performs a bitwise XOR operation on the first and second 16 bytes at the underlying level, with the data interacting to generate a folded sequence of 16 bytes (128 bits). This 16-byte folded sequence not only perfectly matches the key length requirements of standard symmetric encryption algorithms such as AES-128 but also breaks the linear characteristic of the default output of standard cryptographic libraries. The system ultimately uses this folded sequence as the shared symmetric key for subsequent contract data block encryption processes.

[0074] Step S110: Generate encryption parameters for each plaintext data block; Here, encryption parameters refer to dynamic variable data introduced during the initialization phase of a cryptographic encryption algorithm to increase the randomness and uniqueness of the ciphertext, such as encryption parameters used as the initialization vector (IV) or random salt value of the encryption algorithm.

[0075] This step is performed after successfully generating a unified shared symmetric key, but before executing encryption calculations for each individual data block. Specifically, to prevent identical plaintext data blocks from producing identical ciphertext after being encrypted with the same shared symmetric key (thus vulnerable to ciphertext frequency analysis attacks), the system must construct a unique encryption environment for each data block. The system iterates through all plaintext data blocks, extracting the physical location characteristics, timestamp information, or generating random sequences using a random number generator. Through specific combinations and hash calculations, encryption parameters are generated for each plaintext data block. For example, when the system reads the first plaintext data block containing "purchase 100 computers," it extracts its sequence number 1 and combines it with the current system time (milliseconds) to generate a 16-byte random character string as the encryption parameter. When reading the second plaintext data block also containing "purchase 100 computers," it extracts sequence number 2 to generate another completely different 16-byte random character string as the encryption parameter, ensuring the absolute uniqueness of the encryption parameters for each plaintext data block.

[0076] Alternatively, S110 may refer to the following more specific solutions; Based on the sequential permutation matrix, query the index value of the target permutation position corresponding to each plaintext data block; The initial physical order includes the initial sequence number corresponding to each plaintext data block. The target permutation position index value, the initial sequence number, and the preset random number of each plaintext data block are concatenated to obtain the concatenation parameters. Perform a hash operation on the concatenation parameters to generate the encryption parameters corresponding to each plaintext data block.

[0077] Specifically, the system first traverses all plaintext data blocks and, based on the generated permutation matrix, performs a lookup operation in memory to precisely retrieve the target permutation position index value corresponding to each plaintext data block. Simultaneously, since the initial physical order includes the initial sequence number corresponding to each plaintext data block, the system directly extracts this inherent numerical identifier. Subsequently, the system performs a byte stream combination operation in the underlying buffer, strictly concatenating the target permutation position index value, the initial sequence number, and a preset random number from the system's underlying layer for each plaintext data block to obtain the concatenation parameters. This concatenation method physically binds the "past position" (initial number) and "future position" (target index) of the data block. Finally, the system calls the cryptography module to perform a hash operation on the concatenation parameters, utilizing the avalanche effect of the hash function to eliminate the format characteristics of the concatenated data and generate the encryption parameters corresponding to each plaintext data block. For example, when the system processes a plaintext data block containing "Total amount: 500,000 yuan," its initial sequence number is extracted as 3. The system queries the permutation matrix and finds that this data block will be placed at position 42 in subsequent rearrangements, i.e., the target permutation position index value is 42. The system concatenates "42", "3" and the underlying fixed preset random number "0xABCD" into a complete byte stream in memory as concatenation parameters. Next, the system performs a SHA-256 hash operation on these parameters, extracting the first 16 bytes of the result to generate encryption parameters specific to that plaintext data block. Through this dual-position binding mechanism, even if two plaintext data blocks with identical content exist in the contract, their initial numbers and target positions are absolutely different, resulting in completely different encryption parameters, thus ensuring the absolute uniqueness of the encryption result.

[0078] Step S111: Based on the shared symmetric key and encryption parameters, an authentication encryption algorithm is used to perform encryption operations on each plaintext data block to obtain an independent encrypted data unit corresponding to each plaintext data block, and the independent encrypted data unit is used as a plaintext data block.

[0079] Specifically, the system calls the authentication encryption algorithm module in the underlying cryptography library. For each plaintext data block, the system uses a globally unified shared symmetric key as the master key input and the encryption parameters specific to that data block as the initial vector input for the algorithm. Based on the shared symmetric key and encryption parameters, the system uses the authentication encryption algorithm to perform encryption operations on each plaintext data block. This encryption operation not only transforms the plaintext data into unreadable ciphertext but also synchronously calculates an authentication tag (MAC) based on the data content, ultimately obtaining an independent encrypted data unit corresponding to each plaintext data block. To seamlessly integrate with the subsequent reordering process, the system performs pointer replacement and type conversion in memory, treating the independent encrypted data unit as a plaintext data block, overwriting the original plaintext data structure. For example, the system uses the AES-GCM authentication encryption algorithm, with a 256-bit shared symmetric key and specific encryption parameters, to encrypt a plaintext data block containing "Total Amount: 500,000 Yuan," outputting a completely unreadable ciphertext and a 16-byte authentication tag, which together constitute an independent encrypted data unit. Subsequently, the system directly treats this independent encrypted data unit in the ciphertext state as the "plaintext data block" that needs to be scrambled in the subsequent step S105 and performs matrix rearrangement processing.

[0080] In addition, the following scheme can be referenced for the decryption process of the receiver corresponding to S109-S111: In the process of reverse engineering the underlying encrypted data at the receiving end, the receiving system first needs to solve the problem of obtaining the shared symmetric key. The receiving end's local private key refers to the asymmetric cryptographic private key securely kept only by the receiver. The sending node's public key represents the asymmetric cryptographic public key belonging to the sender and publicly released in the digital certificate infrastructure. Key negotiation operation represents the cryptographic process by which both communicating parties use their respective asymmetric keys to derive consistent key data through algebraic geometric calculations. The shared symmetric key refers to the unified encryption / decryption key generated locally after negotiation. In actual cryptographic engineering, the shared symmetric key is never transmitted in plaintext over the network channel. Specifically, the receiving system retrieves its local private key from its local secure hardware and obtains the sending node's public key, using both as input parameters to perform the key negotiation operation. Due to the mathematical symmetry of asymmetric cryptography (such as elliptic curve cryptography), the receiving end can unilaterally derive a key sequence completely identical to the sending end's by performing a dot product calculation using its own private key and the sending end's public key, thus independently generating the shared symmetric key. For example, Company B extracts its local SM2 private key and combines it with Company A's publicly available SM2 public key to perform low-level mathematical calculations. Ultimately, Company B calculates a 256-bit shared symmetric key locally that is exactly the same as the one used by Company A for encryption, thus completely avoiding the risk of the key being eavesdropped on during network transmission.

[0081] After successfully generating the shared symmetric key, the receiving system needs to prepare dynamic variables for the decryption process, i.e., derive the encryption parameters. Here, the independent encrypted data unit refers to the comprehensive data structure generated by the sending end, containing the ciphertext body and integrity verification tag. The encryption parameters represent the dynamic variable data that must be input during the encryption / decryption algorithm initialization phase. The target permutation position index value refers to the target coordinates of the data block in the disorder matrix. The initial sequence number indicates the inherent order of the data block in the original file. The preset random number represents the fixed constant characters hard-coded in the underlying system code of both communicating parties. As per the aforementioned scheme logic, the sending end does not directly send the encryption parameters to the receiving end; instead, both the sending and receiving ends follow the exact same parameter generation protocol. Specifically, after recovering the order permutation matrix from the timestamp credential data, the receiving end traverses each independent encrypted data unit, obtaining its corresponding target permutation position index value and initial sequence number by looking up a table. Subsequently, the system concatenates the target permutation position index value, the initial sequence number, and the underlying system's inherent preset random number, and performs a hash operation on the concatenated data, thereby regenerating encryption parameters locally that are completely identical to those of the sending end. For example, Company B's system looks up the table and finds that the initial sequence number of a certain independent encrypted data unit is 1 and the target position is 5. The system concatenates "5", "1" and the fixed constant "0xABCD" at the system's bottom layer and calculates the hash value, accurately restoring the 16-byte exclusive encryption parameters that Company A used to encrypt the data block at that time.

[0082] After the key and parameters are derived locally, the receiving system formally performs data decryption and verification operations. The authentication encryption algorithm refers to a modern cryptographic standard algorithm pre-agreed upon by both communicating parties in the underlying communication protocol, possessing synchronous encryption / decryption and anti-tampering verification functions. The plaintext data block represents an independent data segment that, after decryption, recovers the original business semantics. Specifically, the receiving system calls the pre-built authentication encryption algorithm module (such as the AES-GCM algorithm) in the underlying code. For each independent encrypted data unit, the system uses the locally calculated shared symmetric key as the master key input and the newly derived encryption parameters specific to that unit as the initial vector input. Based on the shared symmetric key and encryption parameters, the system uses the authentication encryption algorithm to decrypt each independent encrypted data unit. During the operation, the algorithm not only reverses the ciphertext back to plaintext but also recalculates the authentication tag of the data and rigorously compares it with the received tag. After the tag verification passes, confirming that the independent encrypted data unit has not been maliciously tampered with during network transmission, the system finally obtains the plaintext data block corresponding to each independent encrypted data unit. For example, Company B's system calls the pre-agreed AES-GCM authentication encryption algorithm, inputs a 256-bit shared symmetric key and the corresponding 16-byte encryption parameters, and performs decryption operations on a piece of ciphertext garbled text, successfully restoring it to a plaintext data block containing "total amount: 500,000 yuan", providing a real underlying data foundation for subsequent disordered rearrangement recovery.

[0083] The electronic contract encryption device in the embodiments of this invention is described below from the perspective of hardware processing. Please refer to [link / reference needed]. Figure 3 This is a schematic diagram of the physical device structure of an electronic contract encryption device in the embodiments of this application.

[0084] It should be noted that, Figure 3 The structure of the electronic contract encryption device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0085] like Figure 3 As shown, the electronic contract encryption device includes a CPU 301, which can perform various appropriate actions and processes according to a program stored in the read-only memory ROM 302 or a program loaded from the storage section 308 into the random access memory RAM 303, such as performing the methods described in the above embodiments. The RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An I / O interface 305 is also connected to the bus 304.

[0086] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including a liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including a hard disk, etc.; and communication section 309 including a network interface card such as a LAN (Local Area Network) card, modem, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0087] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by CPU 301, it performs the various functions defined in the present invention.

[0088] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0089] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0090] Specifically, the electronic contract encryption device in this embodiment includes a processor and a memory. The memory stores a computer program, and when the computer program is executed by the processor, it implements the electronic contract encryption method provided in the above embodiment.

[0091] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the electronic contract encryption device described in the above embodiments; or it may exist independently and not assembled into the electronic contract encryption device. The storage medium carries one or more computer programs that, when executed by a processor of the electronic contract encryption device, cause the electronic contract encryption device to implement the electronic contract encryption method provided in the above embodiments.

[0092] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for encrypting electronic contracts, characterized in that, The method includes the following steps: Obtain the original text of the electronic purchase and sale contract to be signed, and divide the original text of the electronic purchase and sale contract into a set of plaintext data blocks according to the byte length threshold. The set of plaintext data blocks includes several plaintext data blocks with an initial physical order. Perform a hash tree operation on the plaintext data block and extract the root node hash value as the overall verification hash value; The overall verification hash value is sent to a third-party timestamp server, and the timestamp credential data returned by the third-party timestamp server is received. Extract the timestamp signature sequence from the timestamp voucher data, and generate an order permutation matrix based on the timestamp signature sequence; The initial physical order of the plaintext data blocks is rearranged using the order permutation matrix to obtain a sequence of out-of-order data blocks. The sender's local private key is invoked to perform a signature operation on the out-of-order data block sequence, generating a sequential binding signature. Obtain the public key of the receiving node, and encrypt the timestamp credential data based on the public key to generate an encrypted timestamp credential; The disordered data block sequence, the sequential binding signature, and the encrypted timestamp certificate are encapsulated to generate a target electronic contract data packet, which is then sent to the receiving node.

2. The method according to claim 1, characterized in that, Before rearranging the initial physical order of the plaintext data blocks using the order permutation matrix to obtain the disordered data block sequence, the method further includes: Based on the sender's local private key and public key, perform key negotiation operations to generate a shared symmetric key; Generate encryption parameters for each of the plaintext data blocks; Based on the shared symmetric key and the encryption parameters, an authentication encryption algorithm is used to encrypt each plaintext data block to obtain an independent encrypted data unit corresponding to each plaintext data block, and the independent encrypted data unit is used as the plaintext data block.

3. The method according to claim 2, characterized in that, The step of performing a key negotiation operation based on the sender's local private key and the public key to generate a shared symmetric key specifically includes: The shared key value is obtained by performing a dot multiplication operation between the local private key of the sending end and the public key; Convert the shared key value into an initial byte sequence; The initial byte sequence is divided into a first segment sequence and a second segment sequence according to their length; The folded sequence is obtained by performing an XOR operation on the byte-by-byte sequence between the first segment sequence and the second segment sequence. The folded sequence is used as the shared symmetric key.

4. The method according to claim 2, characterized in that, The step of generating encryption parameters for each of the plaintext data blocks specifically includes: Based on the order permutation matrix, query the target permutation position index value corresponding to each plaintext data block; The initial physical order includes the initial sequence number corresponding to each plaintext data block. The target permutation position index value, the initial sequence number, and a preset random number of each plaintext data block are concatenated to obtain concatenation parameters. A hash operation is performed on the concatenation parameters to generate the encryption parameters corresponding to each plaintext data block.

5. The method according to claim 1, characterized in that, The step of extracting the timestamp signature sequence from the timestamp voucher data and generating an order permutation matrix based on the timestamp signature sequence specifically includes: Perform a hash operation on the timestamp signature sequence to obtain a signature hash value of fixed length; The signature hash value is divided into several hash segments, and each hash segment is converted into a numerical value; The initial sequence number of all the plaintext data blocks is sequentially XORed with each of the numerical values ​​to obtain the perturbation value corresponding to each plaintext data block. The plaintext data blocks are arranged in ascending order of the perturbation values ​​to obtain a permutation sequence. When there are the same perturbation values, the plaintext data blocks with the same perturbation values ​​are sorted in ascending order according to the initial physical order. Construct the sequential permutation matrix based on the permutation sequence.

6. The method according to claim 1, characterized in that, The step of dividing the original electronic purchase and sale contract into a set of plaintext data blocks based on the byte length threshold specifically includes: The original text of the electronic purchase and sale contract is sequentially segmented according to the byte length threshold to obtain several first standard plaintext blocks, and the first original length data of the first standard plaintext blocks is calculated. Select a non-standard plaintext block whose byte length is less than the byte length threshold, generate a padding sequence whose length is equal to the difference between the byte length threshold and the length of the non-standard plaintext block according to a preset byte, and calculate the second original length data of the non-standard plaintext block; The padding sequence is merged with the non-standard plaintext block to obtain the first padded plaintext block; The first padded plaintext block and the second original length data are combined to generate the second padded plaintext block, and the first standard plaintext block and the first original length data are combined to generate the second standard plaintext block. The second padded plaintext block and the second standard plaintext block are combined to form the plaintext data block set.

7. The method according to claim 6, characterized in that, The step of combining the first padded plaintext block and the second original length data to generate a second padded plaintext block, and combining the first standard plaintext block and the first original length data to generate a second standard plaintext block, specifically includes: Divide the first padded plaintext block into a first pre-segment and a first post-segment according to the byte length; The second original length data is inserted between the first pre-segment and the first post-segment, and then concatenated sequentially to generate the second padded plaintext block; The first standard plaintext block is divided into a second pre-segment and a second post-segment according to the length of bytes. The first original length data is inserted between the second pre-segment and the second post-segment, and then concatenated to generate the second standard plaintext block.

8. An electronic contract encryption device, characterized in that, The electronic contract encryption device includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors invoke the computer instructions to cause the electronic contract encryption device to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on the electronic contract encryption device, the electronic contract encryption device performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the electronic contract encryption device, the electronic contract encryption device performs the method as described in any one of claims 1-7.

Images