create an external backup header file about tc-play HOT 25 CLOSED

On 2013-10-18 03:03, mhogomchungu wrote:

truecrypt binary has an option to create a volume header backup in a
separate file independently of the encrypted volume.Any plans to
support this feature?

It's straight forward enough; I'll implement it in the next version.

truecrypt binary also seem to recreate the header when backing it up
whereas cryptsetup seem to just "memcpy()" a LUKS header to a
separate
file as a LUKS header backup.

Any comments on why these two behave differently if you have any?

They behave differently because they are completely different in how
they work.

TrueCrypt aims at plausible deniability, so the header should "appear
random". As such, it contains a random salt, which is then used together
with the passphrase/keyfile to derive a key that may (or may not)
decrypt the actual header (which is located just after the random salt).
As such, you wouldn't want your backup header to look just like the
header on your disk, when you can easily enough just pick a different
random salt to encrypt the master key.

On the other hand, the LUKS header even has specific magic bytes to
identify it. Additionally, since LUKS supports several key slots, each
key slot has its own salt. If you wanted to generate a new LUKS header
(with different salts) with the same master key, you'd have to know all
the passphrases for all key slots. And since LUKS doesn't even try the
whole "plausible deniability" thing there is limited benefit to it in
the first place.

from tc-play.

I should clarify that the TrueCrypt header has no identifiable bits - i.e. nothing that clearly identifies it as a TrueCrypt header, or anything other than random data, really. So, effectively, there is not much point for LUKS to do it, apart from being infeasible since you need passphrases/keyfiles for all key slots.

from tc-play.

cryptsetup people have a negative view on hidden volumes and plausible deniability feature of truecrypt.

what is your general view of the feature?
Do you think its an important feature of significant usefulness or a feature of marginal importance that largely exist for marketing purposes or somewhere in the middle of the two?

from tc-play.

On 2013-10-18 07:59, mhogomchungu wrote:

cryptsetup people have a negative view on hidden volumes and
plausible deniability feature of truecrypt.

what is your general view of the feature?
Do you think its an important feature of significant usefulness or a
feature of marginal importance that largely exist for marketing
purposes or somewhere in the middle of the two?

First off - I'm not a cryptographer, so my two cents are really just
that, my two cents.

IMO plausible deniability is, in theory, a very nice thing to have. In
reality, however, it's very hard to achieve.

Taking the example of hidden volumes, it's relatively easy to leak the
existence of the hidden volume. Silly things like "recent documents"
kind of thing, /tmp files, etc, can easily give your hidden volume away.

Plausible deniability of an outer volume is even worse off. If there's
a partition/external disk/etc that doesn't seem to contain any known
filesystem - isn't it reasonable enough to assume that it might well be
encrypted?

