An AES file confusion encryption system based on dynamic slice reorganization

Abstract

This invention discloses an AES file obfuscation and encryption method, apparatus, system, storage medium, and computer program product based on dynamic slice reconstruction, belonging to the field of computer data security and file encryption technology. To address the problems of high memory consumption in existing whole-file encryption, insufficient obfuscation in sequential block encryption structures, incomplete file header recovery parameters, and weak enterprise authorization and decryption control capabilities, this invention obtains the file size, encryption level, and server key material of the file to be encrypted. It adaptively determines the block size based on the file size, generates a slice reconstruction seed based on the AES key, salt value, and file size, and uses this seed to construct a deterministic out-of-order block arrangement sequence. During encryption, a file header containing the key version, salt value, block size, number of blocks, original file size, slice reconstruction seed, and header checksum is generated. Each plaintext block is encrypted and authenticated using an independent initialization vector using AES-GCM, and then written to the ciphertext file in out-of-order order. During decryption, after server authorization is passed, the block arrangement sequence is reconstructed, and each block is authenticated, decrypted, and written back to its original logical offset position. This invention can improve the obfuscation capability of the physical structure of encrypted files while ensuring file recovery, reduce the memory footprint of large file encryption, and support key version management, authorized decryption, and automatic encryption based on enterprise policies.

Description

Technical Field

[0001] This invention belongs to the fields of computer data security, file encryption, terminal data leakage prevention, and enterprise-level key management technology. Specifically, it relates to an AES file obfuscation encryption method, device, system, storage medium, and computer program product based on dynamic slice recombination. It is applicable to enterprise terminal file encryption, sensitive data disk protection, authorized decryption control, pre-protection of file outgoing, and low memory usage encryption processing of large files. Background Technology

[0002] With the rapid increase in the number of local files on enterprise office terminals, R&D terminals, financial terminals, and mobile office devices, sensitive files such as contracts, source code, design drawings, financial forms, customer information, compressed files, and audio / video materials are often stored in plaintext on disks. Traditional file protection methods typically employ whole-file encryption, fixed-block encryption, or solutions relying solely on access control, which have several technical drawbacks in practical use. First, whole-file AES encryption usually requires reading or buffering large amounts of file data at once. For files of hundreds of MB or even GB, this can easily lead to excessive terminal memory usage, unstable encryption time, and difficulty in cleaning up temporary files after abnormal interruptions. Second, while fixed-order block encryption reduces single-time memory usage, the physical arrangement of ciphertext blocks still matches the logical order of the plaintext. Attackers can still infer the original file structure by analyzing the file header, file footer, fixed-format fragments, block boundaries, and ciphertext length distribution without decryption, resulting in insufficient obfuscation capabilities. Third, conventional file encryption formats often only record a single IV, authentication tag, or simple version information, lacking metadata such as the number of blocks, original file length, slice order seed, key version, and header integrity verification. This results in weak cross-version parsing, authorized decryption, corruption detection, and large file recovery capabilities. Fourth, some local encryption schemes rely on a single key source and lack server-side key version management, decryption authorization verification, usage limit, and expiration control, making it difficult to meet the closed-loop requirements for encryption, approval, auditing, and external distribution control in enterprise data leakage prevention scenarios. Therefore, there is an urgent need for a file obfuscation and encryption technology solution that can maintain the security of AES-certified encryption, improve file structure obfuscation capabilities through dynamic slicing and out-of-order reassembly, and also take into account low-memory processing of large files, verifiable recovery, key version control, and authorized decryption. Summary of the Invention

