A multi-control core parallel cryptanalysis method and system based on hthread

Abstract

This invention discloses a multi-control-core parallel cryptanalysis method and system based on hthread. The method specifically includes: for each acceleration cluster, loading the corresponding pre-compiled device-side kernel image into the on-chip memory of that acceleration cluster via the hthread interface, and activating all control cores within that acceleration cluster as independent threads to execute the pre-compiled device-side kernel image; for each control core, determining and retrieving a subtask block belonging to that control core from the high-bandwidth shared memory of that acceleration cluster based on its unique identifier within the cluster; for each control core, reading the cryptographic candidates in the subtask block into its private scalar memory, and independently executing a complete hash calculation process within the private scalar memory to generate the calculation result. This invention can effectively improve the performance and efficiency of domestic supercomputing platforms in the field of cryptanalysis and is suitable for legitimate authorization scenarios such as network security auditing and weak password detection.

Description

Technical Field

[0001] This invention relates to the intersection of high-performance computing and information security, and in particular to a multi-control-core parallel cryptographic analysis method and system based on hthread. Background Technology

[0002] In the field of cryptanalysis, current mainstream cryptanalysis tools, such as Hashcat and John the Ripper, are primarily designed and optimized for NVIDIA GPUs or x86 multi-core CPUs. These tools heavily rely on CUDA, OpenCL, or POSIX threading models to achieve parallel computation, thereby accelerating the cryptanalysis process.

[0003] However, domestically developed supercomputing platforms possess unique architectural characteristics. Represented by supercomputers such as Sunway TaihuLight and the Tianhe series, they generally employ domestically designed many-core heterogeneous architectures, such as the Matrix-3000 accelerator. This architecture differs significantly from the commonly used GPU or x86 multi-core CPU architectures abroad, lacking native support for CUDA / OpenCL. This results in existing mainstream cryptanalysis tools being unable to run directly on domestic supercomputing platforms, requiring complex porting and adaptation work. Furthermore, they may even fail to run effectively due to significant architectural differences, greatly limiting the application of domestic supercomputing platforms in the field of cryptanalysis. Summary of the Invention

[0004] The purpose of this invention is to provide a multi-control-core parallel cryptanalysis method and system based on hthread, which makes full use of domestic supercomputing control cores and achieves high-throughput, low-overhead, and flexible parallel cryptanalysis through the hthread heterogeneous programming model, so as to solve at least one of the above-mentioned problems in the prior art.

[0005] In a first aspect, the present invention provides a multi-control-core parallel cryptographic analysis method based on hthread, specifically including: Based on the main control unit of the general processing area deployed on domestic supercomputing nodes, a global cryptographic candidate space is generated according to the cryptographic analysis mode specified by the user. The global cryptographic candidate space is divided into multiple coarse-grained task blocks, and the multiple coarse-grained task blocks are statically allocated to each acceleration cluster. For each acceleration cluster, the corresponding pre-compiled device kernel image is loaded into the on-chip memory of that acceleration cluster through the hthread interface, and all control cores in that acceleration cluster are activated as independent threads to execute the pre-compiled device kernel image. For each control core, based on its unique identifier within its acceleration cluster, the subtask block belonging to that control core is determined and retrieved from the high-bandwidth shared memory of that acceleration cluster. For each control core, the password candidates in the subtask block are read into its private scalar memory, and the complete hash calculation process is executed independently in the private scalar memory to generate the calculation result. For any control core, when the computation result it generates matches the target hash value, the corresponding cryptographic plaintext is written to the local result buffer in the high-bandwidth shared memory of the acceleration cluster through atomic operations.

[0006] Secondly, this invention provides a multi-control-core parallel cryptographic analysis system based on hthread, specifically comprising: The cross-cluster allocation module is used to generate a global cryptographic candidate space based on the main control unit of the general processing area deployed on domestic supercomputing nodes, according to the cryptographic analysis mode specified by the user, divide the global cryptographic candidate space into multiple coarse-grained task blocks, and statically allocate the multiple coarse-grained task blocks to each acceleration cluster. The thread activation module is used to load the corresponding pre-compiled device kernel image into the on-chip memory of each acceleration cluster through the hthread interface, and activate all control cores in the acceleration cluster as independent threads to execute the pre-compiled device kernel image. The task retrieval module is used to determine and retrieve the subtask blocks belonging to each control core from the high-bandwidth shared memory of the acceleration cluster based on its unique identifier within the acceleration cluster. The hash calculation module is used to read the password candidates in the subtask block into its private scalar memory for each control core, and independently execute the complete hash calculation process in the private scalar memory to generate the calculation result. The matching and reporting module is used to write the plaintext of the cryptography corresponding to the calculation result into the local result buffer in the high-bandwidth shared memory of the acceleration cluster when the calculation result generated by any control core matches the target hash value.

[0007] Thirdly, the present invention provides a computer device, comprising: a memory and a processor, and a computer program stored in the memory, wherein when the computer program is executed on the processor, it implements the hthread-based multi-control core parallel cryptanalysis method as described in any of the above methods.

[0008] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the hthread-based multi-control-core parallel cryptanalysis method as described in any of the above methods.

[0009] Compared with the prior art, the present invention has at least one of the following technical effects: 1. This invention makes full use of domestic supercomputing control cores and achieves high-throughput, low-overhead, and flexible parallel cryptographic analysis through the hthread heterogeneous programming model. It can effectively improve the performance and efficiency of domestic supercomputing platforms in the field of cryptographic analysis and is suitable for legitimate authorization scenarios such as network security auditing and weak password detection.

[0010] 2. This invention is designed based on the hthread programming model, which avoids the dependence of existing mainstream cryptanalysis tools on CUDA / OpenCL. It can be well adapted to the many-core heterogeneous architecture independently designed by domestic supercomputing companies, so that cryptanalysis tools can run directly on domestic supercomputing platforms without complicated porting and adaptation work, thus broadening the application scope of domestic supercomputing platforms in the field of cryptanalysis.

[0011] 3. This invention fully leverages the general computing capabilities of the control cores of domestically produced supercomputing platforms, allowing each control core to independently undertake complete hash calculation tasks. This bypasses the SIMD limitations of acceleration cores, avoids inefficiency caused by handling complex control flows, thereby improving the utilization rate of control core resources and significantly enhancing the actual throughput of cryptanalysis.

[0012] 4. This invention utilizes the cross-control core task distribution function provided by the hthread programming model. The main control unit can rationally divide the global cipher candidate space into multiple coarse-grained task blocks according to the user-specified cryptanalysis mode and statically allocate them to each acceleration cluster. Each control core then retrieves sub-task blocks from the high-bandwidth shared memory of the acceleration cluster based on its own unique identifier, achieving efficient and orderly task allocation and management, and ensuring the efficiency and accuracy of parallel computing.

[0013] 5. In this invention, when the calculation result generated by the control kernel matches the target hash value, the matching record is written to the local result buffer of the acceleration cluster without locking through atomic operations. The main control unit can access the local result buffer of each acceleration cluster sequentially during or after the calculation, retrieve the matching records, and perform aggregation and deduplication processing, ensuring the timeliness and accuracy of result processing and improving the efficiency of the entire cryptanalysis system.

[0014] 6. In this invention, the control core reads the password candidates from the subtask block into its private scalar memory for computation, while simultaneously making efficient use of the high-bandwidth shared memory of the acceleration cluster to store task block metadata and matching records. This memory usage method fully leverages the characteristics of different memory types, reduces data transfer overhead, improves memory access efficiency, and further enhances the overall system performance.

[0015] 7. This invention is based on an independent execution model of the control kernel. Each thread has a complete program counter and control flow capability, which can efficiently process password input of arbitrary length (such as 1 to 20 characters) without the need for uniform length normalization or padding alignment of the input. This avoids the large performance loss and candidate discarding problems caused by branch divergence in the existing SIMD architecture.

[0016] 8. This invention achieves high-concurrency execution by treating each control core as an independent hash calculation unit and combining it with the low-overhead hthread thread mechanism, significantly increasing the number of hash calculations per unit time (hashes / sec). Under the same hardware configuration, compared with implementations that rely on MOCL and are limited by the SIMD model of the acceleration core, it can make fuller use of the scalar computing capabilities of all control cores, thereby achieving an order-of-magnitude increase in throughput.

[0017] 9. In this invention, the entire hash calculation process is completed in the control kernel's local scalar memory (SM). Intermediate states and constants do not need to access global memory, reducing memory access bottlenecks, improving cache hit rate, thereby significantly reducing latency and improving execution efficiency.

[0018] 10. In this invention, compared with the solution that relies on the SIMD architecture of the acceleration core, this invention avoids the branch blocking problem caused by inter-thread lockstep execution, so that different cryptographic candidates can independently advance the calculation process, thereby maintaining stable performance in complex control flow scenarios.

[0019] 11. This invention can expand computing power approximately linearly according to the number of available control cores, and can flexibly adapt to different hash algorithms (such as MD5, SHA256, NTLM, etc.) without modifying the underlying parallel model.

