From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 26 12:51:47 2008 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 873471065677 for ; Tue, 26 Feb 2008 12:51:47 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 4148213C442 for ; Tue, 26 Feb 2008 12:51:46 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id DA44A45F21; Tue, 26 Feb 2008 13:18:31 +0100 (CET) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 3ABA7456AB; Tue, 26 Feb 2008 13:18:25 +0100 (CET) Date: Tue, 26 Feb 2008 13:17:51 +0100 From: Pawel Jakub Dawidek To: Atom Smasher Message-ID: <20080226121750.GF77530@garage.freebsd.pl> References: <20080223010856.7244.qmail@smasher.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IU5/I01NYhRvwH70" Content-Disposition: inline In-Reply-To: <20080223010856.7244.qmail@smasher.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: hackers@freebsd.org Subject: Re: Security Flaw in Popular Disk Encryption Technologies X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2008 12:51:47 -0000 --IU5/I01NYhRvwH70 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 23, 2008 at 02:08:54PM +1300, Atom Smasher wrote: > article below. does anyone know how this affects eli/geli? >=20 > from the geli man page: "detach - Detach the given providers, which means= =20 > remove the devfs entry and clear the keys from memory." does that mean=20 > that geli properly wipes keys from RAM when a laptop is turned off? Yes, geli tries to clear sensitive informations on detach (mostly keys). I use a script to suspend my laptop, which detach my encrypted partition before suspend. In perforce I've suspend/resume geli(8) subcommands that helps a bit here - on 'geli suspend' command the keys are cleared and all I/O requests are suspended until 'geli resume' provides proper keys. This way one doesn't have to unmount file systems to allow 'geli detach' to succeed. Of course even if keys are cleared there could still be important data in RAM (eg. file system's buffer cache). --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --IU5/I01NYhRvwH70 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHxANuForvXbEpPzQRAr6QAKDARJFmdtLKJSxWtsHELETlLlFHnACeJXLz UnN+N9kFqqQhUKvmcMgUSKU= =U6kc -----END PGP SIGNATURE----- --IU5/I01NYhRvwH70--