Skip to main content

Cryptography Code Review and Security Analysis Methodology

Release: Version 1.0

Document​

FieldDescription
CreatorsHacken OU
Subjectaudit; security analysis; cryptography; zero-knowledge, post-quantum cryptography, quantum cryptography, elliptic curve, privacy, private computation
DescriptionThe methodology described herein provides specific guidance on how to plan and execute an audit of cryptography protocols developed by the Hacken OU. This document will enable everyone to get an understanding of an audit and realize how to be prepared for this process.
AuthorNino Lipartiia | L1 Audits Technical Lead, Hacken OU
ContributorMike Mu | Cryptography Auditor, Hacken OU
ContributorReshma Fareed | Cryptography Auditor, Hacken OU
DateOctober 15th, 2025
RightsHacken OU

Part 1. Background to the Cryptography Review and Security Analysis Methodology​

Why Cryptography Audits Matter​

Cryptography is the backbone of digital trust—powering blockchains, banking, secure messaging, authentication, and privacy-preserving technologies. A single flaw, whether in algorithm design or low-level code, can lead to key compromise, signature forgery, or catastrophic data breaches.

Our cryptography audit methodology combines:

  • Mathematical proof review (soundness, completeness, security assumptions).
  • Implementation verification (constant-time safety, randomness testing, memory safety).
  • Security evaluation and resistance to attacks (side-channel and fault analysis, timing, power, EM leakage).
  • Protocol and logic review (correctness of protocol design and application/business logic).

By covering both the theoretical and practical layers, we provide unmatched assurance that your cryptographic system can withstand both current and emerging adversaries—including quantum attackers.

Alignment with International Standards​

Hacken performs all audits and technical assessments in accordance with the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment and the Penetration Testing Execution Standard (PTES). These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews.

The following sections outline how each of our cryptography audit service categories aligns with recognized ISO/IEC cryptographic standards.

1. Post-Quantum Cryptography (PQC)​

  • FIPS204 (Dilithium digital signatures – applicable to lattice-based DSAs).
  • FIPS204 (Sphincs+ digital signatures – applicable to lattice-based DSAs).
  • FIPS203 (Kyber, encryption algorithms – relevant for PQC KEMs).
  • ISO/IEC 19790 (security requirements for cryptographic modules – applied to PQC libraries).

2. Quantum Cryptography​

  • ISO/IEC 23837-1/2 (Security requirements for Quantum Key Distribution).
  • ISO/IEC 20543 (Quantum Random Number Generators).

3. Elliptic Curve Cryptography (ECC)​

  • ISO/IEC 14888 (digital signature mechanisms – covers ECDSA/EdDSA).
  • ISO/IEC 15946 (public key cryptography based on elliptic curves).
  • ISO/IEC 11770 (key management).

4. Zero-Knowledge Proofs (ZKPs)​

No single ISO yet fully covers ZKPs, but applicable frameworks include:

  • ISO/IEC 14888 (signature schemes extended to proof frameworks).
  • ISO/IEC 29192 (lightweight cryptography – relevant for constrained ZKP use cases).

5. Privacy & Private Computation​

  • ISO/IEC 18033-6 (Fully Homomorphic Encryption – draft standardization stage).
  • ISO/IEC 30136 (Key management for privacy-enhancing computation).
  • ISO/IEC 19592 (Secret sharing and secure multiparty computation – related to garbled circuits and MPC).

Part 2. Cryptography Audit and Analysis Phases​

Cryptography Code Review and Security Analysis process consist of the following phases:

  1. Preparations for the audit (Onboarding)
  2. Code review and testing
  3. Reporting
  4. Remediation check

Preparations for Cryptography Audit​

During the preparation phase, clients review their projects to ensure that planned designs are properly implemented. Many issues can already be identified at this stage, which increases the effectiveness and efficiency of the audit.

To get maximum value from the audit, clients should:

  • Prepare documentation on how to set up the development environment and run the project locally. Documentation should be complete and up to date, covering the project’s design, architecture, implementation details, and cryptographic aspects. This ensures transparency, accountability, and makes it easier for auditors to assess the project’s security posture.
  • Provide cryptographic protocol specifications and whitepapers. This includes academic papers, protocol design documents, or internal specifications that describe the mathematical foundations and security assumptions of the system.
  • Prepare functional requirements describing the intended behavior and features of the project.
  • Prepare comprehensive tests (unit, integration, performance, stress, etc.) with detailed instructions on execution.
  • Provide a commit hash for the audit. The audit will be performed against this single, immutable commit, which must remain unchanged once the testing phase has commenced.

Cryptography Audit Process​

1. Overall Review​

  • Define scope (protocols, libraries, algorithms).
  • Assess threat model (classical, quantum, and side-channel).
  • Map compliance requirements (NIST PQC, FIPS, ISO/IEC, CFRG).