[0020] 12. This invention adopts the standard C language and hthread programming model, without relying on CUDA or OpenCL specific optimization techniques, avoiding complex kernel reconstruction and vectorization design, enabling existing cryptanalysis algorithms to be quickly migrated to domestic supercomputing platforms. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart illustrating a multi-control-core parallel cryptographic analysis method based on hthread provided in an embodiment of the present invention; Figure 2This is a schematic diagram of the MT-3000 hardware architecture provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the overall system architecture of a multi-control core parallel cryptographic analysis method based on hthread provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a multi-control-core parallel cryptoanalysis system based on hthread provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0023] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0024] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0025] The following is a description of the relevant terminology involved in this invention: SM (Scalar Memory): A 64KB scalar memory private to the control kernel, used to store frequently accessed data such as constant tables and intermediate states.

[0026] hthread: A lightweight heterogeneous thread programming model designed specifically for the MT-3000, providing low-overhead thread creation, cross-control core task distribution, and on-chip memory management interfaces.

[0027] .dat file: The device-side kernel binary image file generated by the M3000-makedat tool, which can be loaded into the accelerated cluster memory by the host-side hthread_dat_load API for execution.

[0028] HBSM (High-Bandwidth Shared Memory): Accelerates high-bandwidth on-chip memory shared by all control cores within the cluster, used to store task blocks, password candidates, and result buffers.

[0029] MT-3000: refers to the domestic Matrix-3000 heterogeneous many-core processor, whose architecture includes a general processing zone (GP Zone) and an acceleration zone (ACC Zone), with the ACC Zone consisting of 4 physically isolated acceleration clusters.

[0030] The Matrix-3000 architecture consists of one control core and 16 accelerator cores (ACC cores) per acceleration array. The control core has a complete instruction set, an independent program counter (PC), and 64KB of private scalar memory (SM), enabling it to run standard C programs. The accelerator cores, being SIMD units, are driven by the control core and execute the same instruction flow. In traditional optimization paradigms for rule-based computation (such as dense matrix operations), the control core is often used as a "scheduler" for the accelerator cores, primarily responsible for task allocation and coordinating their work, thus its powerful general-purpose computing capabilities are not fully utilized. However, for cryptographic algorithms like SHA-256 with variable-length inputs and strong state dependencies, the complex control flow involving variable-length inputs and conditional branches is severely incompatible with the unified control flow and aligned data model required by accelerator cores. Executing such algorithms in SIMD mode leads to significant branching overhead and data alignment issues due to the complex control flow, resulting in extremely low computational efficiency. The control core, with its independent program counter, complete instruction set, and support for complex control flow, is fully capable of independently undertaking complete hash calculation tasks without relying on acceleration cores. Bypassing SIMD limitations and performing scalar computations directly on the control core can actually achieve higher actual throughput and resource utilization, fully tapping the computing potential of domestically developed supercomputing platforms.

[0031] hthread is a lightweight heterogeneous thread programming interface designed specifically for domestically produced supercomputers (such as the Tianhe next-generation supercomputer). It boasts numerous advantages, including low-overhead thread creation (down to microsecond levels), support for task distribution across control cores, and explicit on-chip memory (SM) management. These characteristics make the hthread programming model highly suitable for building efficient parallel computing systems. However, currently, no work has applied the hthread programming model to build a purely control-core parallel cryptanalysis system. If the advantages of the hthread programming model can be fully utilized, combined with the characteristics of the control cores of domestically produced supercomputing platforms, and a multi-control-core parallel cryptanalysis method based on hthread can be developed, it is expected to solve the compatibility issues of existing cryptanalysis tools on domestically produced supercomputing platforms, improve the utilization rate of control core resources, and thus significantly enhance the performance and efficiency of domestically produced supercomputing platforms in the field of cryptanalysis.

[0032] In this application embodiment, the entity executing the process includes a terminal device. This terminal device includes, but is not limited to, devices capable of executing the methods disclosed in this application, such as servers, computers, smartphones, and tablets. Figure 1 A flowchart illustrating a multi-control-core parallel cryptoanalysis method based on hthread, as disclosed in an embodiment of the present invention, is shown below in detail: S101, based on the main control unit of the general processing area deployed on domestic supercomputing nodes, generates a global cryptographic candidate space according to the cryptographic analysis mode specified by the user, divides the global cryptographic candidate space into multiple coarse-grained task blocks, and statically allocates multiple coarse-grained task blocks to each acceleration cluster. S102, for each acceleration cluster, load the corresponding pre-compiled device kernel image into the on-chip memory of the acceleration cluster through the hthread interface, and activate all control cores in the acceleration cluster as independent threads to execute the pre-compiled device kernel image; S103, For each control core, based on its unique identifier within the acceleration cluster, determine and retrieve the subtask block belonging to that control core from the high-bandwidth shared memory of that acceleration cluster; S104, For each control core, read the password candidates in the subtask block into its private scalar memory, and independently execute the complete hash calculation process in the private scalar memory to generate the calculation result; S105, for any control core, when the calculation result it generates matches the target hash value, the plaintext corresponding to the calculation result is written to the local result buffer in the high-bandwidth shared memory of the acceleration cluster through atomic operations.

[0033] In this embodiment, the system is deployed on a domestically produced heterogeneous many-core supercomputer node. This node has a unique hardware architecture, providing a solid hardware foundation for the efficient operation of the system. The specific hardware configuration is as follows: The host unit (general processing area) serves as the system's control center, bearing the crucial responsibility of task scheduling and result aggregation. It coordinates the entire cryptanalysis process, ensuring orderly collaboration between modules to efficiently complete cryptanalysis tasks.

[0034] Device side (acceleration area): This area is the core computing region for cryptanalysis, containing four DSP clusters. Each cluster is further subdivided into 24 acceleration arrays, forming a large and efficient computing network.

[0035] Acceleration array composition: Each acceleration array consists of one control core and 16 acceleration cores (ACCCores). In this embodiment, to fully leverage the advantages of parallel computing on the pure control core, acceleration cores (ACCCores) are not used; only the control core is utilized for cryptanalysis computation.

[0036] Control core features: Each control core has an independent program counter (PC), which can precisely control the execution flow of the program; it has 64KB of private scalar memory (SM), which provides independent and efficient space for data storage and processing during the cryptographic calculation process; at the same time, it supports the standard C language execution environment, which makes it convenient for developers to write and debug programs and reduces the development difficulty.

[0037] The software system in this embodiment achieves efficient parallel cryptanalysis with a pure control kernel through the collaborative work of multiple functional modules. The specific functions of each module are as follows: (1) Task generation module (Host side, general processing area): 1.1) Input: This module accepts various input parameters, including a list of target hash values, a salt value (if any), a user-specified analysis mode (dictionary / mask / combination), and parameters (such as the mask string ?l?d?l, dictionary file path, etc.). These input parameters provide users with flexible options for cryptanalysis methods, meeting the needs of cryptanalysis in different scenarios; 1.2) Function: Dynamically construct a global password candidate space based on the analysis mode specified by the user; Dictionary mode: Reads the dictionary file line by line, treating each line of strings as a candidate password, and generating a list of candidate passwords. This mode is suitable when the range of possible passwords is known, and can quickly filter possible passwords from the dictionary; Masking pattern: Recursively expands all combinations based on masking rules (e.g., ?u?l?d represents uppercase letter + lowercase letter + number). This method can generate a large number of password combinations that conform to specific rules, expanding the password search range; Combination pattern: Performs a Cartesian product or concatenation operation on two dictionaries. This pattern can combine strings from different dictionaries to generate more possible passwords, further improving the success rate of cryptanalysis; 1.3) Output: Generate a discrete set of candidate cryptography, providing a data foundation for subsequent task partitioning and parallel computing.

[0038] (2) Task partitioning module (Host side, general processing area): This task is responsible for dividing the global candidate set into subtasks suitable for parallel processing. Based on the MT-3000 hardware topology (4 acceleration clusters × 24 control cores = 96 computing units), the candidate set is divided into M coarse-grained task blocks (M≥96). A static load balancing strategy is adopted to evenly distribute the task blocks across the 4 acceleration clusters, ensuring that the initial load of each cluster is basically consistent. This task partitioning method can fully utilize hardware resources, avoid the problem of low computational efficiency caused by uneven load, and improve the parallel computing performance of the entire system.

[0039] (3) Task distribution module (Host side, general processing area): Cross-cluster task deployment is achieved through a specific API, ensuring that tasks are accurately and efficiently distributed to the control cores of each acceleration cluster. The specific steps are as follows: For each accelerated cluster c∈{0,1,2,3}: Call hthread_dev_open(c) to initialize the device context, preparing for subsequent communication with the device and task deployment; Dynamically select the corresponding device kernel image (such as sha256_kernel.dat) based on the current analysis mode (such as SHA256) to ensure that the device can correctly execute the corresponding cryptographic calculation task; Calling hthread_dat_load(c,kernel_path) loads the selected .dat file into the on-chip memory of cluster c, providing the necessary code support for the execution of the device-side kernel program; The task block metadata allocated to cluster c is written to its predefined control area in high-bandwidth shared memory (HBSM), enabling the control core on the device side to obtain the corresponding task information; The `hthread_group_create(c,24,kernel_func,args)` function is called to start all 24 control cores, where `args` are the parameters required by the kernel functions, ensuring that each control core can start executing cryptographic computation tasks simultaneously.

