Dynamic encryption and decryption method, device and equipment of information and storage medium

Abstract

This application discloses a dynamic encryption / decryption method, apparatus, device, and storage medium for information, relating to the field of data encryption technology. The method includes: encrypting initial information using a public key to obtain initial ciphertext; generating an insertion position index based on the ciphertext length of the initial ciphertext; splitting and concatenating the ciphertext based on the insertion position index to generate target ciphertext; and sending a service request containing the target ciphertext to a backend, so that the backend decrypts the target ciphertext to restore the initial information. This application effectively solves the security risks associated with static key storage by using a public key to encrypt and generate initial ciphertext at the front end and dynamically generating an insertion position index based on its length to split and hide the private key within the target ciphertext. This significantly improves the security of data transmission without requiring additional key management configuration.

Description

Technical Field

[0001] This application relates to the field of data encryption technology, and in particular to methods, apparatus, devices and storage media for dynamic encryption and decryption of information. Background Technology

[0002] In the data interaction and storage process of information systems, encrypting sensitive information is a crucial means of ensuring data security. Currently, mainstream encryption and decryption solutions in the industry typically employ a combination of asymmetric and symmetric encryption. Developers manually call pre-packaged encryption utility classes within the business code to encrypt and decrypt sensitive fields or entire message segments, and the keys used are statically configured in the system's configuration file or database. However, the aforementioned existing technologies suffer from a significant security vulnerability due to static key storage: because the keys are permanently fixed and typically hard-coded into configuration files or databases, if the storage medium or configuration file is leaked, attackers can use this static key to decrypt all historical encrypted data in bulk, threatening the security of data assets.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a dynamic encryption and decryption method, apparatus, device and storage medium for information, aiming to solve the technical problem that static keys are not secure enough for data encryption and decryption.

[0005] To achieve the above objectives, this application proposes a dynamic encryption / decryption method for information, which is applied to a front-end and includes: The initial information is encrypted using the public key to obtain the initial ciphertext; An insertion position index is generated based on the ciphertext length of the initial ciphertext. The target ciphertext is generated by splitting and concatenating the ciphertext based on the insertion position index. A business request containing the target ciphertext is sent to the backend so that the backend can decrypt and restore the target ciphertext to obtain the initial information.

[0006] In one embodiment, the step of encrypting the initial information using a public key to obtain the initial ciphertext includes: Dynamically generate the symmetric encryption key pair for the current request, the key pair including the public key and the private key; The initial information is encrypted using the public key and a symmetric encryption algorithm to obtain the initial ciphertext.

[0007] In one embodiment, the step of generating an insertion position index based on the ciphertext length of the initial ciphertext, and then splitting and concatenating the ciphertext based on the insertion position index to generate the target ciphertext includes: Obtain the character length of the initial ciphertext, and determine the insertion position index within the character length range; The initial ciphertext is split into a first ciphertext segment and a second ciphertext segment according to the insertion position index. The first ciphertext segment, the private key, and the second ciphertext segment are then concatenated in sequence to obtain a third ciphertext segment. The formatted insertion position index and the third ciphertext segment are concatenated to generate the target ciphertext.

[0008] In one embodiment, the dynamic encryption / decryption method for the information is applied to the backend, and the dynamic encryption / decryption method for the information includes: The system receives a service request from the front end containing target ciphertext, which is obtained by the front end encrypting initial information using a public key. An insertion position index is generated based on the ciphertext length of the initial ciphertext, and the system is then split and concatenated based on the insertion position index. The target ciphertext in the business request is decrypted and restored to obtain the initial information.

[0009] In one embodiment, the step of decrypting and restoring the target ciphertext in the service request to obtain the initial information includes: The target ciphertext is parsed to obtain the insertion position index of the target ciphertext and the third ciphertext segment; The third ciphertext segment is split and spliced ​​according to the insertion position index to obtain the initial information.

[0010] In one embodiment, the step of splitting and concatenating the third ciphertext segment according to the insertion position index to obtain the initial information includes: The third ciphertext segment is split using the insertion position index as the dividing point to obtain the first ciphertext segment, the second ciphertext segment, and the private key; The first ciphertext segment and the second ciphertext segment are recombined to obtain the initial ciphertext; The initial information is obtained by decrypting the initial ciphertext using the private key.

[0011] In one embodiment, after the step of receiving the service request containing the target ciphertext sent by the front end, the method further includes: The business request is obtained through aspect-oriented programming, the custom annotations in the business request are identified, and the target ciphertext is extracted from the business request according to the annotation type of the custom annotation. When the annotation type is identified as a method annotation, the entire request parameters of the business request are treated as the target ciphertext. When the annotation type is identified as a field annotation, the field content of the annotated field is extracted from the request parameters of the business request as the target ciphertext.

[0012] Furthermore, to achieve the above objectives, this application also proposes a dynamic encryption / decryption device for information, which includes: The initial encryption module is used to encrypt the initial information using a public key to obtain the initial ciphertext; The target encryption module is used to generate an insertion position index based on the ciphertext length of the initial ciphertext, split and concatenate the ciphertext based on the insertion position index to generate the target ciphertext, and send a business request containing the target ciphertext to the backend so that the backend can decrypt and restore the target ciphertext to obtain the initial information.

[0013] In addition, to achieve the above objectives, this application also proposes a dynamic encryption and decryption device for information, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the dynamic encryption and decryption method for information as described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the dynamic encryption and decryption method for information as described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the dynamic encryption and decryption method for information as described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: This application proposes a dynamic encryption / decryption method, apparatus, device, and storage medium for information, applied at the front end. Initial information is encrypted using a public key to obtain initial ciphertext. An insertion position index is generated based on the ciphertext length of the initial ciphertext. The ciphertext is then split and concatenated based on the insertion position index to generate a target ciphertext. A service request containing the target ciphertext is sent to the back end, whereby the back end decrypts the target ciphertext to restore the initial information. This application effectively solves the security risks associated with static key storage by using a public key to encrypt and generate initial ciphertext at the front end and dynamically generating an insertion position index based on its length to split and hide the private key within the target ciphertext. This significantly improves the security of data transmission without requiring additional key management configuration. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating the dynamic encryption / decryption method for information in this application, provided in Embodiment 1; Figure 2 This is a schematic diagram of the module structure of the dynamic encryption / decryption device for information in an embodiment of this application; Figure 3 This is a schematic diagram of the device structure of the hardware operating environment involved in the dynamic encryption and decryption method of information in the embodiments of this application.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] The main solution of this application embodiment is as follows: Applied to the front end: Initial information is encrypted using a public key to obtain initial ciphertext; an insertion position index is generated based on the ciphertext length of the initial ciphertext; the target ciphertext is generated by splitting and concatenating based on the insertion position index; a service request containing the target ciphertext is sent to the back end, so that the back end can decrypt and restore the target ciphertext to obtain the initial information. Applied to the back end: A service request containing target ciphertext sent by the front end is received. The target ciphertext is obtained by the front end encrypting the initial information using a public key, generating an insertion position index based on the ciphertext length of the initial ciphertext, and splitting and concatenating based on the insertion position index; the target ciphertext in the service request is decrypted and restored to obtain the initial information.

[0024] In this embodiment, for ease of description, the following description will focus on a dynamic encryption / decryption device for information.

[0025] In the data interaction and storage process of information systems, encrypting sensitive information is a crucial means of ensuring data security. Currently, mainstream encryption and decryption solutions in the industry typically employ a combination of asymmetric and symmetric encryption. Developers manually call pre-packaged encryption utility classes within the business code to encrypt and decrypt sensitive fields or entire message segments, and the keys used are statically configured in the system's configuration file or database. However, the aforementioned existing technologies suffer from a significant security vulnerability due to static key storage: because the keys are permanently fixed and typically hard-coded into configuration files or databases, if the storage medium or configuration file is leaked, attackers can use this static key to decrypt all historical encrypted data in bulk, threatening the security of data assets.

