[cdumler]

> The capability of plausible deniability is that the encrypted file is indistinguishable from noise; There is no way you can find out the amount of data stored in the cryptocontainer.

The problem with deniable encryption is: if the attacker can watch the file changes, one can determine the rough size of the data in the volume. The attacker makes note of where in the file changes occur. Once you get them to unlock the file you see if the data is shorter than the size of file changes. If so, you know there is more data.

Once an attacker can see your encrypted volume, you can no longer make changes to the hidden data.

[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.

[thesz]

I think yours is a very deep comment.

Some log-oriented file systems may provide insight into changes made. From what I know, ZFS is one example of such file system and btrfs is another.

[bb88]

> The problem with deniable encryption is: if the attacker can watch the file changes, one can determine the rough size of the data in the volume.

I think it's even more basic than that. An attacker just needs to know you've used such a tool (by using FractalCrypt, eg) to know you're not really unlocking it.

After that it's pretty much game over, at least on being able to have deniability.

[3np]

This is a specific threat model where the attacker can watch live file changes undetected. This may be acceptable e.g. for a laptop without historical archives of the file.

[malf]

If there’s wear leveling, there’s metadata. If not, there’s, like, wear.

[3np]

Good point and good to be aware of. Still, it requires dedicated physical access and specialized physical equipment, right?

I think that at least for the foreseeable decade or so, there are only a handful individuals globally for whom this would be a practical vector rather than a purely theoretical one.

It'd be interesting to see if it can be practical to improve in regards to that

[anigbrowl]

Sure, but all security mechanisms have problems. That doesn't mean they can't be good for limited purposes as long as you're mindful of limitations.