From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 7 18:06:33 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7457516A4CE for ; Mon, 7 Mar 2005 18:06:33 +0000 (GMT) Received: from pd3mo3so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 390EF43D54 for ; Mon, 7 Mar 2005 18:06:33 +0000 (GMT) (envelope-from soralx@cydem.org) Received: from pd5mr7so.prod.shaw.ca (pd5mr7so-qfe3.prod.shaw.ca [10.0.141.183]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICZ005XTUAW5M50@l-daemon> for freebsd-hackers@FreeBSD.ORG; Mon, 07 Mar 2005 11:06:32 -0700 (MST) Received: from pn2ml4so.prod.shaw.ca ([10.0.121.148]) by pd5mr7so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICZ00D94UAW90H0@pd5mr7so.prod.shaw.ca> for freebsd-hackers@FreeBSD.ORG; Mon, 07 Mar 2005 11:06:32 -0700 (MST) Received: from S01060020ed3972ba.ed.shawcable.net (S01060020ed3972ba.ed.shawcable.net [68.149.254.68]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0ICZ00E2FUAV85@l-daemon> for freebsd-hackers@FreeBSD.ORG; Mon, 07 Mar 2005 11:06:32 -0700 (MST) Date: Mon, 07 Mar 2005 11:06:56 -0700 From: soralx@cydem.org In-reply-to: <18767.1110214190@critter.freebsd.dk> To: freebsd-hackers@FreeBSD.ORG, tech-security@NetBSD.ORG Message-id: <200503071106.56075.soralx@cydem.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline References: <18767.1110214190@critter.freebsd.dk> User-Agent: KMail/1.5.4 cc: aleine@austrosearch.net cc: phk@phk.freebsd.dk Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 18:06:33 -0000 > >I agree. I would also add random reads (or specially designed, combined > >random reads and writes) to make traffic analysis and differential attacks > >a real PITA for the hacker (although this idea may not be very effective > >against a highly motivated and determined attacker, such as some > > government, for instance). > > If you want to do something like this, you want to do sectorrenaming > and journaling since that means you can only see that something > was written but not what it was that was written. So you think that just adding specially crafted, random reads/writes will have no significant positive impact on security of "hot" disks? > The performance cost can be considerable and the complexity formidable. > There are incredibly many cornercases to handle. But you do not deny that providing strong protection for "hot" disks is very important? After all, user protection is only available when the disk is hot. Speaking of user protection, how did you implement the procedure of erasing keys? Did you account for the properties of magnetic media and RAM that make data recovery possible? See, for example: http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html Timestamp: 0x422C930D [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2