Major Update: Envelope Format, Manifest, and Robust AAD¶
What’s new:
-
Envelope file format (
.trst
): Now includes a stream header (version, header bytes, BLAKE3 hash) and records (sequence, nonce, signed manifest, ciphertext), all bincode-encoded for compactness and speed. -
Signed manifest: Each chunk includes a bincode-encoded manifest with version, timestamp, sequence, header and chunk hashes, AI/model provenance fields, and Ed25519 signature/public key bytes for strong provenance and integrity.
-
Robust AAD: Each chunk’s AAD is
[header_hash][seq][nonce][manifest_hash]
, binding metadata and provenance to the ciphertext and preventing tampering/replay. -
CLI improvements: New options:
--envelope
(write envelope),--decrypt
(decrypt/verify envelope),--key-hex
(user-supplied key),--key-out
(save generated key),--no-plaintext
(skip round-tripped plaintext). -
Key management: Use a user-supplied 64-char hex key or generate a random key (output to file or stderr for demo/testing).
How it works:
- Reads the input file in user-defined chunks.
- For each chunk: constructs a unique nonce, builds AAD, creates and signs a manifest, encrypts with AES-256-GCM, verifies, and writes output.
- Envelope files contain all metadata for real-world use; round-trip output matches input for verification (no header).
Next steps:
- Add more tests for serialization, AAD, and round-trip.
- Add logging for chunk/manifest info.
- Continue documenting the file format and streaming pipeline.
What’s new:
- Nonce discipline: Now using a random 4-byte prefix + 8-byte counter for GCM-safe, unique nonces, with overflow checks.
- Authenticated header (AAD): Added a fixed 58-byte header (version, alg, key_id, device_id_hash, nonce_prefix, chunk_size), Blake3-hashed with chunk counter and nonce for tamper-evident metadata.
- Tamper check: Debug feature—flipping a bit causes decryption to fail as expected.
- Key hygiene: 256-bit key is zeroized on exit for better security.
Lessons:
- Nonce uniqueness is critical—never reuse a nonce with the same key.
- Bind metadata (headers) to the payload using AAD for integrity.
- Header handling is tricky for file verification; streaming may require per-payload headers.
- Next steps: move config (device_id, salt) to environment variables, implement an envelope structure, and experiment with producer/consumer streaming using
tokio::mpsc
.
Call for feedback:
If you have experience shipping AES-GCM streams in Rust, especially with AAD and nonce/session patterns, feedback is welcome!
TrustEdge — Trustable Edge AI (Rust)¶
TrustEdge is a public learning journey in Rust, focused on building privacy-preserving, trustable edge AI pipelines. Unlike typical CRUD web apps, TrustEdge explores IoT, security/PKI, and edge systems, with a strong emphasis on privacy by design—encrypting at the edge, not just in transit.
Key Features¶
- Language: Rust (stable)
- Privacy by design: Encrypts data at the edge using AES-256-GCM (AEAD)
- Streaming workloads: Chunked file read, per-chunk encryption/decryption
- Immediate verification: Each chunk is decrypted and verified locally
- CLI Demo: Reads an audio file, encrypts/decrypts in chunks, verifies round-trip integrity
- Learning in public: Honest, incremental milestones
Tech Stack¶
- Rust
- Crypto:
aes-gcm
(256-bit keys, 96-bit nonces) - CLI:
clap
- Error handling:
anyhow
Quick Start¶
# Install Rust
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
# Clone the repo
git clone https://github.com/johnzilla/trustedge.git
cd trustedge/trustedge-audio
# Build
cargo build --release
# Run (any audio file is fine)
./target/release/trustedge-audio -i ./sample.wav -o ./roundtrip.wav --chunk 8192
# Verify round trip
sha256sum ./sample.wav ./roundtrip.wav
# Hashes should match
Roadmap¶
- Replace random per-chunk nonces with
random_prefix || counter
- Add envelope struct for chunk metadata
- Split into producer/consumer tasks (tokio)
- Add basic observability/logging
License¶
Mozilla Public License 2.0 (MPL-2.0)