Option "validate passphrase" for command cryptsetup

Hello,
for information, I wrote a small C program to check if the given
passphrase is correct, without doing anything on the disk. The command is used this way:

If you think it can benefit cryptsetup, I offer to write the necessary
patch to include it to cryptsetup (as a "luksValidateKey" LUKS action).

Quoted 7 lines · Louis

Hello,
for information, I wrote a small C program to check if the given
passphrase is correct, without doing anything on the disk. The command is used this way:

If you think it can benefit cryptsetup, I offer to write the necessary
patch to include it to cryptsetup (as a "luksValidateKey" LUKS action).

Special program or command is IMHO overkill, isn't enough just to add option to cryptsetup luksOpen (--dry-run, --no-activate, whatever you prefer)?

So it will work just like

# cryptsetup luksOpen /dev/sdc anything --dry-run --verbose
Enter passphrase for /dev/sdc: 
No key available with this passphrase.
Enter passphrase for /dev/sdc: 
Key slot 0 unlocked.
Command successful.

Trivial to add to code... (while I am doing another RC today, it can be done today even ;-)

Milan
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

I think having this functionality is a good idea.

Quoted 2 lines

Trivial to add to code... (while I am doing another RC today, it can be done today even ;-)

Quoted 4 lines

I think having this functionality is a good idea.

Quoted 2 lines

Trivial to add to code... (while I am doing another RC today, it can be done today even ;-)

Added --without activation option for luksOpen
http://code.google.com/p/cryptsetup/source/detail?r=a38fcafcff9ae75feda12bc84d04b2cdaa591f9f#

# cryptsetup luksOpen /dev/sdc x --without-activation -T 1 ; echo $?
Enter passphrase for /dev/sdc:  (good passphrase)
0

# cryptsetup luksOpen /dev/sdc x --without-activation -T 1 ; echo $?
Enter passphrase for /dev/sdc:  (bad passphrase)
No key available with this passphrase.
2

I find the option name --without-activation to be quite long and hard to type. Is there any reason why you didn't choose '--dry-run' as you first suggested?

Quoted 3 lines · Thomas Bächler

I find the option name --without-activation to be quite long and hard to type. Is there any reason why you didn't choose '--dry-run' as you first suggested?

Actually I wrote --dry-run, --no-activate, --no-activation, --without-activation on paper ... and then asked someone here what's the best:)

Well, I think this option will be rarely used and I guess it is mainly for use in scripts. Option name says exactly what it is doing.

Quoted 4 lines

Hello,
for information, I wrote a small C program to check if the given
passphrase is correct, without doing anything on the disk. The command is used this way:

Quoted 3 lines

If you think it can benefit cryptsetup, I offer to write the
necessary
patch to include it to cryptsetup (as a "luksValidateKey" LUKS action).

Special program or command is IMHO overkill, isn't enough just to add option to cryptsetup luksOpen (--dry-run, --no-activate, whatever you prefer)?

if I'm not wrong, one difference between Louis' suggestion and the way you implemented it is, that the former works with active devices, and the latter doesn't, right?

I like the idea of a --dry-run option which works for all commands, just like a simulation mode. But as well I like the idea of a command for key validation, which takes the same commandline options as luksOpen, and simply verifies whether the given key (passphrase, keyfile, whatever) is valid.

Quoted 11 lines · Milan Broz

Quoted 3 lines · Thomas Bächler

I find the option name --without-activation to be quite long and hard to type. Is there any reason why you didn't choose '--dry-run' as you first suggested?

Actually I wrote --dry-run, --no-activate, --no-activation, --without-activation on paper ... and then asked someone here what's the best:)

Well, I think this option will be rarely used and I guess it is mainly for use in scripts. Option name says exactly what it is doing.

It says what technically happens, not was is the intent of using said option. (You have to read the man-page, at least in the git-version of a few minutes ago the intent is right after the technicallity)

I think intent is much easier to understand.

So i'd vote for: --test-passphrase

Quoted 4 lines

if I'm not wrong, one difference between Louis' suggestion and the way you implemented it is, that the former works with active devices, and the latter doesn't, right?

No, it is exactly the same. It works even for active devices. (Check for active device is later.)

Quoted 5 lines

I like the idea of a --dry-run option which works for all commands, just like a simulation mode. But as well I like the idea of a command for key validation, which takes the same commandline options as luksOpen, and simply verifies whether the given key (passphrase, keyfile, whatever) is valid.

Well, universal --dry-run is nice idea but I am not going to implement it now. (and I would perhaps do it differently - do everything as is except final on-disk metadata update or in-kernel device change.)

Well, I have local commit renaming this luksOpen option to --test-passphrase. If there are no other suggestions for today, I'll commit it.

Milan
(grumbling something about bikeshedding :-)

Hello,
for information, I wrote a small C program to check if the given
passphrase is correct, without doing anything on the disk. The command is used this way:

	$ cryptsetup_check_passphrase /dev/sda1
	Enter passphrase for /dev/sda1:<MY_SECRET_PASSPHRASE>
	Valid key (slot 0)
	$

If you think it can benefit cryptsetup, I offer to write the necessary
patch to include it to cryptsetup (as a "luksValidateKey" LUKS action).

