[clug] Re: More (almost free) stuff. - 3.5" WD 200GB IDE - $10

Paul Wayper paulway at mabula.net
Wed Sep 10 13:26:25 GMT 2008

Hash: SHA1

Steve McInerney wrote:
| On Tue, September 9, 2008 22:40, Paul Wayper wrote:
|> Realistically, by the same argument, I think there's probably a fairly
|> good
|> case for just writing twenty-six alternating all-ones and all-zeros
|> layers.
| Under what circumstances?
| "I think..." is not a terribly useful risk analysis. :-)

Well, in case you can't follow the logic, the reason the attack Ian mentioned
works is because the bits are recorded in the analogue domain, with values
above 1.0 and below 0.0 and in between as well.  Each time you change the
value you mostly overwrite the previous one, but some remains.  Gradually that
'some' reduces as the overwrites accrue until the slight change between the
values is now less than the coercivity of the medium; in other words, the
medium just isn't sensitive enough to accurately record that slight
difference, and your data is now lost in the thermal noise.

So writing all ones and then all zeros and so forth, sooner or later the
original bit will be lost in the thermal noise and be effectively
unrecoverable.  Even if you could theoretically 'undo' those known writes, the
actual data is indistinguishable from the random background fluctuations.
Exactly how many times you have to do that remains a matter of testing, but
the principle is sound.

It's like the fact that 3.1415926535897932384626433 is a well defined point on
the real number line, but even if you had a real ruler a kilometre in length
scaled from 0 to 10 you couldn't mark it accurately to more than about six
decimal places, due to the non-uniformity of the material making up the ruler
and the inaccuracies of the marking and reading devices.

|> The thing that annoys me is, ultimately, the truly paranoid argue for
|> burning
|> the drive in a furnace.
| Using labels to denigrate an opposing POV is a poor way of arguing your
| case; and will typically cause your entire argument to be rejected out of
| hand.

Maybe so.  If your only criticism is my choice of labels then I'm quite happy.

And, fundamentally, I think the thing that is truly wrong about these people
is that they never admit that they might be being too cautious, too paranoid,
to suspicious.  They always justify themselves in nice bold terms of National
Security and Protecting Our Customers, and expect that we'll just throw more
and more money at them to meet whatever they say they need.

| Out of idle curiosity: How many soldiers lives wasted would you consider
| to be sufficient proof that this was no longer a waste of money?
| How many leaks of bank account details?
| No. It's called Risk Analysis.

Are you actually serious about this?

Because I think you need to tell me, first, how many soldiers have died in
Iraq because we went to war over data which ASIO now admits was flawed.  Tell
me how many millions of bank account details, social security numbers, and
identities have already leaked out of 'perfectly secure' live systems.  How
many of these were due to incorrectly wiped hard disks (i.e. hard disks that
were 'securely' erased, say once, and then subsequently recovered using the
method Ian and others outlined), and how many were due to other problems - bad
information, lazy security, lack of care, etc.

If you're going to wave the "risk analysis" flag around, then please do so
with actual justification.

I do not consider it a valid argument to say "just in case there are any
problems that we might not have foreseen, we're going to dismantle the hard
disks inside their secure facility."  You might as well say "and we're then
going to shred them, burn the shreds, pulverise the ashes, make bricks out of
powder, build a building from the bricks, and then blow up the building, and
just to make sure we're going to all close our eyes and sing the 'problems go
away now' song."  In other words, there is no excess that you can't justify in
terms of 'but if we don't do that, we might not be safe'.

Firstly, the risks associated with the data leaks that occur all too regularly
already are well known.  This doesn't make the companies that should know
better plug the holes through which their data is leaking.  Those companies
then doing a bit of security theatre with how they dispose of their old drives
doesn't make them magically more secure, or stop those websites from leaking
identities or credit card numbers and so forth.

And secondly, if I said "no soldiers lives should be wasted", would you be
bringing them all back from all the war zones they're in now?  Using this kind
of "but think of the poor little children" mentality, while it makes for good
press boilerplate and political speeches, is actually a form of emotional
blackmail.  If you're going to accuse me of choosing labels, then perhaps you
should look more carefully at your own rhetorical tactics.

| One obvious & trivial counter is the media published leaks of details from
| HDD's that *weren't* sanitised. Somewhat surprisingly :-) physical
| destruction makes this particular process failure a lot harder to achieve.
| And as an entire *process*, physical destruction is a LOT cheaper than
| sanitisation.

Maybe so.  But it's also wasteful.  And my point has been that we are
destroying a lot of perfectly good resources under the pretense that that's
the only way to 'securely' protect that data.  If secure erasure is possible
while still keeping the drive functioning and useful, or at least recycling
its components into other useful materials, then that is much better than
locking it up (which is what EDS do with their secure data) or destroying it
in an incinerator (an option mentioned last time this topic came up on the
CLUG list).

Anyway, I expect to change approximately zero defence officials minds, and
exactly zero defence department policies, on this, so my choice of using
provocative labels can be put down to knowing that they couldn't care less
about my opinions anyway.

Have fun,

Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the linux mailing list