[0040] (4) Control core computing module (Device side, acceleration area): Each control core independently executes the device-side kernel program to complete the core work of cryptographic calculation. The main process is as follows: The thread ID (0-23) can be obtained using get_thread_id() to determine its position in the acceleration cluster; Obtain the assigned subtask from the task list of this cluster's HBSM and specify the range of passwords you need to calculate; The candidate ciphers are cached in the local HBSM / GSM cluster to provide data support for subsequent calculations; The complete hash calculation (including message stuffing, block splitting, and multi-round compression) is performed within 64KB of private scalar memory (SM). Because the control core has independent computing resources and memory space, it can independently complete cryptographic calculation tasks without relying on an acceleration core, ensuring both efficiency and independence of the computation. The calculation result is compared with the target hash. If a match is found, (plaintext, target_hash_id) is written to the local result buffer of the HBSM in this cluster via a CAS atomic operation. The CAS atomic operation ensures the accuracy and consistency of the result writing and avoids data race issues in a multi-threaded environment. The entire process uses only the control core scalar unit and does not rely on the acceleration core (ACC Core), giving full play to the computing power of the control core.

[0041] (5) Result Collection Module (Host End, General Processing Area): The main control unit is responsible for aggregating and processing the cracking results, integrating and outputting the computation results from each acceleration cluster. It periodically polls or triggers via interrupts, sequentially accessing the HBSMs of the four acceleration clusters, retrieving matching records from their respective local result buffers; then, it performs global deduplication and formatting, outputting the results to a log file or terminal. This mechanism strictly adheres to the hardware constraint of no direct communication between MT-3000 clusters, avoiding invalid access and improving the efficiency and accuracy of result collection.

[0042] Based on the above hardware configuration and software system, the cryptanalysis task is completed in parallel, and the following steps are executed: (I) Host-side initialization and task preparation: 1. User-specified input parameters: The target file, targets.ntlm, contains 10,000 NTLM hashes, specifying the target password hashes that need to be analyzed. Analysis mode: Dictionary mode, which determines that dictionary-based cryptanalysis will be used; The dictionary file dict.txt (containing approximately 14 million strings) provides a set of possible password candidates; 2. The task generation module reads the dictionary file: it parses the strings in dict.txt line by line to prepare data for subsequent task partitioning and parallel computing; 3. Task Partitioning Module: The 14 million strings are divided into 384 task blocks (approximately 36,458 passwords per block), ensuring that each control core is allocated an average of 4 task blocks (384 ÷ 96 = 4). A static load balancing strategy is adopted, allocating task blocks 0-95 to cluster 0, 96-191 to cluster 1, 192-287 to cluster 2, and 288-383 to cluster 3, ensuring that the initial load of each acceleration cluster is basically the same.

[0043] (II) Device kernel loading and cross-cluster boot: 5. The main control unit selects the device kernel image: It identifies that the current task is an NTLM analysis task, selects the pre-compiled device kernel image ntlm_kernel.dat, and ensures that the device can correctly execute the NTLM cryptographic calculation task; 6. Perform operations in parallel for each accelerated cluster: Call hthread_dev_open(c) to open cluster c and initialize the device context; Call hthread_dat_load(c,"ntlm_kernel.dat") to load the kernel into the on-chip memory of cluster c; Write the metadata of the 96 task blocks allocated to cluster c into its HBSM so that the control core on the device side can obtain the corresponding task information; Call hthread_group_create(c,24,"ntlm_compute",args) to start all 24 control cores in cluster c, passing the parameters required by ntlm_compute to ensure that each control core can start executing cryptographic computation tasks simultaneously.

[0044] (III) Control kernel parallel computing: 7. Each control core executes its entry function independently: 96 control cores start simultaneously and execute the ntlm_compute entry function independently; Get the local ID (0-23) using get_thread_id(), calculate the range of task blocks to be claimed (e.g., in cluster 0, the core with ID=0 claims blocks 0, 24, 48, 72), and read the corresponding cryptographic blocks from the HBSM of this cluster; In the 64KB private SM: Load constants and perform the standard NTLM procedure for each password p: Convert ASCII plaintext to Unicode Little-Endian format to prepare for subsequent hash calculations; Perform hash calculations (including padding, chunking, and multi-round non-linear compression) on Unicode byte strings to complete the core calculation work of the cryptography. Compare the calculated hash with the target hash to determine if they match. If a match is successful, the atomic CAS instruction is invoked to write (p, target_hash_id) into the result buffer of the local HBSM cluster, ensuring the accuracy and consistency of the result writing.

[0045] (iv) Results aggregation and output 8. The main control unit collects results: It periodically polls or triggers an interrupt to access the HBSM of the four acceleration clusters in sequence and pulls matching records from their respective local result buffers; 9. Result Processing and Output: Globally deduplicate and format the collected matching records, and output them to a log file or terminal to provide users with the final cryptanalysis results; 10. Release resources: Release all hthread resources, close device handles, and end the entire cryptanalysis process to ensure the reasonable use and release of system resources; Through the detailed design and implementation of the above hardware environment, software system composition, and parallel execution process, the hardware resources of domestically produced heterogeneous many-core supercomputers can be fully utilized to achieve fast and accurate cryptanalysis tasks.

[0046] In some embodiments, the domestic supercomputing node is MT-3000. The MT-3000 includes a general processing area and an acceleration area. The general processing area is responsible for task management, data input / output, and general computing. The acceleration area includes multiple DSP acceleration clusters. Each DSP acceleration cluster includes global shared memory, high-bandwidth shared memory, and multiple acceleration arrays. Each acceleration array includes a control core and multiple acceleration cores.

[0047] In this embodiment, reference is made to Figure 2 The architecture of the domestically produced many-core heterogeneous processor MT3000 has three characteristics: multi-region heterogeneous architecture, bare-metal accelerator, and hybrid memory. The key features are as follows: (a) Multi-region heterogeneity The MT3000 is divided into two zones: GP Zone (General Processing Zone) and ACC Zone (Acceleration Zone). GP Zone (General Purpose Processing Zone): Contains 16 general purpose CPU cores, runs a standard Linux operating system, and is responsible for task management, I / O, and general purpose computing; ACC Zone: This is a bare metal area, a non-general operating system environment, lacking common OS components such as virtual memory, process scheduling, and file systems. It is divided into four independent DSP acceleration clusters. Each DSP acceleration cluster contains 24 control cores and 384 acceleration cores, forming 24 acceleration arrays (each array includes 1 control core and 16 acceleration cores). Each cluster has its own private Global Shared Memory (GSM) and High Bandwidth Shared Memory (HBSM).

[0048] (ii) Acceleration Array Each acceleration array consists of 1 control core + 16 acceleration cores; Control Core: The control core possesses a complete instruction set, an independent program counter (PC), and 64KB of private scalar memory (SM). It is the brain of the entire acceleration array, capable of executing complex serial logic; Lock-step execution: Within an accelerator array, 16 accelerator cores are driven by a single control core, executing the same instruction stream. In other words, all 16 accelerator cores perform the same operation simultaneously. This is a typical SIMD model, suitable for regular data parallelism, but not friendly to complex control flows (such as variable-length cryptography processing).

[0049] (iii) Hybrid Memory Each control core can access several types of memory: (1) its own 64KBSM (private, fastest); (2) the GSM / HBSM of the DSP cluster (shared, faster); and the DDR4 of the cluster (shared, slower). Each acceleration core can only access the GSM / HBSM / DDR4 of its cluster, as well as 768KB of array memory (AM), which is shared by 16 acceleration cores; For data exchange between different acceleration clusters, the CPU core in the general area acts as a relay, preventing direct communication.

[0050] (iv) Programming model support The MT3000 supports two heterogeneous programming models: hthreads: A low-level programming interface that allows programmers to create thread groups in the GP Zone and distribute tasks to the various control cores in the ACC Zone for execution; MOCL: High-level programming interface, an OpenCL implementation for MT3000 hardware, conforming to the OpenCL specification, and relying on hthreads for underlying implementation.

[0051] Reference Figure 3 This invention also provides a schematic diagram of the overall system architecture for a multi-control-core parallel cryptanalysis method based on hthread. The overall structure includes a host unit and domestically produced supercomputing nodes. The host unit is deployed in the general processing area of ​​the MT-3000 and is responsible for task generation, task partitioning, and result aggregation. The domestically produced supercomputing nodes contain multiple acceleration clusters, each with multiple control cores. Each control core contains an independent program counter (PC), private scalar memory (SM), and a hash calculation execution module. The host unit distributes tasks to each control core through the hthread interface, and the control cores feed back the calculation results to the host unit through a shared result buffer. The specific system architecture deployment includes: 1. Main control unit: Deployment location: Deployed in the general processing area of ​​the MT-3000; Compilation and runtime environment: Compiled using standard GCC and run on a Linux system; Functional Responsibilities: Responsible for task scheduling and result aggregation. Specifically, it generates a global cryptanalysis candidate space based on the user-specified cryptanalysis pattern, divides this space into multiple coarse-grained task blocks, and then assigns them to various acceleration clusters; after the computation is completed, it collects the computation results from each acceleration cluster and performs aggregate processing.

