[derefr]

This presumes that you’re working in a random-access manner with your data. A lot of deniable-encryption use-cases involve archival access (i.e. tossing new files into the container, with each written file then treated as immutable.)

An attacker watching the side-channel of your access pattern would just see you growing the volume. But that doesn’t tell them whether you’re adding new real data, or adding noise.

[cdumler]

An important part of deniable encryption is that you can "provably" deny data isn't there when it is. You want the authorities to agree that when you unlock your volume they see "all" of your data so they don't hold you in contempt. If the total changes is less than the data visible, the assumption is you're hiding more data. Adding noise isn't deniable. In fact, it would hurt you: If you can't prove your noise is noise then the authorities are going to assume you are hiding data.

I think you make a good point: the only way to be secure in this method is to A) work on an uncompromised machine and B) write each layer in series and C) never change it again.

[a1369209993]

> Adding noise isn't deniable.

Noise should be added either in a fixed pattern or randomly. Eg consider a disk of size 2^N, with volumes of size 2^(N-1), 2^(N-2), 2^(N-3), ..., 2^(log minsize). Blocks would be written such that every second block is for volume -1, every fourth block is for volume -2, etc. Data for lower volumes should be queued to be written in turn; when the turn comes up, if the queue is empty (or less than a appropriately-distributed[0] random amount full), a appropriately-distributed[0] number of new blocks should be added to the queue.

(Note that you'll also need a compaction phase when the disk fills up; I don't think that can be done without the keys for the lower volumes (or losing that data), so you need to be careful to regularly compact while in a safe environment.)

0: This requires some tuning depending on general (but obviously not specific) expected usage.