[0026] This application provides a solution that effectively solves the security risks caused by static key storage by using public key encryption to generate initial ciphertext at the front end and dynamically generating insertion position subscripts according to its length to split and hide the private key in the target ciphertext. This significantly improves the security of data transmission without the need for additional key management configuration.

[0027] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or a dynamic encryption / decryption device capable of performing the above functions. The following description uses a dynamic encryption / decryption device as an example to illustrate this embodiment and the subsequent embodiments.

[0028] Based on this, embodiments of this application provide a method for dynamic encryption and decryption of information, referring to... Figure 1 , Figure 1This is a flowchart illustrating the first embodiment of the dynamic encryption / decryption method for information in this application.

[0029] In this embodiment, the dynamic encryption / decryption method for information is applied to the front end, and the dynamic encryption / decryption method for information includes steps S11~S12: Step S11: Encrypt the initial information using the public key to obtain the initial ciphertext.

[0030] It should be noted that the public key refers to the key used to encrypt the original data in a symmetric encryption algorithm. In this embodiment, the encryption key of the SM4 commercial block symmetric encryption algorithm is used. The SM4 algorithm is issued by the State Cryptography Administration, with a block length and key length of 128 bits (16 bytes). Based on the Feistel network structure, it adopts a 32-round nonlinear iterative mechanism. In each round, the round key is used to obfuscate and spread the data. The core operations include modulo-2 addition (XOR operation), cyclic shift, and S-box substitution. Initial information refers to sensitive business data that the front end needs to transmit to the back end, including but not limited to user identity information, account information, transaction amounts, and other data content that needs to be kept confidential. Initial ciphertext refers to the string that cannot be directly read after the initial information is mathematically transformed by the encryption algorithm. Its length is related to the block processing method and padding rules of the initial information.

[0031] Understandably, the purpose of this step is to convert sensitive information to be transmitted into ciphertext, preventing its direct leakage after illegal interception during transmission. Using public-key encryption, the original plaintext data undergoes 32 rounds of iterative computation and reversal processing using the SM4 algorithm, outputting 128-bit block ciphertext of the same length as the plaintext. If the plaintext length exceeds 128 bits, it is padded and encrypted group by group, ultimately concatenating to form the complete initial ciphertext. The effect of this step is that even if the transmission channel is intercepted, attackers cannot directly recover the original sensitive information from the ciphertext, thus establishing the first line of security for data transmission.

[0032] Specifically, in the first embodiment of this application, a key generation utility class is called to dynamically generate an SM4 key pair. The public key in this key pair is directly used for encryption, while the private key is temporarily stored in memory for subsequent steps. The advantage of this method is that the key is bound to the request and becomes invalid after a single use, avoiding the risk of long-term exposure of static keys. In the second embodiment of this application, a key generated by a hardware security module is obtained through an encryption service interface for encryption. The advantage of this method is that the key generation process is completed in a physically isolated environment, further improving key security. Before encryption, the initial information is preprocessed, including character encoding unification (e.g., unification to UTF-8 encoding) and length padding (using PKCS7 padding to ensure the data length is an integer multiple of 16 bytes). The advantage of this method is that it ensures the alignment requirements of SM4 block encryption and avoids decryption failure caused by block misalignment. For example, after dynamically generating the key, it is managed through HSM, and the initial information is preprocessed and padded simultaneously, achieving the technical effect of dual protection of dynamic keys and hardware-level security.

[0033] For example, the front end needs to transmit the user's bank card number "6222021234567890123" to the back end. The data security processing system calls the SM4 key generation tool to generate a 16-byte random key as the public key (e.g., hexadecimal representation "3A7F9E2B8C1D4E5F6A0B7C8D9E1F2A3"). This public key is used to encrypt the bank card number using SM4. Since the bank card number string length is 19 bytes, which is less than a multiple of 16 bytes, the system uses PKCS7 padding to add 13 bytes (each byte with a value of 0x0D) to the end, making the total length 32 bytes (two blocks). After 32 rounds of iterative computation of the SM4 algorithm, the initial ciphertext of 32 bytes is output (e.g., hexadecimal representation "7E3A9F2B... (64 hexadecimal characters in total)").

[0034] Step S12: Generate an insertion position index based on the ciphertext length of the initial ciphertext, split and concatenate the ciphertext based on the insertion position index to generate the target ciphertext, generate an insertion position index based on the ciphertext length of the initial ciphertext, split and concatenate the ciphertext based on the insertion position index to generate the target ciphertext, and send a service request containing the target ciphertext to the backend so that the backend can decrypt and restore the target ciphertext to obtain the initial information.

[0035] It should be noted that the ciphertext length refers to the number of characters or bytes occupied by the initial ciphertext string. In this embodiment, character length is used as the unit of measurement. The insertion position index refers to a selected split position in the initial ciphertext string, which divides the initial ciphertext into two parts. The value range of the index is determined by the ciphertext length, ensuring that neither part is empty after the split. The target ciphertext refers to the final transmission ciphertext formed after splitting, embedding key material, and splicing position information. Its structure includes the original ciphertext fragment, the embedded key, and position identification information.

[0036] Additionally, it's important to clarify that a business request refers to an HTTP request or other protocol request initiated by the frontend to the backend, containing business data. It typically includes request headers, request parameters, and a request body. The backend refers to the server-side system that receives and processes frontend requests, responsible for business logic processing and data persistence. Decryption and restoration refers to the backend's reverse operation, separating the key and ciphertext from the target ciphertext, and using the key to decrypt the ciphertext to recover the original information.

[0037] Understandably, the purpose of this step is to hide the encryption key within the ciphertext during transmission, avoiding the risk of key leakage caused by the key being transmitted separately from the ciphertext. By generating a randomly inserted position index, the initial ciphertext is split into two segments, with the private key embedded in the middle, and the position information appended to the end, making the key and ciphertext an inseparable transmission unit. Even if an attacker intercepts the target ciphertext, they cannot directly identify the key's position and length; they must use the correct parsing process to separate the key and ciphertext. This achieves configuration-free key transmission, eliminating the security risks associated with storing or transmitting the key separately in traditional schemes. By embedding the target ciphertext into the standard parameter structure of the business request, the frontend does not need to change its existing request sending method; it only needs to add an encryption processing step during the parameter construction stage. After receiving the request, the backend extracts the target ciphertext according to the parsing rules agreed upon with the frontend and performs decryption. The encrypted transmission process is transparent to the upper-layer business logic, and the way the frontend sends requests remains consistent with the unencrypted version, reducing the intrusiveness of security modifications to the existing business system.

[0038] Specifically, the character length N of the initial ciphertext is obtained, and uniformly distributed random integers are generated within the closed interval [1, N-1] as insertion position indices. The advantage of this method is that the index positions are completely random, and the index positions of different requests are unpredictable, increasing the difficulty of reverse analysis. Before generating the indices, the ciphertext is hashed, and specific bits of the hash value are used as random number seeds input into the pseudo-random number generator. The advantage of this method is that the index generation is related to the ciphertext content, and the ciphertext will be different for the same plaintext under different encryption methods due to different keys, further enhancing unpredictability. Different embedding modes are used when splitting and concatenating, including direct string concatenation mode, memory concatenation mode based on byte arrays, and streaming processing mode. The advantage of this method is that it can adapt to different data scales and processing performance requirements. For example, after determining the random seed based on the ciphertext hash to generate the index, the memory concatenation method based on byte arrays is used to process large-scale data, which can achieve a technical effect that balances position randomness and processing efficiency.

[0039] Furthermore, in the first embodiment of this application, the target ciphertext is sent as a field value in the JSON format request body. The advantage of this approach is its clear structure, facilitating backend parsing and location. In the second embodiment of this application, the target ciphertext is sent as form data or query string. The advantage of this approach is its compatibility with traditional form submission scenarios. Additionally, a custom identifier field can be added to the request header to indicate that the current request contains encrypted content. The advantage of this approach is that the backend can quickly identify encrypted requests through the request header and initiate the decryption process in advance. The above embodiments can be used in combination. For example, embedding the target ciphertext in the JSON request body while adding an encryption identifier in the request header can achieve the dual benefits of data location and process identification.

[0040] For example, the initial ciphertext has a character length of 64 (32 bytes in hexadecimal representation). The data security processing system generates a random index within the range [1, 63], let's say 35. The system splits the initial ciphertext into a first segment (the first 35 characters) and a second segment (the last 29 characters) starting from the 35th character. Assuming the private key is 16 bytes (32 hexadecimal characters), the system concatenates the first segment, the private key, and the second segment in sequence to obtain the third ciphertext segment. Then, the index 35 is formatted as a fixed-length 3-digit string "035" and appended to the end of the third ciphertext segment to form the final target ciphertext. Further, the frontend constructs a POST request with a JSON body in the format {"encryptedData": "7E3A9F2B... (first segment 35 characters) 3A7F9E2B... (private key 32 characters) 8C1D4E5F... (second segment 29 characters) 035"}, and sends it to the backend's / api / transfer interface via the HTTP protocol. After receiving the request, the backend extracts the target ciphertext from the encryptedData field and starts the decryption process.

[0041] This embodiment utilizes the above-described scheme, where the front-end dynamically generates an encryption key pair with each request. Sensitive information is encrypted using the public key, and the private key is embedded within the ciphertext for transmission. The back-end receives the data, separates the key, and decrypts it. This technical solution addresses the key leakage risk and storage cost issues associated with traditional static key configuration. By dynamically binding keys to requests and embedding keys within ciphertext during transmission, it achieves secure transmission without the need for pre-configuration and storage of keys. Simultaneously, it maintains the standard interface for front-end and back-end communication, reducing the intrusion of security modifications into the existing business architecture.

[0042] Based on the above implementation scheme, in one feasible implementation, the step of encrypting the initial information using a public key to obtain the initial ciphertext includes S21~S22: Step S21: Dynamically generate the symmetric encryption key pair for the current request, the key pair including the public key and the private key.

[0043] It should be noted that a symmetric encryption key pair refers to the encryption key and decryption key generated when using a symmetric encryption algorithm. In a symmetric encryption system, the encryption key and decryption key are the same or can be derived from each other through simple derivation. In this embodiment, the SM4 algorithm is used, and its key length is 128 bits (16 bytes). Therefore, the public key and private key are numerically identical, but are used in different operational stages at the encryption and decryption ends, respectively. In this step, the public key refers to the key instance used to perform the encryption operation, and the private key refers to the key instance used to perform the decryption operation. Both originate from the same key material but are used at different stages.

[0044] Understandably, the purpose of this step is to generate a unique encryption key for each independent business request, achieving request-level key isolation. Traditional solutions use static keys, where all requests share the same key. Once this key is leaked, all historical and future data are at risk. This step, through a dynamic generation mechanism, ensures that each request has an independent key space. The keys for different requests are mathematically independent and cannot be derived. The effect of this step is that even if an attacker obtains the key for one request, that key cannot be used to decrypt the ciphertext of other requests, controlling the security risk to the scope of a single request and significantly improving the overall security of the system.

[0045] Specifically, in the first embodiment of this application, the system calls Java's SecureRandom class (secure random number generator) to generate a 16-byte random number as the key seed, and then generates 32 round keys using the SM4 key expansion algorithm. The advantage of this method is that it uses a cryptographically secure random number generator to ensure the unpredictability of the key. In the second embodiment of this application, the system obtains a physical entropy source through a hardware random number generator to generate the key. The advantage of this method is that the key generation process is based on physical noise rather than software algorithms, resulting in stronger anti-prediction capabilities. In the third embodiment of this application, after generating the key, the system associates and binds it with the unique identifier of the request (such as request ID, timestamp, session identifier) ​​to establish a key lifecycle management table. The advantage of this method is that it achieves traceability and controllable destruction of the key. The above embodiments can be used in combination. For example, after generating the key seed through HRNG, it can be bound to the request ID and stored in a memory-mapped table, and an automatic timeout clearing mechanism can be set to achieve the technical effect of dual protection of physical-level randomness and request-level isolation.

[0046] For example, when the front end initiates a transfer request, the data security processing system calls a secure random number generator to generate a 16-byte random array [0x3A, 0x7F, 0x9E, 0x2B, 0x8C, 0x1D, 0x4E, 0x5F, 0x6A, 0x0B, 0x7C, 0x8D, 0x9E, 0x1F, 0x2A, 0x3B], which is then expanded into 32 round keys using the SM4 key arrangement algorithm. The system uses the original 16-byte key simultaneously as both the public key (used for encryption in the current step) and the private key (temporarily stored in memory for subsequent embedding of the target ciphertext).

[0047] Step S22: Use the public key to encrypt the initial information using a symmetric encryption algorithm to obtain the initial ciphertext.

[0048] It should be noted that symmetric encryption algorithms refer to cryptographic algorithms that use the same key for both encryption and decryption. This embodiment specifically employs the SM4 commercial block symmetric encryption algorithm, which has a block length of 128 bits and processes data in 32-bit words. Data obfuscation and diffusion are achieved through 32 rounds of nonlinear iteration. The core operations of the SM4 algorithm include modulo-2 addition (XOR), cyclic shift, and S-box substitution. The S-box is a 16×16 fixed-byte substitution table used to provide nonlinear transformations.

[0049] Understandably, the purpose of this step is to use the generated dynamic public key to mathematically transform the initial information, converting it from readable plaintext into ciphertext that is not directly understandable. The SM4 algorithm iterates through 32 rounds, each round performing multi-level obfuscation and diffusion processing on the data, ensuring that each bit of the ciphertext has a complex non-linear relationship with each bit of the plaintext and each bit of the key. The effect of this step is that even if an attacker possesses a large number of plaintext-ciphertext pairs, they cannot deduce the key through statistical analysis or linear approximation, thus guaranteeing encryption strength.

[0050] Specifically, in the first embodiment of this application, the system uses an electronic codebook mode for block encryption, with each block encrypted independently. The advantage of this method is its simplicity and parallel processing capability. In the second embodiment, the system uses a cipher block chaining mode, performing an XOR operation between the plaintext of the current block and the ciphertext of the previous block before encryption. The advantage of this method is that identical plaintext blocks will produce different ciphertexts, resisting pattern attacks. In the third embodiment, for data exceeding the length of a single block, the system first performs PKCS7 padding to make the length a multiple of 16 bytes, then encrypts and concatenates the blocks one by one. The advantage of this method is its adaptability to input data of arbitrary length. The above embodiments can be used in combination. For example, using CBC mode with PKCS7 padding and selecting the initial vector as the timestamp hash value of the current request can achieve a balance between block correlation and length adaptability.

[0051] For example, the initial information is the bank card number "6222021234567890123", which is encoded in UTF-8 and padded with PKCS7 to form 32 bytes of data. The data security processing system uses the public key generated in step S10 to perform 32 rounds of iterative computation using the SM4 algorithm. In the first round, the 128-bit plaintext is divided into four 32-bit words (X0, X1, X2, X3), and the round function F(Xi, Xi+1,Xi+2, Xi+3, rki) = Xi ⊕ T(Xi+1 ⊕ Xi+2 ⊕ Xi+3 ⊕ rki) is calculated. The T transform includes a nonlinear τ transform and a linear L transform. After 32 rounds, the output is reversed to obtain 128-bit ciphertext blocks, which are finally concatenated into a 64-character hexadecimal initial ciphertext.

[0052] This embodiment, through the above-described scheme, dynamically generates request-level symmetric key pairs and uses these key pairs to perform SM4 symmetric encryption, achieving strict binding between the key and the request and standardized execution of the encryption algorithm. This technical solution addresses the security vulnerabilities of static key storage and configuration. By employing a "one-time pad" key management strategy, it limits the potential impact of security leaks to a single request. Simultaneously, the use of the SM4 algorithm, recognized by the State Cryptography Administration, ensures the autonomous controllability and security of the encryption process.