In practice I just don't think there is a particular and real benefit
to (TrueCrypt's) plausible deniability. That said, it's no worse than an
explicit header (like LUKS'). The only dangerous thing about this kind
of pseudo "plausible deniability" is that someone might actually believe
it offers real plausible deniability.

from tc-play.

you have a point, a 20GB file made up of high quality random data is more than most likely an encrypted volume and under certain circumstances,it better be because proving that it isnt(if it really isnt) is not possible.Thanks for the comment.

from tc-play.

I'll probably get down to doing it this weekend.

from tc-play.

Well, I've added all the required logic and added the command line options. However, I still need/want to do the following:

• add tests for these features
• refactor the internal "API" to avoid having ever-growing lists of arguments
• refactor the external "API" - my assumption that I wouldn't change the tc_api_opts structure much is clearly not holding.

from tc-play.

I'll be ok with whatever modifications you will make on the public API,dont hold back anything on my account.

from tc-play.

The new API is mostly in place now, but I still need to figure out the error messages and logging in general.

My current plan for that is to allow the user to register two callbacks via the task_set method for state logging and error logging. The state logging are the non-error messages + messages when it starts and ends long processes (such as gathering entropy and wiping the disk). That way the user of the API gets all the messages, not just whatever is still in the internal log buffer, with an indication of whether it's an error message or something else.

Any thoughts?

Other stuff that's missing:

• new man page for new API
• more tests for new features (restore from/save to header file, mainly)

from tc-play.

Let say the user has set the error logging method and the error happens,the API will first call the user provided error function and then return with an error and that seems like an anti pattern to me since the normal approach is to get the return value from the API and then check the error message if interested in it.

The new API looks like its build to last :-) but the "key" variable name seem odd to me.

from tc-play.

your new API fail to build in C++

below program produces below outputs

struct tc_api_task;
struct tc_api_volinfo;

typedef struct tc_api_task *tc_api_task;
typedef struct tc_api_volinfo *tc_api_volinfo;

int main(void)
{
    return 0 ;
}

[ink@mtz ~]$ gcc -o tc t.c
[ink@mtz ~]$ g++ -o tcpp t.cpp
t.cpp:5:29: error: conflicting declaration ‘typedef struct tc_api_task* tc_api_task’
t.cpp:2:8: error: ‘struct tc_api_task’ has a previous declaration as ‘struct tc_api_task’
t.cpp:6:32: error: conflicting declaration ‘typedef struct tc_api_volinfo* tc_api_volinfo’
t.cpp:3:8: error: ‘struct tc_api_volinfo’ has a previous declaration as ‘struct tc_api_volinfo’
[ink@mtz ~]$ 

from tc-play.

Well, it was more of a case of: if you get an error, check any errors that were logged using the given callback function for a description - so it's really a logging function that provides you with information as to whether it's related to an error or not. So point is: it's not an error function, it's a logging function.

from tc-play.

would appreciate a comment on why i can not seem to get the new API to set cipher chain from this this source file[1]

line 183 seem to work without a problem while line 161 fail with an "invalid cipher" comment as seen from below output

[ink@localhost zuluCrypt-cli]$ zuluCrypt-cli -ck -d /home/ink/test.img -t tcrypt -e 10000000 -f /home/ink/zc/key1 -u /home/ink/zc/key
Invalid cipher: AES-256-XTS
SUCCESS: volume created successfully

The above command basically creates a truecrypt volume with a 10MB hidden volume using keyfiles for both inner and outer volume.

So far,the new API seem to more or less the same as the old one.

[1] https://github.com/mhogomchungu/zuluCrypt/blob/master/zuluCrypt-cli/lib/create_tcrypt.c

from tc-play.

Probably because tc_api_init is called after 161 but before 183.
tc_api_init initializes cipher chains.

You should always call tc_api_init() first, before any other (API) function.

HTH,
Alex

On 05/01/14 05:41, mhogomchungu wrote:

would appreciate a comment on why i can not seem to get the new API to
set cipher chain from this this source file[1]

line 183 seem to work works without a problem while line 161 fail with
an "invalid cipher" comment as seen from below output

|[ink@localhost zuluCrypt-cli]$ zuluCrypt-cli -ck -d /home/ink/test.img -t tcrypt -e 10000000 -f /home/ink/zc/key1 -u /home/ink/zc/key
Invalid cipher: AES-256-XTS
SUCCESS: volume created successfully
|

The above command basically creates a truecrypt volume with a 10MB
hidden volume using keyfiles for both inner and outer volume.

So far,the new API seem to more or less the same as the old one.

[1]
https://github.com/mhogomchungu/zuluCrypt/blob/master/zuluCrypt-cli/lib/create_tcrypt.c

—
Reply to this email directly or view it on GitHub
#43 (comment).

from tc-play.

shouldnt "tc_api_task_init()" deal with all necessary initializations for the operation it is created to do? I call it at line 144.

speaking of "tc_api_task_init()",what is the proper way to check if it succeeded or not?

from tc-play.

On 05/01/14 07:56, mhogomchungu wrote:

shouldnt "tc_api_task_init()" deal with all necessary initializations
for the operation it is created to do? I call it at line 144.

No - tc_api_task_init deals with initialization of a task. You can
call this multiple times- effectively every time you want to do a
certain tcplay operation. You shouldn't reuse a task.

tc_api_init deals with initialization of tcplay. In practice, that means
initializing ciphers and building the cipher chain stuff.

tc_api_uninit, btw, will clean all memory that tcplay has allocated and
might not have been unallocated for whatever reason yet - so you should
always call it at some point as well.

speaking of "tc_api_task_init()",what is the proper way to check if it
succeeded or not?

if it returns NULL, it failed. Otherwise it succeeded.

from tc-play.

in the "write_to_file()" function in io.c,the "open()" function does not have "O_CREAT" argument and hence the attempt to create a backup of the header in a file fail if the file path is not valid.

I think it will be better if the function will check if the path is already taken and fail out if it is and should create the file to put the header in when it found the path not taken.

With the current behavior,the user of the API will have to create an empty file before calling the API and that seem like an odd requirement.

from tc-play.

Just completed adding support for saving and restoring volume headers and the new API works for all my use cases.

The terminal though produces the following output

[ink@mtz ~]$ zuluCrypt-cli -B -d ~/tcrypt_1.img -z ~/rrr  -p xxx
Oops, secure memory pool already initialized
SUCCESS: header saved successfully
[ink@mtz ~]$ 

The "Oops" line is coming from somewhere in tcplay

from tc-play.

I hope to finish the new API and release 2.0 some time in the next few weeks. Good to hear it all works :)

from tc-play.

From a short googling, that oops comes from gcrypt, so potentially initializing that somewhere twice. I don't think I've ever seen that with tcplay itself, so I'll have to have a look at zulucrypt.

from tc-play.

I just looked into this and it looks like in my case,cryptsetup initializes the library and tcplay reinitialize it too and that is where the message is coming from.It comes from gcrypt double initialization.

Based on the link below,it seems like both you and cryptsetup are not using the library the way it is recommended since both of you are initializing it in your respective libraries.

Perhaps it will be better for tcplay to not keep an internal variable that tracks its own initialization of the library and instead use a global one as recommended in the linked page.

http://www.gnupg.org/documentation/manuals/gcrypt/Initializing-the-library.html#Initializing-the-library

from tc-play.

I'll add that check for

if (!gcry_control (GCRYCTL_INITIALIZATION_FINISHED_P))

later today.

from tc-play.

Have committed that now. Hopefully you won't see the issue anymore, assuming you initialize tcplay after cryptsetup.

from tc-play.

Just checked and the issue is gone now.

I looked at cryptsetup source code and they did not have this problem since they only initialize the library after they found it not already initialized.In other words,they do what you are now doing.

from tc-play.

All of this is in now. If you find any other issue before I release 2.0 later this month, please open another one.

Thanks :)

from tc-play.