[0003] The technical problem this invention aims to solve is as follows: Addressing the issues of high memory consumption in existing whole-file encryption, insufficient obfuscation in fixed-order block encryption structures, incomplete file header metadata, and weak key and decryption authorization control capabilities, this invention provides an AES file obfuscation encryption method, apparatus, system, storage medium, and computer program product based on dynamic slice reassembly. This scheme adaptively determines the block granularity according to file size, generates a deterministic out-of-order seed based on key material, salt value, and file length, constructs a reproducible block arrangement sequence, and independently performs AES-GCM encryption authentication on each plaintext block before writing it into the ciphertext file in out-of-order order. This ensures recoverable authorized decryption while improving the non-correspondence between the physical structure of the ciphertext and the logical structure of the plaintext. The technical solution adopted by this invention to solve its technical problem is: an AES file obfuscation encryption method based on dynamic slice reassembly. The process includes the following steps: S01 File identification and key material acquisition: The terminal obtains the file path, file size, encryption level, and file identifier of the file to be encrypted, and requests key material corresponding to the encryption level or file identifier from the key server. The key material includes at least the AES encryption key, salt value, and key version. If the server-side key material cannot be obtained, the terminal refuses to perform encryption operations that require server-side key protection. S02 Adaptive slice parameter determination: The terminal determines the block size based on the size of the file to be encrypted. When the file size is less than or equal to the small file threshold, the whole file AES-GCM encryption format is used. When the file size is greater than the small file threshold, a dynamic slice reassembly mode is entered, and different block sizes are selected according to different file size ranges. The number of blocks and the effective byte length of the last block are calculated. S03 Out-of-order seed generation: The terminal uses a portion of the AES encryption key, a portion of the salt value, and the file size as seed input material. After hashing, a digest data is obtained, and a fixed-length value is extracted from the digest data as a slice reassembly seed, so that the same key material, salt value, and file size correspond to the same slice reassembly seed. S04 Dynamic Permutation Sequence Construction: The terminal initializes a pseudo-random number generator based on the slice recombination seed, and performs a deterministic randomization of the plaintext block index array from 0 to the block number minus 1 to obtain a block permutation sequence. The block permutation sequence contains each plaintext block index without repetition and is used to determine the writing order of each ciphertext block in the ciphertext file. S05 Encrypted File Header Generation: The terminal generates a dynamically slice-reconstructed encrypted file header. The file header includes at least the file magic number, file format version, key version, salt value, slice recombination flag, block size, block number, original file size, slice recombination seed, and header checksum. The header checksum is used to detect damage or tampering of the file header during storage or transmission.S06 Block Reading, Authentication Encryption, and Out-of-Order Writing: The terminal sequentially determines the plaintext block index to be processed according to the block arrangement sequence, and reads the plaintext block from the corresponding offset position of the original file according to the plaintext block index and block size; an independent initialization vector is generated for each plaintext block, and the plaintext block is encrypted using AES-256-GCM to generate an authentication tag; the independent initialization vector, authentication tag, and ciphertext block are written to the ciphertext file in sequence, so that the physical block order in the ciphertext file is different from the logical block order of the original file. S07 Original File Protection and Atomic Disk Writing: The terminal first moves or backs up the original file to a hidden protection directory, and then writes the ciphertext data to a temporary file; after all file headers and ciphertext blocks are written, the temporary file is renamed to the target encrypted file; if the encryption process is abnormally interrupted, the temporary file is cleaned up to reduce the risk of the semi-finished ciphertext file being misused. S08 Authorized Decryption and Reverse Reconstruction: After a user requests decryption and passes the server's authorization verification, the terminal reads the ciphertext file header and verifies the header checksum. Based on the block size, number of blocks, original file size, and slice reconstruction seed in the file header, the terminal reconstructs the block arrangement sequence. The terminal reads the initialization vector, authentication tag, and ciphertext blocks one by one according to the physical order recorded in the ciphertext file. It performs AES-GCM decryption and authentication verification using the server-derived decryption key, and writes the decrypted plaintext blocks back to the original logical offset position of the target file according to the corresponding plaintext block index, thereby restoring the original file content. Further, the small file threshold is 1MB; when the file size is greater than 1MB and less than or equal to 64MB, the block size is 256KB; when the file size is greater than 64MB and less than or equal to 1GB, the block size is 1MB; when the file size is greater than 1GB, the block size is 2MB. The above thresholds and block sizes can be configured according to the terminal storage medium, processor performance, and enterprise policies. Furthermore, the pseudo-random number generator employs a deterministic state update algorithm based on a slice reconstruction seed, and the deterministic out-of-order arrangement uses the Fisher-Yates shuffling method, enabling the encryption end and the authorized decryption end to reconstruct the same block arrangement sequence based on the same slice reconstruction seed without additionally storing the complete arrangement array. Furthermore, the file magic number is a fixed byte sequence used to identify the encrypted file type, the file format version is used to distinguish between the whole file AES-GCM format and the dynamic slice reconstruction AES-GCM format, and the slice reconstruction flag is used to indicate that the file header carries out-of-order block recovery information. Furthermore, each block independently generates an initialization vector and an authentication tag. When a ciphertext block or its authentication tag is tampered with, the anomaly can be detected only during the decryption and authentication stage of that block, without needing to complete the entire file decryption before determining file integrity.Furthermore, the key server derives a decryption key based on the file identifier, encryption level, key version, and salt value. Before decryption, it also verifies the decryption application status, authorization validity period, and remaining usage count. If the authorization verification fails, it does not return a key that can be used for decryption to the terminal. Furthermore, the terminal also performs file scanning, policy matching, and automatic encryption processes, determining the encryption level of the file to be encrypted based on the file extension, file path, policy source priority, encryption level priority, and policy priority. For files matching the mandatory encryption policy, it automatically executes the AES file obfuscation encryption method based on dynamic slice reassembly. The beneficial effects of this invention are: First, this invention combines AES-GCM authentication encryption with dynamic slice reassembly, not only encrypting the file content but also changing the physical arrangement order of ciphertext blocks, decoupling the ciphertext order from the plaintext logical order, and improving the obfuscation protection capability for file structure, format fragments, and block boundaries. Second, this invention adaptively determines the slice granularity based on the file size, employing block reading, block encryption, and block writing for large files, avoiding loading the entire file into memory at once, reducing peak terminal memory usage, and improving the stability of GB-level file encryption and decryption processes. Third, this invention records the key version, salt value, block size, number of blocks, original file size, slice reconstruction seed, and header checksum in the file header, enabling encrypted files to have clear version identification, parameter recovery, and header integrity detection capabilities, which is beneficial for cross-version compatibility and abnormal file identification. Fourth, this invention uses an initialization vector and authentication tag to independently perform AES-GCM authentication encryption on each block. If a single block is tampered with, truncated, or swapped, it can be detected in time during the decryption process, enhancing the ability to verify ciphertext integrity and locate corruption. Fifth, this invention establishes a closed-loop management system through server-side key materials, key version, decryption application, authorization validity period, and usage limit, which can adapt to enterprise terminal file encryption, authorization decryption, external approval, and audit record scenarios, reducing the risk of uncontrolled plaintext file propagation. Sixth, this invention employs original file hiding backup, temporary ciphertext files, and renaming mechanisms during the encryption and disk writing process, reducing the risk of both the original and ciphertext files becoming unusable due to abnormal interruptions, program crashes, or disk write failures. Attached Figure Description

