Recently decided to try a full-disk encryption(including /boot) with in-place reencryption. Rehearsal in VM with all options by default was successful, so I went for real. On first boot, GRUB said that passphrase was invalid. Had to add a new passphrase with PBKDF2 algo for key in order to get through. But then GRUB wasn’t able to load kernel:
error: loader/efi/linux.c:grub_cmd_linux:542:out of memory.
error: loader/efi/linux.c:grub_cmd_initrd:412:you need to load the kernel first.
Finally, with a replaced “filekey” with PBKDF2 algo as well, everything went smooth.
I again tried to use Argon2id algo for keys, but with non-default 131072 memory cost(default is 1048576), and it worked.
I have 16GB of RAM on Lenovo ThinkPad T480 laptop, therefore the question is: what is the problem with GRUB reading Argon2id keys created with default options? Is it a bug or maybe I have some unusual options set somewhere?
Yeah, support for luks2 with Argon2 key is a new feature in stock Grub - was released only month ago with 2.14 version. That’s why I decided to give it a try.
As far as I know, Argon2 might not work on some devices due to issues with the memory allocator. So yes, reducing the required memory size can sometimes fix this problem, But it will make the bruteforce attack easier. It also seems that at the moment Grub does not support all Luks2 combinations.
I tried to use Argon2 from Grub 2.14, unfortunately it didn’t work for me and I had to go back to grub-improved-luks2-git.
Also, strangely enough, Argon2 doesn’t work on my motherboard with the latest version of UEFI, so I had to downgrade the firmware version.
… will it make brute force easier?
from what I know and think:
can you (can “one”) somehow determine
during an attempt to brute force
that the “level of encryption” has been weakened?
… How would someone, some “attacker” know
that they had a better (but still very low) chance
to eventually succeed?
This is not about weakening cryptography, but that it requires less memory when trying to decrypt data. So it will be easier and cheaper for the attacker to scale bruteforce attack.
… but how would anyone even know what kind of encryption “they” where up against?
was my thought/question
How and why …
would someone even be able to halfway correctly assume a specific kind of encryption to be employed -
to then be able to narrow down on the specific weaknesses that this might entail?
The keys lots of LUKS2 headers contain information and parameters for the used password-based key derivation function. So basically these information is not a secret and is available for everyone that can access the locked drive.
Can that be read remotely?
Can that be accessed or read in the encrypted state?
(when you have got the physical medium - when you are in possession of the actual hardware)
How can or could this info on the type and level of encryption be gathered by someone trying to break it?
… to make the “job” a little easier - but still very difficult …
I thought so.
How does one read that header?
(without knowing of it’s presence - just assuming it is there …)
I’ll look and find out myself.
But if you can tell: please, do so.
I’ll shut down my system and boot from some ISO
and test this.
In the current state - system up and running - this reveals this:
(root access needed, of course)
sudo cryptsetup luksDump /dev/sda3
...
LUKS header information
Version: 2
Epoch: 4
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
UUID: 3abdd00f-b272-48cf-9ec1-751087bec1ee
Label: (no label)
Subsystem: (no subsystem)
Flags: (no flags)
Data segments:
0: crypt
offset: 16777216 [bytes]
length: (whole device)
cipher: aes-xts-plain64
sector: 4096 [bytes]
Keyslots:
0: luks2
Key: 512 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 512 bits
PBKDF: argon2id
Time cost: 4
Memory: 995408
Threads: 4
Salt: 57 3e ec 72 83 c0 09 b4 a1 75 18 cd 28 16 46 08
98 83 2e 09 c3 23 ca 3e 15 cc 5e 7c 7f 6f 8e 97
AF stripes: 4000
AF hash: sha256
Area offset:32768 [bytes]
Area length:258048 [bytes]
Digest ID: 0
1: luks2
Key: 512 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 512 bits
PBKDF: argon2id
Time cost: 4
Memory: 1033110
Threads: 4
Salt: fd 06 25 f0 ca 34 3a e2 02 f0 31 d8 47 03 eb 2d
fe 65 34 41 91 f7 ac 6e 5d ae b6 00 6a 82 29 9f
AF stripes: 4000
AF hash: sha256
Area offset:290816 [bytes]
Area length:258048 [bytes]
Digest ID: 0
Tokens:
Digests:
0: pbkdf2
Hash: sha256
Iterations: 58724
Salt: 99 3c 3c ad eb 9f 53 3c 05 ec f1 d6 42 9d 14 ac
06 7d 96 54 06 22 54 01 94 82 1d 94 26 80 78 81
Digest: 4f dd 0b b6 2a 82 a2 c9 65 af d1 fc 29 3d 3d 4e
6e 89 7d a6 4c bb 30 d9 73 c7 98 f6 41 c8 60 67
the “password” to unlock it is relatively simple and not even very long - but it is not a word found anywhere …
How would one measure progress towards getting near to “breaking” it?
… can’t be done is what I always assumed so far …
You have got it when you have got it - but there is no indication of you getting close.
No?