[0053] Based on the above implementation scheme, in one feasible implementation, the step of generating an insertion position index based on the ciphertext length of the initial ciphertext, and splitting and splicing the ciphertext based on the insertion position index to generate the target ciphertext includes S31~S33: Step S31: Obtain the character length of the initial ciphertext, and determine the insertion position index within the character length range.

[0054] It should be noted that character length refers to the number of characters in the initial ciphertext when represented as a string. When the ciphertext is encoded in hexadecimal, each byte corresponds to 2 hexadecimal characters, therefore the character length is twice the byte length. The character length range refers to the range of valid values ​​for the insertion position index. To ensure that neither of the two ciphertext segments after splitting is empty, the index value range should exclude the start and end positions, forming a valid internal segmentation range.

[0055] Understandably, the purpose of this step is to determine a random split point for subsequent ciphertext splitting. By dynamically determining the index range based on the ciphertext length, a valid split position is ensured regardless of changes in the ciphertext length. The introduction of random indices ensures that the target ciphertext structure generated from the same plaintext in different requests is completely different. Attackers cannot deduce the fixed position of the key by comparing multiple target ciphertexts. This step increases the unpredictability of the target ciphertext structure and enhances its resistance to analysis.

[0056] Specifically, in the first embodiment of this application, the system calls a random number generator to generate uniformly distributed integers as indices within the range [1, N-1], where N is the character length of the initial ciphertext. This method is advantageous because it is simple to implement and provides a uniform distribution. In the second embodiment, the system performs a CRC32 checksum calculation on the ciphertext before generating the indices, using the checksum as a random number seed to associate the indices with the ciphertext content. This method increases the deterministic association of the indices, preventing the predictability of a purely random generator. In the third embodiment, the system restricts the indices to a specific range of values ​​(e.g., no more than 3 decimal digits) for subsequent formatting into a fixed length. This method controls the length of the position marker at the end of the target ciphertext, facilitating backend parsing. The above embodiments can be used in combination. For example, after generating indices based on the CRC32 seed, if the indices exceed 3 decimal digits, they are truncated by modulo, achieving a balance between content association and format controllability.

[0057] For example, the initial ciphertext has a character length of 64, and the data security processing system determines the character length range to be [1, 63]. The system calls a random number generator, assuming it generates a random integer 35 as the insertion position index. This index satisfies 1 ≤ 35 ≤ 63, which is within the valid range and can be used for subsequent splitting.

[0058] Step S32: Split the initial ciphertext into a first ciphertext segment and a second ciphertext segment according to the insertion position index, and concatenate the first ciphertext segment, the private key and the second ciphertext segment in sequence to obtain a third ciphertext segment.

[0059] It should be noted that the first ciphertext segment refers to the substring from the beginning of the initial ciphertext to the insertion index, containing the specified number of characters. The second ciphertext segment refers to the substring from the insertion index to the end of the initial ciphertext, containing the remaining characters. The third ciphertext segment is a new string formed by concatenating the first ciphertext segment, the private key, and the second ciphertext segment in sequence, with a length equal to the sum of the length of the initial ciphertext and the length of the private key.

[0060] Understandably, the purpose of this step is to hide the private key within the ciphertext. Through splitting, embedding, and concatenating operations, the private key becomes part of the ciphertext structure rather than being transmitted independently. The first and second ciphertext segments are essentially two parts of the same initial ciphertext. After the private key is embedded, the third ciphertext segment appears to be a continuous long string, making it impossible to directly distinguish which parts are the original ciphertext and which are the embedded key. The effect of this step is to achieve a physical fusion of the key and ciphertext. Even if an attacker intercepts the third ciphertext segment, they cannot directly identify the boundaries of the key and must use the correct index information to locate the key's position.

[0061] Specifically, in the first embodiment of this application, the system uses string slicing operations for splitting and concatenating, directly manipulating character sequences. The advantage of this method is its intuitiveness and ease of debugging. In the second embodiment, the system uses byte array operations to reorganize data at the memory level. The advantage of this method is that it avoids the performance loss caused by string encoding conversion. In the third embodiment, the system adds delimiters (such as specific invisible characters) during concatenation to assist internal recognition; however, this method reduces security and is therefore not recommended for high-security scenarios, only suitable for debugging environments. The first and second embodiments can be used in combination. For example, string operations can be used to ensure readability with small data volumes, while byte array operations can be switched to improve performance with large data volumes, achieving a balance between simplicity and processing efficiency.

[0062] For example, the initial ciphertext is a 64-character hexadecimal string: The insertion position is "7E3A9F2B8C1D4E5F6A0B7C8D9E1F2A30B1C2D3E4F5A6B7C8D9E0F1A2B3C4D5E6F7A8B9C0D1E2F3A4B5C6D7E8F9A0B1C2D3E4F5A6B7C8D9E0F1A2B3", with an insertion index of 35.

[0063] The system splits the message at the 35th character, with the first ciphertext segment consisting of the first 35 characters: "7E3A9F2B8C1D4E5F6A0B7C8D9E1F2A30B1C2D3E4F5A6B7C8D9E0F1A2B3C4D5E6F7A8B9C0D1E2F3A4B5".

[0064] The second ciphertext segment consists of the last 29 characters: "C6D7E8F9A0B1C2D3E4F5A6B7C8D9E0F1A2B3".

[0065] The private key is a 32-character hexadecimal string: "3A7F9E2B8C1D4E5F6A0B7C8D9E1F2A3".

[0066] The system concatenates the three parts in sequence to obtain the third ciphertext segment, with a total length of 35+32+29=96 characters.

[0067] Step S33: Concatenate the formatted insertion position subscript and the third ciphertext segment to generate the target ciphertext.

[0068] It should be noted that formatting refers to converting the insertion position index into a string representation with a fixed length and uniform format, typically including operations such as converting numbers to strings, length padding, and encoding standardization. The target ciphertext refers to the final transmission string containing the third ciphertext segment and the formatted index; it is a complete encrypted data unit sent from the front end to the back end.

[0069] Understandably, the purpose of this step is to append the segmentation location information to the end of the ciphertext, enabling the backend to reverse-engineer the segmentation operation based on this information. By formatting the index to a fixed length, the backend can accurately extract the index value without needing additional length information during parsing, simplifying the protocol design. The effect of this step is that the location information becomes an inherent component of the target ciphertext, transmitted along with it, avoiding the protocol complexity and information leakage risks associated with transmitting location information separately.

[0070] Specifically, the insertion position index is formatted by converting the index into a string in a specified base and padding the string with zeros at specified positions to a fixed length. For example, if the default formatted insertion position index is a three-digit number, the insertion position index is converted into a decimal string, and if it is less than three digits, zeros are padded to the left to bring it to three digits.

[0071] For example, the insertion position index is 35. The data security processing system converts it to the decimal string "35", pads it with zeros on the left to a fixed length of 3 digits, resulting in the formatted index "035". The system appends "035" to the end of the third ciphertext segment to generate the final target ciphertext. The total length of the target ciphertext is 96 + 3 = 99 characters, with the structure: [First ciphertext segment 35 characters][Private key 32 characters][Second ciphertext segment 29 characters][Index 035].

[0072] This embodiment, through the above-described scheme, constructs a clear and secure ciphertext format by determining a random index based on the ciphertext length, splitting the initial ciphertext into two segments and embedding the private key in the middle, and finally appending a formatted index to the end. This technical solution solves the risk of key leakage during independent transmission. By hiding the key within the ciphertext and binding it to a location identifier, it achieves inseparable transmission of the key and ciphertext. Furthermore, the random index increases the dynamic variability of the ciphertext structure, enhancing its resistance to reverse engineering.

[0073] Based on the above implementation scheme, in one feasible implementation, the dynamic encryption / decryption method for the information is applied to the backend, and the dynamic encryption / decryption method for the information includes S41~S42: Step S41: Receive a service request containing target ciphertext sent by the front end. The target ciphertext is obtained by the front end encrypting the initial information with the public key to obtain the initial ciphertext. An insertion position index is generated according to the ciphertext length of the initial ciphertext, and the data is split and concatenated based on the insertion position index.

[0074] It should be noted that a business request refers to a data transmission request initiated by the frontend to the backend via HTTP, HTTPS, or other application layer protocols. It typically includes components such as a request method, URL, request headers, and request body. The target ciphertext refers to an encrypted transmission unit generated by the frontend that contains an embedded private key and location identifier. Its structure is: first ciphertext segment + private key + second ciphertext segment + formatted insertion position index.

[0075] Understandably, the purpose of this step is to establish an entry point for the backend to receive encrypted data. The backend receives requests from the frontend through a standard network listening interface, extracts the target ciphertext from the request payload, and prepares input data for subsequent decryption operations. Since the generation of the target ciphertext is completed independently by the frontend, the backend does not need to know the key information of this request in advance; it only needs to parse the request according to the agreed protocol format. The effect of this step is to achieve configuration-free key reception, eliminating the need for the backend to maintain a key store or key negotiation state machine, thus simplifying the system architecture.

[0076] Specifically, in the first embodiment of this application, the backend receives POST requests through a RESTful interface and extracts the target ciphertext from a specified field in the JSON request body. The advantage of this approach is its clear structure and compatibility with existing web service systems. In the second embodiment, the backend receives asynchronous messages sent by the frontend through a message queue (such as Kafka or RabbitMQ) and extracts the target ciphertext from the message body. The advantage of this approach is that it decouples the direct connection between the frontend and backend, supports high concurrency, and handles peak and valley loads. In the third embodiment, the backend receives requests through binary protocols such as gRPC and parses the target ciphertext from the Protobuf message structure. The advantage of this approach is its high transmission efficiency and low serialization overhead. The above embodiments can be used in combination; for example, providing a RESTful interface to receive synchronous requests externally while processing them asynchronously internally through a message queue can achieve a balance between interface compatibility and processing scalability.

[0077] For example, the backend data security processing system listens to the / api / secure / transfer interface and receives an HTTP POST request sent by the frontend. The request body is {"requestId": "REQ20240513001", "encryptedPayload": "7E3A9F2B...(first ciphertext segment) 3A7F9E2B...(private key) 8C1D4E5F...(second ciphertext segment) 035"}. The system extracts the target ciphertext from the encryptedPayload field and prepares to enter the decryption process.

[0078] Step S42: Decrypt and restore the target ciphertext in the service request to obtain the initial information.

[0079] It should be noted that decryption and restoration refers to the backend performing the reverse sequence of operations as the frontend encryption process. This includes steps such as separating the location identifier from the target ciphertext, locating the private key, extracting the ciphertext segment, reconstructing the initial ciphertext, and decrypting with the private key, ultimately restoring the original sensitive information sent by the frontend.

[0080] Understandably, the purpose of this step is to restore the encrypted data transmitted from the front end to a processable plaintext form, enabling the business logic to execute normally. Decryption and restoration are the mathematical inverse of the front-end encryption process; using the correct key and algorithm parameters, the ciphertext is converted back to plaintext. Because the front end uses a dynamically generated request-level key during encryption, the back end must extract this key from the target ciphertext to successfully decrypt. The effect of this step is that the decryption operation depends on the correct structure of the target ciphertext; any tampering with the target ciphertext will lead to key extraction failure or incorrect decryption results, thus providing an indirect mechanism for verifying transmission integrity.

[0081] Specifically, in the first embodiment of this application, the system performs format verification on the target ciphertext before decryption, including length check, character set verification, and structural integrity verification. The advantage of this method is that it can identify malformed input in advance and avoid invalid calculations. At the same time, a timeout mechanism is introduced when performing decryption. If a certain step is not completed within a limited time, the process is terminated and the exception is recorded. The advantage of this method is that it can prevent resource exhaustion attacks.

[0082] For example, the data security processing system extracts 3 characters from the end of the target ciphertext to obtain "035", removes leading zeros, and restores the insertion position index 35. Starting from the 35th character position of the target ciphertext, the system extracts 32 characters forward to obtain the private key "3A7F9E2B...". The 35 characters before the private key and the 29 characters after the private key are concatenated to obtain the initial ciphertext of 64 characters. The SM4 decryption algorithm is then executed on the initial ciphertext using the private key. After 32 rounds of reverse iteration, the original plaintext "6222021234567890123" is output.

[0083] This embodiment, through the above-described scheme, enables the backend to autonomously extract the key from the data transmitted by the frontend and complete decryption without the need for pre-configuration of the key, by receiving a business request containing the target ciphertext and performing decryption and restoration. This technical solution solves the security risks and configuration complexities of the traditional solution where the backend needs to maintain a static keystore. Through a self-contained transmission mechanism that embeds the key into the ciphertext, it achieves configuration-free decryption capabilities for the backend while maintaining compatibility with standard request processing procedures.

[0084] Based on the above implementation scheme, in one feasible implementation, the step of decrypting and restoring the target ciphertext in the service request to obtain the initial information includes S51~S52: Step S51: Parse the target ciphertext to obtain the insertion position index and the third ciphertext segment.

[0085] It should be noted that parsing refers to the process of separating different functional components from the target ciphertext according to its predetermined structure. The insertion position index refers to the ciphertext splitting position determined by the front-end when generating the target ciphertext, and is appended to the end of the target ciphertext in a formatted manner. The third ciphertext segment refers to the remaining part of the target ciphertext after removing the end position index, and includes the first ciphertext segment, the embedded private key, and the second ciphertext segment.

[0086] Understandably, the purpose of this step is to extract the control information (index) and main data (third ciphertext segment) required for decryption from the target ciphertext. The target ciphertext is a structured string, with a fixed-length storage location identifier at the end and the actual key embedding data at the beginning. Through parsing, the target ciphertext is decomposed into two logical parts, providing input for subsequent location and extraction operations. The effect of this step is to establish a conversion channel from raw transmitted data to structured information, providing a usable data foundation for subsequent key extraction and ciphertext reconstruction.

[0087] Specifically, in the first embodiment of this application, the system extracts a fixed-length string (e.g., 3 characters) from the end of the target ciphertext as a position identifier, and the remaining part serves as the third ciphertext segment. The advantage of this method is its simplicity, requiring only one extraction. In the second embodiment, the system scans backward from the end, finding the first non-numeric character as the dividing point; the left side is the third ciphertext segment, and the right side is the position identifier. The advantage of this method is its adaptability to position identifiers of variable length. In the third embodiment, the system performs a length check on the target ciphertext before parsing. If the length is less than a minimum threshold (e.g., private key length + position identifier length + 2), it is determined to be illegal input. The advantage of this method is its ability to filter obviously erroneous data in advance. The above embodiments can be used in combination; for example, performing length verification first and then using fixed-length extraction can achieve a balance between input validity verification and parsing determinism.

[0088] For example, the target ciphertext is "7E3A9F2B... (96 characters in total) 035", with a total length of 99 characters. The data security processing system extracts 3 characters from the end to obtain "035", and the remaining first 96 characters form the third ciphertext segment.

[0089] Step S52: Split and splice the third ciphertext segment according to the insertion position index to obtain the initial information.

[0090] It should be noted that in this step, splitting and reassembling refers to the reverse operation performed by the backend, which is the opposite of the frontend's splitting and reassembling. This includes a series of sub-operations such as locating the private key based on its index, extracting the private key, separating the two ciphertext segments, reassembling the initial ciphertext, and decrypting it using the private key. The initial information refers to the original sensitive data sent by the frontend, which is the final output of the decryption and restoration operation.

[0091] Understandably, the purpose of this step is to use the parsed location information to reverse-engineer the original data state at the time of encryption from the third ciphertext segment. When generating the target ciphertext, the front-end uses indices to split the initial ciphertext into two segments and inserts the private key in between. The back-end uses the same indices to locate the boundary of the private key in the third ciphertext segment, extracts the private key, and then merges the two ciphertext segments back into the initial ciphertext. Finally, it uses the private key to decrypt. The effect of this step is that, through the bidirectional use of indices (the front-end as the splitting point and the back-end as the positioning point), strict structural symmetry is achieved in the encryption and decryption processes, ensuring the reversibility and correctness of the decryption operation.

