From: Milan Broz <gmazyland@gmail.com>
To: ".. ink .." <mhogomchungu@gmail.com>
Cc: dm-crypt@saout.de
Subject: Re: [dm-crypt] request for new API to found out is a volume is a luks volume or a tcrypt volume
Date: Fri, 07 Dec 2012 23:35:41 +0100 [thread overview]
Message-ID: <50C26F3D.3070101@gmail.com> (raw)
In-Reply-To: <CAFnMBaRZAqnL=ymWZLR2XEynLw8paV+cLjTQ0ytFcir2wK3LOA@mail.gmail.com>
On 12/07/2012 10:50 PM, .. ink .. wrote:
> finding out if a device is luks device is a bit clunky at the moment
> because a user will have to go through the crypt_init(),crypt_load()
> and finally crypt_free() to see if a device is luks device.
yes, this is how it is designed.
> Just added support for opening truecrypt volumes and the way to check
> if a volume is a true crypt volume seem to be clunkier since it
> involves doing
> crypt_init(),crypt_load(),crypt_activate_by_volume_key() and if on
> success, crypt_deavicate() and then finally crypt_free()
No. crypt_load is enough, exactly the same logic as in LUKS
(just need to provide password/keyfiles).
See action_isLuks and action_tcryptDump (in cryptsetup.c).
truecrypt-compatible header support it is not yet stable API,
I am still playing with it and it can still change.
(but you already found it so thanks for testing ;-)
(And for curious - only activation will supported, no header
manipulation. I will write more later on pre-release time,
it will need a lot of testing.)
> It will be nice if these operations were simplified with something
> like:
>
> crypt_is_luks( const char* device )
> crypt_is_tcrypt( const char* device,const char* key,size_t key_len )
Is it really problem to do 3 simple steps? (init, load, free)
Milan
next prev parent reply other threads:[~2012-12-07 22:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-07 21:50 [dm-crypt] request for new API to found out is a volume is a luks volume or a tcrypt volume .. ink ..
2012-12-07 22:35 ` Milan Broz [this message]
2012-12-07 22:58 ` .. ink ..
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50C26F3D.3070101@gmail.com \
--to=gmazyland@gmail.com \
--cc=dm-crypt@saout.de \
--cc=mhogomchungu@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.