[dm-crypt] [ANNOUNCE] cryptsetup 1.2.0-rc1 (test release candidate)

[dm-crypt] [ANNOUNCE] cryptsetup 1.2.0-rc1 (test release candidate)

[Milan Broz]

Cryptsetup 1.2.0 (rc1) Release Notes
====================================

The first cryptsetup 1.2.0-rc1 release candidate is available at

   http://code.google.com/p/cryptsetup/

Feedback and bug reports are welcomed.

Changes since version 1.1.3

Important changes
~~~~~~~~~~~~~~~~~

 * Add text version of *FAQ* (Frequently Asked Questions) to distribution.

 * Add selection of random/urandom number generator for luksFormat
 (option --use-random and --use-urandom).

 (This affects only long term volume key in *luksFormat*,
 not RNG used for salt and AF splitter).

  You can also set the default to /dev/random during compilation with
  --enable-dev-random. Compiled-in default is printed in --help output.

  Be very careful before changing default to blocking /dev/random use here.

 * Fix *luksRemoveKey* to not ask for remaining keyslot passphrase,
 only for removed one.

 * No longer support *luksDelKey* (replaced with luksKillSlot).
  * if you want to remove particular passphrase, use *luksKeyRemove*
  * if you want to remove particular keyslot, use *luksKillSlot*

 Note that in batch mode *luksKillSlot* allows removing of any keyslot
 without question, in normal mode requires passphrase or keyfile from
 other keyslot.

 * *Default alignment* for device (if not overridden by topology info)
 is now (multiple of) *1MiB*.
 This reflects trends in storage technologies and aligns to the same
 defaults for partitions and volume management.

 * Allow explicit UUID setting in *luksFormat* and allow change it later
 in *luksUUID* (--uuid parameter).

 * All commands using key file now allows limited read from keyfile using
 --keyfile-size and --new-keyfile-size parameters (in bytes).

 This change also disallows overloading of --key-size parameter which
 is now exclusively used for key size specification (in bits.)

 * *luksFormat* using pre-generated master key now properly allows
 using key file (only passphrase was allowed prior to this update).

 * Add --dump-master-key option for *luksDump* to perform volume (master)
 key dump. Note that printed information allows accessing device without
 passphrase so it must be stored encrypted.

 This operation is useful for simple Key Escrow function (volume key and
 encryption parameters printed on paper on safe place).

 This operation requires passphrase or key file.

 * The reload command is no longer supported.
 (Use dmsetup reload instead if needed. There is no real use for this
 function except explicit data corruption:-)

 * Cryptsetup now properly checks if underlying device is in use and
 disallows *luksFormat*, *luksOpen* and *create* commands on open
 (e.g. already mapped or mounted) device.

 * Option --non-exclusive (already deprecated) is removed.

Libcryptsetup API additions:

 * new functions
  * crypt_get_type() - explicit query to crypt device context type
  * crypt_resize() - new resize command using context
  * crypt_keyslot_max() - helper to get number of supported keyslots
  * crypt_get_active_device() - get active device info
  * crypt_set/get_rng_type() - random/urandom RNG setting
  * crypt_set_uuid() - explicit UUID change of existing device
  * crypt_get_device_name() - get underlying device name

 * Fix optional password callback handling.

 * Allow to activate by internally cached volume key immediately after
 crypt_format() without active slot (for temporary devices with
 on-disk metadata)

 * libcryptsetup is binary compatible with 1.1.x release and still
 supports legacy API calls

 * cryptsetup binary now uses only new API calls.

 * Static compilation of both library (--enable-static) and cryptsetup
 binary (--enable-static-cryptsetup) is now properly implemented by common
 libtool logic.

 Prior to this it produced miscompiled dynamic cryptsetup binary with
 statically linked libcryptsetup.

 The static binary is compiled as src/cryptsetup.static in parallel
 with dynamic build if requested.

