Emergency wipe and deniability

[jaromil]

There are situations in which one may be coerced to give up the password, with a fine or imprisonment or even torture. We can address this in Tomb v3 with a new feature, hereby proposed.

An additional 'emergency' password may be given: when used to open the tomb will silently wipe all contents and eventually place decoy contents inside to not raise suspicion. This should happen without leaving a trace of the operation. Of course those adopting this feature are supposed to have backups of the Tomb in another place.

I'm interested in discussing this feature while designing the upcoming Tomb major version which will rely on Zenroom rather than GnuPG for key encryption, hence offering more advanced logics of interaction with passwords and keys as well advanced crypto as zero-knowledge proofs (zk-SNARKS).

Comments welcome.

[Narrat]

Definitely an interesting idea. But in what way generate meaningful decoy items?
Another idea in that regard could be a hidden volume. One file, password x opens the first and another opens an additional container hidden in that file. But propably not easy an easy task to implement. First glance might be good, but if "the numbers aren't matching"..

[amerlyq]

the numbers aren't matching

We actually could resize (extend) decoy partition volume and filesystem on-the-fly to make external and internal size of tomb matching :) And decoy itself may be a compressed volume on top of that.

Decoys are better be manually picked and prepared beforehand. Because they must have a feeling of being "personally sensitive" -- enough to justify placing into tomb -- and still exposure of which would be "recoverable". Such that this "oversecurity" leaved people in the bewilderment and laughing over the geek you are. Like keeping some insignificant work-related documents and passwords to useless sites inside of tomb -- which will always can be justified as reasonable and done by you only for the fun.

The only issue -- we must randomly update dates on decoy files to simulate recent activity.
Maybe even populate ext4 journal with some move/copy ghost entries to misguide deep analysis.

[jaromil]

Back on this topic, I have been pondering where to store the emergency password activating the decoy, since that should be undetectable... tricky.

I now see that the steganography tool outguess can store multiple and hard to detect secrets inside the same jpeg.

This feature then may be best activated using such steganography, which BTW we haven't yet implemented.

Other details on decoy management still need thinkering... making it up to date with recent file access could be automated....