## 4 Results and Discussion
### Comparative Analysis  
In our proposed parallel implementation, we chose to utilize the master-slave approach with our proposed modification using the Message Passing Interface standard to improve the performance of rainbow tables generation. The classic master-slave approach relies on the master process to generate tasks and distribute them among the slave processes. As the distribution of tasks requires communications between processes, which contributes to the execution time, we gave each process, including the master process, the responsibility of \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Hash Function** & **Digest Size** & **Block Size** & **Number of Rounds** \\ \hline SHA-256 & 256 bits (32 bytes) & 512 bits (64 bytes) & 64 rounds \\ SHA-512 & 512 bits (64 bytes) & 1024 bits (128 bytes) & 80 rounds \\ MD5 & 128 bits (16 bytes) & 512 bits (64 bytes) & 64 rounds \\ NTLMv2 & 128 bits (16 bytes) & No fixed block size (based on MD4) & 3 rounds \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Summary of cryptographic hash functions internal characteristics. generating the tasks (generate starting points for rainbow chains) for themselves, which reduces the amount of communications between processes and, as a result, improves the performance of the implementation. In this section, we aim to compare our results to three other MPI-based implementations from [PERSON] et al. [37], [PERSON] [10] and [PERSON] et al. [38], who used MPI to speed up the rainbow tables generation. The first two implementations are quite old, but they still present questions relevant to modern computing. Each implementation, including the approach in this paper, differs in the problem being solved. [PERSON] et al. [37] focused on improving the RainbowCrack tool for rainbow tables attack, essentially targeting the long time required to generate rainbow tables as well as to search them. [PERSON] [10] focused solely on the long time required to generate rainbow tables, and [PERSON] et al. [38] aimed at solving the problem of inefficiency related with discarding merged chains during the generation process. In terms of the parallelization model, only [PERSON] [10] explicitly mentioned the parallelization model (classic master-slave). Our method improves on this model by decentralizing the chains generation to each process (modified master-slave). Looking at the number of computing nodes (or CPU cores), we can see significant differences. [PERSON] [10] was the one utilizing the largest amount of computing nodes (exactly 201 nodes), while [PERSON] et al. [38] utilized the least amount of nodes, equalling five. Our experimental environment consists of 15 CPU nodes. Although the more resources one has the better, it is not always feasible. In terms of performance, [PERSON] [10] achieved the largest performance gain due to the size of the cluster used in his experiments. He reduced the generation time from 816.62 min in sequential implementation to 3.38 min in parallel implementation and reduced the generation time from 7.14 days in sequential implementation to 46.45 min in parallel implementation. His results were measured for generation of a rainbow table consisting of 10,000,000 chains and 100,000,000 chains, respectively, when using 201 computing nodes, one for the master process and 200 for the slave processes. In our case, we are limited with the number of computing nodes; we utilized exactly 15 nodes in our experimental environment. Generating a rainbow table with dimensions close to 10,000,000 chains takes 41.73 min, which is less then it took to generate 100,000,000 chains with the author's parallel implementation. [PERSON] et al. [37] also achieved some performance gain reducing the execution time from an estimated six years to just a few days. This result demonstrates a significant increase in efficiency, indicating the potential of their optimizations or architectural changes in resolving the scalability issues of the original solution. Despite this improvement, the execution time still has practical limitations.