[0052] 2. Work Unit: Execution unit: Executed by 96 control cores in total, consisting of four acceleration zones (24 control cores in each acceleration zone); Compilation Requirements: The program needs to be compiled separately into a bare-metal executable image using the MT-3000 dedicated DSP compiler toolchain, and then converted into a .dat data file for host loading. This compilation method enables the program to better adapt to the MT-3000 architecture and fully utilize its hardware performance; This embodiment also includes the process of compiling and generating device-side programs, compiling host-side programs, and loading and executing device programs.

[0053] 3. The compilation and generation of the device-side program requires independent compilation using the MT-3000-specific DSP cross-compilation toolchain. The specific process is as follows: Compiling the target file: First, the kernel source code (such as kernel.c) is compiled into a target file using the MT3000-gcc compiler. During the compilation process, specific compilation options such as -fenable-m3000 are enabled to adapt to the special requirements of the MT-3000 architecture and ensure that the generated code can run efficiently on this processor; Linking to generate an executable file: The compiled object files are then linked with device-side libraries such as libhthread_device.a and vlib3000.a to generate an ELF executable file (e.g., kernel.out). These libraries provide various functions and features required for device-side programs to run. Convert to binary image file: Finally, the MT3000-makedat tool is used to convert the ELF executable file into a .dat format binary image file (such as kernel.dat). This file has a specific format and structure, which can be directly loaded into the acceleration cluster memory by the host-side API for execution, facilitating the loading and running of device-side programs.

[0054] 4. The host-side program is compiled using standard GCC in the general processing area. Its compilation process does not depend on the DSP toolchain and can be completed using only a standard Linux development environment. During compilation, the libhthread_host.a library needs to be linked to call interfaces such as hthread_dev_open, hthread_dat_load, and hthread_group_create. These interfaces are crucial for enabling interaction between the host and device sides, allowing the host-side program to load the device kernel, pass parameters, and perform multi-cluster parallel control.

[0055] 5. The loading and execution of the device program are completed collaboratively by the host program through the hthread API. The specific process is as follows: Open the target acceleration cluster: The host first calls hthread_dev_open(cluster_id) to open the target acceleration cluster and establish a communication connection with the acceleration cluster, preparing for subsequent operations; Loading the kernel image: Subsequently, the pre-compiled .dat kernel image is loaded into the on-chip memory of the cluster using hthread_dat_load(cluster_id,"kernel.dat"). This step ensures that device-side programs can be correctly loaded and run on the accelerated cluster; Starting the control cores: Next, all 24 control cores are started on the specified cluster using `hthread_group_create`. Each control core performs cryptographic hash calculations as an independent thread, starting from the kernel entry point. This step fully leverages the parallel computing capabilities of multiple control cores within the cluster, improving the efficiency of cryptanalysis. Waiting for computation to complete: Finally, the host calls `hthread_group_wait` to block and wait for all control cores in the cluster to complete their tasks. During this waiting period, the host can monitor the computation progress in real time to ensure the successful completion of the computation task. This process can be applied sequentially to all four acceleration clusters, enabling the coordinated parallel execution of 96 control cores and further improving the overall performance of the system.

[0056] In actual operation, the main control unit first generates a global cipher candidate space based on the cryptanalysis task information input by the user, and divides it into multiple task blocks. Then, following the device program loading and execution flow described above, it operates on each acceleration cluster sequentially, allocating task blocks to each control core for parallel computation. After receiving the task, each control core performs cipher hash calculation using its internal hash calculation execution module and feeds back the calculation result to the main control unit through a shared result buffer. After collecting the calculation results from all control cores, the main control unit summarizes and analyzes them, and finally outputs the cryptanalysis result.

[0057] Through the design and implementation of the above system architecture deployment, device-side program compilation and generation, host-side program compilation, and device program loading and execution process, this invention can fully leverage the hardware performance of the domestically produced many-core heterogeneous processor MT-3000 to achieve efficient multi-control core parallel cryptographic analysis based on hthread, providing strong support for cryptographic analysis work in the field of information security.

[0058] In some embodiments, in step S101 above, the main control unit based on the general processing area deployed on a domestic supercomputing node generates a global cryptographic candidate space according to the cryptographic analysis mode specified by the user, and divides the global cryptographic candidate space into multiple coarse-grained task blocks, specifically including: The system receives a user-specified cryptanalysis pattern and its corresponding parameters, and dynamically constructs a global cryptanalysis candidate set based on the cryptanalysis pattern. The cryptanalysis patterns include mask patterns, dictionary patterns, and combination patterns. Based on the main control unit, according to the total number of control cores, the global cryptographic candidate set is divided into coarse-grained task blocks of no less than the total number of control cores. Each coarse-grained task block includes several cryptographic candidates to be verified. For each coarse-grained task block, corresponding task block metadata is generated. The task block metadata includes the starting position of the corresponding coarse-grained task block in the global cryptographic candidate set and the number of cryptographic candidates.

[0059] In this embodiment, during the cryptanalysis process, to fully utilize the parallel computing capabilities of multiple control cores, the cryptanalysis tasks need to be rationally allocated to each control core. Generating a suitable global cryptanalysis candidate space and dividing it into task blocks suitable for parallel processing is a crucial preliminary step. Different cryptanalysis modes, such as masking, dictionary, and combination modes, have different characteristics and requirements, requiring the main control unit to be flexible, dynamically construct the global cryptanalysis candidate set, and rationally divide tasks to improve the efficiency and accuracy of cryptanalysis.

[0060] The main control unit first receives the cryptanalysis mode and its corresponding parameters specified by the user. Users can input this information via command line, graphical interface, or other methods. Cryptoanalysis modes include mask mode, dictionary mode, and combination mode. For example, in mask mode, the user needs to input the mask rule, such as ?l?l?d representing two lowercase letters plus one digit; in dictionary mode, the user needs to specify the path to the dictionary file; in combination mode, the user needs to provide the paths to two dictionary files or the mask rule and other relevant information. The main control unit parses and verifies this input information to ensure it conforms to the corresponding format and requirements.

[0061] Based on the cryptanalysis pattern specified by the user, the main control unit dynamically constructs a global cryptanalysis candidate set.

[0062] Masking Mode: When a user selects a masking mode, the main control unit dynamically generates all candidate passwords that conform to the specified format according to the masking rules provided by the user and a specific algorithm. For example, for the masking rule ?l?l?d, the main control unit will iterate through all possible combinations of lowercase letters and numbers, generate candidate passwords that conform to the rule, and summarize these candidate passwords to form a global candidate password set.

[0063] Dictionary Mode: If the user selects dictionary mode, the main control unit will read the plaintext password list line by line from the dictionary file specified by the user. The dictionary file can contain various common password combinations, and the main control unit will treat each password read as a password candidate to construct a global password candidate set.

[0064] Combination Mode: When the user selects a combination mode, the main control unit performs a Cartesian product combination on the two dictionaries or mask results provided by the user. For example, if the user provides two dictionary files, the main control unit will combine each password in the first dictionary with each password in the second dictionary to generate new password candidates, thereby constructing a global password candidate set; if the user provides mask rules, the main control unit first generates the corresponding password candidate set according to the mask rules, and then performs a Cartesian product combination.

[0065] Based on the main control unit, the global cryptographic candidate set is divided into coarse-grained task blocks, which are no less than the total number of control cores, according to the total number of control cores. In this embodiment, the total number of control cores is 96, therefore the global cryptographic candidate set is divided into M coarse-grained task blocks, where M ≥ 96. The main control unit ensures that each coarse-grained task block contains several cryptographic candidates to be verified, and that the size of each task block is as uniform as possible, so that each control core can achieve approximately the same load when processing tasks, thereby improving the efficiency of parallel computing. For example, if the global cryptographic candidate set contains 10,000 cryptographic candidates and the total number of control cores is 96, the main control unit can divide the set into 100 coarse-grained task blocks, each containing 100 cryptographic candidates (the last few task blocks may be slightly adjusted according to the actual situation), ensuring that there are enough task blocks for the control cores to process in parallel.

[0066] For each coarse-grained task block, corresponding task block metadata is generated. This metadata includes the starting position of the coarse-grained task block within the global cryptographic candidate set and the number of cryptographic candidates. For example, the metadata for a given coarse-grained task block might record that it starts at the 101st cryptographic candidate in the global cryptographic candidate set and contains 100 cryptographic candidates. This metadata is used in subsequent task allocation and when the control core receives tasks, enabling the control core to accurately locate the range of cryptographic candidates it needs to process, ensuring the accuracy and efficiency of task allocation. The main control unit organizes and stores this task block metadata for use in subsequent task allocation processes.