Other changes
~~~~~~~~~~~~~
 * Fix default plain password entry from terminal in activate_by_passphrase.
 * Initialize volume key from active device in crypt_init_by_name()
 * Fix cryptsetup binary exit codes.
   0 - success, otherwise fail
   1 - wrong parameters
   2 - no permission
   3 - out of memory
   4 - wrong device specified
   5 - device already exists or device is busy
 * Remove some obsolete info from man page.
 * Add more regression tests for commands.
 * Fix possible double free when handling master key file.
 * Fix pkg-config use in automake scripts.
 * Wipe iteration and salt after luksKillSlot in LUKS header.
 * Rewrite file differ test to C (and fix it to really work).
 * Do not query non-existent device twice (cryptsetup status /dev/nonexistent).
 * Check if requested hash is supported before writing LUKS header.
 * Fix problems reported by clang scan-build.

Milan

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.2.0-rc1 (test release candidate)

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 136 bytes --]

On Tue, 2010-11-16 at 09:58 +0100, Milan Broz wrote:
> Cryptsetup 1.2.0 (rc1) Release Notes
Great :) Well done!


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.2.0-rc1 (test release candidate)

[Milan Broz]

On 11/16/2010 09:58 AM, Milan Broz wrote:
> 
>   Be very careful before changing default to blocking /dev/random use here.

Just my personal rant here:

Why I think using /dev/random is strange idea.

I think that /dev/urandom should be usable for long term key use. Period.

If you know about some problem, please fix it. Use better PRNG. Whatever.

There are many "entropy" sources which fills the entropy pool
and which are (or will be) disputable in several situations.

Just examples:

- disk seek as source of entropy. What happens if you replace HDD with SSD
(with constant seek time)? (Recent kernels already disabled it
for non-rotational drives).

- fully virtualised environment - how we can pretend that events are random
if everything is virtualised and controlled by hypervisor?
Can hypervisor fake events such way that application waiting for /dev/random
input get some mangled values? Is it real risk or not for you?

- HW random generators. Can you prove that your favourite chip manufacturer
really generates "true random"(tm)? Can anyone fake it by hw manipulation?
(Like manipulating with voltage or whatever.)

For me seems to be better to have some defined PRNG (pseudo random number generator)
in kernel which is designed with known and open algorithms.
(an example like ANSI X9.31 PRNG based on CTR(AES-128))

It is interesting to see how various programs tried to "fix" this problem.

See Truecrypt with its random pool and hash mixes.

See gcrypt which tries to get 300 bytes from /dev/random just to initialise
its own "strong random pool".

...

Then read "man urandom" page:

"A read from the /dev/urandom device will not block waiting for more entropy.  As a result,
if there is not sufficient entropy in the entropy pool, the returned values are theoretically
vulnerable to a cryptographic attack  on  the  algorithms  used  by  the driver.
Knowledge  of how to do this is not available in the current unclassified literature,
but it is theoretically possible that such an attack may exist.  If this is a concern in your
application, use /dev/random instead."

then (means reading /dev/random):

" ... so if any program reads more  than  256  bits  (32 bytes) from the kernel random pool
per invocation, or per reasonable reseed interval (not less than one minute), that should be
taken as a sign that its cryptography is not skilfully implemented."

Evil application can always exhaust /dev/random pool affecting other users or intentionally
drop applications into state that /dev/random blocks.

Seems anyone implements some own random pool to avoid this.

Why every application should try to solve this in the fist place?
Why risk possible mistakes in such critical part of system like key generator
in every application?

So. The basic idea of cryptsetup is to "setup" volumes and "use" kernel provided
crypto. Not to fix kernel RNG or crypto. Not to implement cryptographic primitives
itself and introduce possible mistakes.

If the encryption algorithm is broken or proven to not be strong enough - you will
replace it with something better, right?
I think this should apply to /dev/urandom RNG too.
</rant>