[0004] Figure 1 is a flowchart of the overall process of the AES file obfuscation and encryption method based on dynamic slice recombination of the present invention; Figure 2 is a schematic diagram of the dynamic slicing parameter determination, disordered seed generation, and block arrangement sequence construction of the present invention; Figure 3 is a schematic diagram of the encrypted file header and the out-of-order encrypted block storage structure of the present invention; Figure 4 is a schematic diagram of the authorization decryption and reverse recombination recovery process of this invention; Figure 5 is a schematic diagram of the collaborative structure of the terminal, key server, policy server and file system of the present invention. Detailed Implementation

[0005] The preferred embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. These embodiments are used to explain the technical solutions of the present invention, facilitating understanding and implementation by those skilled in the art. As shown in Figures 1 to 5, the present invention can be deployed in a terminal data protection system composed of an enterprise file encryption client, a key server, and a policy server. The enterprise file encryption client runs on the user terminal and is responsible for file scanning, policy matching, key material request, file encryption, authorized decryption, and encryption record reporting. The key server is responsible for generating, storing, or deriving key materials corresponding to different encryption levels and different key versions. The policy server is responsible for issuing encryption levels, protection paths, file types, network environment processing rules, auditing rules, and alarm rules. In one embodiment, the user selects one or more files to be encrypted on the terminal and specifies an encryption level L1, L2, L3, or L4. The terminal requests key materials from the key server, and the key server returns the key version, salt value, and derived AES-256 key. The terminal performs short-term caching of the key materials; the cache key can consist of the encryption level and file identifier, and the cache time can be set to 5 minutes to reduce repeated network requests during the encryption process of the same batch of files. For files requiring server-side key protection, if the terminal is not connected to the server or cannot obtain the key materials, the terminal will not perform encryption. After obtaining the size of the file to be encrypted, the terminal determines whether to enter dynamic slice reassembly mode. When the file size is less than or equal to 1MB, the terminal can use whole-file AES-GCM encryption, i.e., generating an initialization vector for the entire file, performing AES-GCM encryption once, generating an authentication tag, and recording the file magic number, version number, key version, salt value, initialization vector, and authentication tag in the ciphertext header. When the file size is greater than 1MB, the terminal enters dynamic slice reassembly mode: for files between 1MB and 64MB, 256KB blocks are used; for files between 64MB and 1GB, 1MB blocks are used; and for files exceeding 1GB, 2MB blocks are used. The terminal calculates the number of blocks based on the file size and block size, and processes the last block according to the remaining byte length. In dynamic slice reconstruction mode, the terminal concatenates the first 16 bytes of the AES key, the first 16 bytes of the salt value, and the file size string to form a seed input. It then performs a SHA-256 hash operation on this seed input and reads the first 8 bytes of the digest as a 64-bit slice reconstruction seed. This seed depends on the key material, salt value, and file size; therefore, different files, different key versions, or different salt values ​​typically produce different block permutation sequences, reducing the risk of reusing permutation patterns between different ciphertext files. The terminal initializes a deterministic pseudo-random number generator with the slice reconstruction seed and performs a Fisher-Yates shuffle on the array containing all plaintext block indices to obtain the block permutation sequence.For example, the original plaintext block indices are 0, 1, 2, 3, 4, 5, which can be rearranged into 3, 0, 5, 1, 4, 2. The terminal then reads the plaintext blocks in the rearranged order, not the original order. When reading the block with index 3, the terminal reads data from the original file offset position 3 times the block size; when reading the block with index 0, the terminal reads data from the beginning of the original file. In this way, the first ciphertext block in the ciphertext file does not necessarily correspond to the beginning of the original file, and the end of the ciphertext file does not necessarily correspond to the end of the original file. The terminal generates a dynamically sliced ​​reconstructed encrypted file header. This header can be organized in the following format: [File magic number 4 bytes][File format version 1 byte][Key version 2 bytes][Salt value 32 bytes][Flag bit 1 byte][Block size 4 bytes][Number of blocks 4 bytes][Original file size 8 bytes][Slice reconstructing seed 8 bytes][Header checksum 4 bytes]. The file magic number is used to quickly identify the encrypted file of this invention. The file format version can be set to represent the version number of the dynamic slice reassembly format. At least one bit in the flag bits indicates that the seed scrambling mode is enabled. The header checksum can be generated using Adler-32, CRC32, or other lightweight checksum algorithms. The terminal writes the file header to the beginning of the target temporary ciphertext file, and then processes each plaintext block sequentially according to the block arrangement sequence. For each plaintext block, the terminal generates an independent random initialization vector, and uses AES-256-GCM to encrypt the plaintext block with the initialization vector and the AES key to obtain the ciphertext block and the authentication tag. The terminal appends the ciphertext block to the temporary ciphertext file according to the record format [initialization vector][authentication tag][ciphertext block]. Since the ciphertext length of AES-GCM is the same as the plaintext block length, the terminal can calculate the ciphertext block length of each record based on the block size, number of blocks and original file size in the file header, where the last block uses the remaining plaintext byte length. To enhance disk security, the terminal can create a hidden protection directory before encryption. For example, a hidden directory can be created within the original file's directory, with a backup subdirectory within that hidden directory. The terminal moves the original file to the hidden backup directory before encryption; if the move fails, the original file can be protected by copying and then deleting it. Encrypted output is first written to a temporary file corresponding to the target path. After all file headers, initialization vectors, authentication tags, and ciphertext blocks are written, the temporary file is renamed to the final encrypted file. The final encrypted file can have an encryption extension appended to the original filename, with different suffixes added based on the encryption level, allowing the terminal and server to identify the encryption level. During decryption, the user first sends a decryption request to the server, including the file identifier and the reason for decryption. The server determines whether decryption is allowed based on the approval status, authorization validity period, remaining usage count, and user identity.Before performing local decryption, the terminal verifies decryption permission with the server and reads the key version and salt value from the ciphertext file header, requesting the corresponding decryption key from the server. The server only returns the decryption key or key derivation result if authorization is successful. After reading the ciphertext file header, the terminal verifies the file magic number, file format version, slice reconstruction flag, and header checksum. After successful verification, the terminal reconstructs the same block arrangement sequence as the encryption stage based on the number of blocks and the slice reconstruction seed in the file header. The terminal sequentially reads the initialization vector, authentication tag, and ciphertext blocks starting from the first ciphertext record after the file header. For each plaintext block index in the arrangement sequence, the terminal performs AES-GCM decryption authentication using the initialization vector and authentication tag in the corresponding record; after successful authentication, the obtained plaintext block is written to the target output file at a logical offset position determined by the plaintext block index and block size. After all block processing is completed, the target output file is restored to the original plaintext file. In another embodiment, the present invention can also be combined with a policy engine. The policy engine periodically synchronizes policies from the server. These policies include file type, protected path, policy source, encryption level, network environment rules, audit flags, and alarm flags. The policy engine scans or monitors the terminal file system. When it detects a file path and file type matching a mandatory encryption policy, it selects the highest priority policy based on policy source priority, encryption level priority, and custom policy priority, and automatically protects the file using the dynamic slicing and reassembly AES file obfuscation encryption process of this invention. After encryption, the terminal reports the encrypted file path, file name, file size, encryption level, and encryption time to the server for subsequent decryption approval, external distribution approval, and audit tracking. In another embodiment, the dynamic slicing and reassembly mode can be configured to be extended according to the terminal device type. For example, for solid-state drive terminals, smaller blocks and increased out-of-order strength can be used to improve the file structure obfuscation effect; for mechanical hard drive terminals, the block size can be appropriately increased or the number of random reads can be limited to reduce disk seek overhead. These parameter adjustments do not change the core idea of ​​this invention: adaptive slicing, deterministic out-of-order arrangement, block-based AES authentication encryption, and authorization recovery based on file header parameters. In the above embodiments, the file magic number, version number, threshold, block size, verification algorithm, key caching time, encryption level name, and file extension can all be replaced or adjusted equivalently according to actual deployment requirements. As long as they still employ the technical means of dynamic slicing based on file size, deterministic block reassembly based on key material, block AES authentication encryption, and authorization recovery based on file header parameters, they fall within the implementation methods covered by the technical concept of this invention.

