From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gmazyland@gmail.com>
Received: from mail.saout.de ([127.0.0.1])
 by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id lzF-l6t3kTU9 for <dm-crypt@saout.de>;
 Fri,  7 Dec 2012 23:35:45 +0100 (CET)
Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (No client certificate requested)
 by mail.saout.de (Postfix) with ESMTPS
 for <dm-crypt@saout.de>; Fri,  7 Dec 2012 23:35:45 +0100 (CET)
Received: by mail-ee0-f50.google.com with SMTP id b45so659975eek.37
 for <dm-crypt@saout.de>; Fri, 07 Dec 2012 14:35:45 -0800 (PST)
Message-ID: <50C26F3D.3070101@gmail.com>
Date: Fri, 07 Dec 2012 23:35:41 +0100
From: Milan Broz <gmazyland@gmail.com>
MIME-Version: 1.0
References: <CAFnMBaRZAqnL=ymWZLR2XEynLw8paV+cLjTQ0ytFcir2wK3LOA@mail.gmail.com>
In-Reply-To: <CAFnMBaRZAqnL=ymWZLR2XEynLw8paV+cLjTQ0ytFcir2wK3LOA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [dm-crypt] request for new API to found out is a volume is a
 luks volume or a tcrypt volume
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt/>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=subscribe>
To: ".. ink .." <mhogomchungu@gmail.com>
Cc: dm-crypt@saout.de

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