Expanded more on protection of hidden TrueCrypt volumes and

its problems.

1 files changed, 15 insertions, 3 deletions

diff --git a/man/cryptsetup.8 b/man/cryptsetup.8
index 688d169..f4a12cd 100644
--- a/man/cryptsetup.8
+++ b/man/cryptsetup.8
@@ -426,9 +426,21 @@ become detectable. This is not a cryptsetup limitation, it is
 a limitation of how hidden volumes are implemented in TrueCrypt.
 The way to deal with this is not to mount the outer volume after
 a hidden volume has been created in it.
-This, in turn, causes the problem that after a while all time-stamps
-in the outer volume become old and it becomes obvious that
-it is unused. This may cause suspicion in itself. 
+This, in turn, causes the problem that after a while all 
+time-stamps in the outer volume become old and it becomes obvious 
+that it is unused. This may cause suspicion in itself. 
+An alternative is to protect the area of the hidden volume
+from write access using the Device Mapper, e.g. by mapping it
+to the zero or error target. This corresponds to the protection 
+mechanism present in TrueCrypt, but can cause filesystem 
+annomalies and error messages in the system logs that reveal 
+the presence of the hidden volume. For that reason, TrueCrypt
+sets both outer and hidden volume to read-only once a write
+that would have damaged the hidden volume is intercepted.
+They claim this preserves plausible deniability, but that
+claim seems doubtful, because it also limits possible
+changes to the outer volume and may result in truncated
+and damaged files.   
 
 .PP
 \fIopen\fR \-\-type tcrypt <device> <name>