I implemented random/urandom selection so you can do whatever you want with it now..

But please think about it - If cryptsetup relies on kernel for encryption, it should trust
even its RNG. Even virtual machine with no entropy once seeded should provide some
reliable and nonblocking PRNG.

BTW I'll be happy if you can provide links to literature and analysis related
to this problem.

Milan

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.2.0-rc1 (test release candidate)

[Arno Wagner]

I have trouble parsing this. Is it a list-replay to a
partially quoted personal message?

As a statement to random/urandom, some time ago we discussed that
in an entropy-starved installation situation (and basically only
there), using /dev/random instead of /dev/urandom would be a good 
idea under some circumstances, even if it may make key generation 
slow. For practically all other cases /dev/urandom should be 
fine. If I remember correctly, the request to allow the use of
/dev/randome was only for this special situation or similar others.

As to the possible entropy-startved situations, embedded systems
and virtualized systems in connection with automatized installation
were mentioned. 

An alternative would be to introduce randomness form the outside,
but that may again be a security risk. Bottom line, setting
key-generation to use /dev/random is a specialist option that
most beople will never need, but that can be very handy in
some situations.

Arno


On Wed, Nov 17, 2010 at 07:01:16PM +0100, Milan Broz wrote:
> On 11/16/2010 09:58 AM, Milan Broz wrote:
> > 
> >   Be very careful before changing default to blocking /dev/random use here.
> 
> Just my personal rant here:
> 
> Why I think using /dev/random is strange idea.
> 
> I think that /dev/urandom should be usable for long term key use. Period.
> 
> If you know about some problem, please fix it. Use better PRNG. Whatever.
> 
> There are many "entropy" sources which fills the entropy pool
> and which are (or will be) disputable in several situations.
> 
> Just examples:
> 
> - disk seek as source of entropy. What happens if you replace HDD with SSD
> (with constant seek time)? (Recent kernels already disabled it
> for non-rotational drives).
> 
> - fully virtualised environment - how we can pretend that events are random
> if everything is virtualised and controlled by hypervisor?
> Can hypervisor fake events such way that application waiting for /dev/random
> input get some mangled values? Is it real risk or not for you?
> 
> - HW random generators. Can you prove that your favourite chip manufacturer
> really generates "true random"(tm)? Can anyone fake it by hw manipulation?
> (Like manipulating with voltage or whatever.)
> 
> For me seems to be better to have some defined PRNG (pseudo random number generator)
> in kernel which is designed with known and open algorithms.
> (an example like ANSI X9.31 PRNG based on CTR(AES-128))
> 
> It is interesting to see how various programs tried to "fix" this problem.
> 
> See Truecrypt with its random pool and hash mixes.
> 
> See gcrypt which tries to get 300 bytes from /dev/random just to initialise
> its own "strong random pool".
> 
> ...
> 
> Then read "man urandom" page:
> 
> "A read from the /dev/urandom device will not block waiting for more entropy.  As a result,
> if there is not sufficient entropy in the entropy pool, the returned values are theoretically
> vulnerable to a cryptographic attack  on  the  algorithms  used  by  the driver.
> Knowledge  of how to do this is not available in the current unclassified literature,
> but it is theoretically possible that such an attack may exist.  If this is a concern in your
> application, use /dev/random instead."
> 
> then (means reading /dev/random):
> 
> " ... so if any program reads more  than  256  bits  (32 bytes) from the kernel random pool
> per invocation, or per reasonable reseed interval (not less than one minute), that should be
> taken as a sign that its cryptography is not skilfully implemented."
> 
> Evil application can always exhaust /dev/random pool affecting other users or intentionally
> drop applications into state that /dev/random blocks.
> 
> Seems anyone implements some own random pool to avoid this.
> 
> Why every application should try to solve this in the fist place?
> Why risk possible mistakes in such critical part of system like key generator
> in every application?
> 
> So. The basic idea of cryptsetup is to "setup" volumes and "use" kernel provided
> crypto. Not to fix kernel RNG or crypto. Not to implement cryptographic primitives
> itself and introduce possible mistakes.
> 
> If the encryption algorithm is broken or proven to not be strong enough - you will
> replace it with something better, right?
> I think this should apply to /dev/urandom RNG too.
> </rant>
> 
> I implemented random/urandom selection so you can do whatever you want with it now..
> 
> But please think about it - If cryptsetup relies on kernel for encryption, it should trust
> even its RNG. Even virtual machine with no entropy once seeded should provide some
> reliable and nonblocking PRNG.
> 
> BTW I'll be happy if you can provide links to literature and analysis related
> to this problem.
> 
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.2.0-rc1 (test release candidate)

[Milan Broz]

On 11/17/2010 11:36 PM, Arno Wagner wrote:
> I have trouble parsing this. Is it a list-replay to a
> partially quoted personal message?

Partially. It is just warning that setting default is not just
straightforward.

(I think there is already request for setting default to /dev/random
in Debian.)

> If I remember correctly, the request to allow the use of
> /dev/randome was only for this special situation or similar others.

Sure, this setting affects only volume key generation. Others
are always generated using urandom. 
(See the source in lib/random.c - there is flag CRYPT_RND_NORMAL / KEY.
Only calls marked with KEY quality can use /dev/random.)

> As to the possible entropy-startved situations, embedded systems
> and virtualized systems in connection with automatized installation
> were mentioned. 

I think it is not only about starved situations, thats just practical
impact of using this interface.
Ipsec need to set key too and cannot wait for entropy.
Isn't there the same quality requested if you can record encrypted
communication and analyse it later? (just example)

I sent this "rant" separately because it is just my opinion but
I simply think that /dev/random vs /dev/urandom is bad design.

But it is up to user how to configure cryptsetup - I provided
all needed ways to set it up according to needs
(configure, runtime, libcryptsetup API).

I would prefer some interface to kernel RNG where I can specify
requested quality. Or simply setup urandom to generate strong
data usable always as long term key.
Maybe we get better access to kernel RNG through new userspace API.

I think that many applications which implements its own RNG
(because mixing /dev/random with something into own pool _is_
new RNG) use some tricks. Are these tricks properly documented
and backed by proper analysis? I hope so:-)

> An alternative would be to introduce randomness form the outside,
> but that may again be a security risk. Bottom line, setting
> key-generation to use /dev/random is a specialist option that
> most beople will never need, but that can be very handy in
> some situations.

You can provide pre-generated volume key or you can use /dev/random
if requested in cryptsetup - the option is there.

Milan

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.2.0-rc1 (test release candidate)

[Christoph Anton Mitterer]

Quoting Milan Broz <mbroz@redhat.com>:
> (I think there is already request for setting default to /dev/random
> in Debian.)
Yeah that was me ;)

I mean I absolutely see your points, Milan.

But IMHO one should always go for the most secure setting per default.
Just the same as one e.g. does when gnupg creates keys. Of course one  
could argue there, too, that for the average user, urandom might be  
good enough.


As far as I've always understood you, your main-concern are fully  
automated installs, right?
And personally I just don't see the major use case of disk encryption  
for that at all.

And typically, when you do that you have some special tool for it  
anyway (e.g. FAI),... which could then always use --use-urandom per  
default.


That's why I personally would suggest to use random as default, and  
just announce this change in behaviour in some NEWS-file with the hint  
that the /dev/random blocking might be a problem for some people.
Just with about the same arguments, as it was agreed here (IIRC) that  
TRIM will be (for security reasons) discarded per default.



Cheers,
Chris.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.2.0-rc1 (test release candidate)

[Arno Wagner]

