NetBSD Problem Report #28627

From gson@araneus.fi  Sun Dec 12 10:14:29 2004
Return-Path: <gson@araneus.fi>
Received: from gusto.araneus.fi (gusto.araneus.fi [204.152.189.154])
	by narn.netbsd.org (Postfix) with ESMTP id 9FFEE251ED0
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 12 Dec 2004 10:14:29 +0000 (UTC)
Message-Id: <200412121014.iBCAENNi024272@guava.araneus.fi>
Date: Sun, 12 Dec 2004 12:14:23 +0200 (EET)
From: gson@gson.org (Andreas Gustafsson)
Reply-To: gson@gson.org (Andreas Gustafsson)
To: gnats-bugs@netbsd.org
Subject: cgdconfig -g is unreliable
X-Send-Pr-Version: 3.95

>Number:         28627
>Category:       bin
>Synopsis:       cgdconfig -g is unreliable
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Dec 12 10:15:00 +0000 2004
>Closed-Date:    
>Last-Modified:  Tue Mar 24 13:49:17 +0000 2009
>Originator:     Andreas Gustafsson
>Release:        NetBSD 2.99.10
>Organization:
>Environment:
System: NetBSD guam.araneus.fi 2.99.10 NetBSD 2.99.10 (GUAM) #0: Sun Dec 5 15:10:56 EET 2004 gson@guava.araneus.fi:/usr/src/sys/arch/i386/compile/GUAM i386
Architecture: i386
Machine: i386
>Description:

On a lightly loaded Toshiba Libretto L2 laptop, running the command

   cgdconfig -g -V disklabel -o /etc/cgd/wd0e aes-cbc 256

fails about nine times out of ten with the error message

   cgdconfig: could not calibrate pkcs5_pbkdf2
   cgdconfig: Failed to generate defaults for keygen

This is caused by cgdconfig measuring the password encryption
performance of the CPU twice and considering any discrepancy between
the measurements exceeding 5% to be a failure.  Perhaps the
performance of the Transmeta Crusoe CPU used in the L2 varies more
over time than that of a typical desktop CPU due to the "code
morphing" technology it uses, or due to some power-saving feature.

>How-To-Repeat:

Run the above command on a Toshiba Libretto L2 or other Crusoe-powered
laptop (taking care not to accidentally overwrite any existing cgd
parameters file).

>Fix:

Unless there is a compelling security argument to the contrary,
the tolerance for variability between timing measurements should be
increased from the current 5%.

Also, it would be helpful if the error message indicated that the
failure is caused by a transient timing issue and that retrying the
command may help.

>Release-Note:

>Audit-Trail:
From: Christos Zoulas <christos@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/28627 CVS commit: src/sbin/cgdconfig
Date: Mon, 21 Apr 2008 15:23:35 +0000 (UTC)

 Module Name:	src
 Committed By:	christos
 Date:		Mon Apr 21 15:23:35 UTC 2008

 Modified Files:
 	src/sbin/cgdconfig: pkcs5_pbkdf2.c

 Log Message:
 PR/28627: Andreas Gustafsson: Try 5 times to calibrate before failing. Should
 fix issues with CPU's that don't produce consistent timing output due to code
 morphing or power-savings.


 To generate a diff of this commit:
 cvs rdiff -r1.12 -r1.13 src/sbin/cgdconfig/pkcs5_pbkdf2.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 22 Feb 2009 08:27:23 +0000
State-Changed-Why:
Should be fixed as of last April?


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

 dholland@NetBSD.org 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

From: Roland Dowdeswell <elric@imrryr.org>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
	gson@gson.org (Andreas Gustafsson)
Subject: Re: bin/28627 (cgdconfig -g is unreliable) 
Date: Mon, 23 Feb 2009 09:31:18 -0500

 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/

State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Tue, 24 Mar 2009 13:49:17 +0000
State-Changed-Why:
Feedback was received...


>Unformatted:

Home	PR Database Search