Always allow setting initial number of iterations for ELI encrypted disk created without passphrase

[mav]

Summary

There are scenarios when for ELI disk created without passphrase it is impossible to set one, since geli has to initialize number of PKCS#5v2 iterations, which attempt fail. This patch relaxes overly strict checks, allowing number of iteration to be set first time even if both keys are are already set.

This should fix: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218512
, as much more simple alternative to: https://github.com/freebsd/freebsd/pull/109

[fhriley_gmail.com]

This comment was removed by fhriley_gmail.com.

[mav]

This comment was removed by mav.

[fhriley_gmail.com]

Here is the test that fails with this patch. You can't change the password once it is set:

geli init -B none -P -K $keyfile1 md${no}
geli attach -p -k $keyfile1 md${no}
geli setkey -n 1 -i 10 -J $passfile2 -K $keyfile2 md${no} >/dev/null
geli setkey -n 1 -i 10 -J $passfile2 -K $keyfile2 md${no} >/dev/null

[mav]

You can change password, you should just not specify -i after it is set first time. If you wish, it is trivial to add check to not consider error setting value which is already there. I'd say you should not specify -i at all, since that may compromise the security.

[fhriley_gmail.com]

In the space I work in, not specifying -i is the security risk. Everything is explicit. Also, not being able to change the iterations is another security risk. When on high says I have to do X seconds of iterations, but I want to increase my cpu power and use the same disks, what do I do?

I'm not opposed to leaving out the md_passphrases field I added in my pull, but I don't see it (or any of my other changes, they're pretty simple and have tests) as particularly invasive.

[mav]

In D10338#214219, @fhriley_gmail.com wrote:

In the space I work in, not specifying -i is the security risk. Everything is explicit. Also, not being able to change the iterations is another security risk. When on high says I have to do X seconds of iterations, but I want to increase my cpu power and use the same disks, what do I do?

Increase and use. Nothing should change for you. In my understanding the idea of choosing number of iterations is just a compromise between keeping sufficient strength against brute force attack on password and processing entered password on attach in reasonable time. Increasing your CPU power will just allow you to attach disks faster. Strength against brute force on the other hand by definition depends not on your CPU power, but on CPU power of attacker. Unless you are upgrading your system from some 100MHz ARM to 4GHz x86, I don't see significant reason to bother about the number of iterations, while if it so, password encrypted with low number of iterations for ancient/low-end ARM can probably be brute-forced much easier on modern high-end cluster.

I'm not opposed to leaving out the md_passphrases field I added in my pull, but I don't see it (or any of my other changes, they're pretty simple and have tests) as particularly invasive.

I don't care which of two solutions will be committed. For me personally it would be enough to be able to add password to disks that never had it before, that is exactly what my patch allows. But GELI is not normally my area or interest, and so I'd leave the decision about your patch to more interested people.