(tooling-agents) branch main updated: ASVS audit: 11.1.4.md (redacted) [source: apache/steve/v3 @ d0aa7e9]

[as...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

asf-tooling pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tooling-agents.git


The following commit(s) were added to refs/heads/main by this push:
     new b0e2459  ASVS audit: 11.1.4.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
b0e2459 is described below

commit b0e24593e81efbc7d14b8d1bbbac48c49aa3b228
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 22:51:48 2026 +0200

    ASVS audit: 11.1.4.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
---
 ASVS/reports/steve/v3/d0aa7e9/all/11.1.4.md | 132 ++++++++++++++++++++++++++++
 1 file changed, 132 insertions(+)

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/11.1.4.md b/ASVS/reports/steve/v3/d0aa7e9/all/11.1.4.md
new file mode 100644
index 0000000..3556d58
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/11.1.4.md
@@ -0,0 +1,132 @@
+# Security Audit Report: ASVS 11.1.4
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 11.1.4 |
+| **Files Analyzed** | 8 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that a cryptographic inventory is maintained. This must include a documented plan that outlines the migration path to new cryptographic standards, such as post-quantum cryptography, in order to react to future threats.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 1 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-11.1.4: Cryptographic Inventory with PQC Migration Plan
+
+### Findings for 11.1.4
+
+#### [MEDIUM]
+**Finding ID:** ASVS-1114-MED-001  
+**Title:** No Documented Post-Quantum Cryptography Migration Plan
+
+**Location:** `v3/steve/crypto.py`, `v3/docs/schema.md`
+
+**Description:**  
+While the code acknowledges a planned transition from Fernet to XChaCha20-Poly1305, there is no documented migration plan addressing post-quantum cryptography threats. The current cryptographic primitives (AES-128, SHA-256, BLAKE2b) have varying levels of quantum resistance, and no formal assessment or migration roadmap exists.
+
+**Evidence of awareness but no PQC plan:**
+
+```python
+# crypto.py line 63
+### still using Fernet now, but will switch soon. Leaving comments.
+keymaker = hkdf.HKDF(
+    algorithm=hashes.SHA256(),
+    length=32,  # 32-byte key for XChaCha20-Poly1305
+    salt=salt,
+    info=b'xchacha20_key',
+)
+```
+
+```markdown
+# schema.md
+- **Future Changes**: The `ciphertext` encryption will transition from Fernet to XChaCha20-Poly1305.
+```
+
+**Quantum risk assessment (not documented anywhere in the project):**
+- Fernet (AES-128-CBC): Grover's algorithm reduces effective security to 64-bit — vulnerable
+- HKDF-SHA256: Reduced but still adequate (128-bit security)
+- Argon2: Memory-hard functions are believed quantum-resistant
+- BLAKE2b: Reduced but still adequate
+- No asymmetric cryptography currently in use (lower immediate risk)
+
+**Impact:** Without a migration plan, the project cannot react efficiently to quantum computing advances. The planned Fernet → XChaCha20-Poly1305 migration doesn't address quantum threats (both are symmetric and similarly affected by Grover's algorithm). AES-128 specifically should be upgraded to AES-256 for quantum resistance.
+
+**Remediation:**  
+Create a `PQC_MIGRATION_PLAN.md` documenting:
+1. Current algorithm inventory with quantum risk assessment
+2. Timeline for migrating AES-128 (Fernet) to AES-256 or authenticated encryption with 256-bit keys
+3. Assessment of when PQC-resistant key exchange might be needed (if TLS/network crypto is added)
+4. Crypto-agility requirements (see 11.2.2) to enable seamless future upgrades
+5. Data re-encryption strategy for stored ciphertext
+
+### Security Controls Inventory for 11.1.4
+
+| Control | Location | Status |
+|---------|----------|--------|
+| Planned Fernet → XChaCha20 transition | `crypto.py` comment, `schema.md` | ⚠️ Informal/undocumented plan |
+| PQC risk assessment | Not found | ✗ Missing |
+| PQC migration timeline | Not found | ✗ Missing |
+| Algorithm upgrade procedures | Not found | ✗ Missing |
+
+### Positive Patterns for 11.1.4
+
+- The development team has acknowledged the need for algorithm upgrades (Fernet → XChaCha20-Poly1305)
+- HKDF `info` parameter is set to `b'xchacha20_key'`, showing forward-thinking about key separation
+- The system uses symmetric cryptography only (no RSA/ECC to urgently replace for PQC)
+- Argon2 (memory-hard KDF) is believed to be quantum-resistant
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **Centralized Crypto Module:** All cryptographic operations are centralized in `v3/steve/crypto.py`. This is excellent for auditability but currently lacks the abstraction needed for agility. The centralization makes future refactoring feasible.
+
+2. **Key Derivation Chain:** The system uses a well-designed multi-level key derivation: `election_data → BLAKE2b → Argon2 → opened_key → (+ pid + iid + salt) → Argon2 → vote_token → HKDF → vote_key → Fernet(vote)`. This provides good key separation and limits blast radius, but the entire chain is hardcoded.
+
+3. **Documentation Gap:** The project has partial documentation (`schema.md`) but lacks formal security/crypto documentation. The existing documentation focuses on database schema rather than cryptographic design decisions.
+
+4. **Anti-Tamper Design:** The `opened_key` serves dual purposes: (1) tamper detection via `is_tampered()` and (2) vote token derivation. This coupling means the anti-tamper mechanism is tied to the same cryptographic algorithm as the voting mechanism — upgrading one requires upgrading both.
+
+5. **No Asymmetric Cryptography:** The system uses only symmetric primitives and key derivation. This reduces PQC urgency compared to systems using RSA/ECC, but the AES-128 effective key length under Grover's algorithm (64-bit) is a concern for long-term data confidentiality.
+
+6. **Inconsistency Between Production and Benchmark:** Production uses Argon2d while the benchmark uses Argon2id, suggesting either incomplete migration or a deliberate but undocumented choice.
+
+## Cross-cutting Recommendations
+
+### Immediate (Sprint-level)
+1. **Change Argon2d to Argon2id** in `_hash()` function (ASVS-1121-MED-001). This is a one-line change with significant security improvement. Note: this will change all derived values, so must be coordinated with any existing deployed databases.
+
+2. **Add `crypto_version` column** to the `vote` table to enable future algorithm transitions without data loss.
+
+### Short-term (1-3 months)
+3. **Create formal cryptographic inventory document** mapping all algorithms, keys, their purposes, access scopes, and protection requirements (satisfies 11.1.1, 11.1.2).
+
+4. **Implement crypto abstraction layer** in `crypto.py` with version-based algorithm selection and a configuration mechanism for algorithm parameters (satisfies 11.2.2).
+
+5. **Add cryptographic linting** to CI/CD pipeline using `semgrep` or equivalent with rules for:
+   - Flagging new crypto imports
+   - Detecting weak algorithms
+   - Ensuring CSPRNG usage (satisfies 11.1.3)
+
+### Long-term (3-12 months)
+6. **Complete Fernet → XChaCha20-Poly1305 migration** with proper versioning, re-encryption tooling, and rollback capability.
+
+7. **Document PQC migration plan** assessing quantum risk for each primitive and establishing upgrade timelines, particularly upgrading to AES-256 for long-term vote confidentiality (satisfies 11.1.4).
+
+8. **Implement key lifecycle management** including maximum key age, scheduled rotation for long-lived keys, and secure key destruction after election archival (satisfies 11.1.1).
+        
\ No newline at end of file


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@tooling.apache.org
For additional commands, e-mail: commits-help@tooling.apache.org