[0092] Specifically, the system performs ciphertext decryption according to the process of "locating the private key, extracting the private key, separating the ciphertext segment, reconstructing the ciphertext, and decrypting". After extracting the private key, the system performs validity verification on the private key, including length verification, character set verification, and matching check with known key patterns. The advantage of this method is that it can detect key extraction errors in advance. At the same time, after reconstructing the initial ciphertext, the system performs integrity verification, such as calculating whether the length of the reconstructed ciphertext is equal to the length of the original ciphertext. The advantage of this method is that it can verify the correctness of the reconstruction operation.

[0093] For example, the data security processing system, based on index 35, extracts 32 characters (the hexadecimal length of the SM4 key) from the 35th character position of the third ciphertext segment to obtain the private key "3A7F9E2B8C1D4E5F6A0B7C8D9E1F2A3". The 35 characters before the private key are used as the first ciphertext segment, and the 29 characters after the private key are used as the second ciphertext segment. These two segments are concatenated to obtain an initial ciphertext of 64 characters. The extracted private key is used to perform SM4 decryption on the initial ciphertext. After 32 rounds of reverse key operations and reversal processing, the original sensitive information is output.

[0094] This embodiment, through the above-described scheme, decomposes the decryption process into two hierarchical steps: "parse to obtain the index and the third ciphertext segment, and split and concatenate based on the index to obtain the initial information," establishing a clear conversion path from transmitted ciphertext to original information. This technical solution solves the problem of coupling between decryption logic and business code in traditional encryption and decryption schemes. Through a standardized parsing process, the decryption operation is executed independently of the business logic, improving the maintainability of the system and the consistency of secure operations.

[0095] Based on the above implementation scheme, in a feasible implementation, the step of splitting and splicing the third ciphertext segment according to the insertion position index to obtain the initial information includes S61~S63: Step S61: Split the third ciphertext segment using the insertion position index as the dividing point to obtain the first ciphertext segment, the second ciphertext segment, and the private key.

[0096] It should be noted that the split point refers to the coordinates used to define the starting position of the private key in the third ciphertext segment. Its value is equal to the insertion index, indicating the position offset by that number of characters from the beginning of the third ciphertext segment. The first ciphertext segment refers to the substring within the third ciphertext segment from the starting position to the split point, corresponding to the first ciphertext segment during front-end encryption. The second ciphertext segment refers to the substring within the third ciphertext segment from the split point after offsetting the key length to the end, corresponding to the second ciphertext segment during front-end encryption. The private key is the substring starting from the split point, with a length equal to the key length of the symmetric encryption algorithm; it is the key material for decrypting the initial ciphertext.

[0097] Understandably, the purpose of this step is to precisely separate three components from the third ciphertext segment: two original ciphertext segments and the embedded key. When generating the third ciphertext segment, the front end concatenates them in the order of "first ciphertext segment + private key + second ciphertext segment"; the back end uses the same indices and the known key length to reverse the process of "truncating the key length from the indices → dividing the remaining part into two segments." The effect of this step is that, through the dual constraints of indices and key length, precise location and extraction of the key within the ciphertext are achieved. Any incorrect indices or mismatched key lengths will lead to extraction failure, thus providing a structural integrity verification mechanism.

[0098] Specifically, in the first embodiment of this application, the system directly slices the string according to the index value, and extracts a fixed length (such as 32 hexadecimal characters of the SM4 key) as the private key from the index position; before extracting the private key, the system first verifies whether the total length of the third ciphertext segment satisfies the relationship of "index value + key length + remaining length"; after extracting the private key, the system performs format verification on the private key (such as whether it is a valid hexadecimal string and whether the length meets the algorithm requirements). The advantage of this method is that it ensures that the extracted key material can be used for subsequent decryption.

[0099] For example, the third ciphertext segment is 96 characters long, with an insertion index of 35, and the SM4 key has a hexadecimal character length of 32. The data security processing system verifies that 96 ≥ 35 + 32 = 67, satisfying the basic condition. Starting from the 35th character position (0-based index 34), the system extracts 32 characters backward to obtain the private key "3A7F9E2B8C1D4E5F6A0B7C8D9E1F2A3". The 35 characters before the 35th character constitute the first ciphertext segment, and the 29 characters after the 35 + 32 = 67th character constitute the second ciphertext segment.

[0100] Step S62: Reassemble the first ciphertext segment and the second ciphertext segment to obtain the initial ciphertext.

[0101] It should be noted that reassembly refers to reconnecting the separated first and second ciphertext segments in their original order to recover the initial ciphertext string used during front-end encryption. The initial ciphertext refers to the original ciphertext after the front-end has encrypted the initial information using the public key, before any splitting or embedding operations have been performed; it is the direct input to the decryption algorithm.

[0102] Understandably, the purpose of this step is to recover a valid ciphertext format that can be decrypted by the private key. During encryption, the front end uses the public key to encrypt the initial information to obtain initial ciphertext, then splits the initial ciphertext into two segments and inserts the private key in between. The back end needs to remove the embedded private key and reassemble the two segments into the complete initial ciphertext before it can be correctly decrypted using the extracted private key. The effect of this step is that the reassembly operation eliminates the structural transformation introduced by the front end for key transmission, restoring the ciphertext to a standard encrypted output format and providing the correct input for subsequent decryption operations.

[0103] Specifically, the first and second ciphertext segments are concatenated. Before concatenation, the system performs length checks on both segments to ensure the sum of their lengths equals the original ciphertext length. This method is advantageous in verifying the integrity of the reconstructed text. After concatenation, the system performs format checks on the reconstructed ciphertext, such as checking if it is a valid hexadecimal string and if its length is an integer multiple of the algorithm's grouping length. This method is advantageous in detecting reconstruction errors early. For example, by first checking the lengths of the two segments separately, then performing the concatenation, and finally verifying the format of the reconstructed ciphertext, a technical effect that balances segment correctness and overall validity can be achieved.

[0104] For example, the first ciphertext segment is a 35-character hexadecimal string, and the second ciphertext segment is a 29-character hexadecimal string. The data security processing system concatenates the two in sequence to obtain a 64-character reconstructed ciphertext. It is verified that 64 is an even number (meeting the hexadecimal encoding requirements), and 64 / 2 = 32 bytes, which is an integer multiple of the SM4 block length of 16 bytes (32 / 16 = 2 blocks), thus satisfying the decryption input requirements.

[0105] Step S63: Decrypt the initial ciphertext using the private key to obtain the initial information.

[0106] It should be noted that decryption calculation refers to the mathematical process of converting ciphertext into plaintext using the inverse operation of a symmetric encryption algorithm. For the SM4 algorithm, the decryption calculation uses the same algorithm structure as encryption, but the order of the round keys is reversed. That is, the round keys (rk0, rk1, ..., rk31) are used during encryption, and the round keys (rk31, rk30, ..., rk0) are used during decryption. The initial information refers to the original sensitive data sent by the front end, which is restored from the ciphertext state to readable plaintext after the decryption calculation.

[0107] Understandably, the purpose of this step is to use the private key extracted in step S10 to perform an inverse mathematical transformation on the initial ciphertext reconstructed in step S20, thereby recovering the original sensitive information. Since the front-end uses a dynamically generated request-level key for encryption, this key only exists in the target ciphertext of this request. The back-end must obtain this key through the correct parsing and extraction process to successfully decrypt. The effect of this step is to remove the mathematical protection relationship established during encryption, restoring the data to a processable plaintext state. Furthermore, due to the dynamic and one-time-use nature of the key, even if a decryption key is leaked in a particular instance, it will not affect the security of other requests.