2. Code Review and Testing​

  • Algorithm and protocol review — evaluation of mathematical soundness, security assumptions, and alignment with whitepapers or specifications.
  • Implementation code audit — line-by-line manual review, supported by automated scanning tools (static and dynamic analysis).
  • Side-channel and randomness analysis — testing resistance to timing, power, EM leakage, and validation of entropy sources.
  • Adversarial simulation — practical exploitation attempts and fault injection scenarios to evaluate real-world robustness.
  • Continuous reporting — findings are published throughout the audit process, categorized by severity (Critical → Informational). Each issue includes strategic recommendations, and proof-of-concept demonstrations where applicable.

3. Preliminary Audit Report Delivery​

All findings are documented and delivered through Hacken’s reporting portal:

  • Clients gain real-time access to audit results without waiting for the final report.
  • This approach provides flexibility, allowing early discussions, prioritization, and remediation planning.
  • Clear and structured reporting ensures that vulnerabilities and recommended actions are easy to review and address effectively.

Upon completion of the code review, analysis, and testing phases, the auditors prepare a comprehensive preliminary report documenting the audit results. The report typically follows the structure below:

  • Introduction
  • Audit Summary
  • System Overview
  • Risks
  • Findings and Recommendations
  • Disclaimers and Appendices
  • Scope

For High and Critical issues, the methodology requires including Proof of Concept (PoC) test cases in the audit report. A Proof of Concept is a concrete test or exploit scenario demonstrating how a vulnerability can be triggered under real conditions. This approach ensures that severe issues are both verifiable and actionable for development teams.

4. Quality Assurance​

The Quality Assurance (QA) phase is a dedicated step to ensure that each audit is thorough, consistent, and meets Hacken’s quality standards. The assigned lead auditor oversees this process, independently reviewing the findings and verifying the overall audit workflow.

During this phase, the lead auditor:

  • Validates findings – Confirms that identified vulnerabilities are accurately described, correctly classified by severity, and reproducible.
  • Checks consistency – Ensures that all sections of the audit adhere to the established methodology, reporting format, and internal standards.
  • Reviews recommendations – Verifies that suggested mitigations are practical, actionable, and aligned with security best practices.

5. Remediation Period​

After the preliminary audit report is delivered, clients have 20 business days to review the findings and implement fixes according to the recommendations and severity classifications.

All issues are first reported to the client in the preliminary report. If any points are unclear, auditors can provide additional descriptions or clarify them during a call. After the preliminary report is delivered, the client has 20 working days to submit fixes for the reported issues. Once this period ends—or earlier if the client confirms readiness—the retesting begins. During retesting, auditors review and verify the fixes for all findings. Important notes:

  • All fixes must be merged into the same branch before retesting starts.
  • The retest codebase should not contain significant changes compared to the audited commit, except for issue fixes.
  • Each fix should be provided as a separate commit hash or pull request.
  • Auditors may identify new vulnerabilities introduced by specific fixes.
  • By default, no additional fixes can be submitted after the 20 working day remediation period ends.

If these conditions are not met, the auditing team—subject to approval by the lead auditor—may decline retesting if rule violations prevent proper verification.

Early visibility through the reporting portal allows teams to track progress, clarify issues, and coordinate remediation efficiently.

A final report with updated issue statuses is provided to the client after retesting is complete.

6. Review of Fixes and Final Report​

Once all fixes are implemented and the final remediation commit hash is submitted:

  • Auditors verify that every issue has been properly addressed.
  • A final, comprehensive report is prepared, documenting all findings, remediation actions, and recommendations for future improvements.
  • The final report serves as the official record of the audit and may be shared with stakeholders, investors, or the broader community.

Part 3. Cryptography Domains & Subcategories​

Below is a list of cryptography domains and categories that we cover in our audits. For each category, we provide a non-exhaustive overview of the main areas of audit focus.

1. Post-Quantum Cryptography (PQC)​

1.1 FIPS203 (KEM), FIPS204/205 (DSA), Falcon (DSA)​

  • Audit of lattice-based schemes (Kyber, Dilithium, Falcon) for compliance with NIST/FIPS standards.
  • Verify IND-CCA security for KEMs and EUF-CMA security for DSAs.
  • Constant-time checks against timing leaks in lattice reduction and Gaussian sampling.
  • RNG robustness testing for signature nonces (critical in Falcon).

1.2 PQC-based Multisig & MPC Schemes​

  • Validation of threshold signatures and distributed key generation (DKG) for post-quantum primitives.
  • Rogue-key attack resistance and mis-coordination fault tolerance.
  • Performance and scalability review in real-world deployments.

1.3 PQC-based ZKPs (zkSTARKs)​

  • Analysis of algebraic assumptions (hash-based, low-degree testing).
  • Post-quantum soundness verification under interactive oracle proofs.
  • Review of efficiency vs. transparency trade-offs.

2. Quantum Cryptography​

2.1 Quantum Key Distribution (QKD)​

  • Audit of quantum channel setup (BB84, E91, CV-QKD).
  • Verification of error-correction and privacy amplification steps.
  • Resistance against photon number splitting and Trojan-horse attacks.
  • Compliance with ETSI and ITU-T standards for QKD.

