[dm-crypt] Troubleshooting: Header Conversion to argon2id

[dm-crypt] Troubleshooting: Header Conversion to argon2id

[procmem]

Hi, I went ahead and tested the commands recommended by Milan for
converting headers to use the better pbkdf algo. Unfortunately I'm
running into an obscure error and wanted your advice on how to solve it.

Please see the output of the command with --debug


root@debian:/home/user# cryptsetup luksConvertKey --key-slot 1 --pbkdf
argon2id --pbkdf-force-iterations 50 --pbkdf-memory 1048576
--pbkdf-parallel 4 /dev/vda1 --debug
# cryptsetup 2.0.4 processing "cryptsetup luksConvertKey --key-slot 1
--pbkdf argon2id --pbkdf-force-iterations 50 --pbkdf-memory 1048576
--pbkdf-parallel 4 /dev/vda1 --debug"
# Running command luksConvertKey.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /dev/vda1.
# Trying to open and read device /dev/vda1 with direct-io.
# Initialising device-mapper backend library.
# Trying to load LUKS2 crypt type from device /dev/vda1.
# Crypto backend (gcrypt 1.8.3) initialized in cryptsetup library
version 2.0.4.
# Detected kernel Linux 4.17.0-3-amd64 x86_64.
# Loading LUKS2 header (repair disabled).
# Opening lock resource file /run/cryptsetup/L_254:1
# Acquiring read lock for device /dev/vda1.
# Verifying read lock handle for device /dev/vda1.
# Device /dev/vda1 READ lock taken.
# Trying to read primary LUKS2 header at offset 0x0.
# Opening locked device /dev/vda1
# Veryfing locked device handle (bdev)
# Trying to read secondary LUKS2 header at offset 0x4000.
# Opening locked device /dev/vda1
# Veryfing locked device handle (bdev)
# Trying to read secondary LUKS2 header at offset 0x8000.
# Opening locked device /dev/vda1
# Veryfing locked device handle (bdev)
# Trying to read secondary LUKS2 header at offset 0x10000.
# Opening locked device /dev/vda1
# Veryfing locked device handle (bdev)
# Trying to read secondary LUKS2 header at offset 0x20000.
# Opening locked device /dev/vda1
# Veryfing locked device handle (bdev)
# Trying to read secondary LUKS2 header at offset 0x40000.
# Opening locked device /dev/vda1
# Veryfing locked device handle (bdev)
# Trying to read secondary LUKS2 header at offset 0x80000.
# Opening locked device /dev/vda1
# Veryfing locked device handle (bdev)
# Trying to read secondary LUKS2 header at offset 0x100000.
# Opening locked device /dev/vda1
# Veryfing locked device handle (bdev)
# Trying to read secondary LUKS2 header at offset 0x200000.
# Opening locked device /dev/vda1
# Veryfing locked device handle (bdev)
# Trying to read secondary LUKS2 header at offset 0x400000.
# Opening locked device /dev/vda1
# Veryfing locked device handle (bdev)
# LUKS2 header read failed (-22).
# Device /dev/vda1 READ lock released.
# Releasing crypt device /dev/vda1 context.
# Releasing device-mapper backend.
# Unlocking memory.
Command failed with code -1 (wrong or missing parameters).

Re: [dm-crypt] Troubleshooting: Header Conversion to argon2id

[Ondrej Kozina]

On 09/11/2018 07:09 PM, procmem wrote:
> Hi, I went ahead and tested the commands recommended by Milan for
> converting headers to use the better pbkdf algo. Unfortunately I'm
> running into an obscure error and wanted your advice on how to solve it.
> 
> Please see the output of the command with --debug
> 
Hi,

luksConvertKey command works only on LUKS2 keyslots. Looking at debug 
output it seems your device is not LUKS2 type.

Regards
Ondrej

Re: [dm-crypt] Troubleshooting: Header Conversion to argon2id

[procmem]

Ondrej Kozina:
> On 09/11/2018 07:09 PM, procmem wrote:
>> Hi, I went ahead and tested the commands recommended by Milan for
>> converting headers to use the better pbkdf algo. Unfortunately I'm
>> running into an obscure error and wanted your advice on how to solve it.
>>
>> Please see the output of the command with --debug
>>
> Hi,
> 
> luksConvertKey command works only on LUKS2 keyslots. Looking at debug
> output it seems your device is not LUKS2 type.
> 
> Regards
> Ondrej

Thanks. I see. How can I convert a LUKS1 to a LUKS2 before running this
command on it?

Re: [dm-crypt] Troubleshooting: Header Conversion to argon2id

[procmem]

Ondrej Kozina:
> On 09/11/2018 07:09 PM, procmem wrote:
>> Hi, I went ahead and tested the commands recommended by Milan for
>> converting headers to use the better pbkdf algo. Unfortunately I'm
>> running into an obscure error and wanted your advice on how to solve it.
>>
>> Please see the output of the command with --debug
>>
> Hi,
> 
> luksConvertKey command works only on LUKS2 keyslots. Looking at debug
> output it seems your device is not LUKS2 type.
> 
> Regards
> Ondrej

Now that I think about it this can't be the reason because the header is
LUKS2 when using cryptsetup 2.0 and above - which is the version
included in Debian Testing/Buster.

Also running 'cryptsetup convert' with --debug gives the same error.

Re: [dm-crypt] Troubleshooting: Header Conversion to argon2id

[Milan Broz]

On 12/09/18 06:16, procmem wrote:
> Ondrej Kozina:
>> On 09/11/2018 07:09 PM, procmem wrote:
>>> Hi, I went ahead and tested the commands recommended by Milan for
>>> converting headers to use the better pbkdf algo. Unfortunately I'm
>>> running into an obscure error and wanted your advice on how to solve it.
>>>
>>> Please see the output of the command with --debug
>>>
>> Hi,
>>
>> luksConvertKey command works only on LUKS2 keyslots. Looking at debug
>> output it seems your device is not LUKS2 type.
>>
>> Regards
>> Ondrej
> 
> Now that I think about it this can't be the reason because the header is
> LUKS2 when using cryptsetup 2.0 and above - which is the version
> included in Debian Testing/Buster.

No, header is not always LUKS2 by default, cryptsetup 2.0.x luksFormat still uses LUKS1
format by default. Do not mix version of utility and version of LUKS metadata format.

Anyway, it seems that there is no LUKS header on the device at all, or it is somehow
corrupted, all commands then must fail of course.

Can you please paste output of "blkid -p <device>" and "cryptsetup luksDump --debug <device>" ?

m.


> 
> Also running 'cryptsetup convert' with --debug gives the same error.
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt
> 

Re: [dm-crypt] Troubleshooting: Header Conversion to argon2id

[procmem]

Milan Broz:
> On 12/09/18 06:16, procmem wrote:
>> Ondrej Kozina:
>>> On 09/11/2018 07:09 PM, procmem wrote:
>>>> Hi, I went ahead and tested the commands recommended by Milan for
>>>> converting headers to use the better pbkdf algo. Unfortunately I'm
>>>> running into an obscure error and wanted your advice on how to solve it.
>>>>
>>>> Please see the output of the command with --debug
>>>>
>>> Hi,
>>>
>>> luksConvertKey command works only on LUKS2 keyslots. Looking at debug
>>> output it seems your device is not LUKS2 type.
>>>
>>> Regards
>>> Ondrej
>>
>> Now that I think about it this can't be the reason because the header is
>> LUKS2 when using cryptsetup 2.0 and above - which is the version
>> included in Debian Testing/Buster.
> 
> No, header is not always LUKS2 by default, cryptsetup 2.0.x luksFormat still uses LUKS1
> format by default. Do not mix version of utility and version of LUKS metadata format.
> 
> Anyway, it seems that there is no LUKS header on the device at all, or it is somehow
> corrupted, all commands then must fail of course.
> 
> Can you please paste output of "blkid -p <device>" and "cryptsetup luksDump --debug <device>" ?
> 
> m.
> 



Summary: OK. Looks like I was manipulating the wrong device. It is vda5
not vda1 that has the header. The header is version 1. Conversion to v2
still fails however.





blkid -p /dev/vda5
/dev/vda5: VERSION="1" UUID="fd28a001-e2a1-46dc-8e6c-99f0a55b1851"
TYPE="crypto_LUKS" USAGE="crypto" PART_ENTRY_SCHEME="dos"
PART_ENTRY_UUID="860c80ea-05" PART_ENTRY_TYPE="0x83"
PART_ENTRY_NUMBER="5" PART_ENTRY_OFFSET="501760"
PART_ENTRY_SIZE="104353792" PART_ENTRY_DISK="254:0"


***