# why do I need such a command ?

We are a group of hacktivists who offer some online services (such as
email addresses). Our disks are encrypted using LUKS. As we are six members operating the server, and we reboot it only a few times a year, it may happen that some of us only use the passphrase once in two years, which is prone to forgetting. So we want a way to, once in a while (at our monthly meetings), check that we still know our passphrase, without risking to do something on the disk (creating, removing partition, deleting passphrases, etc.).

# Security risks

Isn't this function a wonderful tool to try brute force attacks ? I do
not think so. Attacker needs to be root to run it, at which point (s)he can already do a lot of harmful things. Moreover, once (s)he is root, attacker might as well compile the program I just wrote to try this brute force attack. To sum up: Yes, it can be used to brute force the partition, but nothing more that what was possible to do without this tool.

Regards,
Louis

PS : Not to overload this list with many files, I only give you here the C code. If you want the makefile and configure.ac, just ask.

#include<stdio.h>
#include<stdlib.h>
#include<string.h>

#include<libcryptsetup.h>

void usage() {
   printf("cryptsetup_check_passphrase LUKSDEVICE\n");
}

int check_passphrase(const char* device_name) {
   int keyslot;
   int error;
   int status;
   struct crypt_device *cd = NULL;

   if ((error = crypt_init(&cd, device_name))) {
     printf("Could not open device \"%s\": %s\n", device_name,
strerror(-error));
     return 1;
   }
   if ((error = crypt_load(cd, NULL, NULL))) {
     printf("Could not load device \"%s\": %s\n", device_name,
strerror(-error));
     return 1;

}

keyslot = crypt_activate_by_passphrase(cd, NULL, CRYPT_ANY_SLOT, NULL,

0, 0);
   if (keyslot>= 0) {
     printf("Valid key (slot %u)\n", keyslot);
     status = 0;
   } else {
     printf("No matching key found: %s\n", strerror(-keyslot));
     status = 1;
   }
   crypt_free(cd);
   return status;
}

int main( int argc, const char* argv[] ) {
   int status;

   /* Parsing arguments */
   if (argc != 2) {
     usage();
     return 1;
   }

   /* Check */
   status = check_passphrase(argv[1]);

   return status;
}

_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

I find the option name --without-activation to be quite long and hard to type. Is there any reason why you didn't choose '--dry-run' as you first suggested?

Quoted 3 lines · jonas

if I'm not wrong, one difference between Louis' suggestion and the way you implemented it is, that the former works with active devices, and the latter doesn't, right?

No, it is exactly the same. It works even for active devices. (Check for active device is later.)

Quoted 5 lines

I like the idea of a --dry-run option which works for all commands, just like a simulation mode. But as well I like the idea of a command for key validation, which takes the same commandline options as luksOpen, and simply verifies whether the given key (passphrase, keyfile, whatever) is valid.

Well, universal --dry-run is nice idea but I am not going to implement it now. (and I would perhaps do it differently - do everything as is except final on-disk metadata update or in-kernel device change.)

Well, I have local commit renaming this luksOpen option to --test-passphrase. If there are no other suggestions for today, I'll commit it.

Milan
(grumbling something about bikeshedding :-)
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

Thanks for this. Yes, I would like the makefile and configure.ac files.

Will this program work on just the LUKS header? Or does it work only on the entire mount point (with all the data therein included)?.

Is there a delay of some seconds required between invocations?

Quoted 39 lines

Hello,
for information, I wrote a small C program to check if the given
passphrase is correct, without doing anything on the disk. The command is used this way:

    $ cryptsetup_check_passphrase /dev/sda1
    Enter passphrase for /dev/sda1:<MY_SECRET_PASSPHRASE>
    Valid key (slot 0)
    $

If you think it can benefit cryptsetup, I offer to write the
necessary
patch to include it to cryptsetup (as a "luksValidateKey" LUKS action).

# why do I need such a command ?

We are a group of hacktivists who offer some online services (such as
email addresses). Our disks are encrypted using LUKS. As we are six members operating the server, and we reboot it only a few times a year, it may happen that some of us only use the passphrase once in two years, which is prone to forgetting. So we want a way to, once in a while (at our monthly meetings), check that we still know our passphrase, without risking to do something on the disk (creating, removing partition, deleting passphrases, etc.).

# Security risks

Isn't this function a wonderful tool to try brute force attacks ?
I do
not think so. Attacker needs to be root to run it, at which point (s)he can already do a lot of harmful things. Moreover, once (s)he is root, attacker might as well compile the program I just wrote to try this brute force attack. To sum up: Yes, it can be used to brute force the partition, but nothing more that what was possible to do without this tool.

Regards,
Louis

Quoted 2 lines

Will this program work on just the LUKS header? Or does it work only on the entire mount point (with all the data therein included)?.

I have no idea.

Quoted 1 line

Is there a delay of some seconds required between invocations?

Well, on my computer, it takes more than one second to run, which may
seem long for a simple verification of a passphrase. But I think it is simply the time taken by the API to check the passphrase on my very old computer. There is no such delay in my code to prevent brute force attack, nor (if I am not wrong) in the functions of the Cryptsetup API I am using.