Re: bin/28627 (cgdconfig -g is unreliable)

[Roland Dowdeswell <elric%imrryr.org@localhost>]

On 1235397003 seconds since the Beginning of the UNIX epoch
Andreas Gustafsson wrote:
>

> I back-ported the change to 4.99.30 (which is what my only remaining
> Crusoe-powered machine is running) and tested it, and found that it
> doesn't fully fix the problem - cgdconfig still fails in the same way
> as before, although not quite as frequently.
> 
> This is not entirely unexpected given that my original bug report said
> cgdconfig was failing "about nine times out of ten", and the "fix" was
> to retry five times...
> 
> I tried adding a debug printf showing the calibration discrepancy as a
> percentage; this is what it printed in one of the failed runs:
> 
>   $ cgdconfig -g -V disklabel aes-cbc 256
>   -9 % off
>   -6 % off
>   9 % off
>   -5 % off
>   -7 % off
>   cgdconfig: could not calibrate pkcs5_pbkdf2
>   cgdconfig: Failed to generate defaults for keygen
> 
> Note that my suggested fix was not to retry the operation, but to
> increase the calibration tolerance.  Retrying certainly doesn't hurt,
> but it's not enough - the tolerance still needs to be increased.
> 
> I assume the reason for doing the calibration is to make the amount of
> computation required for a brute-force attack on the passphrase scale
> as machine speeds increase, but there is no way to do that with any
> degree of precision, because the performance that matters is not that
> of your own machine at the time when the disk encryption is set up
> (which is what the calibration is measuring), but that of the
> attacker's machine at the time of the attack.  Given that the relative
> speeds of your machine and the attacker's can easily vary by orders of
> magnitude, requiring a +-5% calibration tolerance is just absurd.
> +-50% would be far more reasonable.

The check exists not to ensure that the iteration count will consume
a certain amount of resources on the attacker's machine but rather
to check that the calibration on your machine actually worked and
that we can trust the results.  So, increasing the tolerance is
reasonable but probably not all the way to 50%.  If it turns out
that it is common that we're 40% off then we should revisit the
calibration logic and find an algorithm that is more likely to be
correct.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/