Claims

1. A method for AES file obfuscation and encryption based on dynamic slice recombination, characterized in that, Includes the following steps: S01 Obtain the file size, encryption level, and file identifier of the file to be encrypted, and obtain key materials corresponding to the encryption level or file identifier from the key server. The key materials include an AES encryption key, a salt value, and a key version. S02 When the file size is greater than a preset small file threshold, determine the block size based on the file size, and calculate the number of blocks and the effective length of each plaintext block based on the file size and the block size. S03 Generates a slice recombination seed based on the AES encryption key, salt value, and file size; S04. Based on the slice recombination seed, the plaintext block index array is deterministically shuffled to obtain a block arrangement sequence; S05. An encrypted file header is generated and written, the encrypted file header including the file magic number, file format version, key version, salt value, slice recombination flag, block size, number of blocks, original file size, slice recombination seed, and header checksum. S06 Determine the plaintext block index to be processed according to the block arrangement sequence, and read the plaintext block from the corresponding logical offset position of the file to be encrypted according to the plaintext block index; S07 Generate an independent initialization vector for each plaintext block, encrypt the plaintext block using AES-GCM and generate an authentication tag, and write the independent initialization vector, authentication tag and ciphertext block into the ciphertext file, so that the physical order of the ciphertext blocks in the ciphertext file is different from the logical order of the plaintext blocks in the file to be encrypted.

