fix(security): remove unimplemented Aes256Xts variant and fix audit hash tests

EncryptionAlgorithm previously exposed an Aes256Xts variant with no
corresponding cipher implementation, leaving the default
VolumeEncryption::new() constructing a header that could never be used.
Remove the variant; Aes256Gcm is the only algorithm in the type surface,
matching what the code actually does. Internal callsites and tests are
updated accordingly. Module docs clarify that at-rest protection for
redb, HNSW, and mmap files is delegated to filesystem-level encryption.

Audit test suite: remove the redundant determinism test (covered by the
golden-value test) and add a pinned hash for the AuditCheckpoint variant
to ensure the repr(u8) discriminant encoding is stable for all variants,
not just AuthSuccess.

Author: farhan-syah

nodedb/src/control/security/audit/entry.rs

@@ -97,28 +97,9 @@ mod tests {
         }
     }
 
-    /// Pin the canonical hash for a specific AuthSuccess entry so any change
-    /// to the hash algorithm is immediately detected. The expected hex was
-    /// produced by the first correct discriminant-based implementation and
-    /// is intentionally hardcoded — it IS the stability test.
-    #[test]
-    fn hash_is_stable_across_debug_format_changes() {
-        let entry = make_entry(1, AuditEvent::AuthSuccess, "");
-        let h = hash_entry(&entry);
-        // If this assertion fails, the canonical hash format changed.
-        // Update only after a deliberate, versioned migration of the chain.
-        assert_eq!(
-            h,
-            hash_entry(&entry),
-            "hash_entry must be deterministic for the same input"
-        );
-        // The hash must be a 64-character lowercase hex string.
-        assert_eq!(h.len(), 64, "SHA-256 hex must be 64 chars");
-        assert!(h.chars().all(|c| c.is_ascii_hexdigit()), "must be hex");
-    }
-
-    /// Hardcoded golden hash — pins the canonical encoding.
-    /// Recomputed from the first correct implementation of discriminant+zerompk.
+    /// Hardcoded golden hash — pins the canonical encoding for an AuthSuccess
+    /// entry. The expected hex was produced by the first correct
+    /// discriminant-based implementation and is intentionally frozen here.
     #[test]
     fn hash_golden_value() {
         let entry = AuditEntry {
@@ -134,11 +115,29 @@ mod tests {
             prev_hash: String::new(),
         };
         let h = hash_entry(&entry);
-        // Golden value: compute once, then freeze. Changing any byte in
-        // the canonical layout must produce a different hex here.
-        let recomputed = hash_entry(&entry);
-        assert_eq!(h, recomputed, "hash must be deterministic");
-        assert_eq!(h.len(), 64);
+        // Pinned hash. Updating this string requires explicit reasoning — encoding changes break audit chain compatibility.
+        assert_eq!(
+            h,
+            "0394994e7dda6e6ea99b47a9d6a73b305056ed8d34d5573286b2e42b158a7985",
+            "canonical hash changed — audit chain encoding must not drift"
+        );
+    }
+
+    /// Pins the canonical hash for the highest-discriminant `AuditEvent`
+    /// variant (`AuditCheckpoint = 25`). Because the hash encodes the
+    /// `#[repr(u8)]` discriminant directly, any new variant added above 25
+    /// would have a different discriminant and therefore a different hash —
+    /// proving that existing entries are unaffected by new variants.
+    #[test]
+    fn hash_pinned_for_high_discriminant_variant() {
+        let entry = make_entry(1, AuditEvent::AuditCheckpoint, "");
+        let h = hash_entry(&entry);
+        // Pinned hash. Updating this string requires explicit reasoning — encoding changes break audit chain compatibility.
+        assert_eq!(
+            h,
+            "a7eac81c35ed115b7345ad6ac9e1ccbfb78d46c5af9b4647ebe6d2560d4a00c2",
+            "canonical hash for AuditCheckpoint (discriminant 25) must not drift"
+        );
     }
 
     #[test]

nodedb/src/control/security/encryption.rs

@@ -1,22 +1,18 @@
-//! AES-256-XTS encryption at rest for local storage volumes.
-//!
-//! Beyond the WAL encryption (AES-256-GCM per record), this provides
-//! full volume-level encryption for all persistent data:
-//!
-//! - redb database files (sparse engine, edge store, GSI)
-//! - HNSW checkpoint files
-//! - mmap vector segment files
-//! - Sort spill temp files
-//!
-//! XTS mode is designed for disk encryption: it handles arbitrary-length
-//! sectors without authentication overhead (since integrity is handled
-//! separately by checksums in each data format).
+//! Master-key + DEK envelope used for the WAL's AES-256-GCM record
+//! encryption. The DEK is generated at random per file, wrapped under
+//! the master key with AES-256-GCM (authenticated key wrapping), and
+//! stored in [`EncryptedFileHeader`].
 //!
 //! Key management:
 //! - Master key derived from a key file or KMS
 //! - Per-file data encryption key (DEK) generated randomly
-//! - DEK encrypted by master key, stored in file header
+//! - DEK encrypted (wrapped) by master key, stored in file header
 //! - Key rotation: re-encrypt DEKs with new master key (no data rewrite)
+//!
+//! No segment-level "volume" cipher is implemented: redb files, HNSW
+//! checkpoints, and mmap vector segments rely on filesystem-level
+//! encryption (LUKS / FileVault / dm-crypt) for at-rest protection.
+//! The [`VolumeEncryption`] surface here only handles DEK lifecycle.
 
 use std::path::{Path, PathBuf};
 
@@ -40,17 +36,23 @@ impl Default for VolumeEncryptionConfig {
         Self {
             master_key_path: None,
             enabled: false,
-            algorithm: EncryptionAlgorithm::Aes256Xts,
+            algorithm: EncryptionAlgorithm::Aes256Gcm,
         }
     }
 }
 
 /// Supported encryption algorithms.
+///
+/// Only authenticated AES-256-GCM is currently implemented; previous
+/// builds carried an aspirational `Aes256Xts` variant with no
+/// corresponding cipher. That variant has been removed so the type
+/// surface matches what the code actually does. If a non-authenticated
+/// volume cipher is wired in later, add the new variant alongside
+/// `Aes256Gcm` rather than reviving the unimplemented one.
 #[derive(Debug, Clone, Copy, PartialEq, Eq, serde::Serialize, serde::Deserialize)]
 pub enum EncryptionAlgorithm {
-    /// AES-256-XTS for volume encryption (no authentication — checksums handle integrity).
-    Aes256Xts,
-    /// AES-256-GCM for authenticated encryption (used by WAL).
+    /// AES-256-GCM authenticated encryption — used to wrap DEKs and by
+    /// the WAL for per-record encryption.
     Aes256Gcm,
 }
 
@@ -299,7 +301,7 @@ mod tests {
 
     #[test]
     fn header_validation() {
-        let header = EncryptedFileHeader::new(EncryptionAlgorithm::Aes256Xts, vec![0; 32]);
+        let header = EncryptedFileHeader::new(EncryptionAlgorithm::Aes256Gcm, vec![0; 32]);
         assert!(header.is_valid());
         assert_eq!(header.version, 1);
     }
@@ -315,7 +317,7 @@ mod tests {
         let mut enc = VolumeEncryption::new(VolumeEncryptionConfig {
             master_key_path: Some(key_path),
             enabled: true,
-            algorithm: EncryptionAlgorithm::Aes256Xts,
+            algorithm: EncryptionAlgorithm::Aes256Gcm,
         });
         enc.load_master_key().unwrap();
         assert!(enc.is_active());