Nevertheless how many iterations are agreed it seems that the amount of iterations will be increased in a next version. Does this require to "upgrade" an already existing partition created with the current default values or is it sufficient just to use the new version? If an "upgrade" would be required, how to do it? Cheers Stefan Arno Wagner schrieb: > On Thu, Nov 19, 2009 at 10:21:07AM +0100, Heinz Diehl wrote: >> On 19.11.2009, Arno Wagner wrote: >> >>> If I understand this correctly, this is the "iteration-count" >>> parameter to PBKDF2. If so, then RFC 2898 recommends a minimum >>> count of 1000 anyways. >> This has been discussed in various places, and the conclusion was that it >> should not be lower than 50.000 iterations. See f.ex. rfc3962 on >> implemetation of PBKDF2 for Kerberos5. >> >>> The main purpose of this parameter is to make exhaustive search more expensive. >> Yes, it should make bruteforcing a lot more time-expensive. >> >>> I think this should definitely go up to 1000. >> I think this should maybe go up to 50.000 or 100.000. >> If I understood all correctly, so should a bump-up to 100.000 not have >> much noticeable impact on the main speed either. >> >> Please correct me if I'm wrong. > > Just did a few benchmarks with a 10MB loopback on a dual > Athlon 64 5600+. As the master key iterations are not accessible > via commandline, I have tried some time settings for the > slot key (-i <milisec>). They should have similar effort. > > Iteration time Iterations time (elapsed) for luksOpen > 1 ms 301 1.01 sec > 10 ms 3 029 1.01 sec > 100 ms 30 247 1.06 sec > 1 sec 303 694 1.51 sec > 10 sec 3 043 420 6.02 sec > 100 sec 30 212 200 50.92 sec > > Ok, something is going on, that should be > 100 sec on the > last one. Nonetheless a rough estimation is possible. Maybe > a cache issue. > > I would estimate that the time for 100'000 iterations is below > 1 sec even for weak systems. For mine it is around 0.15 sec. > > This makes going to 100'000 on mk_iter entirely feasible. > > I curretntly do not see whether this is really needed, but > clearly it is not a problem and 100'000 is the recommended > value, so let's use it. Anybody having real slowdown because > they run this on a 25 Mhz 386SX CPU can still reduce the > count via commandline. > > Arno _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
