(tooling-agents) branch main updated: ASVS audit: 11.3.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 45e1926  ASVS audit: 11.3.4.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
45e1926 is described below

commit 45e1926bd8c54404fd5dac428de83ffdd3c3d4ff
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 22:52:03 2026 +0200

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

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/11.3.4.md b/ASVS/reports/steve/v3/d0aa7e9/all/11.3.4.md
new file mode 100644
index 0000000..021ba28
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/11.3.4.md
@@ -0,0 +1,103 @@
+# Security Audit Report: ASVS 11.3.4
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 11.3.4 |
+| **Files Analyzed** | 6 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that nonces, initialization vectors, and other single-use numbers are not used for more than one encryption key and data-element pair. The method of generation must be appropriate for the algorithm being used.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 0 |
+| 🟢 Low | 1 |
+
+---
+
+## ASVS-11.3.4: Nonces, IVs, and Single-Use Numbers
+
+### Findings for 11.3.4
+
+No critical vulnerabilities detected. The system relies on `cryptography.fernet.Fernet` for encryption, which internally generates a cryptographically random 128-bit IV for every call to `encrypt()`. Even when the same key is derived for re-votes (same person, same issue), fresh IVs are guaranteed by the library.
+
+However, one low-severity observation exists regarding the HKDF `info` parameter mislabeling:
+
+### [LOW]
+
+**Finding ID**: ASVS-1134-LOW-001  
+**File**: `v3/steve/crypto.py`, function `_b64_vote_key`, lines 60-67  
+
+```python
+def _b64_vote_key(vote_token: bytes, salt: bytes) -> bytes:
+    "Key-stretch the vote_token. (ref: PBKDF)"
+
+    ### 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',
+    )
+```
+
+**Data flow**: `vote_token` → HKDF with misleading `info` label → Fernet key  
+**Impact**: The `info=b'xchacha20_key'` is a domain separation label for HKDF. When the system migrates to XChaCha20-Poly1305, this `info` value will remain the same, meaning keys derived for Fernet would be identical to keys derived for XChaCha20-Poly1305. If old ciphertexts coexist with new ciphertexts during migration, this violates the principle that a single key should not be used across different algorithm/data-element pairs.  
+**Remediation**: Use `info=b'fernet_vote_key'` now, and switch to `info=b'xchacha20_vote_key'` during migration to ensure domain separation:
+
+```python
+info=b'fernet_vote_key',  # Change to b'xchacha20_vote_key' when algorithm changes
+```
+
+### Security Controls Inventory for 11.3.4
+
+| Control | Location | Coverage Status |
+|---------|----------|-----------------|
+| Random IV generation per encrypt | `cryptography.fernet.Fernet.encrypt()` (internal) | ✅ Applied to all encryption operations |
+| Unique salt per mayvote row | `election.py:add_salts()` line 116 | ✅ Each person-issue pair gets unique salt |
+| CSPRNG for salt generation | `crypto.py:gen_salt()` line 37 | ✅ Uses `secrets.token_bytes()` |
+
+### Positive Patterns for 11.3.4
+
+1. **Fernet IV management**: The library guarantees a fresh 128-bit random IV for every encryption call, preventing nonce reuse even when the same key is derived for re-votes.
+2. **Unique salts per voter-issue pair**: Each `mayvote` row gets a distinct 16-byte salt from `secrets.token_bytes()`, ensuring distinct keys per person-issue combination.
+3. **CSPRNG usage**: All random values (salts, IDs) use `secrets` module, which is cryptographically secure.
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **Cryptographic Architecture is Well-Designed**: The multi-layered approach (election data → BLAKE2b → Argon2 → opened_key; then opened_key + identifiers → Argon2 → vote_token → HKDF → encryption key) provides defense in depth with appropriate separation of concerns.
+
+2. **Argon2 Variant Inconsistency**: The benchmark function uses `Type.ID` (Argon2id) while production uses `Type.D` (Argon2d). This appears to be an oversight rather than a deliberate design choice, as there's no documented rationale for choosing Argon2d.
+
+3. **Fernet as Transitional Algorithm**: The code explicitly marks Fernet as temporary (comments mention switching to XChaCha20-Poly1305). The HKDF `info` parameter is already set for XChaCha20, which could cause key equivalence issues during migration if not properly managed.
+
+4. **No Password Storage**: The system delegates authentication to external infrastructure (ASF/LDAP), meaning traditional password hashing requirements (11.4.2) have limited direct applicability. The Argon2 usage is for key derivation and anti-tamper rather than password verification.
+
+5. **Anti-Tamper Integrity**: The `opened_key` mechanism provides cryptographic assurance that election configuration hasn't been modified after opening — a strong integrity control binding election metadata, issues, and voter lists.
+
+## Cross-cutting Recommendations
+
+### Immediate (Critical/High Priority)
+1. **Switch Argon2 variant to Argon2id** (`Type.ID`): Single-line change in `_hash()` function, aligning production with benchmark code and OWASP recommendations. This affects all derived keys.
+
+### Short-term (Medium Priority)
+2. **Plan migration path for Fernet → XChaCha20-Poly1305**: Ensure the HKDF `info` parameter changes during migration to prevent key reuse across algorithms. Document the migration strategy for existing encrypted votes.
+3. **Review Argon2 parameters against current hardware**: Run `benchmark_argon2()` on production hardware to determine if `time_cost` can be increased (current value of 2 is the minimum recommended).
+
+### Long-term (Low Priority)
+4. **Consider BLAKE2b → SHA-512 substitution**: If strict NIST compliance is required, replace BLAKE2b with SHA-512 for the data reduction step. Functionally equivalent with no performance concern for the single-call use case.
+5. **Add cryptographic agility documentation**: Document the algorithm choices, migration strategy, and key derivation chain in a security design document to support future audits.
+        
\ 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