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

[gson%gson.org@localhost (Andreas Gustafsson)]

The following reply was made to PR bin/28627; it has been noted by GNATS.

From: gson%gson.org@localhost (Andreas Gustafsson)
To: gnats-bugs%NetBSD.org@localhost
Cc: dholland%NetBSD.org@localhost
Subject: Re: bin/28627 (cgdconfig -g is unreliable)
Date: Mon, 23 Feb 2009 15:47:54 +0200

 dholland%NetBSD.org@localhost wrote:
 > Should be fixed as of last April?
 
 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.
 -- 
 Andreas Gustafsson, gson%gson.org@localhost