Re: [dm-crypt] how to get keyslog PBKDF settings via libcryptsetup

Jonas Meurer <[email protected]>
Newsgroups de.saout.dm-crypt
Message-ID <[email protected]>
Hey Ondrej,

Ondrej Kozina:
> On 1/28/20 3:51 PM, Jonas Meurer wrote:
>> Hello dm-crypt folks,
>>
>> I want to retrieve pbkdf params for active keyslots of LUKS devices.
>> First I looked into `crypt_keyslot_get_pbkdf()`, but contrary to what
>> the code suggests[1], it doesn't return values for LUKS1 devices.
> 
> No, it should definitely work. What version of library have you tested
> it with?

Thanks for your comments and confirming that I'm on the right track :)

I'm using the latest cryptsetup 2.2.2 version (from the Debian packages).

> So, are you sure *cd contains proper LUKS1 context?

At least I hope so. `crypt_get_type(cd)` returns 'LUKS1' and 'LUKS2'
respectively.

> Probably, you've just switched the condition on
> crypt_keyslot_get_pbkdf(). It returns 0 on success and negative value
> otherwise.

That's how I first understood it that way as well. But after some
testing I got the impression that my crypt_pbkdf_type struct contains
values if the return code is *not* 0. Anyway, I checked the return codes
of `crypt_keyslot_get_pbkdf(cd, ki, &pbkdf_ki)` now for LUKS1 and LUKS2
devices and interestingly, I always get return code '0' for LUKS1
devices and '-2' for LUKS2 devices:

Device cont1_crypt (type LUKS2)
Active keyslot 0: 2
  return code: -2
Active keyslot 1: 2
  return code: -2

Device cont3_crypt (type LUKS1)
Active keyslot 0: 3
cryptsetup-suspend: couldn't get PBKDF for keyslot 0 of device
cont3_crypt: Success
  return code: 0

Also, the crypt_pbkdf_type struct has values '0' for all integers for
LUKS1 and seems to have random values for LUKS2 (probably pointers to
random memory pages?).

Simplified code:

struct crypt_device *cd = NULL;
crypt_init_by_name(&cd, devices[i]);
printf("Device %s (type %s)\n", devices[i], crypt_get_type(cd));
int ks_max = crypt_keyslot_max(crypt_get_type(cd));
for (int j = 0; j < ks_max; j++) {
    crypt_keyslot_info ki = crypt_keyslot_status(cd, j);
    if (ki != CRYPT_SLOT_ACTIVE && ki != CRYPT_SLOT_ACTIVE_LAST)
        continue;
    printf("Active keyslot %d: %d\n", j, ki);
    struct crypt_pbkdf_type pbkdf_ki;
    int res = crypt_keyslot_get_pbkdf(cd, ki, &pbkdf_ki);
    printf("  return code: %d\n", res);
}
crypt_free(cd);


>> Also, looking at the actual return valudes, it seems to return the
>> calculated values for a new keyslot, not the ones for the active
>> keyslot, right?
> 
> Again, this would be either bug in libcryptsetup or some mistake in your
> application code. Looking at libcryptsetup code it extracts values
> directly from metadata for both LUKS1 and LUKS2.

Yep, apparently either I'm doing something wrong or there's a bug in
libcryptsetup. Unfortunately I'm not sure which one is true ;)

> Do you get same values when you try to modify your code a bit?
> 
> Could you replace crypt_init_by_name() with
> 
> crypt_init(/path/to/luks/metadata/device)
> and subsequent
> crypt_load()
> 
> Do you get same (wrong) values?

Jep, I now tried that with exactly the same results.

Cheers
 jonas
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEELIzSg9Pv30M4kOeDUmLn/0kQSf4FAl4xk1EACgkQUmLn/0kQ
Sf5jFhAAoVcv2T1fX7fG6hPN6kEl3IBxcOQDEYNkdgYW2zDaEnQl/+EhMz5qr+1F
MEe2bAAdJ7Ob8KpdjguVFHHpynau39VOnM5XtDu/eQpqMqHEBktnm8OOPGeaKlRq
GlbWcb1Q3x5dV+0m8YDD3Fozt022WR75oLJeOIvKeuLVi7Qg0R4G2E7xYxZknOC7
RZnRfRrrmctAvZSwQ6X+wtK6pWSrSDQNr7+O1WJ+4Z8WdSX2P6ekHFOwUdvbicZg
q/bp4n/Rxeotq8gtuN112bZxt8azyIxsPUb7BVT+F0kOTQtlmoLMzt3BgWDZBS6B
Cus8U3D6KMq5sFO9btxVTkCoyaANVha+yjHrFc+PEPp6alizCY5bVqrxVYytzUP6
rV/IKeoPzNLJCzLS5JaX6f0inXHX4NVZ6Ekbwtpo8Z5EX07SWZsf595TitF4utrv
YCxDivLjIfPo8CWjTwLdfE1n1iIhjGi0sDh3yeCSx8oi5iqsA8GZkoYnZ+yrZNEC
4utjA3KiUP57u455ljEzTTWa8ENrQuosHGCu4QxCGSBIPaplZXJ6+jwUmoem5hEi
Ce5N+LJ0tFkfuYzxLvI32cqeznVRsBZR4KQej0rTfX+LeiNM1z8o6B1KSkgmCTJd
k4vuH1PSGxk6/mGJvL/t9MEcs6XWEoPtMzpKsqmcMKPTb67eil0=
=g2hD
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.