# Snigdha Persistence: Security Model, Threat Assessment & Cryptographic Policy

Snigdha OS Decentralized — Phase 4 Security Specification
SPDX-License-Identifier: GPL-3.0-or-later

# 1. Executive Security Summary

Snigdha Persistence provides strong cryptographic confidentiality for selective user data stored on removable media. While locked and powered off, data stored inside the persistent container is cryptographically inaccessible without the master passphrase or a valid keyslot.

However, cryptography at rest does not make unlocked storage immune to operational risks. When persistent storage is unlocked, any unconfined process running under the user session can read or write files within persistent mountpoints. Furthermore, persisting cryptographic credentials (such as SSH keys or GnuPG keys) creates cross-session linkability, potentially degrading the anonymity guarantees of Snigdha Amnesia and Snigdha NetGuard if misused.

This document formalizes the cryptographic parameters, attack models, data remnant boundaries, and operational risks of the subsystem.

# 2. Threat Model and Protection Boundaries

# In-Scope Adversary Capabilities

# Out-of-Scope / Non-Mitigated Risks

1. Compromised Runtime Session: If an adversary achieves arbitrary code execution within the active desktop session while storage is unlocked, the adversary can read and exfiltrate unlocked files. Cryptography protects data at rest, not against an active in-memory rootkit.
2. Weak User Passphrases: A 6-character dictionary word can be cracked via dictionary attack. The system enforces a minimum length of 8 characters and displays strong passphrase advice, but user-chosen entropy remains paramount.
3. Flash Wear-Leveling Remnants: Flash memory controllers (USB thumb drives, SD cards) use wear leveling. Overwriting a block or zeroing a file does not guarantee physical erase at the NAND chip level. Data confidentiality relies strictly on the LUKS2 envelope, never on filesystem-level deletion.
4. Authenticity / Integrity at Rest: Standard dm-crypt with AES-XTS provides confidentiality, but not authenticated encryption with associated data (AEAD). While dm-crypt resists unauthorized plaintext recovery, it does not detect targeted ciphertext bit-flipping without dm-integrity (which carries extreme performance overhead on USB flash media). File-level integrity is verified via filesystem checksums and manifests.

# 3. Cryptographic Primitives & Justifications

# LUKS2 Specification Compliance

LUKS2 is the current Linux standard for disk encryption. Compared to legacy LUKS1, LUKS2 provides:

• Dual redundant metadata headers, protecting against accidental header sector corruption.
• Native support for modern memory-hard PBKDFs (Argon2id).
• Flexible JSON metadata storage.
• Cryptographic checksumming of header metadata blocks via SHA-256.

# Cipher Suite: aes-xts-plain64

• Cipher: Advanced Encryption Standard (AES) in XEX-based Tweaked-codebook mode with ciphertext Stealing (XTS).
• Key Length: 512 bits (split into two 256-bit keys: one for AES encryption and one for tweak encryption).
• Standard: IEEE 1619, NIST SP 800-38E.
• Hardware Acceleration: Accelerated via Intel/AMD AES-NI instructions, minimizing CPU overhead and power consumption during file I/O.

# PBKDF: Argon2id

• Algorithm: Winner of the Password Hashing Competition (RFC 9106).
• Mode: Argon2id combines Argon2d (resisting GPU-based brute-force attacks through data-dependent memory access) and Argon2i (resisting side-channel attacks through data-independent memory access).
• Tuning & Bounds:
  • Time cost: 4 iterations (2.0s target benchmarking duration).
  • Memory cost: Dynamically benchmarked, capped at 1,048,576 KiB (1 GiB).
  • Threads: Up to 4 parallel execution threads.
• Hardware Compatibility Assessment: Standard cryptsetup Argon2id benchmarking allocates 50% of available RAM. On a 16GB workstation, this would produce an Argon2id header requiring 8GB of RAM to unlock, instantly crashing on a 4GB system. Snigdha Persistence's 1 GiB memory ceiling ensures universal portability across all hardware within declared support scope.

# 4. Key Management & Keyslot Lifecycle

LUKS2 separates the volume master encryption key (stored encrypted in the keyslot area) from the user passphrases used to unlock it.

# Minimum Keyslot Preservation Invariant

A LUKS container without an active keyslot is permanently destroyed. To prevent operator lock-out during passphrase updates:

1. add_luks2_passphrase enrolls the new passphrase in a secondary keyslot.
2. The new keyslot is tested with cryptsetup open --test-passphrase.
3. Only after the new keyslot is verified operational is the obsolete keyslot safely retired via remove_luks2_keyslot.
4. Attempting to delete the last remaining keyslot is blocked unconditionally by the daemon.

# 5. Privacy & Identity Linkage Considerations

The primary privacy hazard of persistent storage in an amnesic OS is cross-session linkability.

# SSH Key Linkage

• Risk: Storing an SSH private key (~/.ssh/id_ed25519) allows a remote server operator or network adversary to correlate connections from different physical locations (e.g. home, coffee shop, transit) to the exact same cryptographic public key.
• Mitigation: SSH persistence is disabled by default. When enabling SSH persistence, the user is presented with a privacy warning advising the use of distinct, compartmentalized SSH keys for different network environments.

# GnuPG Key Linkage

• Risk: Persisting OpenPGP keys allows decryption of past communication across reboots, but also allows physical possessors of the unlocked device to inspect private keyrings and user IDs.
• Mitigation: GnuPG persistence is disabled by default. GnuPG agent sockets (S.gpg-agent) are maintained in volatile tmpfs under /run/user/1000/gnupg/ to prevent socket credential leakage.

# Tor Bridges & Network Configurations

• Risk: Storing network connection profiles (Wi-Fi SSIDs, MAC addresses, pre-shared keys) links physical locations to the device.
• Mitigation: NetworkManager connection persistence is excluded from v1 automatic persistence. Tor bridges are managed in volatile memory via NetGuard and must only be saved upon explicit, isolated user request.

# 6. Secure Passphrase Guidance

Users should select passphrases based on the Diceware methodology or multi-word passphrases:

• Recommended Length: 5 to 7 random words (e.g., correct-horse-battery-staple-tulip).
• Minimum Requirement: 8 characters.
• Offline Generation: Never test or generate passphrases using web browsers or online "strength checking" tools.
• Recovery Advisory: If the master passphrase is forgotten, data recovery is mathematically impossible. There is no developer backdoor, no vendor master key, and no cloud recovery escrow.