On Thu, Nov 18, 2010 at 04:51:08AM +0100, Milan Broz wrote:
> On 11/17/2010 11:36 PM, Arno Wagner wrote:
> > I have trouble parsing this. Is it a list-replay to a
> > partially quoted personal message?
> 
> Partially. It is just warning that setting default is not just
> straightforward.
> 
> (I think there is already request for setting default to /dev/random
> in Debian.)
> 
> > If I remember correctly, the request to allow the use of
> > /dev/randome was only for this special situation or similar others.
> 
> Sure, this setting affects only volume key generation. Others
> are always generated using urandom. 
> (See the source in lib/random.c - there is flag CRYPT_RND_NORMAL / KEY.
> Only calls marked with KEY quality can use /dev/random.)
> 
> > As to the possible entropy-startved situations, embedded systems
> > and virtualized systems in connection with automatized installation
> > were mentioned. 
> 
> I think it is not only about starved situations, thats just practical
> impact of using this interface.
> Ipsec need to set key too and cannot wait for entropy.

It has to. No entropy - no security. The entropy does not
nee to be "fresh", but it needs to be there.

> Isn't there the same quality requested if you can record encrypted
> communication and analyse it later? (just example)

Indeed.

> I sent this "rant" separately because it is just my opinion but
> I simply think that /dev/random vs /dev/urandom is bad design.

I don;t think there is anything wrong with /dev/random. 
But /dev/urandom would efinitely need to wait as default 
until it has been properly initialized before beginning
to hand out randomness. That it does not basically 
sisqualkifies it a crypto-generatro. If that is your
point, then I completely agree.

> But it is up to user how to configure cryptsetup - I provided
> all needed ways to set it up according to needs
> (configure, runtime, libcryptsetup API).
> 
> I would prefer some interface to kernel RNG where I can specify
> requested quality. Or simply setup urandom to generate strong
> data usable always as long term key.
> Maybe we get better access to kernel RNG through new userspace API.

I agree.

> I think that many applications which implements its own RNG
> (because mixing /dev/random with something into own pool _is_
> new RNG) use some tricks. Are these tricks properly documented
> and backed by proper analysis? I hope so:-)

But each one may get it worng. I agree that these are new 
generators and that /dev/random is just used as entropy source 
in this case.

Arno

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.2.0-rc1 (test release candidate)

[Milan Broz]

On 11/18/2010 01:40 PM, Arno Wagner wrote:
>> I think it is not only about starved situations, thats just practical
>> impact of using this interface.
>> Ipsec need to set key too and cannot wait for entropy.
> 
> It has to. No entropy - no security. The entropy does not
> nee to be "fresh", but it needs to be there.

Maybe I said it wrong - RNG of course must be seeded (using entropy).
But this is in initialisation phase. It must wait forever here
if there is no entropy.
But once seeded, it should produce strong enough stream of data,
optionally mixed with environmental noise.

Milan

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.2.0-rc1 (test release candidate)

[Arno Wagner]

On Thu, Nov 18, 2010 at 02:01:13PM +0100, Milan Broz wrote:
> On 11/18/2010 01:40 PM, Arno Wagner wrote:
> >> I think it is not only about starved situations, thats just practical
> >> impact of using this interface.
> >> Ipsec need to set key too and cannot wait for entropy.
> > 
> > It has to. No entropy - no security. The entropy does not
> > nee to be "fresh", but it needs to be there.
> 
> Maybe I said it wrong - RNG of course must be seeded (using entropy).
> But this is in initialisation phase. It must wait forever here
> if there is no entropy.
> But once seeded, it should produce strong enough stream of data,

Ah, yes, I see we are in agreement. Once properly seesed
it _must_ perform. 

> optionally mixed with environmental noise.

That is not stricly needed, agreed, but it helps to
add more entropy if the crypto-PRNG has slight weaknesses
or slight information leakage. It is more of a safety-net
for these cases. It is essential if an installation 
including seed is copied or restored from backup.