[0067] In this embodiment, the main control unit can efficiently generate a global cryptanalysis candidate space according to the cryptanalysis mode specified by the user, and reasonably divide it into coarse-grained task blocks suitable for parallel processing by multiple control cores, laying the foundation for subsequent cryptanalysis task allocation and parallel computing.

[0068] In some embodiments, step S101 above, which involves statically allocating multiple coarse-grained task blocks to each acceleration cluster, specifically includes: Based on the main control unit, according to the total number of acceleration clusters, multiple coarse-grained task blocks are evenly divided into task block groups equal to the total number of acceleration clusters, and each task block group corresponds to an acceleration cluster; A static mapping relationship is established between each task block group and the corresponding acceleration cluster, and the static mapping relationship is recorded in the memory of the main control unit; For each acceleration cluster, the master control unit writes the task block metadata of each coarse-grained task block in the task block group corresponding to the acceleration cluster into a preset control area in the high-bandwidth shared memory of the acceleration cluster.

[0069] In this embodiment, in the multi-control-core parallel cryptanalysis based on domestically produced supercomputing nodes, there exists a scenario where multiple acceleration clusters work collaboratively. Due to the high communication costs between acceleration clusters, improper task allocation can lead to significant time wasted on data transmission and communication coordination, thereby reducing the overall cryptanalysis efficiency of the system. Therefore, an effective task allocation scheme is needed to rationally distribute the multiple coarse-grained task blocks generated by the main control unit to each acceleration cluster, in order to fully utilize the computing resources of each acceleration cluster and improve the overall system performance.

[0070] The main control unit first groups and plans multiple coarse-grained task blocks according to the total number of acceleration clusters. In this embodiment, the total number of acceleration clusters is 4. The main control unit evenly divides the multiple coarse-grained task blocks into task block groups equal to the total number of acceleration clusters, that is, into 4 task block groups, with each task block group corresponding to one acceleration cluster. The purpose of this even division is to ensure that each acceleration cluster can undertake approximately equal workloads, achieve load balancing, and avoid situations where one acceleration cluster is overloaded while other acceleration clusters are idle, thereby improving the overall computing efficiency of the system.

[0071] After determining the correspondence between task block groups and acceleration clusters, the main control unit establishes a static mapping relationship between each task block group and its corresponding acceleration cluster. This static mapping relationship is fixed and pre-defined, and will not change arbitrarily during system operation. For example, task block group 0 is statically mapped to acceleration cluster 0, task block group 1 is statically mapped to acceleration cluster 1, and so on. The main control unit records these static mapping relationships in detail in its memory so that this information can be quickly retrieved and used in subsequent task allocation and management processes. By establishing static mapping relationships, the system can reduce the overhead of dynamic allocation and coordination during runtime, improving the efficiency of task allocation.

[0072] For each acceleration cluster, the master control unit locates the corresponding task block group based on the previously established static mapping relationship. Then, the master control unit writes the task block metadata of each coarse-grained task block within that task block group into a preset control area in the high-bandwidth shared memory of that acceleration cluster. The high-bandwidth shared memory has a high data transfer rate, meeting the acceleration cluster's need for rapid retrieval of task block metadata. The preset control area is specifically allocated for storing task block metadata, ensuring orderly storage and fast access to the metadata. For example, for acceleration cluster 0, the master control unit accurately writes the starting position, number of password candidates, and other metadata of each coarse-grained task block in its corresponding task block group into the preset control area of ​​the high-bandwidth shared memory for acceleration cluster 0. Thus, when the acceleration cluster starts working, its internal control core can quickly read its own task block metadata from the preset control area of ​​the high-bandwidth shared memory, thereby beginning to execute the corresponding cryptanalysis task.

[0073] In this embodiment, the main control unit can efficiently statically allocate multiple coarse-grained task blocks to each acceleration cluster and ensure that each acceleration cluster can obtain relevant task information in a timely manner, laying a good foundation for subsequent parallel cryptanalysis calculations and effectively improving the overall performance and computational efficiency of the system.

[0074] In some embodiments, step S102 above, specifically, loading the corresponding pre-compiled device-side kernel image to the on-chip memory of the acceleration cluster via the hthread interface for each acceleration cluster, and activating all control cores within the acceleration cluster as independent threads to execute the pre-compiled device-side kernel image, specifically includes: Call the hthread device open interface to open the target acceleration cluster and establish a communication context with that target acceleration cluster; Based on the current cryptanalysis pattern, determine the target kernel image file corresponding to the cryptanalysis pattern from multiple pre-compiled device kernel images; Call the hthread data loading interface to load the target kernel image file into the on-chip memory of the target acceleration cluster; The hthread thread group creation interface is called to start all control cores within the target acceleration cluster at once, so that each control core executes as an independent thread starting from the entry symbol of the target kernel image file.

[0075] In this embodiment, different cryptanalysis modes (such as SHA256, NTLM, etc.) require different device kernel images to execute the corresponding computational logic. Simultaneously, to fully leverage the parallel computing capabilities of multiple control cores within the acceleration cluster, each control core needs to be activated as an independent thread, enabling it to begin task execution from the correct entry point. However, due to the special hardware architecture and communication mechanisms of the acceleration cluster, accurately loading the device kernel and effectively activating the control cores become key issues for improving system performance and efficiency.

[0076] Specifically, for each acceleration cluster that needs to execute a task, the master control unit first calls the hthread device open interface, that is, performs an operation similar to hthread_dev_open (here, the function description is used instead of the specific function name), to open the target acceleration cluster. The main purpose of this operation is to establish a stable communication context between the master control unit and the target acceleration cluster. By establishing a communication context, the master control unit can effectively transmit data and exchange instructions with the acceleration cluster, laying the foundation for subsequent operations such as device kernel loading and control kernel activation. For example, when opening acceleration cluster 0, the master control unit establishes a connection with acceleration cluster 0 through this interface, ensuring that both parties can accurately identify each other and perform subsequent communication operations.

[0077] The main control unit determines the corresponding target kernel image file from multiple pre-compiled device kernel images based on the current cryptanalysis mode. Different cryptanalysis modes have different algorithmic logic and computational requirements, thus requiring different device kernel images to support them. For example, if the current cryptanalysis mode is SHA256, because the SHA256 algorithm has a specific computational process and data processing method, the main control unit needs to select sha256_kernel.dat (illustrated here with a specific filename example) specifically generated for the SHA256 algorithm from multiple pre-compiled device kernel images as the target kernel image file; if the cryptanalysis mode is NTLM, then the corresponding ntlm_kernel.dat is selected as the target kernel image file. These pre-compiled device kernel images are independently compiled by the device for different algorithms and input processing logic, ensuring correct execution of computational tasks under the corresponding cryptanalysis mode.

[0078] After identifying the target kernel image file, the main control unit calls the hthread data loading interface to load the target kernel image file into the on-chip memory of the target acceleration cluster. On-chip memory offers high access speed, providing rapid data reading and instruction fetching support for the execution of the device-side kernel. For example, for target acceleration cluster 0, the main control unit accurately loads the selected target kernel image file into the on-chip memory of acceleration cluster 0 by calling the corresponding data loading interface, ensuring that the device-side kernel can quickly access the required code and data during subsequent execution.

[0079] The main control unit calls the hthread thread group creation interface to launch all control cores within the target acceleration cluster at once, enabling each control core to execute as an independent thread starting from the entry symbol of the target kernel image file. Each control core, as an independent computing unit, can execute cryptanalysis tasks in parallel, thus fully utilizing the parallel computing capabilities of the acceleration cluster. For example, in target acceleration cluster 0, there are 24 control cores. The main control unit activates these 24 control cores at once by calling the thread group creation interface, forming a thread group containing 24 hthread threads. Each control core starts from the entry symbol of the target kernel image file and executes cryptanalysis tasks according to predetermined computational logic. Simultaneously, the main control unit writes the list of task blocks allocated to the acceleration cluster (including metadata pointers, quantities, etc.) into the cluster's high-bandwidth shared memory (HBSM). During execution, the control core can read task block information from the HBSM, obtain the cryptanalysis candidate data to be processed, and store the computation results and other data back to the corresponding memory areas.

[0080] In this embodiment, the main control unit can successfully complete the loading of the device kernel and activation of the control kernel for each acceleration cluster, enabling each acceleration cluster to efficiently execute cryptanalysis tasks according to a predetermined cryptanalysis mode, thereby improving the computational efficiency and performance of the entire system.

[0081] In some embodiments, step S103 above, specifically determining and retrieving the subtask block belonging to the control core from the high-bandwidth shared memory of the acceleration cluster based on its unique identifier within the cluster, includes: For each control core, call the thread identifier acquisition interface to obtain the unique identifier of that control core within its acceleration cluster; Enable all control cores to collaboratively access the task block metadata list stored in the high-bandwidth shared memory of the acceleration cluster, and filter out the target task block metadata that has a preset correspondence with the unique identifier from the task block metadata list; Each control core determines the range of subtask blocks belonging to that control core in the global cryptographic candidate space based on the target task block metadata, and reads the cryptographic candidate data corresponding to the subtask blocks from high-bandwidth shared memory.

