I DNA-encode my encrypted database before writing it to disk - here's why (and why it's not "quantum" anything)

2026年8月30日2 次浏览来源:Dev.to阅读原文

Every value in my little embedded key-value store gets encrypted, then its ciphertext gets encoded as a string of A/C/G/T characters before it ever touches the filesystem.

Open the file in a text editor and you'll see actual DNA-looking text - not because it's a gimmick, but because that's genuinely the storage format.

This is , a ~348KB embeddable encrypted key-value store I built in Rust for places a server can't reach - a watch face, a phone app, a background service.

It's part of a larger repo, ModelDB, that also includes MDC, a Python conversational data engine (query AI models, databases, images, and documents in plain English, no SQL) with its own DNA-inspired archival storage tier.

The actual storage format Every call does this, in order: Pack into one plaintext buffer.

Encrypt the whole thing with XChaCha20-Poly1305 (a 256-bit key you supply - the crate never generates or stores key material itself; real key custody belongs to the platform's secure hardware, iOS Secure Enclave or Android Keystore).

DNA-encode the resulting blob: 2 bits per base, .

Every byte maps to exactly 4 bases, so there's no padding ambiguity on decode.

Write the ACGT text to disk, atomically (temp file + rename).

Filenames are keyed BLAKE3 hashes of the logical key, not the key name itself, so a directory listing alone leaks nothing - no key names, no values, no way to tell how many distinct keys exist versus how many files are on disk.

分享
Baike.dev

baike.dev helps you discover great languages, frameworks, databases, DevOps and cloud-native tools.

Quick links

About

Contribute

Found a great developer tool? Share it with the community.

Submit a tool
© 2026 baike.dev Developer EncyclopediaUpdated daily · Discover great developer tools