2.2 Quantum Random Number Generation (QRNG)​

  • Entropy source validation from quantum processes (shot noise, photon arrival time).
  • Bias detection, min-entropy estimation, and NIST SP800-90B testing.
  • Integration audit for QRNG hardware in cryptographic stacks.

3. Elliptic Curve Cryptography (ECC)​

3.1 ECDSA, EdDSA​

  • Review of nonce generation (RFC6979, deterministic nonces).
  • Validation of curve parameters (secp256k1, ed25519, P-256).
  • Testing against invalid curve attacks and signature malleability.
  • Side-channel checks on scalar multiplication (Montgomery ladder, GLV).
  • Verification of symmetric and public key cryptography usage (AES, ChaCha20, RSA, Diffie–Hellman), ensuring secure modes of operation and key management.
  • Review of hash function deployment (SHA-2, SHA-3, BLAKE2, Poseidon), checking for collision resistance, preimage resistance, and misuse of outdated algorithms.
  • Assessment of MAC implementations (HMAC, Poly1305), validating key handling, integrity guarantees, and constant-time execution.

3.2 ECC-based Multisig & MPC​

  • Audit of MuSig, MuSig2, and FROST protocols.
  • Threshold signature review (Shamir secret sharing, verifiable DKG).
  • Resilience against key aggregation failures and rogue-key forgeries.

4. Zero-Knowledge Proof Systems​

4.1 Groth16​

  • Trusted setup ceremony review (multi-party computation, toxic waste disposal).
  • Constraint system verification for circuit correctness.
  • Security check of elliptic curve pairings and subgroup assumptions.

4.2 Plonk​

  • Universal trusted setup audit.
  • Polynomial commitment scheme review (Kate commitments).
  • Analysis of batching optimizations and their security implications.

4.3 Halo2​

  • Recursive proof composition audit.
  • Constraint system validation for range proofs and arithmetic circuits.
  • Implementation checks in Rust libraries (zkSync, Scroll).

4.4 zkSTARKs, Plonky, Binius, zkVM​

  • Analysis of transparent setup properties.
  • Security review of hash-based commitments (FRI protocol).
  • Scalability and proof-size evaluation for blockchain integration.
  • Novel algebraic frameworks like Binius for efficiency vs. soundness trade-offs.

4.5 Jolt / Binius​

  • Review of cutting-edge polynomial IOPs and algebraic holographic proofs.
  • Focus on proof size, verification complexity, and algebraic reductions.
  • Assessment of research-to-implementation risks in early-stage protocols.

5. Privacy & Private Computation​

5.1 Fully Homomorphic Encryption (FHE)​

Scope: Review implementations of FHE schemes (BFV, CKKS, BGV, TFHE).

  • Parameter validation (modulus size, lattice dimensions, noise growth).
  • Ciphertext lifecycle checks (bootstrapping, relinearization, modulus switching).
  • Side-channel resistance for polynomial arithmetic.
  • Performance and scalability assessments for real-world workloads.
  • Risks Addressed: Incorrect parameters leading to ciphertext breakability, insecure noise handling, and timing side-channels in modular arithmetic.

5.2 Trusted Execution Environments (TEE)​

Scope: Audit TEEs such as Intel SGX, ARM TrustZone, AMD SEV.

  • Attestation flow verification and cryptographic binding of enclave identities.
  • Memory isolation testing against rollback, replay, and cache side-channels.
  • Key sealing and provisioning process validation.
  • Integration with higher-level cryptographic protocols.
  • Risks Addressed: Side-channel leakage (Foreshadow, Spectre, Meltdown), improper enclave boundary handling, and reliance on outdated microcode.

5.3 Garbled Circuits (Yao’s Garbled Circuit)​

Scope: Review two-party and multiparty computation protocols built with garbled circuits.

Audit Focus:

  • Circuit construction correctness (free-XOR, half-gates optimization).
  • Secure oblivious transfer (OT) implementation and extension protocols.
  • Key management and wire-label handling.
  • Efficiency and scalability trade-off analysis.
  • Risks Addressed: Circuit mis-implementation leading to information leakage, insecure OT extension, and excessive performance overhead undermining security guarantees.

Part 4. Appendices​

Appendix A: Issues Statuses​

During the audit process, each issue can be assigned one of the following statuses:

Issue Status


Appendix B: Vulnerabilities Severity Formula​

The severity of each identified vulnerability is determined using a standardized formula that assesses its impact and likelihood. This methodology ensures a consistent, transparent, and objective evaluation across all findings.

Vulnerabilities severity formula

The following illustrates how severities are typically classified for high-likelihood findings:

  • Critical – Key recovery, signature forgery, proof system break.
  • High – Side-channel exploitable in practical deployments.
  • Medium – Weak parameters, insecure integrations.
  • Low - Minor misconfigurations or deviations from recommended practices that do not immediately compromise security but could reduce resilience or create operational inefficiencies (e.g., non-optimal curve selection, redundant computations, or lack of parameter hardening).
  • Informational – Optimization or best-practice gaps.

Stay in Touch​

We’re excited to share our expertise and help you build a safer web3 future. If you have any questions, feel free to contact us.