2. The AES file obfuscation and encryption method based on dynamic slice reassembly according to claim 1, characterized in that: The preset small file threshold is 1MB; when the file size is greater than 1MB and less than or equal to 64MB, the block size is 256KB; when the file size is greater than 64MB and less than or equal to 1GB, the block size is 1MB; when the file size is greater than 1GB, the block size is 2MB.

3. The AES file obfuscation and encryption method based on dynamic slice reassembly according to claim 1, characterized in that: The step of generating a slice reconstruction seed based on the AES encryption key, salt value, and file size includes concatenating a portion of the AES encryption key, a portion of the salt value, and the file size into seed input material, performing a hash operation on the seed input material, and extracting a fixed-length value from the hash digest as the slice reconstruction seed.

4. The AES file obfuscation and encryption method based on dynamic slice reassembly according to claim 1, characterized in that: The step of deterministically shuffling the plaintext block index array according to the slice recombination seed includes initializing a pseudo-random number generator using the slice recombination seed and performing Fisher-Yates shuffling on the plaintext block index array based on the pseudo-random number generator, so that the resulting block arrangement sequence contains all plaintext block indices and there are no duplicate indices.

5. The AES file obfuscation and encryption method based on dynamic slice reassembly according to claim 1, characterized in that: The header checksum is calculated based on the fields in the encrypted file header other than the header checksum, and is used to verify whether the encrypted file header is damaged or tampered with before decryption.

