Recovery of LUKS keyslot during PBKDF phase of overwrite ChangeKey possible?

Recovery of LUKS keyslot during PBKDF phase of overwrite ChangeKey possible?

[Christian Förster]

Good evening,

to make it short: I have started a luksChangeKey operation on keyslot 0 
with --keyslot=0 (overwrite) and bad parameters for argon2id (1000000 
iterations). As letting that run to completion would take at least a 
week, I am looking for a way to recover from this command while the 
volume is still mounted (decrypted). I do not have a header backup. Is 
this possible?

I'm using cryptsetup 2.3.5 and the volume is a LUKS2 volume.

Longer explanation: due to impatience, hangover and inexperience with 
LUKS I misinterpreted the "Iterations" parameter in the "Tokens" section 
of luksdump as being the iterations of the "main" KDF; I wanted to 
increase security by increasing the number of iterations and since the 
parameter shown was about 120,000 I thought I'd just try one million to 
see if that was too much (it was...heh). The command was:

sudo cryptsetup luksChangeKey --key-slot=0 --pbkdf=argon2id 
--pbkdf-memory=4000000 --pbkdf-parallel=12 
--pbkdf-force-iterations=1000000 /dev/

but the last time I tried it with pbkdf-memory=4000000 it only used 2 GB 
due to peculiarities with my system, where the component controlling the 
LUKS container administratively only has 4 GB of RAM, so it probably is 
using only 2 again, now. The parallelity also seems to be limited to 4 
instead of 12 as I've learned reading the FAQ now.

I chose the overwrite parameter (--keyslot=0) because my setup is a bit 
complicated and the key needs to be in keyslot 0 for other system 
components to work properly. There are no other keys or header backups 
or keyslot backups.

I did not know about the cryptsetup benchmark program and did not think 
about creating a header backup first. I do have a full system backup and 
since the system is live I just backed up the important changes I made 
since that last full backup, but I'd prefer not to have to reinstall and 
restore everything, as it's a complicated system.

Having just run the benchmark, it shows 5 iterations for argon2id with 
~1GB of RAM for 2 secs; given the above mentioned parameters of my 
command, I estimate that allowing the command to finish (it is currently 
paused with Ctrl+Z) would take at least a week of full time computing 
with the CPU churning away all this time; I'd like to avoid that.

On the plus side, I've learned some things about LUKS and cryptography 
and the first thing I'll do after recovering from this is make a header 
backup.

So, I reiterate my initial question: is it possible to recover from this 
situation without a complete reinstall or letting the command complete 
for a long time? The disk encryption key should still be in RAM IIUC, 
but since it's LUKS2, according to the FAQ extracting it from there is 
not trivial.

Thank you for any help,

C.F.

Re: Recovery of LUKS keyslot during PBKDF phase of overwrite ChangeKey possible?

[Christian Förster]

I should have included these questions:

Could I just terminate the systemd process when it hasn't actually 
computed the key yet? More specifically, when does cryptsetup actually 
start overwriting the keyslot when the --keyslot parameter is used? Is 
there some overwriting already before it is done computing or only 
after? If only after, then the keyslot should not yet have been harmed 
as it's not done with the iterations, right?

Thank you.

Re: Recovery of LUKS keyslot during PBKDF phase of overwrite ChangeKey possible?

[Arno Wagner]

Hi Christian,

if the volume is mounted, make a backup 
of its contents and throw the container away.
You should have that backup anyways.

I do not recommend doing _anything_ else before 
you have that backup.

Regards,
Arno

On Wed, Nov 22, 2023 at 21:53:59 CET, Christian Förster wrote:
> Good evening,
> 
> to make it short: I have started a luksChangeKey operation on keyslot 0 with
> --keyslot=0 (overwrite) and bad parameters for argon2id (1000000
> iterations). As letting that run to completion would take at least a week, I
> am looking for a way to recover from this command while the volume is still
> mounted (decrypted). I do not have a header backup. Is this possible?
> 
> I'm using cryptsetup 2.3.5 and the volume is a LUKS2 volume.
> 
> Longer explanation: due to impatience, hangover and inexperience with LUKS I
> misinterpreted the "Iterations" parameter in the "Tokens" section of
> luksdump as being the iterations of the "main" KDF; I wanted to increase
> security by increasing the number of iterations and since the parameter
> shown was about 120,000 I thought I'd just try one million to see if that
> was too much (it was...heh). The command was:
> 
> sudo cryptsetup luksChangeKey --key-slot=0 --pbkdf=argon2id
> --pbkdf-memory=4000000 --pbkdf-parallel=12 --pbkdf-force-iterations=1000000
> /dev/
> 
> but the last time I tried it with pbkdf-memory=4000000 it only used 2 GB due
> to peculiarities with my system, where the component controlling the LUKS
> container administratively only has 4 GB of RAM, so it probably is using
> only 2 again, now. The parallelity also seems to be limited to 4 instead of
> 12 as I've learned reading the FAQ now.
> 
> I chose the overwrite parameter (--keyslot=0) because my setup is a bit
> complicated and the key needs to be in keyslot 0 for other system components
> to work properly. There are no other keys or header backups or keyslot
> backups.
> 
> I did not know about the cryptsetup benchmark program and did not think
> about creating a header backup first. I do have a full system backup and
> since the system is live I just backed up the important changes I made since
> that last full backup, but I'd prefer not to have to reinstall and restore
> everything, as it's a complicated system.
> 
> Having just run the benchmark, it shows 5 iterations for argon2id with ~1GB
> of RAM for 2 secs; given the above mentioned parameters of my command, I
> estimate that allowing the command to finish (it is currently paused with
> Ctrl+Z) would take at least a week of full time computing with the CPU
> churning away all this time; I'd like to avoid that.
> 
> On the plus side, I've learned some things about LUKS and cryptography and
> the first thing I'll do after recovering from this is make a header backup.
> 
> So, I reiterate my initial question: is it possible to recover from this
> situation without a complete reinstall or letting the command complete for a
> long time? The disk encryption key should still be in RAM IIUC, but since
> it's LUKS2, according to the FAQ extracting it from there is not trivial.
> 
> Thank you for any help,
> 
> C.F.
> 
> 

-- 
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