Method of encrypting data and related products

Abstract

This invention relates to a method for encrypting data and related products. The method includes: when performing a hash operation on streamed plaintext data, determining a first ciphertext and a second ciphertext for each input data segment during the streamed input process; in response to the input plaintext data satisfying predetermined conditions, obtaining a first parameter and a second parameter based on the first ciphertext, and obtaining a third parameter based on the second ciphertext; and during the calculation of a compression function, determining intermediate variables TT1 and TT2 in the compression function based on the first to third parameters, and updating the registers involved in the hash operation until the updated registers output the hash result for the plaintext data. Through the solution of this invention, when performing hash calculations on streamed plaintext functions, plaintext can be effectively protected in ciphertext form throughout the entire algorithm implementation process, ensuring that no plaintext appears throughout the entire process, thus improving data security.

Description

Technical Field

[0001] This invention generally relates to the field of information security technology. More specifically, this invention relates to a method for encrypting data, and an electronic device and computer-readable storage medium for performing the aforementioned method. Background Technology

[0002] This section is intended to provide background or context for embodiments of the invention set forth in the claims. The description herein may include concepts that may be explored, but not necessarily concepts that have been previously conceived or explored. Therefore, unless otherwise stated, what is described in this section is not prior art for the purposes of this application's specification and claims, and is not acknowledged as prior art simply by virtue of its inclusion in this section.

[0003] The SM3 algorithm is a hash algorithm, also called a digest algorithm. A hash algorithm is defined as taking a set of data as input and outputting a fixed-length hash value. An ideal hash algorithm has three characteristics:

[0004] 1. One-wayness, which means that the hash value can be easily derived from the original text, but the original text cannot be derived from the hash value.

[0005] 2. Consistency, which means that regardless of the length of the input content, the output length is a fixed value, and the output value is evenly distributed in the output domain.

[0006] 3. Collision resistance, which means that the output hash values ​​are almost impossible to be equal when the inputs are different.

[0007] Based on these characteristics, hash algorithms are frequently used for data digesting and verification, message authentication code generation, verification, and random number generation. In practical applications, while traditional hash algorithms support encrypted computation of streaming input data, security vulnerabilities exist in their implementation. For example, in password input scenarios, traditional streaming implementations of hash algorithms store the password in plaintext in memory until the input is complete or reaches 64 bytes. This makes them vulnerable to attacks targeting memory searches and eavesdropping, leading to security risks. Currently, there is no effective solution to this problem. Summary of the Invention

[0008] To at least address the technical problems described in the background section, this invention proposes a data encryption scheme. Using the scheme of this invention, the security of the encryption process for streaming input data can be improved.

[0009] In view of this, the present invention provides solutions in the following aspects.

[0010] A first aspect of the present invention provides a method for encrypting data, the method comprising: when performing a hash operation on plaintext data streamed into the stream, determining a first ciphertext and a second ciphertext of data input in a single instance during the plaintext data stream; in response to the input plaintext data satisfying predetermined conditions, obtaining a first parameter and a second parameter for a compression function based on the first ciphertext, and obtaining a third parameter for the compression function based on the second ciphertext, wherein the first parameter, the second parameter, and the third parameter are all in ciphertext state; and during the calculation of the compression function, determining intermediate variables TT1 and TT2 in the compression function based on the first parameter, the second parameter, and the third parameter, and updating registers involved in the hash operation until the updated registers output a hash result for the plaintext data.

[0011] In one embodiment, determining the first ciphertext and the second ciphertext of a single input data session during the plaintext data streaming process includes: calculating the XOR value between the single input data session and the corresponding byte in the temporary key to obtain the first ciphertext; and calculating the difference between the XOR value and the single input data session to obtain the second ciphertext.

[0012] In one embodiment, the method further includes: obtaining a random array; and

[0013] The random array is initialized to obtain the temporary key.