cryptsetup luksDump --debug /dev/vda5
# cryptsetup 2.0.4 processing "cryptsetup luksDump --debug /dev/vda5"
# Running command luksDump.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /dev/vda5.
# Trying to open and read device /dev/vda5 with direct-io.
# Initialising device-mapper backend library.
# Trying to load any crypt type from device /dev/vda5.
# Crypto backend (gcrypt 1.8.3) initialized in cryptsetup library
version 2.0.4.
# Detected kernel Linux 4.17.0-3-amd64 x86_64.
# PBKDF pbkdf2, hash sha256, time_ms 2000 (iterations 0), max_memory_kb
0, parallel_threads 0.
# Reading LUKS header of size 1024 from device /dev/vda5
# Key length 64, device size 104353792 sectors, header size 4036 sectors.
LUKS header information for /dev/vda5

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha256
Payload offset: 4096
MK bits:        512
MK digest:      92 88 0b 12 d8 87 59 a4 01 25 08 a9 54 df 70 31 ac 31 8b 6f
MK salt:        7d 75 4b 38 2c ce 04 ba be 99 81 c7 18 4e d9 ea
                04 c3 70 16 6e 7b f3 74 92 c2 a5 da c8 86 8f 57
MK iterations:  64503
UUID:           fd28a001-e2a1-46dc-8e6c-99f0a55b1851

Key Slot 0: ENABLED
        Iterations:             1007276
        Salt:                   82 dd 05 76 f7 39 41 45 c9 a4 a6 f3 b4
a4 50 a5
                                f8 00 3a cb bd e1 ff 00 39 cb 74 b2 f2
1a 0a e9
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
# Releasing crypt device /dev/vda5 context.
# Releasing device-mapper backend.
# Unlocking memory.
Command successful.


***


cryptsetup convert /dev/vda5 --type luks2 --debug
# cryptsetup 2.0.4 processing "cryptsetup convert /dev/vda5 --type luks2
--debug"
# Running command convert.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /dev/vda5.
# Trying to open and read device /dev/vda5 with direct-io.
# Initialising device-mapper backend library.
# Trying to load any crypt type from device /dev/vda5.
# Crypto backend (gcrypt 1.8.3) initialized in cryptsetup library
version 2.0.4.
# Detected kernel Linux 4.17.0-3-amd64 x86_64.
# PBKDF pbkdf2, hash sha256, time_ms 2000 (iterations 0), max_memory_kb
0, parallel_threads 0.
# Reading LUKS header of size 1024 from device /dev/vda5
# Key length 64, device size 104353792 sectors, header size 4036 sectors.

WARNING!
========
This operation will convert /dev/vda5 to LUKS2 format.


Are you sure? (Type uppercase yes): YES
# Converting LUKS device to type LUKS2
# Max size: 2097152, LUKS1 (full) header size 2068480 , required shift:
28672
# DM-UUID is CRYPT-LUKS1-fd28a001e2a146dc8e6c99f0a55b1851-
Cannot convert device /dev/vda5 which is still in use.
# Releasing crypt device /dev/vda5 context.
# Releasing device-mapper backend.
# Unlocking memory.
Command failed with code -5 (device already exists or device is busy).

Re: [dm-crypt] Troubleshooting: Header Conversion to argon2id

[Guilhem Moulin]

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

Hi,

On Wed, 12 Sep 2018 at 15:21:00 +0000, procmem wrote:
> cryptsetup convert /dev/vda5 --type luks2 --debug
> […]
> Cannot convert device /dev/vda5 which is still in use.
> […]
> Command failed with code -5 (device already exists or device is busy).