[0082] In this embodiment, each acceleration cluster contains multiple control cores that need to execute cryptanalysis tasks in parallel. To achieve efficient parallel computing, the multiple sub-task blocks into which the global cryptanalysis candidate space is divided need to be rationally allocated to each control core. However, due to the large number of control cores and the need for efficient and accurate task allocation within the acceleration cluster, designing an effective task assignment mechanism becomes a key issue for improving system performance.

[0083] Specifically, for each activated control core, before it begins executing the task retrieval operation, it first needs to call the thread identifier acquisition interface to obtain a unique identifier for that control core within its acceleration cluster. This unique identifier is crucial for distinguishing different control cores; each control core has a unique identifier within the acceleration cluster. For example, among the 24 control cores in an acceleration cluster, each control core can obtain a unique ID from 0 to 23 by calling the corresponding interface. This ID will be used in the subsequent task filtering and retrieval process.

[0084] After all control cores have obtained their unique identifiers, they collaboratively access the task block metadata list stored in the High Bandwidth Shared Memory (HBSM) of their respective acceleration cluster. HBSM offers a high data transfer rate, sufficient to meet the simultaneous access needs of multiple control cores. The control cores jointly review the task block metadata list, which contains information about each subtask block. Each control core, based on its unique identifier, filters the task block metadata list to find the target task block metadata that has a predefined correspondence with that unique identifier. For example, a correspondence can be established such that each control core receives task blocks whose ID, modulo the number of control cores, equals its own ID. In this way, each control core can accurately locate its own target task block metadata, preparing it for subsequently receiving subtask blocks.

[0085] After filtering the target task block metadata, each control core determines the range of subtask blocks belonging to that control core within the global cryptographic candidate space based on this metadata. The target task block metadata contains information such as the starting position of the subtask block in the global cryptographic candidate space and the number of cryptographic candidates. By parsing this information, the control core can clearly define the specific range of cryptographic candidates it needs to process. Subsequently, the control core reads the cryptographic candidate data corresponding to the subtask block from high-bandwidth shared memory. To facilitate subsequent computation, the control core can batch-load the acquired cryptographic candidates into the cluster's global shared memory (GSM) or high-bandwidth shared memory (HBSM). This allows the control core to quickly retrieve the required cryptographic candidate data from the corresponding memory region during subsequent cryptanalysis computations, improving computational efficiency.

[0086] In this embodiment, each control core can accurately and efficiently obtain its own subtask block and corresponding cryptographic candidate data within its acceleration cluster, laying a good foundation for subsequent parallel cryptographic analysis calculations and helping to improve the overall system's computing performance and resource utilization.

[0087] In some embodiments, step S104 above, specifically, for each control core, reading the password candidates in the subtask block into its private scalar memory, and independently executing the complete hash calculation process within the private scalar memory to generate the calculation result, includes: Each control core preloads the constant table and intermediate state variables required by the target hash algorithm into its private scalar memory, and reads the password candidates contained in the subtask blocks into its private scalar memory in batches from the shared memory of the acceleration cluster. For a single password candidate read into private scalar memory, the corresponding control core performs a message padding operation on the password candidate according to the standard specification of the target hash algorithm, generates a padded message that meets the requirement of being an integer multiple of the block size, and divides the padded message into several data blocks; Each control core performs multiple rounds of nonlinear compression operations on each data block sequentially within its private scalar memory, and updates the intermediate state variables stored in its private scalar memory after each round of operations. After all data blocks have completed multiple rounds of nonlinear compression operations, each control core combines the intermediate state variables finally stored in its private scalar memory into the calculation result.

[0088] In this embodiment, hash calculation is a crucial step in cryptanalysis. However, hash algorithm calculation is complex, involving a large number of data operations and state updates. Traditional calculation methods may suffer from low computational efficiency due to issues such as memory access latency and data transfer overhead. The control kernel's private scalar memory (SM) offers fast access; therefore, effectively utilizing this feature to optimize the hash calculation process is key to improving the system's cryptanalysis performance.

[0089] Specifically, firstly, to fully leverage the fast access advantage of the control core's private scalar memory, each control core preloads the constant table and intermediate state variables required by the target hash algorithm into its private scalar memory. For example, for the MD5 algorithm, its T[i] constant table and related data such as intermediate state registers (A, B, C, D...) are preloaded into its private scalar memory; for the SHA-256 algorithm, necessary data such as the K[t] constant table are loaded. Since the amount of cryptographic candidate data is usually large, it is impossible to fit it completely into the control core's 64KB private scalar memory, so the shared memory (HBSM / GSM) of the acceleration cluster is used as a secondary cache. The control core reads the cryptographic candidates contained in the subtask blocks from the shared memory of the acceleration cluster into its private scalar memory in batches to meet the subsequent computational needs.

[0090] For a single password candidate read into private scalar memory, the corresponding control core performs a message padding operation on the candidate according to the standard specifications of the target hash algorithm. Taking a common hash algorithm as an example, a "1" bit is typically appended to the end of the password candidate, followed by several "0" bits as padding, thus generating a standardized message with a length that is an integer multiple of the block size. This step ensures that the password candidate conforms to the hash algorithm's requirements for input data format, preparing for subsequent message segmentation and computation. For example, if the hash algorithm requires a block size of 512 bits, the control core ensures that the length of the password candidate is an integer multiple of 512 bits by padding the password candidate.

[0091] After message stuffing is complete, the control core divides the stuffed message into several data blocks of a fixed size (e.g., 512 bits). For each block, the control core executes an algorithm-specific message scheduling process. For example, in the MD5 or SHA-1 algorithm, the control core expands each 512-bit block into 64 32-bit words for subsequent round function calculations. This step, through the expansion and scheduling of data blocks, provides suitable data input for multiple rounds of nonlinear compression operations.

[0092] Each control core, within its private scalar memory, sequentially performs multiple rounds of non-linear compression operations on each partitioned and expanded data block. During each round, the control core performs operations including logical functions, constant mixing, and circular left shifts. For example, a specific hash algorithm might involve the use of logical functions such as AND, OR, and NOT, as well as mixing operations with predefined constants, and circular left shifts to change the data's bit order. After each round of computation, the control core updates the intermediate state variables stored in its private scalar memory. These intermediate state variables are crucial data in the hash calculation process; through continuous updates, they gradually approach the final hash result.

[0093] After all data blocks have undergone multiple rounds of nonlinear compression operations, each control core combines the intermediate state variables finally stored in its private scalar memory into a calculation result. These intermediate state variables, updated and evolved through multiple rounds of operations, already contain key information about the cryptographic candidates after hash calculation. Following the specifications of the target hash algorithm, the control core combines these intermediate state variables to form the final hash calculation result. For example, the values ​​in the intermediate state registers are concatenated in a specific order to obtain the final hash value.

[0094] Throughout the computation, since this scheme executes entirely within the control core's scalar units without requiring the involvement of the acceleration core, the 768KB array memory (AM) designed for SIMD is not used. Simultaneously, the intermediate state variables of the hash algorithm always reside in the registers of the current control core or its private 64KB scalar memory (SM), avoiding access to off-chip or shared global memory, thereby effectively improving computational efficiency and reducing latency.

[0095] In this embodiment, the control kernel can efficiently and accurately complete the entire hash calculation process in its private scalar memory, generate calculation results, and provide strong support for subsequent cryptanalysis work.

[0096] In some embodiments, step S105 above, specifically, for any control core, when its generated calculation result matches the target hash value, writing the plaintext corresponding to the calculation result into the local result buffer in the high-bandwidth shared memory of the acceleration cluster through atomic operations, includes: For each acceleration cluster, during the initialization phase of the main control unit, a local result buffer is pre-allocated in the high-bandwidth shared memory of the acceleration cluster. The local result buffer is used to temporarily store the matching records reported by each control core in the acceleration cluster. For any control core, after generating the calculation result, the calculation result is compared with the target hash value pre-distributed by the main control unit. If the two are consistent, it is determined that the match is successful. When a match is determined to be successful, the control kernel performs a comparison and exchange atomic operation to write the matching record, which contains the plaintext of the calculated result and the identifier corresponding to the target hash value, into the local result buffer of the acceleration cluster without locking. During or after the calculation, the main control unit sequentially accesses the high-bandwidth shared memory of each acceleration cluster, pulls matching records from their respective local result buffers, and performs aggregation and deduplication processing in the memory of the general processing area where the main control unit is located.

[0097] In this embodiment, when the calculation result generated by a control core matches the target hash value, the relevant result needs to be reported promptly. However, the MT-3000 has a limitation that inter-cluster communication is not possible, making traditional result collection methods unsuitable. Therefore, an effective result reporting mechanism needs to be designed to ensure accurate and efficient collection of matching results from each control core for subsequent processing.

