From 1a5c169c064d85e250f00c9b1cf7dccf22dd7a55 Mon Sep 17 00:00:00 2001 From: wagner Date: Tue, 2 Jul 2013 03:23:49 +0200 Subject: [PATCH] Expanded more on protection of hidden TrueCrypt volumes and its problems. --- man/cryptsetup.8 | 18 +++++++++++++++--- 1 file 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 -- 2.7.4