Improve Parallel Resistance of Hashcash Tree

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

The article is well written and contains nice figures, relevant to the readers. They give enough and valuable information about the proposed algorithm. The list of references is long enough and supports this work.

Author Response

We thanks the reviewer for their time.

Reviewer 2 Report

Comments and Suggestions for Authors

I commend the authors for a painstaking, scientifically sound and validated result. One interesting scientific approach in this research is the improvement it brings to existing knowledge using a combination of different known efficient algorithms.

Use of known and functional systems in improving another system for efficiency helps to underscore the usability and dependability of the research outcome. A known an tested algorithm or system reduces trial and error when used on improving another system for efficiency and effectiveness.

Author Response

We thanks the reviewer for their time.

Reviewer 3 Report

Comments and Suggestions for Authors

The paper proposes an improved version of the hashcash tree data structure designed to mitigate Denial-of-Service (DoS) attacks, especially against parallel processing attacks. The results of experiments show its effectiveness. It is so innovative and will provide references to other researchers. Certainly, it will be better to discuss the impact it has on normal users more deeply.

Author Response

Comments 1: Certainly, it will be better to discuss the impact it has on normal users more deeply.

Response 1: We added "Importantly, this change is transparent to the end-user; just as the end-user did not directly interact with or perceive the hashcash computations before, they remain unaware of these processes now." at the end of the conclusion.

Reviewer 4 Report

Comments and Suggestions for Authors

This manuscript presents significant advancements in enhancing the resistance of Hashcash trees against parallel computation, a standard attack strategy in Denial-of-Service (DoS) scenarios. The study addresses the susceptibility of traditional Hashcash-based client puzzle protocols to parallelism, which attackers can exploit to solve computational puzzles rapidly. The authors propose a modified Hashcash tree structure that introduces additional synchronization points during computation. A sequential dependency is enforced by including the labels of child nodes and the subsequent node in a breadth-first search (BFS) traversal within the hash function, thereby increasing the complexity of parallel attacks. However, major revisions are needed before it is finally accepted.

1.     While the paper introduces significant improvements, it lacks a detailed comparative analysis with other existing DoS mitigation techniques beyond Hashcash. Comparing the proposed method with other state-of-the-art techniques, such as memory-bound puzzles or machine learning-based anomaly detection, would provide a clearer understanding of its relative advantages and limitations.

2.     The paper primarily addresses the issue of parallel computation in DoS attacks. However, it does not consider other potential attack vectors or combinations of attack strategies that may exploit different weaknesses in the system. A more comprehensive security analysis could strengthen the paper’s overall impact.

3.     The comprehensive performance evaluation covers a limited range of scenarios and workloads. Testing the system under varying conditions, such as different network loads or types of DoS attacks, would offer a more robust validation of the proposed method’s effectiveness.

Author Response

Comments 1: While the paper introduces significant improvements, it lacks a detailed comparative analysis with other existing DoS mitigation techniques beyond Hashcash. Comparing the proposed method with other state-of-the-art techniques, such as memory-bound puzzles or machine learning-based anomaly detection, would provide a clearer understanding of its relative advantages and limitations.
Response 1: We expanded RW
In addition to the improvements introduced by the hashcash tree method, it is important to compare it with other DoS mitigation techniques to provide a comprehensive understanding of its relative advantages and limitations. 
In particular, we consider here memory-bound puzzles and machine learning-based anomaly detection.
%
Memory-bound puzzles are designed to be computationally intensive in terms of memory access rather than CPU usage. They are particularly effective against attackers using specialized hardware optimized for CPU-bound tasks.
Among their strengths, memory-bound puzzles are difficult to solve with specialized hardware, ensuring a more level playing field between attackers and legitimate users.
On the other hand, these puzzles can be inefficient on devices with limited memory, potentially leading to denial of service to legitimate users as well.
While memory-bound puzzles are effective in certain scenarios, they cannot be employed to protect services that are accessed by general audience, who may use devices with limited memory.
%
Machine learning techniques for DoS mitigation involve training models to detect anomalies in network traffic that may indicate an ongoing attack.
Among their strengths, machine learning models can adapt to new attack patterns and have the potential for high accuracy in detecting sophisticated attacks.
On the other hand, these techniques require extensive datasets for training, are complex to implement, and can suffer from false positives and negatives.
While machine learning offers adaptability and accuracy, hashcash trees provide a simpler and more deterministic approach. 
They are easier to implement and do not require large datasets for training. 
Additionally, hashcash trees can be deployed in real-time scenarios with predictable performance, unlike machine learning models which might require periodic retraining and tuning.
Nonetheless, it is also important to note that a more advanced mitigation method can be obtained by combining machine learning-based anomaly detection systems and hashcash trees, essentially by determining the parameters controlling the difficulty in constructing the hashcash tree based on the anomaly level detected by the machine learning algorithms.

Comments 2: The paper primarily addresses the issue of parallel computation in DoS attacks. However, it does not consider other potential attack vectors or combinations of attack strategies that may exploit different weaknesses in the system. A more comprehensive security analysis could strengthen the paper’s overall impact.
Response 2: We added in the conclusion
Finally, it is important to observe that our puzzle protects the application-layer, while lower layers need different protection mechanisms to prevent, among other attacks, volumetric attacks (e.g., UDP floods) or protocol attacks (e.g., SYN floods).

Comments 3: The comprehensive performance evaluation covers a limited range of scenarios and workloads. Testing the system under varying conditions, such as different network loads or types of DoS attacks, would offer a more robust validation of the proposed method’s effectiveness.
Response 3: We added an experiment and the comment
In order to test the puzzle protocol under varying conditions, we used the \lstinline|stress-ng| utility (\url{https://github.com/ColinIanKing/stress-ng}) to simulate increasing workloads.
In particular, we used the command \lstinline|stress-ng --cpu $n$|, where $n$ was assigned values between 1 and 32, to spawn $n$ workers, each of which uses a CPU at 100\%.
Prefix length was fixed to 4 and the size of the hashcash tree was increased from 15 to 255 nodes.
We measured the CPU usage (user time + system time) of both server and client to address 1000 (one thousand) requests, as well as the elapsed real (wall clock) time used by the process.
Results are shown in Table~\ref{tab:stress}, where we report the wall clock time and the percentage of CPU time used by the server (with respect to the total CPU time used by both the server and the client; we recall here that the time of the server includes the CPU usage for running FastAPI).
It can be observed that even for hashcash trees of small size (15 or 31 nodes), the server has to address an easier computational task than the one addressed by the client.
Finally, we observe that the effort of the server is not significantly affected by the workload of the server, which anyhow is expected to be monitored to determine the size of hashcash trees:
in case the server is overloaded, access to resources is granted only after the client computes an hashcash tree of relatively large size, so to delay the rate of incoming requests.

Round 2

Reviewer 4 Report

Comments and Suggestions for Authors

The authors have satisfactorily modified their manuscript according to my previous criticisms. Therefore, I recommend the publication of this manuscript.