[0098] Specifically, for each acceleration cluster, during the initialization phase of the master control unit, a local result buffer is pre-allocated in the high-bandwidth shared memory (HBSM) of that acceleration cluster. This step requires comprehensive consideration of factors such as the expected system load and the amount of result data to reasonably determine the size of the local result buffer. For example, based on experience from similar cryptanalysis tasks in the past, the number of matching records that the control core within each acceleration cluster may generate is estimated, thereby allocating sufficient storage space for the local result buffer. The main function of the local result buffer is to temporarily store the matching records reported by each control core within the acceleration cluster, providing a data source for subsequent result collection and processing.

[0099] For any control core, after completing the cryptanalysis calculation and generating the result, its result is compared with the target hash value pre-distributed by the master control unit. During the task allocation phase, the master control unit distributes the corresponding target hash value to each control core as the comparison standard for the calculation results. The control core determines whether the calculation result matches the target hash value through precise numerical comparison. If they match, it is considered a successful match, meaning that the control core has found the hash value corresponding to the required plaintext ciphertext; if they do not match, it continues with subsequent calculation tasks or waits for a new task allocation.

[0100] Upon successful matching, the control core needs to write the matching record to the local result buffer using a specific atomic operation. Since multiple control cores may attempt to write to the local result buffer simultaneously in the MT-3000 architecture, a Compare-and-Swap (CAS) atomic operation is used to avoid data conflicts and race conditions. The control core writes the matching record, containing the plaintext of the calculated result and the identifier corresponding to the target hash value, to the local result buffer of its accelerated cluster without locking using the CAS atomic operation. The CAS atomic operation ensures that data writing operations are atomic in a multi-threaded environment (where the control core can be considered an independent thread); either the data is completely written, or it is not written at all, avoiding data inconsistency and conflict issues, and guaranteeing the accuracy and integrity of the data in the local result buffer.

[0101] Based on the limitation that MT-3000 clusters cannot communicate directly, a cross-cluster result retrieval mechanism is designed. The master control unit periodically (e.g., at regular time intervals) or through interrupt triggering accesses the high-bandwidth shared memory of each acceleration cluster sequentially. When accessing each acceleration cluster, the master control unit retrieves the found matching records from the local result buffer of that acceleration cluster. Since the computation progress of different acceleration clusters may differ, the master control unit needs to access each acceleration cluster in a specific order to ensure that all possible matching results are collected. After collecting the matching records from all acceleration clusters into the memory of the general processing area where the master control unit resides, the master control unit performs global deduplication and persistent storage processing on these matching records. Deduplication is performed to avoid duplicate records interfering with subsequent analysis, while persistent storage saves the results to a stable storage medium for subsequent querying, analysis, and use.

[0102] The above two-level result reporting mechanism can effectively solve the problem of result collection caused by the inability to communicate directly between MT-3000 clusters, ensuring that the cryptanalysis results can be collected and processed accurately and efficiently, and providing a strong guarantee for the successful completion of the cryptanalysis task.

[0103] Furthermore, the process of generating the pre-compiled device-side kernel image includes: The device-side kernel source code is compiled using a dedicated cross-compiler that matches the architecture of the acceleration zone, and specific compilation options adapted to the hardware characteristics of the acceleration zone are enabled during the compilation process to generate target files. The target file is linked with the device runtime library to generate an intermediate executable file that can be executed in the bare metal environment of the acceleration zone; A dedicated format conversion tool is invoked to convert the intermediate executable file into a binary image file that meets the requirements of the host-side loading interface, and the binary image file is identified as a pre-compiled device-side kernel image.

[0104] In this embodiment, because general compilation methods are often unable to adapt to the unique hardware characteristics of the accelerator, the generated program may fail to run properly or have poor performance. Therefore, a pre-compiled device kernel image generation scheme specifically for the accelerator architecture is needed to ensure that the device kernel can fully utilize the computing power of the accelerator while effectively interacting and cooperating with the host.

[0105] Specifically, first, the device-side kernel source code is compiled using a dedicated cross-compiler matched to the accelerator architecture. This dedicated cross-compiler can identify the instruction set and hardware characteristics of the accelerator, laying the foundation for subsequent generation of programs adapted to the accelerator. During compilation, specific compilation options adapted to the accelerator hardware characteristics are enabled. These specific compilation options are designed for the special hardware of the accelerator. For example, in the MT-3000 architecture, enabling specific compilation options such as -fenable-m3000 allows the compiler to fully consider the processor characteristics and memory architecture of the MT-3000 when generating object files, optimizing and adapting the code to generate object files tightly integrated with the accelerator hardware. Through this step, the device-side kernel source code is converted into computer-recognizable intermediate code, providing a foundation for subsequent linking and conversion.

[0106] The generated target file is linked with the device-side runtime library. The device-side runtime library contains various functions and functionalities required for device programs to run in the accelerator bare-metal environment, such as memory management functions and thread management functions. Through the linking operation, the target file is integrated with these library files to generate an intermediate executable file that can run in the accelerator bare-metal environment. Taking the MT-3000 as an example, device-side libraries such as libhthread_device.a and vlib3000.a are linked. These libraries provide low-level support related to the MT-3000 hardware, enabling the generated intermediate executable file to run correctly in the MT-3000's accelerator environment and complete the expected tasks such as cryptanalysis.

[0107] A dedicated format conversion tool is used to convert the intermediate executable file into a binary image file that conforms to the host-side loading interface requirements. This tool adjusts and converts the format of the intermediate executable file according to the specifications and requirements of the host-side loading interface. For example, in the MT-3000 system, the MT3000-makedat tool is used to convert an ELF executable file (such as kernel.out) into a .dat format binary image file (such as kernel.dat). This binary image file has a specific format and structure, enabling it to be directly recognized by the host-side API and loaded into the accelerated cluster memory for execution. The converted binary image file is then identified as a pre-compiled device-side kernel image. This image file contains all the code and data required for the device-side kernel to run in the accelerated area and meets the host-side loading requirements, facilitating subsequent loading and execution of the device-side kernel by the host.

[0108] Through the complete pre-compiled device kernel image generation process described above, a device kernel image that is adapted to the acceleration zone architecture and meets the host loading requirements can be generated, ensuring that the device program runs efficiently and stably in the bare metal environment of the acceleration zone, thereby supporting the smooth execution of multi-control core parallel computing tasks of the entire system.

[0109] Reference Figure 4 An embodiment of the present invention provides a multi-control core parallel cryptoanalysis system 4 based on hthread, specifically including: The cross-cluster allocation module 401 is used to generate a global cryptographic candidate space based on the main control unit of the general processing area deployed on the domestic supercomputing node, according to the cryptographic analysis mode specified by the user, divide the global cryptographic candidate space into multiple coarse-grained task blocks, and statically allocate the multiple coarse-grained task blocks to each acceleration cluster. The thread activation module 402 is used to load the corresponding pre-compiled device kernel image into the on-chip memory of each acceleration cluster through the hthread interface, and activate all control cores in the acceleration cluster as independent threads to execute the pre-compiled device kernel image. The task acquisition module 403 is used to determine and acquire subtask blocks belonging to each control core from the high-bandwidth shared memory of the acceleration cluster based on its unique identifier within the acceleration cluster. The hash calculation module 404 is used to read the password candidates in the subtask block into its private scalar memory for each control core, and independently execute the complete hash calculation process in the private scalar memory to generate the calculation result. The matching and reporting module 405 is used to write the plaintext of the cryptographic result corresponding to the calculation result into the local result buffer in the high-bandwidth shared memory of the acceleration cluster through atomic operations when the calculation result generated by any control core matches the target hash value.

[0110] It is understandable that, such as Figure 1 The content of the hthread-based multi-control-core parallel cryptanalysis method embodiment shown is applicable to this hthread-based multi-control-core parallel cryptanalysis system embodiment. The specific functions implemented in this hthread-based multi-control-core parallel cryptanalysis system embodiment are the same as those shown below. Figure 1 The embodiment of the hthread-based multi-control-core parallel cryptanalysis method shown is the same, and the beneficial effects achieved are the same as those described above. Figure 1 The beneficial effects achieved by the embodiment of the hthread-based multi-control-core parallel cryptanalysis method shown are also the same.

[0111] It should be noted that the information interaction and execution process between the above systems are based on the same concept as the method embodiments of the present invention. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0112] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0113] Reference Figure 5 The present invention also provides a computer device 5, including: a memory 502 and a processor 501, and a computer program 503 stored in the memory 502. When the computer program 503 is executed on the processor 501, it implements the hthread-based multi-control core parallel cryptographic analysis method as described in any of the above methods.

[0114] The computer device 5 may be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device 5 may include, but is not limited to, a processor 501 and a memory 502. Those skilled in the art will understand that... Figure 5The computer device 5 is merely an example and does not constitute a limitation on the computer device 5. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0115] The processor 501 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0116] In some embodiments, the memory 502 may be an internal storage unit of the computer device 5, such as a hard disk or memory of the computer device 5. In other embodiments, the memory 502 may be an external storage device of the computer device 5, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 5. Furthermore, the memory 502 may include both internal and external storage units of the computer device 5. The memory 502 is used to store the operating system, applications, boot loader, data, and other programs, such as the program code of the computer program. The memory 502 can also be used to temporarily store data that has been output or will be output.

