Bug#923513: [pkg-cryptsetup-devel] Bug#923513: cryptsetup-bin: Can no longer luksFormat as non-root: "Not compatible PBKDF options."

2019-03-02 Thread Milan Broz 
On 02/03/2019 11:23, Christoph Biedl wrote:
> Thanks for looking into this and the insights given. For luksmeta
> however ... it's "to access metadata in a LUKSv1 header", and before the
> buster release I better shall refrain from checking how the related
> tools like clevis deal with LUKSv2 headers  B-)

Clevis/Tang already supports direct metadata store to LUKS2 token objects
(so the luksmeta package is obsolete for LUKS2 format).

IIRC they use cryptsetup token command in the wrapper.

Milan

Bug#923513: [pkg-cryptsetup-devel] Bug#923513: cryptsetup-bin: Can no longer luksFormat as non-root: "Not compatible PBKDF options."

2019-03-02 Thread Christoph Biedl 
Guilhem Moulin wrote...

> FWIW the regression isn't directly tied to the new default LUKS format,
> but to the PBKDF benchmark for Argon2i/id (the default PBKDF for LUKS2).
> Here is an output snippet obtained with --debug:
(...)
> Anyway, IMHO in test scenari it makes sense to the PBKDF benchmark and
> instead force parameters directly (via --pbkdf-force-iterations and
> --pbkdf-memory) to speed up luksFormat and luksOpen.

Thanks for looking into this and the insights given. For luksmeta
however ... it's "to access metadata in a LUKSv1 header", and before the
buster release I better shall refrain from checking how the related
tools like clevis deal with LUKSv2 headers  B-)

Christoph



signature.asc
Description: PGP signature

Bug#923513: [pkg-cryptsetup-devel] Bug#923513: cryptsetup-bin: Can no longer luksFormat as non-root: "Not compatible PBKDF options."

2019-03-01 Thread Guilhem Moulin 
Control: found -1 2:2.1.0-1

Hi Christoph,

On Fri, 01 Mar 2019 at 11:09:53 +0100, Christoph Biedl wrote:
> Declare usage of format 1 like in
> 
>   $ echo -n foo | cryptsetup luksFormat --type luks1 /tmp/blob -
> 
> and possibly some other ways.

FWIW the regression isn't directly tied to the new default LUKS format,
but to the PBKDF benchmark for Argon2i/id (the default PBKDF for LUKS2).
Here is an output snippet obtained with --debug:

# Found area 32768 -> 290816
# Running argon2i() benchmark.
# PBKDF benchmark: memory cost = 32, iterations = 4, threads = 4 (took 4 ms)
# PBKDF benchmark: memory cost = 512, iterations = 4, threads = 4 (took 1 
ms)
# PBKDF benchmark: memory cost = 8192, iterations = 4, threads = 4 (took 10 
ms)
Not compatible PBKDF options.
[…]
Command failed with code -3 (out of memory).

and now as root:

# Running argon2i() benchmark.
# PBKDF benchmark: memory cost = 32, iterations = 4, threads = 4 (took 3 ms)
# PBKDF benchmark: memory cost = 512, iterations = 4, threads = 4 (took 1 
ms)
# PBKDF benchmark: memory cost = 8192, iterations = 4, threads = 4 (took 7 
ms)
# PBKDF benchmark: memory cost = 131072, iterations = 4, threads = 4 (took 
152 ms)
# PBKDF benchmark: memory cost = 215578, iterations = 4, threads = 4 (took 
256 ms)
# PBKDF benchmark: memory cost = 1048576, iterations = 6, threads = 4 (took 
1920 ms)
# Benchmark returns argon2i() 6 iterations, 1048576 memory, 4 threads (for 
512-bits key).
# Calculating attributes for LUKS2 keyslot 0.
[…]
Command successful.

Hence other possible workarounds include using PBKDF2 (default PBKDF for
LUKS1) 

cryptsetup luksFormat --pbkdf pbkdf2

Alternatively, you can pass --pbkdf-memory $KBYTES with a low enough
value so the benchmark doesn't exceed getrlimit(RLIMIT_MEMLOCK,), to
avoid the failing large mmap(2).  Milan, perhaps the benchmark should
call getrlimit(RLIMIT_MEMLOCK,) and automatically reduce --pbkdf-memory
accordingly?

Anyway, IMHO in test scenari it makes sense to the PBKDF benchmark and
instead force parameters directly (via --pbkdf-force-iterations and
--pbkdf-memory) to speed up luksFormat and luksOpen.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature