Shamir Secret Sharing + AES-GCM file encryption tool - seeking cryptographic review

I've built a practical tool for securing critical files using Shamir's Secret Sharing combined with AES-256-GCM encryption. The implementation prioritizes offline operation, cross-platform compatibility, and security best practices.

# Core Architecture

1. Generate 256-bit AES key using enhanced entropy collection
2. Encrypt entire files with AES-256-GCM (unique nonce per operation)
3. Split the AES key using Shamir's Secret Sharing
4. Distribute shares as JSON files with integrity metadata

# Key Implementation Details

# Entropy Collection

Combines multiple sources including `os.urandom()`, PyCryptodome's `get_random_bytes()`, `time.time_ns()`, process IDs, and memory addresses. Uses SHA-256 for mixing and SHAKE256 for longer outputs.

# Shamir Implementation

Uses [PyCryptodome's](https://pypi.org/project/pycryptodome/) Shamir module over GF(2^(8).) For 32-byte keys, splits into two 16-byte halves and processes each separately to work within the library's constraints.

# Memory Security

Implements secure clearing with multiple overwrite patterns (0x00, 0xFF, 0xAA, 0x55, etc.) and explicit garbage collection. Context managers for temporary sensitive data.

# File Format

Encrypted files contain: metadata length (4 bytes) → JSON metadata → 16-byte nonce → 16-byte auth tag → ciphertext. Share files are JSON with base64-encoded share data plus integrity metadata.

# Share Management

Each share includes threshold parameters, integrity hashes, tool version, and a unique `share_set_id` to prevent mixing incompatible shares.

# Technical Questions for Review

1. **Field Choice:** Is GF(2^(8)) adequate for this use case, or should I implement a larger field for enhanced security?
2. **Key Splitting:** Currently splitting 32-byte keys into two 16-byte halves for Shamir. Any concerns with this approach vs. implementing native 32-byte support?
3. **Entropy Mixing:** My enhanced entropy collection combines multiple sources via SHA-256. Missing any critical entropy sources or better mixing approaches?
4. **Memory Clearing:** The secure memory implementation does multiple overwrites with different patterns. Platform-specific improvements worth considering?
5. **Share Metadata:** Each share contains tool version, integrity hashes, and set identifiers. Any information leakage concerns or missing validation?

# Security Properties

* Information-theoretic security below threshold (k-1 shares reveal nothing)
* Authenticated encryption prevents ciphertext modification
* Forward security through unique keys and nonces per operation
* Share integrity validation prevents tampering
* Offline operation eliminates network-based attacks

# Threat Model

* Passive adversary with up to k-1 shares
* Active adversary attempting share or ciphertext tampering
* Memory-based attacks during key reconstruction
* Long-term storage attacks on shares

# Practical Features

* Complete offline operation (no network dependencies)
* Cross-platform compatibility (Windows/macOS/Linux)
* Support for any file type and size
* Share reuse for multiple files
* ZIP archive distribution for easy sharing

# Dependencies

Pure Python 3.12.10 with PyCryptodome only. No external cryptographic libraries beyond the standard implementation.

# Use Cases

* Long-term key backup and recovery
* Cryptocurrency wallet seed phrase protection
* Critical document archival
* Code signing certificate protection
* Family-distributed secret recovery

The implementation emphasizes auditability and correctness over performance. All cryptographic primitives use established PyCryptodome implementations rather than custom crypto.

**GitHub:** [https://github.com/katvio/fractum](https://github.com/katvio/fractum)
**Security architecture docs:** [https://fractum.katvio.com/security-architecture/](https://fractum.katvio.com/security-architecture/)

Particularly interested in formal analysis suggestions, potential timing attacks, or implementation vulnerabilities I may have missed. The tool is designed for high-stakes scenarios where security is paramount.

Any cryptographer willing to review the Shamir implementation or entropy collection would be greatly appreciated!

# Technical Implementation Notes

# Command Line Interface

# Launch interactive mode (recommended for new users)
fractum -i

# Encrypt a file with 3-5 scheme
fractum encrypt secret.txt -t 3 -n 5 -l mysecret

# Decrypt using shares from a directory
fractum decrypt secret.txt.enc -s ./shares

# Decrypt by manually entering share values
fractum decrypt secret.txt.enc -m

# Verify shares in a directory
fractum verify -s ./shares

# Share File Format Example

{
"share_index": 1,
"share_key": "base64-encoded-share-data",
"label": "mysecret",
"share_integrity_hash": "sha256-hash-of-share",
"threshold": 3,
"total_shares": 5,
"tool_integrity": {...},
"python_version": "3.12.10",
"share_set_id": "unique-identifier"
}

# Encrypted File Structure

[4 bytes: metadata length]
[variable: JSON metadata]
[16 bytes: AES-GCM nonce]
[16 bytes: authentication tag]
[variable: encrypted data]