[dm-crypt] Add --iter-count in order to not use --iter-time

[dm-crypt] Add --iter-count in order to not use --iter-time

[Oliver Smith]

Dear cryptsetup developers,


we are working on a project where we are building a Linux distro targeting older 
mobile devices (e.g. armhf arch). The OS image is built and luksFormat is 
executed on a modern CPU before being moved to the older device, resulting in a 
very high iter count. This is problematic because it typically takes the older 
device tens of seconds in some cases to open the luks partition (for reasons you 
point out in the FAQ). Using -iter-time is not really a good option since the 
types of 'modern cpus' where the distro image can be built is quite varied 
(multiple project devs, etc).

(NOTE: I took the liberty to copy-paste and the above text from Clayton Craft,
who is involved in the same project, from here:
<https://gitlab.com/cryptsetup/cryptsetup/issues/280#note_38098185>.)

The problem described above would be solved with a new command-line option for 
the cryptsetup utility, that allows to directly specify the iteration count.

Follow-up questions:
* Would it be feasible for you to implement this feature any time soon?
* Would you accept a patch if we gave it a shot (we might need some guidance 
though)?

PS: I've noted that you can only send to this mailing list, when you are subscribed,
and to subscribe, one must register over a non-TLS secured HTTP connection (which
of course makes trivial MITM attacks possible).


Best regards,
Oliver Smith

Re: [dm-crypt] Add --iter-count in order to not use --iter-time

[Milan Broz]

On 09/19/2017 10:43 PM, Oliver Smith wrote:
> Dear cryptsetup developers,
> 
> 
> we are working on a project where we are building a Linux distro targeting older 
> mobile devices (e.g. armhf arch). The OS image is built and luksFormat is 
> executed on a modern CPU before being moved to the older device, resulting in a 
> very high iter count. This is problematic because it typically takes the older 
> device tens of seconds in some cases to open the luks partition (for reasons you 
> point out in the FAQ). Using -iter-time is not really a good option since the 
> types of 'modern cpus' where the distro image can be built is quite varied 
> (multiple project devs, etc).
> 
> (NOTE: I took the liberty to copy-paste and the above text from Clayton Craft,
> who is involved in the same project, from here:
> <https://gitlab.com/cryptsetup/cryptsetup/issues/280#note_38098185>.)
> 
> The problem described above would be solved with a new command-line option for 
> the cryptsetup utility, that allows to directly specify the iteration count.
> 
> Follow-up questions:
> * Would it be feasible for you to implement this feature any time soon?

This option can be quite dangerous but I agree that there is a use case for it.

Actually that feature is already implemented as part of support for other
PBKDF in new LUKS2 format (for now in wip-luks2 branch), but this one will
be available even for old LUKS1 format.
It requires API changes so it will be in cryptsetup2, not backported to
1.7 stable (but you can format LUKS1 with new version and then open it with
older one).

So, for cryptsetup there is --pbkdf-force-iterations option that set PBKDF2
iteration count directly and will disable any PBKDF benchmarks.
(There is just forced minimum to 1000 PBKDF2 iterations.)

(New LUKS2 format will support memory-hard KDF so there is also a memory cost,
but this does not apply to LUKS1.)

I will describe how to use it in release notes once we will try to release
testing version. Please be patient, it will come soon :)

> * Would you accept a patch if we gave it a shot (we might need some guidance 
> though)?
> 
> PS: I've noted that you can only send to this mailing list, when you are subscribed,
> and to subscribe, one must register over a non-TLS secured HTTP connection (which
> of course makes trivial MITM attacks possible).

I guess Jana could fix that, I do not have even admin rights to this list.

Thanks,
Milan

Re: [dm-crypt] Add --iter-count in order to not use --iter-time

[Arno Wagner]

On Wed, Sep 20, 2017 at 00:40:22 CEST, Milan Broz wrote:
[...]
> 
> This option can be quite dangerous but I agree that there is a use case
> for it.
> 

I agree that while this option will allow some people to shoot 
themselves in the foot (and hence is somewhat dangerous), it
does have its uses. Unfortunately, people can always abotage 
themselves when using crypto, so I think the additional risk is
small.

One thing to think about with the memory hard KDF for LUKS2 
(I assume Argon2) is whether to give the user access to all 
the relevant parameters. I think the same reasoning as to 
BPKDF2 iterations applies, i.e. warn people to not do this 
unless they know what they are doing, but if they want to 
do it anywys, give them a clean way to do so to minimize
additional risks.

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