I also see you had a piece of information I was not aware
of so far (but which is logical in hindsight), namely that
the kernel does not reseed the PRNG from its former state
after a reboot. It seems in Debian, this is done by 
/etc/init.d/urandom, i.e. by the distribution.

Thinking about this, I believe the only clean solution would 
have been to drop /dev/urandom from the kernel entirely, as
it runs into the seeding problem after each reboot and has
to do so unless the kernel was allowed to write the filesystem,
which would cause a whole lot of other issues. It would
seem that while the kernel is the place to gather entropy 
(and /dev/random does a reasonable job of that), it is not
the place for a dependable cryptographic PRNG service. 


Ok, I think I really see your point now ;-)

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.2.0-rc1 (test release candidate)

[Arno Wagner]

Compiles and installs fine. What is the new output line
for 'type' on 'cryptestup status'?:


  type:  PLAIN


Arno


On Tue, Nov 16, 2010 at 09:58:51AM +0100, Milan Broz wrote:
> Cryptsetup 1.2.0 (rc1) Release Notes
> ====================================
> 
> The first cryptsetup 1.2.0-rc1 release candidate is available at
> 
>    http://code.google.com/p/cryptsetup/
> 
> Feedback and bug reports are welcomed.
> 
> Changes since version 1.1.3
> 
> Important changes
> ~~~~~~~~~~~~~~~~~
> 
>  * Add text version of *FAQ* (Frequently Asked Questions) to distribution.
> 
>  * Add selection of random/urandom number generator for luksFormat
>  (option --use-random and --use-urandom).
> 
>  (This affects only long term volume key in *luksFormat*,
>  not RNG used for salt and AF splitter).
> 
>   You can also set the default to /dev/random during compilation with
>   --enable-dev-random. Compiled-in default is printed in --help output.
> 
>   Be very careful before changing default to blocking /dev/random use here.
> 
>  * Fix *luksRemoveKey* to not ask for remaining keyslot passphrase,
>  only for removed one.
> 
>  * No longer support *luksDelKey* (replaced with luksKillSlot).
>   * if you want to remove particular passphrase, use *luksKeyRemove*
>   * if you want to remove particular keyslot, use *luksKillSlot*
> 
>  Note that in batch mode *luksKillSlot* allows removing of any keyslot
>  without question, in normal mode requires passphrase or keyfile from
>  other keyslot.
> 
>  * *Default alignment* for device (if not overridden by topology info)
>  is now (multiple of) *1MiB*.
>  This reflects trends in storage technologies and aligns to the same
>  defaults for partitions and volume management.
> 
>  * Allow explicit UUID setting in *luksFormat* and allow change it later
>  in *luksUUID* (--uuid parameter).
> 
>  * All commands using key file now allows limited read from keyfile using
>  --keyfile-size and --new-keyfile-size parameters (in bytes).
> 
>  This change also disallows overloading of --key-size parameter which
>  is now exclusively used for key size specification (in bits.)
> 
>  * *luksFormat* using pre-generated master key now properly allows
>  using key file (only passphrase was allowed prior to this update).
> 
>  * Add --dump-master-key option for *luksDump* to perform volume (master)
>  key dump. Note that printed information allows accessing device without
>  passphrase so it must be stored encrypted.
> 
>  This operation is useful for simple Key Escrow function (volume key and
>  encryption parameters printed on paper on safe place).
> 
>  This operation requires passphrase or key file.
> 
>  * The reload command is no longer supported.
>  (Use dmsetup reload instead if needed. There is no real use for this
>  function except explicit data corruption:-)
> 
>  * Cryptsetup now properly checks if underlying device is in use and
>  disallows *luksFormat*, *luksOpen* and *create* commands on open
>  (e.g. already mapped or mounted) device.
> 
>  * Option --non-exclusive (already deprecated) is removed.
> 
> Libcryptsetup API additions:
> 
>  * new functions
>   * crypt_get_type() - explicit query to crypt device context type
>   * crypt_resize() - new resize command using context
>   * crypt_keyslot_max() - helper to get number of supported keyslots
>   * crypt_get_active_device() - get active device info
>   * crypt_set/get_rng_type() - random/urandom RNG setting
>   * crypt_set_uuid() - explicit UUID change of existing device
>   * crypt_get_device_name() - get underlying device name
> 
>  * Fix optional password callback handling.
> 
>  * Allow to activate by internally cached volume key immediately after
>  crypt_format() without active slot (for temporary devices with
>  on-disk metadata)
> 
>  * libcryptsetup is binary compatible with 1.1.x release and still
>  supports legacy API calls
> 
>  * cryptsetup binary now uses only new API calls.
> 
>  * Static compilation of both library (--enable-static) and cryptsetup
>  binary (--enable-static-cryptsetup) is now properly implemented by common
>  libtool logic.
> 
>  Prior to this it produced miscompiled dynamic cryptsetup binary with
>  statically linked libcryptsetup.
> 
>  The static binary is compiled as src/cryptsetup.static in parallel
>  with dynamic build if requested.
> 
> Other changes
> ~~~~~~~~~~~~~
>  * Fix default plain password entry from terminal in activate_by_passphrase.
>  * Initialize volume key from active device in crypt_init_by_name()
>  * Fix cryptsetup binary exit codes.
>    0 - success, otherwise fail
>    1 - wrong parameters
>    2 - no permission
>    3 - out of memory
>    4 - wrong device specified
>    5 - device already exists or device is busy
>  * Remove some obsolete info from man page.
>  * Add more regression tests for commands.
>  * Fix possible double free when handling master key file.
>  * Fix pkg-config use in automake scripts.
>  * Wipe iteration and salt after luksKillSlot in LUKS header.
>  * Rewrite file differ test to C (and fix it to really work).
>  * Do not query non-existent device twice (cryptsetup status /dev/nonexistent).
>  * Check if requested hash is supported before writing LUKS header.
>  * Fix problems reported by clang scan-build.
> 
> Milan
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.2.0-rc1 (test release candidate)

