Re: {1406} Harddisk destroy in les then 30 sec ?

From: <cont..._at_yahoo.co.uk>
Date: Wed, 21 Mar 2007 15:56:07 -0700

>From - Sat Mar 02 00:57:18 2024
Received: by 10.36.128.14 with SMTP id a14mr1560278nzd.1177479073977;
        Tue, 24 Apr 2007 22:31:13 -0700 (PDT)
Return-Path: <az..._at_osuny.co.uk>
Received: from osuny.co.uk (adsl-75-16-232-133.dsl.kntpin.sbcglobal.net [75.16.232.133])
        by mx.google.com with ESMTP id h49si2935214nzf.2007.04.24.22.31.13;
        Tue, 24 Apr 2007 22:31:13 -0700 (PDT)
Received-SPF: neutral (google.com: 75.16.232.133 is neither permitted nor denied by best guess record for domain of az..._at_osuny.co.uk)
Received: from osuny.co.uk (localhost.osuny [127.0.0.1])
        by sdf1.osuny (8.13.8/8.13.4) with ESMTP id l3P5Udp6000164
        for <TSCM-..._at_googlegroups.com>; Wed, 25 Apr 2007 00:30:40 -0500 (CDT)
From: "_azure" <az..._at_osuny.co.uk>
To: TSCM-L2006_at_googlegroups.com
Subject: Re: [TSCM-L] {1482} Re: Harddisk destroy in les then 30 sec ?
Date: Wed, 25 Apr 2007 00:30:39 -0500
Message-Id: <20070425052748.M39015_at_osuny.co.uk>
In-Reply-To: <462ECBF6.3040302_at_phreaker.net>
References: <1174512089.374460.264800_at_l75g2000hse.googlegroups.com> <1174577353.001993.271400_at_e65g2000hsc.googlegroups.com> <462ECBF6.3040302_at_phreaker.net>
X-Mailer: Open WebMail 2.51 20050228
X-OriginatingIP: 144.160.5.25 (azure)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1

--- On Tue, 24 Apr 2007 23:33:10 -0400, kondrak wrote

> That only removes the FAT table, data is still there on the platters
> and can be recovered. Even a format isn't good enough, as latent
> data signatures can be recovered even though theyre very weak. The
> old standard of rewriting sequential zeros and ones is pretty good,
> but still not classified as 'destruction". Ill stick with the thermite.

Or, use encrypted volumes to begin with. Then all you have to do is power off
the system. It's more risky in that there is always the possibility the
encryption scheme (or its implementation) has been broken; but it satisfies
the speed requirement, and is also more forgiving of false-alarms.


_azure
Received on Sat Mar 02 2024 - 00:57:18 CST

This archive was generated by hypermail 2.3.0 : Sat Mar 02 2024 - 01:11:44 CST