[0014] In one embodiment, obtaining the first and second parameters for the compression function based on the first ciphertext includes: expanding the first ciphertext to obtain the first and second parameters.

[0015] In one embodiment, obtaining the third parameter for the compression function based on the second ciphertext includes: performing integer merging on the second ciphertext to obtain the third parameter, wherein carry and borrow are processed every 4 bytes during the integer merging process.

[0016] In one embodiment, the intermediate variable TT1 is determined according to the following formula:

[0017] TT1←FF j (A, B, C) + D + SS2 + W a [j]-W b [j], W a [j+4]=W key [j+4]

[0018] And j<16

[0019]

[0020] Among them, FF j Let W be a Boolean function, A, B, C, and D be the registers, j be the iteration number of the compression function, and W be the value of the Boolean function. a For the first parameter, W′ a SS2 is the second parameter, and W is an intermediate parameter. key It is obtained by expanding the temporary key.

[0021] In one embodiment, the intermediate variable TT2 is determined according to the following formula:

[0022] TT2←GG j (E, F, G) + H + SS1 + W a [j]-W b [j], j < 16

[0023]

[0024] Among them, GG j Let W be a Boolean function, E, F, G, and H be the registers, j be the iteration number of the compression function, and W be the value of W. a For the first parameter, W′ a The second parameter is SS1, which is an intermediate parameter, and W is W. b W is the third parameter. key It is obtained by expanding the temporary key.

[0025] In one embodiment, the hash algorithm includes the SM3 algorithm.

[0026] A second aspect of the present invention provides an electronic device comprising: a processor; and a memory storing computer instructions containing encrypted data, wherein when the computer instructions are executed by the processor, the device performs the method described in accordance with the first aspect above and the various embodiments described below.

[0027] A third aspect of the invention provides a computer-readable storage medium including program instructions for encrypting data, which, when executed by a processor, cause the method according to the first aspect above and the various embodiments below to be implemented.

[0028] The solution provided by this invention effectively protects plaintext data input in a single stream, ensuring that all data is calculated in ciphertext throughout the entire computation process, thus preventing the appearance of plaintext. This significantly improves the security of the encryption process for streaming input data. Attached Figure Description

[0029] The above and other objects, features, and advantages of exemplary embodiments of the present invention will become readily apparent upon reading the following detailed description with reference to the accompanying drawings. In the drawings, several embodiments of the invention are illustrated by way of example and not limitation, and like or corresponding reference numerals denote like or corresponding parts, wherein:

[0030] Figure 1 This is a flowchart illustrating a method for encrypting data according to an embodiment of the present invention;

[0031] Figure 2 This is a flowchart illustrating a method for encrypting data according to another embodiment of the present invention;

[0032] Figure 3 This is a flowchart illustrating a method for encrypting data according to another embodiment of the present invention; and

[0033] Figure 4 This is a structural diagram illustrating an electronic device according to an embodiment of the present invention. Detailed Implementation

[0034] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0035] It should be understood that the terms "first," "second," "third," and "fourth," etc., in the claims, specification, and drawings of this invention are used to distinguish different objects, rather than to describe a specific order. The terms "comprising" and "including" used in the specification and claims of this invention indicate the presence of the described features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof.

[0036] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this specification and claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes such combinations.

[0037] As used in this specification and claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0038] The traditional SM3 algorithm involved in this application can be understood as the SM3 cryptographic hash algorithm, which is the national commercial cryptographic hash algorithm standard.

[0039] The inventors discovered that the traditional SM3 algorithm has poor security when processing streaming input data. This is because the traditional SM3 algorithm implementation cannot avoid the presence of plaintext in the memory or registers involved. Specifically, in the traditional SM3 algorithm implementation, the `update` function continuously inputs data and performs hashing synchronously, and then calls the `final` function to complete the entire hash calculation after the input is finished. However, in streaming hash calculations, hash calculations are only performed when the data reaches an integer multiple of the block length (64 bytes). Before that, the original text exists in memory in plaintext form.

[0040] While related technologies have seen improvements, the results remain unsatisfactory. For example, the SM3 algorithm implemented in the open-source software library OpenSSL is based on the Chinese national standard GMT 0004-2012. Source code from some open-source platforms (such as GitHub) reveals that plaintext values ​​are stored in intermediate variables during hash calculation, thus failing to meet the requirement of plaintext hiding. Another example is the use of changing the initial value of registers to further protect intermediate variable values; however, this method does not protect the extended word, meaning that plaintext information can still appear in the extended word when the input information is less than 16 characters, making it unsuitable for scenarios requiring plaintext protection for stream input. Furthermore, some related technologies may encrypt each character, but decryption to obtain the plaintext is still required before subsequent calculations can be performed, making it impossible to completely prevent the appearance of plaintext in this process.

[0041] Therefore, regardless of the classic implementation of the traditional SM3 algorithm or the methods mentioned above, plaintext may appear or flash in memory and registers during the calculation of the compression function or extended word. This clearly cannot meet the requirements of some application scenarios with high security requirements, especially those that input data in a streaming manner. For example, plaintext should be avoided as much as possible in memory during the input of password information or other sensitive personal information. In scenarios with high security requirements, it is best to achieve a complete absence of plaintext throughout the entire process.

[0042] Based on this, the inventors discovered through research that by adjusting the specific implementation process of the hash algorithm so that the entire calculation process only involves ciphertext, the appearance of plaintext can be effectively avoided, thereby effectively improving the security of the encryption process of streaming input data.

[0043] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0044] Figure 1 This is a schematic diagram illustrating a method 100 for encrypting data according to an embodiment of the present invention.

[0045] like Figure 1 As shown, in step S101, when performing a hash operation on the plaintext data input via streaming, the first and second ciphertexts of each input data session during the plaintext data streaming process can be determined. Here, streaming input can be understood as a continuous data input method, a sequential data input method, or a sequential data input method. Streaming plaintext data can be understood as plaintext data whose content is continuously, sequentially, or sequentially input. It should be noted that the specific type of plaintext data is not limited here; for example, it can be passwords, other sensitive information, or data with high security requirements that can be input in a streaming manner. During the plaintext data input process, each input data session can be encrypted to obtain the first and second ciphertexts. Therefore, all content in the plaintext can be effectively protected during the input stage, preventing the plaintext from being leaked.

[0046] The above process will be explained using a password as the plaintext data as an example. The process of sequentially entering each digit of the password (e.g., 123456) can be understood as the password being entered in a streaming manner. For each single input (e.g., any digit from "1", ..., "6"), the first and second ciphertexts of each digit can be obtained. Thus, each digit can be stored in ciphertext to improve the security of the data input stage. It should be noted that this explanation only uses a password as an example; the input process for other types of plaintext data can also refer to the above process, and will not be exhaustively listed here.

[0047] After obtaining the first and second ciphertexts, in step S102, in response to the input plaintext data satisfying predetermined conditions, a first parameter and a second parameter for the compression function are obtained based on the first ciphertext, and a third parameter for the compression function is obtained based on the second ciphertext. In some exemplary scenarios, the predetermined conditions include the input completing all content, or the input reaching a predetermined block length (e.g., 64 bytes or an integer multiple thereof), or other conditions that can trigger data expansion operations. When the input plaintext data meets the above-mentioned preset conditions, the first, second, and third parameters can be obtained by calculating the first and second ciphertexts. These first, second, and third parameters will participate in the subsequent calculation process of the compression function in ciphertext state. It can be seen that this process does not require decryption of the ciphertext obtained in step S101, that is, no plaintext is required to participate in the calculation of this process, which can effectively ensure data security.

