Prepared by:
HALBORN
Last Updated 09/16/2025
Date of Engagement: August 26th, 2024 - September 20th, 2024
100% of all REPORTED Findings have been addressed
All findings
27
Critical
4
High
1
Medium
5
Low
12
Informational
5
Holonym engaged Halborn to perform a security assessment of their Rust codebase from September 2, 2024, to September 27, 2024. The assessment focused on the specific crates listed in the provided GitHub repository and included relevant commit hashes. More details can be found in the Scope section of this report.
The Halborn team was allocated four weeks for the engagement and assigned a full-time security engineer to assess the security of the crates and the overall codebase. The security engineer is an expert in blockchain and smart contract security, with advanced skills in penetration testing and smart contract auditing, as well as extensive knowledge of various blockchain protocols.
The purpose of this assessment is to:
Ensure that codebase functions operate as intended
Identify potential security issues within codebase
Halborn Performed a combination of the manual view of the code and automated security testing to balance efficiency, timeliness, practicality, and accuracy regarding the scope of the codebase assessment. While manual testing is recommended to uncover flaws in logic, process, and implementation, automated testing techniques. They can quickly identify items that do not follow security best practices. The following phases and associated tools were used throughout the term of the assessment:
Research on the architecture, purpose, and usage of the Human network.
Manual code reading and walkthroughs to gain an understanding of the overall design and potential vulnerabilities.
Manual assessment of critical Rust variables and functions to identify arithmetic-related vulnerabilities.
Testing for race conditions and thread safety in the Rust actor framework.
Audit of the DKG (Distributed Key Generation) cryptographic protocol to ensure robustness against potential attacks.
Review of libp2p configuration and security to validate network communication integrity.
Security testing of cryptographic primitives to ensure they meet industry standards.
Scanning Rust files for vulnerabilities using Cargo Audit, identifying outdated dependencies and known security issues.
Checking for unsafe code usage with Cargo Geiger to minimize risks associated with unsafe Rust features.
Analysis of node communication and message integrity to mitigate risks from malicious nodes.
Review of error handling and logging practices to ensure sensitive information is not exposed.
Testing for denial-of-service vulnerabilities and resilience against resource exhaustion attacks.
| EXPLOITABILITY METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Attack Origin (AO) | Arbitrary (AO:A) Specific (AO:S) | 1 0.2 |
| Attack Cost (AC) | Low (AC:L) Medium (AC:M) High (AC:H) | 1 0.67 0.33 |
| Attack Complexity (AX) | Low (AX:L) Medium (AX:M) High (AX:H) | 1 0.67 0.33 |
| IMPACT METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Confidentiality (C) | None (C:N) Low (C:L) Medium (C:M) High (C:H) Critical (C:C) | 0 0.25 0.5 0.75 1 |
| Integrity (I) | None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C) | 0 0.25 0.5 0.75 1 |
| Availability (A) | None (A:N) Low (A:L) Medium (A:M) High (A:H) Critical (A:C) | 0 0.25 0.5 0.75 1 |
| Deposit (D) | None (D:N) Low (D:L) Medium (D:M) High (D:H) Critical (D:C) | 0 0.25 0.5 0.75 1 |
| Yield (Y) | None (Y:N) Low (Y:L) Medium (Y:M) High (Y:H) Critical (Y:C) | 0 0.25 0.5 0.75 1 |
| SEVERITY COEFFICIENT () | COEFFICIENT VALUE | NUMERICAL VALUE |
|---|---|---|
| Reversibility () | None (R:N) Partial (R:P) Full (R:F) | 1 0.5 0.25 |
| Scope () | Changed (S:C) Unchanged (S:U) | 1.25 1 |
| Severity | Score Value Range |
|---|---|
| Critical | 9 - 10 |
| High | 7 - 8.9 |
| Medium | 4.5 - 6.9 |
| Low | 2 - 4.4 |
| Informational | 0 - 1.9 |
Critical
4
High
1
Medium
5
Low
12
Informational
5
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| Unrestricted Growth of PubkeyShares HashMap Can Lead to Out-of-Memory (OOM) | Critical | Solved - 03/08/2025 |
| Message::ForwardMulRequest Potential DDoS | Critical | Solved - 06/04/2025 |
| Inadequate Validation of Messages in DKG Protocol | Critical | Solved - 03/08/2025 |
| Deadlock in DKG | Critical | Solved - 03/08/2025 |
| Lack of Validation for Threshold Parameters in update_threshold Function | High | Solved - 02/13/2025 |
| Incorrect Threshold Check for Multiplication Verification in process_verification Function | Medium | Solved - 03/08/2025 |
| Incomplete Election State Update and Lack of Error Handling in conduct_election Function | Medium | Not Applicable - 03/08/2025 |
| Panic in Polynomial Generation from Seed | Medium | Solved - 06/11/2025 |
| Out-of-Bounds Access Due to Empty Vectors | Medium | Not Applicable - 03/08/2025 |
| Missing t,n Validation in Network Initialization | Medium | Solved - 03/08/2025 |
| Non-Constant Time Cryptographic Operations In PointTrait | Low | Not Applicable - 03/08/2025 |
| Missing Error Handling for encode() in process_verification Function | Low | Not Applicable - 03/08/2025 |
| Lack of I/O Lock for File Operations in StoreKeyShares Handling | Low | Not Applicable - 03/08/2025 |
| Missing Synchronization for Shared State in ElectionEngineState | Low | Not Applicable - 03/08/2025 |
| Insecure RNG for Polynomial Coefficients | Low | Not Applicable - 03/08/2025 |
| Sensitive Data Exposure Through Logging of Seed Value | Low | Solved - 10/10/2024 |
| Misconfigurations in gossip Initialization | Low | Solved - 03/08/2025 |
| Lack of Peer Blacklisting in Gossipsub Engine | Low | Solved - 03/08/2025 |
| Unchecked Return Values in Request and Subscription Handlers | Low | Not Applicable - 03/08/2025 |
| Insufficient Error Handling in handle_store_reshared_received_pubshare | Low | Solved - 06/04/2025 |
| Missing Update of Total Nodes in add_node Function | Low | Not Applicable - 03/08/2025 |
| Multiple Overflows in Polynomial Operations | Low | Not Applicable - 03/08/2025 |
| Invalid Threshold Calculation in calculate_threshold Function | Informational | Not Applicable - 03/08/2025 |
| Function Naming and State Update Issue in check_election_status | Informational | Not Applicable - 03/08/2025 |
| Missing Degree Constraints in Polynomial Creation Function | Informational | Solved - 06/01/2025 |
| Insecure Fallback to Local Random Number Generation | Informational | Not Applicable - 03/08/2025 |
| Use of Non-Cryptographically Secure Random Number Generators in dkg nodes | Informational | Not Applicable - 03/08/2025 |
//Critical
//Critical
//Critical
//Critical
//High
//Medium
//Medium
//Medium
//Medium
//Medium
//Low
//Low
//Low
//Low
//Low
//Low
//Low
//Low
//Low
//Low
//Low
//Low
//Informational
//Informational
//Informational
//Informational
//Informational
Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.
// Download the full report
MPC/Threshold Cryptography
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed
