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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