[0108] Specifically, the system calls the SM4 decryption algorithm library, inputs the private key and initial ciphertext, and performs a standard 32-round reverse iterative decryption. The advantage of this method is that it utilizes a mature algorithm, ensuring both correctness and efficiency. Before decryption, the system performs key expansion on the private key to generate 32 reverse round keys, and then performs decryption operations round by round. The advantage of this method is that it allows control over each step of the decryption process, facilitating debugging and optimization. After decryption, the output result undergoes padding removal (e.g., PKCS7 depadding) and character encoding conversion (e.g., UTF-8 decoding). The advantage of this method is that it restores the original data format. For example, after calling the algorithm library to perform depadding and encoding conversion, the original sensitive information is finally output, achieving a technical effect that balances decryption correctness and format recovery.

[0109] For example, the data security processing system uses the private key "3A7F9E2B8C1D4E5F6A0B7C8D9E1F2A3" to perform SM4 decryption on an initial 64-character ciphertext. The system first expands the private key into 32 round keys, then performs 32 rounds of iterative operations on the ciphertext in the reverse order of encryption (rk31 to rk0). Each round performs a transformation with the same structure as the encryption round function but in reverse order of the round keys. After 32 rounds of reverse operations and reversal processing, 32 bytes of plaintext data are output. After removing PKCS7 padding (the last 13 bytes being 0x0D), the original bank card number "6222021234567890123" is obtained after UTF-8 decoding.

[0110] This embodiment, through the above-described scheme, establishes a four-step operation chain of "locating the segmentation point → splitting into three segments → reconstructing the two ciphertext segments → decrypting with the private key," transforming the general description in claim 5 into a precisely executable technical process. This technical solution solves the problems of ambiguous key positioning and non-standard ciphertext reconstruction in traditional decryption processes. By using the dual constraints of subscripts and key length, it achieves precise key positioning and standardized ciphertext reconstruction, ensuring the reversibility and reliability of the decryption operation.

[0111] Based on the above implementation scheme, in one feasible implementation, after the step of receiving the service request containing the target ciphertext sent by the front end, the method further includes steps S71 to S73: Step S71: Obtain the business request through aspect-oriented programming, identify the custom annotations in the business request, and extract the target ciphertext from the business request according to the annotation type of the custom annotations.

[0112] It should be noted that Aspect-Oriented Programming (AOP) is a software design paradigm that dynamically adds functionality to a program without modifying the source code, through pre-compilation or runtime dynamic proxies. In this embodiment, the AOP mechanism defines pointcuts to match requests carrying specific annotations, inserting cross-cutting logic (advice) before the request reaches the business processor, thus achieving automatic interception of security processing. Custom annotations refer to metadata tags defined by the system to identify the encryption scope and processing method, including method annotations at the method level and field annotations at the field level. Annotation type refers to the classification identifier of the custom annotation, used to distinguish between full-message encryption mode and single-field encryption mode.

[0113] Understandably, the purpose of this step is to establish an entry mechanism for the backend to automatically identify and process encrypted requests. In traditional solutions, encryption and decryption logic is scattered across various business code segments, requiring developers to manually call encryption utility classes, resulting in highly intrusive code and difficult maintenance. This step, through AOP aspect-based interception, decouples the security processing logic from the business code, allowing the framework to execute it uniformly at the front end of the request processing chain. Business developers only need to add annotations to methods or fields to trigger automatic encryption processing, without needing to concern themselves with the specific encryption and decryption implementation. The effect of this step is to decouple security logic from business logic, lower the barrier to entry for using security features, and improve code consistency and maintainability through centralized processing by the framework.

[0114] Specifically, the system uses the Spring AOP framework to define aspects, surrounding method calls annotated with @Encrypt or @Decrypt via @Around advice. The advantage of this approach is seamless integration with the Spring ecosystem and suitability for most Java Web applications. It also uses AspectJ compile-time weaving, weaving aspect logic into target classes during the compilation phase. This approach offers lower runtime overhead and better performance. Finally, it intercepts business requests using Java dynamic proxies or CGLIB bytecode generation. This approach is more versatile and does not depend on a specific framework. These implementation methods can be combined; for example, Spring AOP can be used for rapid development externally, while AspectJ compile-time weaving can be used for performance-sensitive scenarios, achieving a balance between development efficiency and runtime performance.

[0115] For example, the data security processing system is configured with a Spring AOP aspect, with the pointcut expression `@annotation(com.security.Encrypted)`, matching all methods annotated with `@Encrypted`. When the frontend sends a request to the `@Encrypted public Response transfer(Request req)` method, the AOP aspect intercepts the request before the method execution, recognizes the `@Encrypted` annotation at the method level, and triggers the decryption process.

[0116] Step S72: When the annotation type is identified as a method annotation, the entire request parameters of the business request are used as the target ciphertext.

[0117] It should be noted that method annotations are custom annotations applied to method declarations to indicate that the request corresponding to that method uses full-text encryption mode. Request parameters refer to all data content that serves as input parameters to the method in a business request; in RESTful APIs, this typically corresponds to the complete JSON or XML content of the request body.

[0118] Understandably, the purpose of this step is to establish ciphertext extraction rules under full-message encryption mode. When a business scenario requires protection of the entire request content (such as a complete transaction message or batch data upload), the front-end encrypts the entire request parameters before sending. After the back-end recognizes the method annotation, it decrypts the entire request parameter as the target ciphertext. The effect of this step is that it automatically routes to the full-message processing mode through annotation type, eliminating the need for developers to write additional extraction logic, and achieving a zero-intrusion security transformation of "annotation-driven, automatic processing".

[0119] Specifically, one approach is to read the complete byte stream of the HTTP request body as a string and directly use it as the target ciphertext input for decryption. This method is simple, direct, and results in no information loss. Another approach is to parse the request body into a specific object and then call the object's serialization method to regenerate the string as the target ciphertext. This method leverages existing serialization mechanisms. A third approach is to perform encoding verification on the request body before extraction (e.g., UTF-8, GBK) to ensure correct string conversion. This method avoids decryption failures caused by encoding errors. For example, identifying the encoding before reading the complete byte stream achieves a balance between data integrity and encoding correctness.

[0120] For example, the front end sends a POST request with the entire encrypted string "7E3A9F2B...035" in the request body. The data security processing system recognizes that the transfer method carries the @Encrypted annotation, extracts the entire request body as the target ciphertext, and proceeds to the decryption process.

[0121] Step S73: When the annotation type is identified as a field annotation, the field content of the annotated field is extracted from the request parameters of the business request as the target ciphertext.

[0122] It should be noted that field annotations are custom annotations applied to class fields (member variables) to indicate that the data corresponding to that field uses a single-field encryption mode. The content of the field annotated with a field annotation refers to the specific field value marked by field annotations such as @EncryptedField in the request parameter object, which is usually a string type.

[0123] Understandably, the purpose of this step is to establish ciphertext extraction rules under single-field encryption mode. When only certain sensitive fields (such as bank card numbers, ID card numbers, and mobile phone numbers) need to be protected in a business scenario, while the remaining fields are in plaintext, the front end only encrypts these sensitive fields. After the back end recognizes the field annotations, it accurately extracts the content of the annotated fields from the request parameters as the target ciphertext. The effect of this step is that it achieves fine-grained field-level encryption control, avoids the performance overhead and structural complexity brought by full-message encryption, and maintains the readability and debuggability of non-sensitive fields.

[0124] Specifically, one approach uses Java reflection to traverse all fields of the request parameter object, searching for members carrying field annotations and retrieving their values ​​as the target ciphertext. This method is advantageous because it is universal and applicable to any object structure. Another approach uses pre-compiled bytecode analysis to build a field annotation index table during class loading, allowing for direct table lookup at runtime. This avoids the performance overhead of runtime reflection. A third approach supports nested object structures, recursively searching for field annotations within nested objects. This approach is advantageous because it adapts to complex data models. By using reflection to extract data from simple objects and recursive reflection for complex nested objects, a balance between versatility and processing efficiency can be achieved.

