Tamper-resilient storage & keying

**Description**
Implement a secure, modular storage layer that focuses on **resilience against tampering or post-compromise forensics**. This is not about detecting tamper events, but ensuring that once a trigger fires, **data becomes cryptographically irrecoverable**.

This storage layer should tie into existing trigger mechanisms to wipe RAM-resident keys, making data unreadable even with physical access working alongside tamper detection layers (see #2) for full lifecycle defense.

**Components**

* Ephemeral keying for encrypted storage

* RAM-resident encryption keys (non-persistent)
* Keys wiped on trigger (e.g., keyboard phrase, USB event, network packet)
* Integration with dm-crypt / LUKS volumes

* One-time pad (OTP) or XOR-based multi-layer key splits

* Distribute decryption key into multiple parts
* Require all pieces for full recovery
* Optional: store parts across different locations (e.g., device + remote peer)

**Goals**

* Use standard Linux mechanisms (e.g., dm-crypt, LUKS) where possible
* Abstract encryption/key-wiping logic behind an internal API
* Ensure key material never touches disk or swap
* Optionally: allow key splitting via simple XOR or Shamir's Secret Sharing

**Optional extensions**

* TPM-backed key storage with time-based unlock windows
* Remote key escrow with secure request protocol
* Support for volatile in-memory filesystems (e.g., `tmpfs` + encrypted overlay)

The issue describes integrating with existing trigger mechanisms (see issue #2) and Linux kernel modules like dm-crypt/LUKS. Start by examining the kernel module source in the repository to understand the trigger system. Look for existing storage or encryption code. The goal is to design a secure storage layer that wipes RAM-resident keys on trigger, making data irrecoverable. 'Done' means a modular API that ties into triggers and uses standard Linux encryption mechanisms.

Written by the indexing model from the issue text.