As the error message indicates, you need to remove (ie, close) the
mapped device first.  If that device is required for your system to run
(for instance if it's holding the root file system) you won't be able to
run `cryptsetup luksClose $name` from the main system; however you
should be able to perform `cryptsetup convert` from a live CD, or from
the initramfs image.

Also, if as you hinted at you're using a detached header, you'll need to
pass --header=/path/to/header to `cryptsetup convert`.

Cheers,
-- 
Guilhem.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [dm-crypt] Troubleshooting: Header Conversion to argon2id

[procmem]

Guilhem Moulin:
> Hi,
> 
> On Wed, 12 Sep 2018 at 15:21:00 +0000, procmem wrote:
>> cryptsetup convert /dev/vda5 --type luks2 --debug
>> […]
>> Cannot convert device /dev/vda5 which is still in use.
>> […]
>> Command failed with code -5 (device already exists or device is busy).
> 
> As the error message indicates, you need to remove (ie, close) the
> mapped device first.  If that device is required for your system to run
> (for instance if it's holding the root file system) you won't be able to
> run `cryptsetup luksClose $name` from the main system; however you
> should be able to perform `cryptsetup convert` from a live CD, or from
> the initramfs image.
> 

initramfs sounds like the most versatile option. Any pointers on how to
to this? Searching SE turns up irrelevant results.

> Also, if as you hinted at you're using a detached header, you'll need to
> pass --header=/path/to/header to `cryptsetup convert`.
> 
> Cheers,
> 

Re: [dm-crypt] Troubleshooting: Header Conversion to argon2id

[Arno Wagner]

On Thu, Sep 13, 2018 at 02:47:00 CEST, procmem wrote:
> 
> 
> Guilhem Moulin:
> > Hi,
> > 
> > On Wed, 12 Sep 2018 at 15:21:00 +0000, procmem wrote:
> >> cryptsetup convert /dev/vda5 --type luks2 --debug
> >> […]
> >> Cannot convert device /dev/vda5 which is still in use.
> >> […]
> >> Command failed with code -5 (device already exists or device is busy).
> > 
> > As the error message indicates, you need to remove (ie, close) the
> > mapped device first.  If that device is required for your system to run
> > (for instance if it's holding the root file system) you won't be able to
> > run `cryptsetup luksClose $name` from the main system; however you
> > should be able to perform `cryptsetup convert` from a live CD, or from
> > the initramfs image.
> > 
> 
> initramfs sounds like the most versatile option. Any pointers on how to
> to this? Searching SE turns up irrelevant results.

The FAQ has an example how to do an an initrd, including dropping to 
shell, in Chapter 9:

https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#9-the-initrd-question

Regards,
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

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] Troubleshooting: Header Conversion to argon2id

[Guilhem Moulin]

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

On Thu, 13 Sep 2018 at 00:47:00 +0000, procmem wrote:
> Guilhem Moulin:
>> On Wed, 12 Sep 2018 at 15:21:00 +0000, procmem wrote:
>>> cryptsetup convert /dev/vda5 --type luks2 --debug
>>> […]
>>> Cannot convert device /dev/vda5 which is still in use.
>>> […]
>>> Command failed with code -5 (device already exists or device is busy).
>> 
>> As the error message indicates, you need to remove (ie, close) the
>> mapped device first.  If that device is required for your system to run
>> (for instance if it's holding the root file system) you won't be able to
>> run `cryptsetup luksClose $name` from the main system; however you
>> should be able to perform `cryptsetup convert` from a live CD, or from
>> the initramfs image.
> 
> initramfs sounds like the most versatile option. Any pointers on how to
> to this? Searching SE turns up irrelevant results.

Before rebooting you might want to make sure the ‘algif_skcipher’ kernel
module is included in the initramfs image, otherwise you might not be
able to open LUKS2 volumes.  (See https://bugs.debian.org/896968 for
details.)  To do so, run the following two commands:

    echo algif_skcipher | sudo tee -a /etc/initramfs-tools/modules
    sudo update-initramfs -u

Now assuming your bootloader is GRUB, reboot, press <E> to obtain an
emacs-like screen, append “ break=premount” to the line starting with
“initrd”, and press <Ctrl>+<X> to boot.  (The edit is transient and
won't survive the next reboot.)  You should land into an initramfs debug
shell; see initramfs-tools(7) for details.

That has probably become off-topic for the dm-crypt list, by the way
(discussing how to reboot into an initramfs shell has nothing to do with
dm-crypt, LUKS, or cryptsetup(8) per se); the user support channels of
your distro might be a better venue for this.

-- 
Guilhem.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [dm-crypt] Troubleshooting: Header Conversion to argon2id

[procmem]

Guilhem Moulin:
> On Thu, 13 Sep 2018 at 00:47:00 +0000, procmem wrote:
>> Guilhem Moulin:
>>> On Wed, 12 Sep 2018 at 15:21:00 +0000, procmem wrote:
>>>> cryptsetup convert /dev/vda5 --type luks2 --debug
>>>> […]
>>>> Cannot convert device /dev/vda5 which is still in use.
>>>> […]
>>>> Command failed with code -5 (device already exists or device is busy).
>>>
>>> As the error message indicates, you need to remove (ie, close) the
>>> mapped device first.  If that device is required for your system to run
>>> (for instance if it's holding the root file system) you won't be able to
>>> run `cryptsetup luksClose $name` from the main system; however you
>>> should be able to perform `cryptsetup convert` from a live CD, or from
>>> the initramfs image.
>>
>> initramfs sounds like the most versatile option. Any pointers on how to
>> to this? Searching SE turns up irrelevant results.
> 
> Before rebooting you might want to make sure the ‘algif_skcipher’ kernel
> module is included in the initramfs image, otherwise you might not be
> able to open LUKS2 volumes.  (See https://bugs.debian.org/896968 for
> details.)  To do so, run the following two commands:
> 
>     echo algif_skcipher | sudo tee -a /etc/initramfs-tools/modules
>     sudo update-initramfs -u
> 
> Now assuming your bootloader is GRUB, reboot, press <E> to obtain an
> emacs-like screen, append “ break=premount” to the line starting with
> “initrd”, and press <Ctrl>+<X> to boot.  (The edit is transient and
> won't survive the next reboot.)  You should land into an initramfs debug
> shell; see initramfs-tools(7) for details.
> 
> That has probably become off-topic for the dm-crypt list, by the way
> (discussing how to reboot into an initramfs shell has nothing to do with
> dm-crypt, LUKS, or cryptsetup(8) per se); the user support channels of
> your distro might be a better venue for this.
> 

Appending break=premount to the line starting with "linux" worked for
converting the header to v2. However changing it to argon2id still
failed with a -1 error code.

So I ended up bypassing this process by creating a new keyslot with the
same passphrase - which happens to use the best parameters by default
(argon2id in this case) and then going back and deleting the legacy keyslot:

# cryptsetup luksAddKey /dev/vda5 -S 1

# cryptsetup luksKillSlot /dev/vda5 0


Everything continues to boot up. I think this is the best way to do
things unless anyone has any reservations*

* As long as no SSDs are used I don't think users have to worry about
the old header floating around. Though I'm unsure if in-place conversion
would have been a security advantage in that case.

Re: [dm-crypt] Troubleshooting: Header Conversion to argon2id

[Ondrej Kozina]

On 09/13/2018 04:13 PM, procmem wrote:
> 
> 
> Appending break=premount to the line starting with "linux" worked for
> converting the header to v2. However changing it to argon2id still
> failed with a -1 error code.

Well, this sounds like a bug. Could you please provide us with debug 
output for failing command trying to luksConvertKey that particular keyslot?

> 
> So I ended up bypassing this process by creating a new keyslot with the
> same passphrase - which happens to use the best parameters by default
> (argon2id in this case) and then going back and deleting the legacy keyslot:

Actually luksConvertKey command works similar to process you just 
described. With only exception that it replaces the keyslot in-place.

O.

Re: [dm-crypt] Troubleshooting: Header Conversion to argon2id

[procmem]

Ondrej Kozina:
> On 09/13/2018 04:13 PM, procmem wrote:
>>
>>
>> Appending break=premount to the line starting with "linux" worked for
>> converting the header to v2. However changing it to argon2id still
>> failed with a -1 error code.
> 
> Well, this sounds like a bug. Could you please provide us with debug
> output for failing command trying to luksConvertKey that particular
> keyslot?
> 

Sure thing but I don't know how to access initramfs command history.
Unlike a booted-up environment there is no opportunity to scroll and
select entire output for saving.

>>
>> So I ended up bypassing this process by creating a new keyslot with the
>> same passphrase - which happens to use the best parameters by default
>> (argon2id in this case) and then going back and deleting the legacy
>> keyslot:
> 
> Actually luksConvertKey command works similar to process you just
> described. With only exception that it replaces the keyslot in-place.
> 

Cool. Good to know :)

Re: [dm-crypt] Troubleshooting: Header Conversion to argon2id

[Guilhem Moulin]

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

On Thu, 13 Sep 2018 at 14:22:00 +0000, procmem wrote:
> Ondrej Kozina:
>> Well, this sounds like a bug. Could you please provide us with debug
>> output for failing command trying to luksConvertKey that particular
>> keyslot?
> 
> Sure thing but I don't know how to access initramfs command history.
> Unlike a booted-up environment there is no opportunity to scroll and
> select entire output for saving.

You can redirect the output to a file under /run/initramfs.  /run is
moved to the rootfs at init-bottom stage, shortly before the execution
is turned over to the `init` binary, so content added at early boot
stage will also be available later during the boot process.

(Again, assuming your initramfs is comes from initramfs-tools, which is
the default in Debian — and I guess its derivatives.)

-- 
Guilhem.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [dm-crypt] Troubleshooting: Header Conversion to argon2id

[procmem]

Guilhem Moulin:
> On Thu, 13 Sep 2018 at 14:22:00 +0000, procmem wrote:
>> Ondrej Kozina:
>>> Well, this sounds like a bug. Could you please provide us with debug
>>> output for failing command trying to luksConvertKey that particular
>>> keyslot?
>>
>> Sure thing but I don't know how to access initramfs command history.
>> Unlike a booted-up environment there is no opportunity to scroll and
>> select entire output for saving.
> 
> You can redirect the output to a file under /run/initramfs.  /run is
> moved to the rootfs at init-bottom stage, shortly before the execution
> is turned over to the `init` binary, so content added at early boot
> stage will also be available later during the boot process.
> 
> (Again, assuming your initramfs is comes from initramfs-tools, which is
> the default in Debian — and I guess its derivatives.)
> 

OK here are the contents of the redirected output:


# cryptsetup 2.0.4 processing "cryptsetup luksConvertKey --key-slot 1
--pbkdf argon2id --pbkdf-force-iterations 50 --pbkdf-memory 1048576
--pbkdf-parallel 4 /dev/vda5 --debug"
# Running command luksConvertKey.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /dev/vda5.
# Trying to open and read device /dev/vda5 with direct-io.
# Initialising device-mapper backend library.
# Trying to load LUKS2 crypt type from device /dev/vda5.
# Crypto backend (gcrypt 1.8.3) initialized in cryptsetup library
version 2.0.4.
# Detected kernel Linux 4.18.0-1-amd64 x86_64.
# Loading LUKS2 header (repair disabled).
# Opening lock resource file /run/cryptsetup/L_254:5
# Acquiring read lock for device /dev/vda5.
# Verifying read lock handle for device /dev/vda5.
# Device /dev/vda5 READ lock taken.
# Trying to read primary LUKS2 header at offset 0x0.
# Opening locked device /dev/vda5
# Veryfing locked device handle (bdev)
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
#
Checksum:a1e5fa25edf5bea01bd1367ec6ff77ac06bdbce31e341078879c742ad1d08815
(on-disk)
#
Checksum:a1e5fa25edf5bea01bd1367ec6ff77ac06bdbce31e341078879c742ad1d08815
(in-memory)
# Trying to read secondary LUKS2 header at offset 0x4000.
# Opening locked device /dev/vda5
# Veryfing locked device handle (bdev)
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
#
Checksum:41ee6b99cf321c80bbf50a7f007cf459f50d0b6d90f50ff53b8f79c9abf53933
(on-disk)
#
Checksum:41ee6b99cf321c80bbf50a7f007cf459f50d0b6d90f50ff53b8f79c9abf53933
(in-memory)
# Device size 53429141504, header size 2097152.
# Device /dev/vda5 READ lock released.
# Only 2 active CPUs detected, PBKDF threads decreased from 4 to 2.
# Not enough physical memory detected, PBKDF max memory decreased from
1048576kB to 506328kB.
# PBKDF argon2i, hash sha256, time_ms 2000 (iterations 0), max_memory_kb
506328, parallel_threads 2.
# Only 2 active CPUs detected, PBKDF threads decreased from 4 to 2.
# Not enough physical memory detected, PBKDF max memory decreased from
1048576kB to 506328kB.
# PBKDF argon2id, hash sha256, time_ms 2000 (iterations 50),
max_memory_kb 506328, parallel_threads 2.
# Interactive passphrase entry requested.
# Changing passphrase from old keyslot 1 to new 1.
# Reloading LUKS2 header (repair disabled).
# Opening lock resource file /run/cryptsetup/L_254:5
# Acquiring read lock for device /dev/vda5.
# Verifying read lock handle for device /dev/vda5.
# Device /dev/vda5 READ lock taken.
# Trying to read primary LUKS2 header at offset 0x0.
# Opening locked device /dev/vda5
# Veryfing locked device handle (bdev)
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
#
Checksum:a1e5fa25edf5bea01bd1367ec6ff77ac06bdbce31e341078879c742ad1d08815
(on-disk)
#
Checksum:a1e5fa25edf5bea01bd1367ec6ff77ac06bdbce31e341078879c742ad1d08815
(in-memory)
# Trying to read secondary LUKS2 header at offset 0x4000.
# Opening locked device /dev/vda5
# Veryfing locked device handle (bdev)
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
#
Checksum:41ee6b99cf321c80bbf50a7f007cf459f50d0b6d90f50ff53b8f79c9abf53933
(on-disk)
#
Checksum:41ee6b99cf321c80bbf50a7f007cf459f50d0b6d90f50ff53b8f79c9abf53933
(in-memory)
# Device size 53429141504, header size 2097152.
# Device /dev/vda5 READ lock released.
# Releasing crypt device /dev/vda5 context.
# Releasing device-mapper backend.
# Unlocking memory.
Command failed with code -1 (wrong or missing parameters).

Re: [dm-crypt] Troubleshooting: Header Conversion to argon2id

[Ondrej Kozina]

On 09/14/2018 02:21 AM, procmem wrote:
> 
> 
> Guilhem Moulin:
>> On Thu, 13 Sep 2018 at 14:22:00 +0000, procmem wrote:
>>> Ondrej Kozina:
>>>> Well, this sounds like a bug. Could you please provide us with debug
>>>> output for failing command trying to luksConvertKey that particular
>>>> keyslot?
>>>
>>> Sure thing but I don't know how to access initramfs command history.
>>> Unlike a booted-up environment there is no opportunity to scroll and
>>> select entire output for saving.
>>
>> You can redirect the output to a file under /run/initramfs.  /run is
>> moved to the rootfs at init-bottom stage, shortly before the execution
>> is turned over to the `init` binary, so content added at early boot
>> stage will also be available later during the boot process.
>>
>> (Again, assuming your initramfs is comes from initramfs-tools, which is
>> the default in Debian — and I guess its derivatives.)
>>
> 
> OK here are the contents of the redirected output:
> 

Thank you! Even thought the output is good for nothing. But that's 
definitely our fault for being lazy with more helpful debug messages:)

Out of curiosity, does it behave same after you finish boot process? 
Does it fail with same error as in initrd phase?

Anyway, I'm going to experiment with it now

Thank you
O.

Re: [dm-crypt] Troubleshooting: Header Conversion to argon2id

[Ondrej Kozina]

On 09/14/2018 02:21 AM, procmem wrote:
> 
> 
> Guilhem Moulin:
>> On Thu, 13 Sep 2018 at 14:22:00 +0000, procmem wrote:
>>> Ondrej Kozina:
>>>> Well, this sounds like a bug. Could you please provide us with debug
>>>> output for failing command trying to luksConvertKey that particular
>>>> keyslot?
>>>
>>> Sure thing but I don't know how to access initramfs command history.
>>> Unlike a booted-up environment there is no opportunity to scroll and
>>> select entire output for saving.
>>
>> You can redirect the output to a file under /run/initramfs.  /run is
>> moved to the rootfs at init-bottom stage, shortly before the execution
>> is turned over to the `init` binary, so content added at early boot
>> stage will also be available later during the boot process.
>>
>> (Again, assuming your initramfs is comes from initramfs-tools, which is
>> the default in Debian — and I guess its derivatives.)
>>
> 
> OK here are the contents of the redirected output:
> 

Are you sure your keyslot 1 is active? The only way I can reproduce the 
same cryptic failure is with my keyslot passed in params being inactive. 
It's a bug because cryptsetup cli should emit proper error message about it.

New issue: https://gitlab.com/cryptsetup/cryptsetup/issues/416

O.

Re: [dm-crypt] Troubleshooting: Header Conversion to argon2id

[procmem]

Ondrej Kozina:
> On 09/14/2018 02:21 AM, procmem wrote:
>>
>>
>> Guilhem Moulin:
>>> On Thu, 13 Sep 2018 at 14:22:00 +0000, procmem wrote:
>>>> Ondrej Kozina:
>>>>> Well, this sounds like a bug. Could you please provide us with debug
>>>>> output for failing command trying to luksConvertKey that particular
>>>>> keyslot?
>>>>
>>>> Sure thing but I don't know how to access initramfs command history.
>>>> Unlike a booted-up environment there is no opportunity to scroll and
>>>> select entire output for saving.
>>>
>>> You can redirect the output to a file under /run/initramfs.  /run is
>>> moved to the rootfs at init-bottom stage, shortly before the execution
>>> is turned over to the `init` binary, so content added at early boot
>>> stage will also be available later during the boot process.
>>>
>>> (Again, assuming your initramfs is comes from initramfs-tools, which is
>>> the default in Debian — and I guess its derivatives.)
>>>
>>
>> OK here are the contents of the redirected output:
>>
> 
> Are you sure your keyslot 1 is active? The only way I can reproduce the
> same cryptic failure is with my keyslot passed in params being inactive.
> It's a bug because cryptsetup cli should emit proper error message about
> it.
> 
> New issue: https://gitlab.com/cryptsetup/cryptsetup/issues/416
> 
> O.


Indeed that was it. My bad. I was blindly typing in the same command
that designated the non-existent keyslot 1 while the key was in 0.
Nonetheless a clearer error message should help.

This command did work from initramfs:

cryptsetup luksConvertKey --key-slot 0 --pbkdf argon2id
--pbkdf-force-iterations 50 --pbkdf-memory 1048576 --pbkdf-parallel 4
<device>


Verified that the header data was changed as intended after boot. Also
noticed a nice delay after entering passphrases now. That should throw a
big fat wrench in brute-forcing efforts ;)



sudo cryptsetup luksDump --debug /dev/vda5
# cryptsetup 2.0.4 processing "cryptsetup luksDump --debug /dev/vda5"
# Running command luksDump.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /dev/vda5.
# Trying to open and read device /dev/vda5 with direct-io.
# Initialising device-mapper backend library.
# Trying to load any crypt type from device /dev/vda5.
# Crypto backend (gcrypt 1.8.3) initialized in cryptsetup library
version 2.0.4.
# Detected kernel Linux 4.17.0-3-amd64 x86_64.
# Loading LUKS2 header (repair disabled).
# Opening lock resource file /run/cryptsetup/L_254:5
# Acquiring read lock for device /dev/vda5.
# Verifying read lock handle for device /dev/vda5.
# Device /dev/vda5 READ lock taken.
# Trying to read primary LUKS2 header at offset 0x0.
# Opening locked device /dev/vda5
# Veryfing locked device handle (bdev)
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
#
Checksum:267f3c4bc0b36cb98e99bc1f32066d9e8843c2977a65df04c43c2f474aca3efc
(on-disk)
#
Checksum:267f3c4bc0b36cb98e99bc1f32066d9e8843c2977a65df04c43c2f474aca3efc
(in-memory)
# Trying to read secondary LUKS2 header at offset 0x4000.
# Opening locked device /dev/vda5
# Veryfing locked device handle (bdev)
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
#
Checksum:70714e66fa9d9913bb85191a96cb5f4348d349a716b9c4a8dd297fe02431fc56
(on-disk)
#
Checksum:70714e66fa9d9913bb85191a96cb5f4348d349a716b9c4a8dd297fe02431fc56
(in-memory)
# Device size 53429141504, header size 2097152.
# Device /dev/vda5 READ lock released.
# Only 2 active CPUs detected, PBKDF threads decreased from 4 to 2.
# Not enough physical memory detected, PBKDF max memory decreased from
1048576kB to 506360kB.
# PBKDF argon2i, hash sha256, time_ms 2000 (iterations 0), max_memory_kb
506360, parallel_threads 2.
# {
  "keyslots":{
    "0":{
      "type":"luks2",
      "key_size":64,
      "kdf":{
        "type":"argon2id",
        "time":50,
        "memory":506360,
        "cpus":2,
        "salt":"3K2QS1LyYWoQiVXz2sVfqYoRFgLNj8YOQUnj7PJacgg="
      },
      "af":{
        "type":"luks1",
        "hash":"sha256",
        "stripes":4000
      },
      "area":{
        "type":"raw",
        "encryption":"aes-xts-plain64",
        "key_size":64,
        "offset":"32768",
        "size":"258048"
      }
    }
  },
  "tokens":{
  },
  "segments":{
    "0":{
      "type":"crypt",
      "offset":"2097152",
      "iv_tweak":"0",
      "size":"dynamic",
      "encryption":"aes-xts-plain64",
      "sector_size":512
    }
  },
  "digests":{
    "0":{
      "type":"pbkdf2",
      "keyslots":[
        "0"
      ],
      "segments":[
        "0"
      ],
      "hash":"sha256",
      "salt":"fXVLOCzOBLq+mYHHGE7Z6gTDcBZue\/N0ksKl2siGj1c=",
      "digest":"kogLEtiHWaQBJQipVN9wMawxi28=",
      "iterations":64503
    }
  },
  "config":{
    "json_size":"12288",
    "keyslots_size":"2064384"
  }
}
LUKS header information
Version:        2
Epoch:          3
Metadata area:  12288 bytes
UUID:           fd28a001-e2a1-46dc-8e6c-99f0a55b1851
Label:          (no label)
Subsystem:      (no subsystem)
Flags:          (no flags)

Data segments:
  0: crypt
        offset: 2097152 [bytes]
        length: (whole device)
        cipher: aes-xts-plain64
        sector: 512 [bytes]

Keyslots:
  0: luks2
        Key:        512 bits
        Priority:   normal
        Cipher:     aes-xts-plain64
        PBKDF:      argon2id
        Time cost:  50
        Memory:     506360
        Threads:    2
        Salt:       dc ad 90 4b 52 f2 61 6a 10 89 55 f3 da c5 5f a9
                    8a 11 16 02 cd 8f c6 0e 41 49 e3 ec f2 5a 72 08
        AF stripes: 4000
        Area offset:32768 [bytes]
        Area length:258048 [bytes]
        Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
        Hash:       sha256
        Iterations: 64503
        Salt:       7d 75 4b 38 2c ce 04 ba be 99 81 c7 18 4e d9 ea
                    04 c3 70 16 6e 7b f3 74 92 c2 a5 da c8 86 8f 57
        Digest:     92 88 0b 12 d8 87 59 a4 01 25
                    08 a9 54 df 70 31 ac 31 8b 6f
# Releasing crypt device /dev/vda5 context.
# Releasing device-mapper backend.
# Unlocking memory.
Command successful.