[0048] Finally, in step S103, during the calculation of the aforementioned compression function, intermediate variables TT1 and TT2 in the compression function are determined based on the first, second, and third parameters, and the registers involved in the hash operation are updated until the updated registers output the hash result of the aforementioned plaintext data. During the iterative compression process using the compression function, the intermediate variables TT1 and TT2 are specifically determined using the first, second, and third parameters of the ciphertext state calculated above. The compression function is adjusted using the intermediate variables TT1 and TT2 to adjust the iterative compression process until the hash result of the plaintext data is output. It can be seen that for stream-input plaintext data, effective protection can be provided for single-input data, and all data involved in the hash calculation exists in a ciphertext state, thereby preventing the appearance of plaintext or its use in calculations. This effectively improves the security of the encryption process for stream-input data. Therefore, for scenarios with high security requirements, it is possible to ensure that no plaintext appears in memory or registers throughout the entire input process and hash calculation process, thereby improving the security of the data encryption process.

[0049] Figure 2 This is a flowchart illustrating a method 200 for encrypting data according to another embodiment of the present invention. It should be noted that method 200 can be understood as a further limitation or extension of the steps in method 100. Therefore, the foregoing combined with... Figure 1 The relevant descriptions also apply to the following text.

[0050] like Figure 2As shown, in step S201, when performing hash operation on the plaintext data of the streaming input, the XOR value between the single input data and the corresponding byte in the temporary key can be calculated to obtain the first ciphertext, and the difference between the XOR value and the single input data can be calculated to obtain the second ciphertext.

[0051] In some embodiments, the aforementioned temporary key can be determined using a random array. Specifically, during hash algorithm initialization, a random array can be obtained and initialized to obtain the temporary key.

[0052] During the plaintext data streaming input process, the first ciphertext is obtained by XORing the single input data with the corresponding byte in the temporary key. The second ciphertext is then determined by the difference between this XOR value and the single input data. Taking a key as an example, in the streaming input of the password "123456", for the first input digit "1", the XOR value between "1" and the first byte of the temporary key is calculated, and the difference between this XOR value and "1" is used to determine the second ciphertext. For the second input digit "2", the XOR value between "2" and the second byte of the temporary key is calculated, and the difference between this XOR value and "2" is used to determine the second ciphertext. This process is repeated to encrypt all the contents of the password. It should be noted that this explanation only uses the password as the streaming input plaintext data and does not restrict the specific type of plaintext data. The process for obtaining the first and second ciphertexts from other types of plaintext data can also refer to the above steps.

[0053] Next, at step S202, in response to the input plaintext data satisfying predetermined conditions, the first and second parameters for the compression function can be obtained by expanding the first ciphertext, and the third parameter for the compression function can be obtained by integrating the second ciphertext.

[0054] In some embodiments, the first ciphertext can be expanded to obtain the first and second parameters. In some exemplary application scenarios, when the input plaintext data meets the predetermined block length or after all content input is completed, the first ciphertext can be expanded to obtain the first and second parameters. It should be noted that when the input plaintext data has completed all content input, but the content still does not meet the predetermined block length, it needs to be padded or filled to the predetermined block length (e.g., 64 bytes or an integer multiple thereof). The specific padding or filling principle can refer to the padding or filling principle of traditional SM3. For example, for the input plaintext data m, assuming the length of m is l bits, first add the bit "1" to the end of the plaintext data m, then add k "0"s, where k is the smallest non-negative integer that satisfies l+1+k=≡448 (mod 512). Then, add a 64-bit bit string, the length of which is represented in binary. The bit length of the padded or filled plaintext data m is a multiple of 512 (i.e., 64 bytes or an integer multiple thereof). It should be noted that this description only serves as an example of the specific filling or patching process.

[0055] In some embodiments, the expansion of the first ciphertext can be implemented by referring to the expansion method in the traditional SM3 algorithm standard to obtain the first and second parameters of the 68-word ciphertext state.

[0056] In some embodiments, the third parameter can be obtained by performing integer merging on the second ciphertext described above. During the integer merging process, carry and borrow can be processed every four bytes. Specifically, the second ciphertext can be merged into a 32-bit integer every four bytes. The merging rule is as follows: if the current byte is less than 0, the value of the previous byte is decreased by 1, and the value of the current byte is increased by 256; if the current byte is greater than 256, the value of the previous byte is increased by 1, and the value of the current byte is decreased by 256. Then, the four bytes (each 8 bits) are arranged from front to back into a 32-bit integer and converted to an integer, with the sign bit remaining the same as the first byte. It should be noted that this is only an illustrative description of the second ciphertext merging process; the specific merging method can be adjusted according to application requirements. It should also be noted that this is only an illustrative description of the specific merging process.

[0057] After obtaining the first, second, and third parameters, in step S203, the calculation method of intermediate variables TT1 and TT2 can be modified during the calculation of the compression function, and the modified compression function process can be repeated until the updated register outputs the hash result of the plaintext data.

[0058] In some embodiments, the intermediate variable TT1 can be determined using formulas (1) and (2):

[0059]

[0060]

[0061] In formulas (1) and (2), FF j Let W be a Boolean function, A, B, C, and D be the registers, j be the iteration number of the compression function, and W be the value of the Boolean function. a For the first parameter, W′ a SS2 is the second parameter, and W is an intermediate parameter. key It is obtained by expanding the temporary key (the specific temporary key can be used with the first parameter W). a The same extension method yields W key ).

[0062] In some embodiments, the intermediate variable TT2 can be determined using formulas (3) and (4):

[0063] TT2←GG j (E, F, G) + H + SS1 + W a [j]-W b [j], j < 16 (3)

[0064]

[0065] In formulas (3) and (4), GG j Let W be a Boolean function, E, F, G, and H be the registers, j be the iteration number of the compression function, and W be the value of W. a For the first parameter, W′ a The second parameter is SS1, which is an intermediate parameter, and W is W. key It is obtained by expanding the temporary key (the specific temporary key can be used with the first parameter W). a The same extension method yields W key ).

[0066] It can be seen that when performing hash calculations on plaintext functions with streaming input, the plaintext can be effectively protected in ciphertext mode during both the data input stage and the specific hash calculation stage (including expansion and iterative compression, etc.), so that no plaintext appears throughout the entire process, thereby improving data security and meeting the needs of scenarios with high security requirements.

[0067] Figure 3 A flowchart illustrating a method 300 for encrypting data according to another embodiment of the present invention is shown schematically. It should be noted that method 300 can be understood as a specific technical implementation of method 100 or method 200. Therefore, the foregoing combined with... Figure 1 and Figure 2The relevant detailed descriptions are also referred to below.

[0068] Furthermore, it should be noted that Method 300 can be understood as a further improvement on the specific implementation of the traditional SM3 algorithm standard, in order to solve the technical problem that the traditional SM3 algorithm requires plaintext participation in the specific implementation process, which poses security risks and may even fail to meet the requirements of some high-security scenarios. The specific meanings of characters (including letters, symbols, etc.) involved in some formulas in Method 300 and the various embodiments of this application are consistent with the relevant characters in the traditional SM3 algorithm standard. For example, in the hash calculation process, the registers involved include A, B, C, D, E, F, G, and H; SS1, SS2, TT1, and TT2 are all intermediate variables; and FF... j and GG j This refers to Boolean functions, etc.

[0069] like Figure 3 As shown, in step S301, a temporary key `key` can be initialized. Specifically, during hash algorithm initialization, when hash calculation is required, a 64-byte random array is first initialized as the temporary key `key`.

[0070] Next, in step S302, during the stream input update, the XOR value of the single input and the corresponding byte in the key (i.e., the first ciphertext a) and the difference between the XOR value and the single input character (i.e., the second ciphertext b) are calculated. For the calculation process of the first and second ciphertexts, please refer to the preceding text. Figure 2 The relevant details will not be repeated here.

[0071] Next, in step S303, when 64 bytes have been input or the input has been completed, the first ciphertext a is expanded to obtain the first parameter W of the 68-character ciphertext state. a Second parameter W′ a and use W on the key a The same method is used to extend W. key It should be noted that in practical applications, W a and W′ a and W key The specific extension methods involved can be implemented by referring to the relevant extension methods in the traditional SM3 algorithm standard, and will not be elaborated here.

[0072] At step S304, the second ciphertext b can be integrated to obtain the third parameter W. b Specifically, the second ciphertext b can be merged into a 32-bit integer W every 4 bytes. bThe merging rule is as follows: if the current byte index is less than 0, then the value of the previous byte is decreased by 1 and the value of the current byte is increased by 256; if the current byte is greater than 256, then the value of the previous byte is increased by 1 and the value of the current byte is decreased by 256. Then, the four bytes (each of which is 8 bits) are arranged from front to back into 32 bits and converted into an integer, with the sign bit remaining the same as the first byte.

[0073] Next, in step S305, the intermediate variable TT1 is modified in the compression function of the hash operation. Specifically, if j is less than 16 and W a [j+4] and W key If the values ​​of [j+4] are equal, then TT1 is calculated as follows:

[0074] FF j (A, B, C) + D + SS2 + W a [j]-W b [j]

[0075] Otherwise, TT1 is calculated as follows:

[0076]

[0077] In step S306, the intermediate variable TT2 is modified in the hash operation's compression function. Specifically, if j is less than 16, TT2 is calculated as follows:

[0078] GG j (E, F, G) + H + SS1 + W a [j]-W b [j]

[0079] Otherwise, TT2 is calculated as follows:

[0080]

[0081] It should be noted that in steps S305 and S306, A, B, C, D, E, F, G, and H in the formula represent registers, SS1, SS2, TT1, and TT2 represent intermediate variables, and FF represents intermediate variables. j and GG j This represents a Boolean function, where j is the number of iterations of the compression function, and W... a W′ is the first parameter. a W is the second parameter. key It is derived from the temporary key, and the operators involved can be referenced from the meaning of the relevant operators in the traditional SM3 algorithm standard.

[0082] A similar or identical iterative compression process to that in the traditional SM3 algorithm standard can be used to continuously repeat the compression function process modified by steps S305 and S306, and at step S307, the result of updating the 8 registers is used to obtain a hash result of 256 bytes.

[0083] By improving the implementation of the traditional SM3 algorithm, plaintext data input during streaming can be protected by performing XOR and difference calculations on a single input data stream. Furthermore, subsequent calculations do not require decryption of the ciphertext obtained through XOR or difference calculations. Therefore, plaintext does not appear in memory or registers throughout the entire input phase and the specific hash algorithm calculation process, effectively improving data security. In particular, it prevents data leakage caused by unauthorized memory scanning when inputting sensitive personal information.

[0084] In practical applications, experiments show that the hash result obtained by encrypting streaming input data using the scheme of this application is consistent with the hash result obtained by encrypting the same streaming input data using the traditional SM3 algorithm. Furthermore, implementation results show that the time complexity of the plaintext protection operation in this application is O(n), indicating extremely short processing time.

[0085] Figure 4 A schematic block diagram of an electronic device 400 according to an embodiment of the present invention is shown. Figure 4 As shown, the electronic device 400 may include a processor 401 and a memory 402. The memory 402 stores computer instructions for encrypting data. When these computer instructions are executed by the processor 401, the electronic device 400 performs actions according to the preceding description. Figures 1-3 The method described herein. For example, in some embodiments, the electronic device 400 can perform calculations on the first and second ciphertexts, calculations on the first, second, and third parameters, calculations on intermediate variables, and support iterative compression processes, etc. Based on this, the electronic device 400 can effectively protect the plaintext data input during streaming, ensuring that all related data is calculated in ciphertext throughout the entire computation process, thereby preventing the appearance of plaintext. This effectively improves the security of the encryption process for streaming input data. It should be noted that this application does not limit the specific type of electronic device; any device that supports streaming data input and requires encryption of that data is acceptable.

[0086] As can be seen from the above description of the modular design of the present invention, the system of the present invention can be flexibly arranged according to application scenarios or needs, and is not limited to the architecture shown in the accompanying drawings. Furthermore, it should be understood that any module, unit, component, server, computer, or device performing the operations of the present invention examples may include or otherwise access computer-readable media, such as storage media, computer storage media, or data storage devices (removable) and / or non-removable) such as disks, optical discs, or magnetic tapes. Computer storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. Based on this, the present invention also discloses a computer-readable storage medium storing computer-readable instructions for encrypting data, which, when executed by one or more processors, implement the methods and operations described above in conjunction with the accompanying drawings.

[0087] While various embodiments of the invention have been shown and described herein, it will be apparent to those skilled in the art that such embodiments are provided by way of example only. Many modifications, alterations, and alternatives will occur to those skilled in the art without departing from the spirit and intent of the invention. It should be understood that various alternatives to the embodiments of the invention described herein may be employed in the practice of the invention. The appended claims are intended to define the scope of protection of the invention and therefore cover modular compositions, equivalents, or alternatives within the scope of these claims.

Claims

1. A method of encrypting data, characterized by, The method comprises: determining first and second ciphertexts of single input data in the process of streaming input of the plaintext data when performing a hash operation on the streaming input of the plaintext data; in response to the input plaintext data satisfying a predetermined condition, obtaining a first parameter and a second parameter for a compression function based on the first ciphertext and a third parameter for the compression function based on the second ciphertext, wherein the first parameter, the second parameter and the third parameter are all in ciphertext state; and in the process of performing calculation on the compression function, determining intermediate variables TT1 and TT2 in the compression function based on the first parameter, the second parameter and the third parameter, and updating registers involved in the hash operation until the updated registers output a hash result of the plaintext data; wherein the determination of the first and second ciphertexts of single input data in the process of streaming input of the plaintext data comprises: calculating an exclusive-OR value between the single input data in the process of streaming input of the plaintext data and a corresponding byte in a temporary key to obtain the first ciphertext; and calculating a difference value between the exclusive-OR value and the single input data to obtain the second ciphertext; wherein the obtaining of the first and second parameters for the compression function based on the first ciphertext comprises: expanding the first ciphertext to obtain the first and second parameters; and wherein the obtaining of the third parameter for the compression function based on the second ciphertext comprises: integer merging processing of the second ciphertext to obtain the third parameter, wherein in the integer merging processing, every 4 bytes are processed with carry and borrow.

2. The method of claim 1, wherein, The method further comprises: obtaining a random array; and initializing the random array to obtain the temporary key.

3. The method of claim 1, wherein, The intermediate variable TT1 is determined according to the following formula: TT1 <- FF j (A, B, C) + D + SS2 + W a [j] - W b [j], W a [j+4] = W key [j+4] and j < 16 and the intermediate variable TT2 is determined according to the following formula: TT2 <— GG j (E, F, G) + H + SS1 + W a [j] - W b [j], j < 16 where FF j , GG j are Boolean functions, A, B, C, D, E, F, G and H are the registers, j is the iteration round of the compression function, W a is the first parameter, W′ a is the second parameter, W b is a third parameter, SS1 and SS2 are intermediate parameters, W key is derived based on the temporary key expansion.

4. The method according to any one of claims 1 to 3, characterized in that, The hash operation comprises an SM3 algorithm.

5. An electronic device, comprising: Comprise: a processor; and a memory storing computer instructions of encrypted data, which, when executed by the processor, cause the electronic device to perform the method according to any one of claims 1-4.

6. A computer-readable storage medium, characterized in that, Program instructions comprising encrypted data, which, when executed by a processor, cause the implementation of the method according to any one of claims 1-4.

Images