[0117] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the hthread-based multi-control-core parallel cryptanalysis method as described in any of the above methods.

[0118] In this embodiment, if the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0119] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0120] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0121] In the embodiments disclosed in this application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0122] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

Claims

1. A multi-control-core parallel cryptanalysis method based on hthread, characterized in that, Specifically, it includes: Based on the main control unit of the general processing area deployed on domestic supercomputing nodes, a global cryptographic candidate space is generated according to the cryptographic analysis mode specified by the user. The global cryptographic candidate space is divided into multiple coarse-grained task blocks, and the multiple coarse-grained task blocks are statically allocated to each acceleration cluster. For each acceleration cluster, the corresponding pre-compiled device kernel image is loaded into the on-chip memory of that acceleration cluster through the hthread interface, and all control cores in that acceleration cluster are activated as independent threads to execute the pre-compiled device kernel image. For each control core, based on its unique identifier within its acceleration cluster, the subtask block belonging to that control core is determined and retrieved from the high-bandwidth shared memory of that acceleration cluster. For each control core, the password candidates in the subtask block are read into its private scalar memory, and the complete hash calculation process is executed independently in the private scalar memory to generate the calculation result. For any control core, when the computation result it generates matches the target hash value, the corresponding cryptographic plaintext is written to the local result buffer in the high-bandwidth shared memory of the acceleration cluster through atomic operations.

2. The method according to claim 1, characterized in that, The main control unit, based on the general processing area deployed on domestic supercomputing nodes, generates a global cryptographic candidate space according to the user-specified cryptographic analysis mode, and divides the global cryptographic candidate space into multiple coarse-grained task blocks, specifically including: The system receives a user-specified cryptanalysis pattern and its corresponding parameters, and dynamically constructs a global cryptanalysis candidate set based on the cryptanalysis pattern. The cryptanalysis patterns include mask patterns, dictionary patterns, and combination patterns. Based on the main control unit, according to the total number of control cores, the global cryptographic candidate set is divided into coarse-grained task blocks of no less than the total number of control cores. Each coarse-grained task block includes several cryptographic candidates to be verified. For each coarse-grained task block, corresponding task block metadata is generated. The task block metadata includes the starting position of the corresponding coarse-grained task block in the global cryptographic candidate set and the number of cryptographic candidates.

3. The method according to claim 1, characterized in that, The step of statically allocating multiple coarse-grained task blocks to each acceleration cluster specifically includes: Based on the main control unit, according to the total number of acceleration clusters, multiple coarse-grained task blocks are evenly divided into task block groups equal to the total number of acceleration clusters, and each task block group corresponds to an acceleration cluster; A static mapping relationship is established between each task block group and the corresponding acceleration cluster, and the static mapping relationship is recorded in the memory of the main control unit; For each acceleration cluster, the master control unit writes the task block metadata of each coarse-grained task block in the task block group corresponding to the acceleration cluster into a preset control area in the high-bandwidth shared memory of the acceleration cluster.

4. The method according to claim 1, characterized in that, For each acceleration cluster, the corresponding pre-compiled device-side kernel image is loaded into the on-chip memory of that acceleration cluster via the hthread interface, and all control cores within that acceleration cluster are activated as independent threads to execute the pre-compiled device-side kernel image. Specifically, this includes: Call the hthread device open interface to open the target acceleration cluster and establish a communication context with that target acceleration cluster; Based on the current cryptanalysis pattern, determine the target kernel image file corresponding to the cryptanalysis pattern from multiple pre-compiled device kernel images; Call the hthread data loading interface to load the target kernel image file into the on-chip memory of the target acceleration cluster; The hthread thread group creation interface is called to start all control cores within the target acceleration cluster at once, so that each control core executes as an independent thread starting from the entry symbol of the target kernel image file.

5. The method according to claim 1, characterized in that, For each control core, based on its unique identifier within its acceleration cluster, the subtask block belonging to that control core is determined and retrieved from the high-bandwidth shared memory of that acceleration cluster. Specifically, this includes: For each control core, call the thread identifier acquisition interface to obtain the unique identifier of that control core within its acceleration cluster; Enable all control cores to collaboratively access the task block metadata list stored in the high-bandwidth shared memory of the acceleration cluster, and filter out the target task block metadata that has a preset correspondence with the unique identifier from the task block metadata list; Each control core determines the range of subtask blocks belonging to that control core in the global cryptographic candidate space based on the target task block metadata, and reads the cryptographic candidate data corresponding to the subtask blocks from high-bandwidth shared memory.

6. The method according to claim 1, characterized in that, For each control core, the password candidates in the subtask block are read into its private scalar memory, and a complete hash calculation process is independently executed within the private scalar memory to generate the calculation result. Specifically, this includes: Each control core preloads the constant table and intermediate state variables required by the target hash algorithm into its private scalar memory, and reads the password candidates contained in the subtask blocks into its private scalar memory in batches from the shared memory of the acceleration cluster. For a single password candidate read into private scalar memory, the corresponding control core performs a message padding operation on the password candidate according to the standard specification of the target hash algorithm, generates a padded message that meets the requirement of being an integer multiple of the block size, and divides the padded message into several data blocks; Each control core performs multiple rounds of nonlinear compression operations on each data block sequentially within its private scalar memory, and updates the intermediate state variables stored in its private scalar memory after each round of operations. After all data blocks have completed multiple rounds of nonlinear compression operations, each control core combines the intermediate state variables finally stored in its private scalar memory into the calculation result.

7. The method according to claim 1, characterized in that, For any control core, when its generated calculation result matches the target hash value, the corresponding plaintext of the calculation result is written to the local result buffer in the high-bandwidth shared memory of the acceleration cluster through atomic operations, specifically including: For each acceleration cluster, during the initialization phase of the main control unit, a local result buffer is pre-allocated in the high-bandwidth shared memory of the acceleration cluster. The local result buffer is used to temporarily store the matching records reported by each control core in the acceleration cluster. For any control core, after generating the calculation result, the calculation result is compared with the target hash value pre-distributed by the main control unit. If the two are consistent, it is determined that the match is successful. When a match is determined to be successful, the control kernel performs a comparison and exchange atomic operation to write the matching record, which contains the plaintext of the calculated result and the identifier corresponding to the target hash value, into the local result buffer of the acceleration cluster without locking. During or after the calculation, the main control unit sequentially accesses the high-bandwidth shared memory of each acceleration cluster, pulls matching records from their respective local result buffers, and performs aggregation and deduplication processing in the memory of the general processing area where the main control unit is located.

8. The method according to any one of claims 1 to 7, characterized in that, The domestically produced supercomputing node is MT-3000. MT-3000 includes a general processing area and an acceleration area. The general processing area is responsible for task management, data input / output and general computing. The acceleration area includes multiple DSP acceleration clusters. Each DSP acceleration cluster includes global shared memory, high-bandwidth shared memory and multiple acceleration arrays. Each acceleration array includes a control core and multiple acceleration cores.

9. The method according to claim 8, characterized in that, The process of generating the pre-compiled device kernel image includes: The device-side kernel source code is compiled using a dedicated cross-compiler that matches the architecture of the acceleration zone, and specific compilation options adapted to the hardware characteristics of the acceleration zone are enabled during the compilation process to generate target files. The target file is linked with the device runtime library to generate an intermediate executable file that can be executed in the bare metal environment of the acceleration zone; A dedicated format conversion tool is invoked to convert the intermediate executable file into a binary image file that meets the requirements of the host-side loading interface, and the binary image file is identified as a pre-compiled device-side kernel image.

10. A multi-core parallel cryptoanalysis system based on hthread, characterized in that, Specifically, it includes: The cross-cluster allocation module is used to generate a global cryptographic candidate space based on the main control unit of the general processing area deployed on domestic supercomputing nodes, according to the cryptographic analysis mode specified by the user, divide the global cryptographic candidate space into multiple coarse-grained task blocks, and statically allocate the multiple coarse-grained task blocks to each acceleration cluster. The thread activation module is used to load the corresponding pre-compiled device kernel image into the on-chip memory of each acceleration cluster through the hthread interface, and activate all control cores in the acceleration cluster as independent threads to execute the pre-compiled device kernel image. The task retrieval module is used to determine and retrieve the subtask blocks belonging to each control core from the high-bandwidth shared memory of the acceleration cluster based on its unique identifier within the acceleration cluster. The hash calculation module is used to read the password candidates in the subtask block into its private scalar memory for each control core, and independently execute the complete hash calculation process in the private scalar memory to generate the calculation result. The matching and reporting module is used to write the plaintext of the cryptography corresponding to the calculation result into the local result buffer in the high-bandwidth shared memory of the acceleration cluster when the calculation result generated by any control core matches the target hash value.

Images