6. The AES file obfuscation and encryption method based on dynamic slice reassembly according to claim 1, characterized in that: The independent initialization vector and authentication tag are stored adjacent to the corresponding ciphertext block. Each ciphertext block has an independent authentication tag, so that if any ciphertext block is tampered with, it can be detected during the AES-GCM decryption authentication process of that ciphertext block.

7. The AES file obfuscation and encryption method based on dynamic slice reassembly according to claim 1, characterized in that: Before writing the encrypted file, move or back up the file to be encrypted to a hidden protected directory and write the encrypted data to a temporary file. After all encrypted data has been written, the temporary file is renamed to the target encrypted file; if encryption is interrupted by an abnormality, the temporary file is deleted.

8. The AES file obfuscation and encryption method based on dynamic slice reassembly according to claim 1, characterized in that, The process also includes an authorization and decryption step: the terminal reads the ciphertext file header and verifies the header checksum; it reconstructs the block arrangement sequence based on the block size, number of blocks, original file size, and slice reconstruction seed in the ciphertext file header; after authorization by the server, it obtains the decryption key; it reads the independent initialization vector, authentication tag, and ciphertext blocks according to the physical storage order in the ciphertext file; it performs AES-GCM decryption authentication; and it writes the decrypted plaintext blocks to the original logical offset position of the target file according to the plaintext block index corresponding to the block arrangement sequence.

9. The AES file obfuscation and encryption method based on dynamic slice reassembly according to claim 8, characterized in that: The server authorization includes verifying the decryption application status, user identity, authorization validity period, and remaining usage count; if any verification fails, the server will not return any key materials that can be used for decryption to the terminal.

10. An AES file obfuscation and encryption device based on dynamic slice recombination, characterized in that, include: The key material acquisition module is used to acquire the file size, encryption level, and file identifier of the file to be encrypted, and to obtain the AES encryption key, salt value, and key version from the key server; the dynamic slicing module is used to determine the block size, number of blocks, and effective length of each plaintext block based on the file size. A seed generation module is used to generate a slice recombination seed based on the AES encryption key, salt value, and file size; The permutation construction module is used to perform deterministic random permutation of the plaintext block index array according to the slice recombination seed to obtain the block permutation sequence; the file header generation module is used to generate an encrypted file header containing the file magic number, file format version, key version, salt value, slice recombination flag, block size, number of blocks, original file size, slice recombination seed and header check value. The block encryption writing module is used to read plaintext blocks according to the block arrangement sequence, perform AES-GCM encryption on each plaintext block using an independent initialization vector and generate an authentication tag, and write the independent initialization vector, authentication tag and ciphertext block into the ciphertext file.

11. The AES file obfuscation and encryption device based on dynamic slice reassembly according to claim 10, characterized in that, It also includes an authorized decryption and reassembly module, which reads and verifies the ciphertext file header, reconstructs the block arrangement sequence, obtains the decryption key authorized by the server, decrypts the ciphertext blocks according to the physical storage order of the ciphertext file, and writes the plaintext blocks back to the original logical offset position of the target file according to the corresponding plaintext block index.

12. An AES file obfuscation and encryption system based on dynamic slice recombination, characterized in that, The system includes a terminal client, a key server, and a policy server; the terminal client is used to execute the method described in any one of claims 1 to 9; the key server is used to provide the terminal client with key materials corresponding to the encryption level, file identifier, or key version, and derive a decryption key based on the salt value and key version during the authorized decryption phase; the policy server is used to issue file type, protection path, encryption level, and mandatory encryption policy to the terminal client, enabling the terminal client to automatically perform AES file obfuscation encryption based on dynamic slice reassembly on files that match the policy.

13. The AES file obfuscation and encryption system based on dynamic slice reassembly according to claim 12, characterized in that: The terminal client is also used to scan the local file system, determine the target policy corresponding to the file to be encrypted based on the file extension, file path, policy source priority, encryption level priority and policy priority, and report the encrypted file path, file name, file size, encryption level and encryption time to the server.

14. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that: When the computer program or instructions are executed by the processor, they implement the AES file obfuscation and encryption method based on dynamic slice reassembly as described in any one of claims 1 to 9.

15. A computer program product, characterized in that: Includes a computer program or instructions that, when executed by a processor, implement the AES file obfuscation and encryption method based on dynamic slice reassembly as described in any one of claims 1 to 9.

Images