[0125] For example, the request parameter object is an instance of the TransferRequest class, containing the fields requestId (without annotation), cardNo (with @EncryptedField), and amount (without annotation). The data security processing system uses reflection to traverse the fields, identifies cardNo with the @EncryptedField annotation, extracts its value "7E3A9F2B...035" as the target ciphertext, while requestId and amount remain in plaintext and are directly processed by the business logic.

[0126] This embodiment, through the aforementioned scheme, establishes a three-layer processing model of "aspect-based interception, annotation type identification, and method annotation for full message retrieval / field annotation for field retrieval," completely separating security processing logic from business code and achieving physical separation between the security layer and the business layer. This technical solution solves the problems of deep coupling and scattered maintenance between security logic and business code in traditional encryption and decryption schemes. Through framework-level unified interception and annotation-driven declarative configuration, developers can achieve a high level of data security protection in a zero-intrusion or low-intrusion manner, while maintaining the maintainability and scalability of the system.

[0127] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the dynamic encryption and decryption method of information in this application. Any simple transformations based on this technical concept are within the protection scope of this application.

[0128] This application also provides a dynamic encryption / decryption device for information; please refer to [reference needed]. Figure 2 The dynamic encryption / decryption device for the information includes: The initial encryption module 201 is used to encrypt the initial information using a public key to obtain the initial ciphertext; The target encryption module 202 is used to generate an insertion position index based on the ciphertext length of the initial ciphertext, split and concatenate the ciphertext based on the insertion position index to generate the target ciphertext, and send a service request containing the target ciphertext to the backend so that the backend can decrypt and restore the target ciphertext to obtain the initial information.

[0129] The dynamic encryption / decryption device for information provided in this application, employing the dynamic encryption / decryption method for information in the above embodiments, can solve the technical problem that static keys are insufficient for data encryption and decryption security. Compared with the prior art, the beneficial effects of the dynamic encryption / decryption device for information provided in this application are the same as those of the dynamic encryption / decryption method for information provided in the above embodiments, and other technical features in the dynamic encryption / decryption device for information are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0130] This application provides a dynamic encryption / decryption device for information, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the dynamic encryption / decryption method for information in the first embodiment described above.

[0131] The following is for reference. Figure 3 This document illustrates a structural diagram of a dynamic encryption / decryption device suitable for implementing embodiments of this application. The dynamic encryption / decryption device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 3 The dynamic encryption / decryption device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0132] like Figure 3As shown, the dynamic encryption / decryption device for information may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in the read-only memory 1002 or a program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the dynamic encryption / decryption device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the dynamic encryption / decryption device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows dynamic encryption / decryption devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0133] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0134] The dynamic encryption / decryption device provided in this application, employing the dynamic encryption / decryption method described in the above embodiments, can solve the technical problem that static keys are insufficient for data encryption and decryption security. Compared with the prior art, the beneficial effects of the dynamic encryption / decryption device provided in this application are the same as those of the dynamic encryption / decryption method described in the above embodiments, and other technical features of this dynamic encryption / decryption device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0135] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0136] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0137] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the dynamic encryption and decryption method for information in the above embodiments.

[0138] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More 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 or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0139] The aforementioned computer-readable storage medium may be included in a dynamic encryption / decryption device for information; or it may exist independently and not be assembled into a dynamic encryption / decryption device for information.

[0140] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by a dynamic encryption / decryption device, the dynamic encryption / decryption device causes the following: encrypts the initial information using a public key to obtain initial ciphertext; generates an insertion position index based on the ciphertext length of the initial ciphertext; splits and concatenates the ciphertext based on the insertion position index to generate target ciphertext; and sends a service request containing the target ciphertext to the backend so that the backend can decrypt and restore the target ciphertext to obtain the initial information.

[0141] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0142] 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 this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing 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 indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0143] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0144] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the dynamic encryption and decryption method for the aforementioned information. This solves the technical problem that static keys are insufficient for data encryption and decryption security. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the dynamic encryption and decryption method for information provided in the above embodiments, and will not be elaborated upon here.

[0145] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the dynamic encryption and decryption method for information as described above.

[0146] The computer program product provided in this application can solve the technical problem that static keys are insufficient for data encryption and decryption security. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the dynamic encryption and decryption method for information provided in the above embodiments, and will not be repeated here.

[0147] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for dynamically encrypting and decrypting information, characterized in that, The dynamic encryption / decryption method for information is applied to the front end, and the dynamic encryption / decryption method for information includes: The initial information is encrypted using the public key to obtain the initial ciphertext; An insertion position index is generated based on the ciphertext length of the initial ciphertext. The target ciphertext is generated by splitting and concatenating the ciphertext based on the insertion position index. A business request containing the target ciphertext is sent to the backend so that the backend can decrypt and restore the target ciphertext to obtain the initial information.

2. The dynamic encryption / decryption method for information as described in claim 1, characterized in that, The step of encrypting the initial information using a public key to obtain the initial ciphertext includes: Dynamically generate the symmetric encryption key pair for the current request, the key pair including the public key and the private key; The initial information is encrypted using the public key and a symmetric encryption algorithm to obtain the initial ciphertext.

3. The dynamic encryption / decryption method for information as described in claim 2, characterized in that, The step of generating an insertion position index based on the ciphertext length of the initial ciphertext, and then splitting and concatenating the ciphertext based on the insertion position index to generate the target ciphertext includes: Obtain the character length of the initial ciphertext, and determine the insertion position index within the character length range; The initial ciphertext is split into a first ciphertext segment and a second ciphertext segment according to the insertion position index. The first ciphertext segment, the private key, and the second ciphertext segment are then concatenated in sequence to obtain a third ciphertext segment. The formatted insertion position index and the third ciphertext segment are concatenated to generate the target ciphertext.

4. A method for dynamic encryption and decryption of information, characterized in that, The dynamic encryption / decryption method for the information is applied to the backend, and the dynamic encryption / decryption method for the information includes: The system receives a service request from the front end containing target ciphertext, which is obtained by the front end encrypting initial information using a public key. An insertion position index is generated based on the ciphertext length of the initial ciphertext, and the system is then split and concatenated based on the insertion position index. The target ciphertext in the business request is decrypted and restored to obtain the initial information.

5. The dynamic encryption / decryption method for information as described in claim 4, characterized in that, The step of decrypting and restoring the target ciphertext in the service request to obtain the initial information includes: The target ciphertext is parsed to obtain the insertion position index of the target ciphertext and the third ciphertext segment; The third ciphertext segment is split and spliced ​​according to the insertion position index to obtain the initial information.

6. The dynamic encryption / decryption method for information as described in claim 5, characterized in that, The step of splitting and concatenating the third ciphertext segment according to the insertion position index to obtain the initial information includes: The third ciphertext segment is split using the insertion position index as the dividing point to obtain the first ciphertext segment, the second ciphertext segment, and the private key; The first ciphertext segment and the second ciphertext segment are recombined to obtain the initial ciphertext; The initial information is obtained by decrypting the initial ciphertext using the private key.

7. The dynamic encryption and decryption method for information as described in claim 4, characterized in that, The step of receiving a service request containing the target ciphertext sent by the front end further includes: The business request is obtained through aspect-oriented programming, the custom annotations in the business request are identified, and the target ciphertext is extracted from the business request according to the annotation type of the custom annotation. When the annotation type is identified as a method annotation, the entire request parameters of the business request are treated as the target ciphertext. When the annotation type is identified as a field annotation, the field content of the annotated field is extracted from the request parameters of the business request as the target ciphertext.

8. A dynamic encryption / decryption device for information, characterized in that, The dynamic encryption / decryption device for the information includes: The initial encryption module is used to encrypt the initial information using a public key to obtain the initial ciphertext; The target encryption module is used to generate an insertion position index based on the ciphertext length of the initial ciphertext, split and concatenate the ciphertext based on the insertion position index to generate the target ciphertext, and send a business request containing the target ciphertext to the backend so that the backend can decrypt and restore the target ciphertext to obtain the initial information.

9. A dynamic encryption / decryption device for information, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the dynamic encryption / decryption method for information as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the dynamic encryption and decryption method for information as described in any one of claims 1 to 7.

Images