ULocker: A Streaming, Re-keyable Encrypted Container for Removable Media, and What Its Framing Still Leaks

Abstract

Full-disk encryption protects a USB drive only where a filesystem filter driver can be installed, and the ciphertext still exposes file names, directory structure and exact sizes to anyone who reads the raw device. ULocker is a container format that moves the unit of protection from the block device to a single file: the archive carries an encrypted index, so names and the directory tree are not readable without the password, and file content is written as independently authenticated 1 MiB chunks. A password-derived key unwraps an index key, which in turn unwraps a random data key, so a password change rewrites the header rather than the payload. We measure the format rather than assert its properties. The implementation passes its 212-test suite; a 24-case tamper matrix is detected in 19 cases, and the five misses are reported with their consequences (most are benign, one is a rollback with no freshness counter). A raw-byte audit finds 0 of 11 distinctive file-name, directory-name and content tokens in the container, but reconstructs the number of records and a size profile from the public 16-byte framing alone; eight files collapse into six inferred groups because two sizes are exact multiples of the chunk size. Password rotation takes 105--108 ms for containers from 8 MiB to 1 GiB, changes 388--399 bytes of header, rewrites 69,632 bytes, and leaves the data zone byte-identical. Create and extract throughput are 130--211 and 222--261 MiB/s on one host; the Python process's traced allocation stays at 6.2--7.2 MiB for both an 8 MiB and a 256 MiB container, which supports the streaming claim, while peak working set is dominated by the 64 MiB Argon2id cost. The contribution is the measured boundary: what the framing hides, what it cannot hide, and which attacks the format is not designed to stop.

Body

Imported entry paper (unverified hypothesis)

This paper was imported into jetessays as an entry paper from the author's local archive (ulocker). It is not an established result: under jetessays policy every item is an UNVERIFIED HYPOTHESIS unless explicitly verified. The original source files (LaTeX, figures, scripts, measurements) live in the author's local archive and are not hosted here.

Abstract (as submitted)

Full-disk encryption protects a USB drive only where a filesystem filter driver can be installed, and the ciphertext still exposes file names, directory structure and exact sizes to anyone who reads the raw device. ULocker is a container format that moves the unit of protection from the block device to a single file: the archive carries an encrypted index, so names and the directory tree are not readable without the password, and file content is written as independently authenticated 1 MiB chunks. A password-derived key unwraps an index key, which in turn unwraps a random data key, so a password change rewrites the header rather than the payload. We measure the format rather than assert its properties. The implementation passes its 212-test suite; a 24-case tamper matrix is detected in 19 cases, and the five misses are reported with their consequences (most are benign, one is a rollback with no freshness counter). A raw-byte audit finds 0 of 11 distinctive file-name, directory-name and content tokens in the container, but reconstructs the number of records and a size profile from the public 16-byte framing alone; eight files collapse into six inferred groups because two sizes are exact multiples of the chunk size. Password rotation takes 105--108 ms for containers from 8 MiB to 1 GiB, changes 388--399 bytes of header, rewrites 69,632 bytes, and leaves the data zone byte-identical. Create and extract throughput are 130--211 and 222--261 MiB/s on one host; the Python process's traced allocation stays at 6.2--7.2 MiB for both an 8 MiB and a 256 MiB container, which supports the streaming claim, while peak working set is dominated by the 64 MiB Argon2id cost. The contribution is the measured boundary: what the framing hides, what it cannot hide, and which attacks the format is not designed to stop.

Note

Imported via the jetessays seed importer. The author chose not to keep an explicit upload record on this site; the work is listed as an entry paper so it can be discovered, discussed, endorsed and relayed.

Discussion

Log in to join the discussion

← back to browse