[Milan Broz]

On 11/19/2010 02:01 AM, Arno Wagner wrote:
> Compiles and installs fine. What is the new output line
> for 'type' on 'cryptestup status'?:
> 
>   type:  PLAIN

It's the type of active device according to context,
(these are defined in libcryptsetup.h)
currently there is PLAIN (create command) and LUKS1 (luksOpen),
but maybe later some other formats appears.

Basically you can get this information already from
"dmsetup status <name>" and check DM-UUID prefix.
(In principle this prefix used to check which subsystem owns
the device.)

Probably should be mentioned released notes...

Milan

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.2.0-rc1 (test release candidate)

[Arno Wagner]

On Fri, Nov 19, 2010 at 09:49:21AM +0100, Milan Broz wrote:
> On 11/19/2010 02:01 AM, Arno Wagner wrote:
> > Compiles and installs fine. What is the new output line
> > for 'type' on 'cryptestup status'?:
> > 
> >   type:  PLAIN
> 
> It's the type of active device according to context,
> (these are defined in libcryptsetup.h)
> currently there is PLAIN (create command) and LUKS1 (luksOpen),
> but maybe later some other formats appears.

Ah. Makes sense.
 
> Basically you can get this information already from
> "dmsetup status <name>" and check DM-UUID prefix.
> (In principle this prefix used to check which subsystem owns
> the device.)

Ah, I guess that would be "dmsetup -v status device"? I admit
I have avoided using the dm at all so far, except for 
RAID and dm-crypt, which are pretty much usable as devices
without looking at any dm stuff underneath. Maybe it is time
to have an in-depth look.

> Probably should be mentioned released notes...

Yes. After all it is an minor output format change and not
quite obvious what it means. Only noticed it myself
because my "cryptstat" script complained about a changed
output format ;-)

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier