Hi.

Would this make a good mechanism to securely destroy a hard drive?

1. Crash the heads into the platters with the drive at top speed

2. Seek them from one edge of the platters to the other back and forth
to \
ensure good grinding

3. Pump a concentrated hydrogen/oxygen mix into the hard drive platter
chamber
while the heads are grinding away.

Would the heat from the grinding be enough to ignite the H2/O2 mix and
ensure that data can't be recovered? Would this mechanism be good
enough to keep copies of a large company's trade secrets from a
competing large company?

In article <1d54b7e4.0411251822.729ae8cc [at] posting.google.com>,
mike3 <mike4ty4 [at] yahoo.com> wrote:
:Would this make a good mechanism to securely destroy a hard drive?

:1. Crash the heads into the platters with the drive at top speed

Without opening the drive to do so? You'd have to subject them to
a shock in excess of 25g's: drives aren't sensitive beasts anymore.

:2. Seek them from one edge of the platters to the other back and forth
:to \
: ensure good grinding

You'd have to -keep- the heads on the platters while you did that.
Might be a bit tricky if the drive heads essentially float on a
Bernoulli Effect or diamagnetic levitation rather than being
mechanically positioned. Keep in mind too that a modern drive is
multiple platters with heads on both sides of the platters: you can't
count on gravity to keep the heads grinding against the platters.


:3. Pump a concentrated hydrogen/oxygen mix into the hard drive platter
:chamber
: while the heads are grinding away.

:Would the heat from the grinding be enough to ignite the H2/O2 mix

http://www.hydrogensafety.info/articles/04-feb-04.asp

indicates that "hydrogen is a group B gas with an auto-ignition temperature
of 520C to 585C depending on the information source".

In a table slightly further down, it indicates that the flame temperature
is 2318 Kelvin (fairly similar to propane.) That is provided, of course,
that one is burning the hydrogen rather than exploding it. To burn
the hydrogen, the concentration "in air" must be between 4.0% and 18%,
or else 59% and 75%.

:and
:ensure that data can't be recovered? Would this mechanism be good
:enough to keep copies of a large company's trade secrets from a
:competing large company?


Well, 2318 K is well above the Curie temperature of Iron (1043 K)
and -way- above the Curie temperature of Neodymium magnets (320 C)

http://www.sv.vt.edu/classes/MSE2094_NoteBook/96ClassProj/ex amples/neodym.html

Thus if you could keep the hydrogen burning instead of exploding, you
could do a dandy job of weakening the magnetism of the recorded information.
You'd have to be careful, though, because ferrous materials become
paramagnetic above their Curie temperature. For best effect, you should
probably put the whole thing in a large magnetic field so as to realign
the platters before recooling below the Curie temperature.


Still, I somehow can't help feeling that your proposal would -somehow-
be unsatisfactory in protecting trade secrets when there is a large
amount of money at stake. I would suggest that the company hire one of
the military-grade disk destruction specialists, which usually involves
physically grinding the drive into tiny pieces.
--
I predict that you will not trust this prediction.

mike4ty4 [at] yahoo.com (mike3) writes:
>Would this make a good mechanism to securely destroy a hard drive?

>1. Crash the heads into the platters with the drive at top speed

>2. Seek them from one edge of the platters to the other back and forth
>to \
> ensure good grinding

>3. Pump a concentrated hydrogen/oxygen mix into the hard drive platter
>chamber
> while the heads are grinding away.

>Would the heat from the grinding be enough to ignite the H2/O2 mix and
>ensure that data can't be recovered? Would this mechanism be good
>enough to keep copies of a large company's trade secrets from a
>competing large company?


Sounds like way more specialized work than just taking the platters
out and burning them, or running a grinder over the platters scrapping
all the iron oxide off them or chipping the platters into a billion
tiny parts. Simple is almost always best.

In article <1d54b7e4.0411251822.729ae8cc [at] posting.google.com>,
mike3 <mike4ty4 [at] yahoo.com> wrote:
>Hi.
>
>Would this make a good mechanism to securely destroy a hard drive?
>
>1. Crash the heads into the platters with the drive at top speed
>
>2. Seek them from one edge of the platters to the other back and forth
>to \
> ensure good grinding
>
>3. Pump a concentrated hydrogen/oxygen mix into the hard drive platter
>chamber
> while the heads are grinding away.
>
>Would the heat from the grinding be enough to ignite the H2/O2 mix and
>ensure that data can't be recovered? Would this mechanism be good
>enough to keep copies of a large company's trade secrets from a
>competing large company?


A concrete floor and a 5 pound sledge hammer.

Anyone that claims to be able to read data from a disk platter
that isn't flat and balanced needs to give me something
to back up that claim.
--
a d y k e s [at] p a n i x . c o m
----

mike3 wrote:
> Hi.
>
> Would this make a good mechanism to securely destroy a hard drive?
>
> 1. Crash the heads into the platters with the drive at top speed
>
> 2. Seek them from one edge of the platters to the other back and forth
> to \
> ensure good grinding
>
> 3. Pump a concentrated hydrogen/oxygen mix into the hard drive platter
> chamber
> while the heads are grinding away.
>
> Would the heat from the grinding be enough to ignite the H2/O2 mix and
> ensure that data can't be recovered? Would this mechanism be good
> enough to keep copies of a large company's trade secrets from a
> competing large company?

Open top of drive. Place open drive in plastic container. Pour in
Coca-cola so drive is immersed. Leave for 4 days.
E.

1. Open drive.
2. Remove platter(s)
3. Insert and ignite thermite. Or if you have access to an
appropriate grinder, powder it.

You're not likely to be able to force heads into contact in a
modern drive at all, certainly not for an extended period,
without opening it up. Once you open it, just grind or fry the
thing. No explosive gases to contend with, just aluminum and
rust powders and an igniter. And of course a safe disposal issue.

Unless you physically destroy the recording medium common
laboratory tools can recover information. Various erasure
patterns can do a very good job of protecting data from most
recovery methods and of course very minor physical damage will
stop a "normal" read, but there is no way to ensure complete
erasure even against a standard university electronics lab, let
alone someone with access to significant time and resources.

E. wrote:
> mike3 wrote:
>
>> Hi.
>>
>> Would this make a good mechanism to securely destroy a hard drive?
>>
>> 1. Crash the heads into the platters with the drive at top speed
>>
>> 2. Seek them from one edge of the platters to the other back and forth
>> to \
>> ensure good grinding
>>
>> 3. Pump a concentrated hydrogen/oxygen mix into the hard drive platter
>> chamber
>> while the heads are grinding away.
>>
>> Would the heat from the grinding be enough to ignite the H2/O2 mix and
>> ensure that data can't be recovered? Would this mechanism be good
>> enough to keep copies of a large company's trade secrets from a
>> competing large company?
>
>
> Open top of drive. Place open drive in plastic container. Pour in
> Coca-cola so drive is immersed. Leave for 4 days.
> E.

In article <1d54b7e4.0411251822.729ae8cc [at] posting.google.com>, mike3 wrote:

>Would this make a good mechanism to securely destroy a hard drive?
>
>1. Crash the heads into the platters with the drive at top speed

Modern (since the early 1990s) hard drives have a very hard and smooth
surface on the platters. Crashes do occur in real life, and normally
cause no harm. "Top speed" implies the disk powered up and running
normally (heads NOT parked). How do you propose to cause the 50+Gs to
crash the heads while in this condition? Hard drives have gotten a lot
more resilient since Reynold Johnson's "baloney slicer" system in 1956.

>2. Seek them from one edge of the platters to the other back and forth
>to \
> ensure good grinding

See above. Every time you power down a drive, you "crash" the heads
(admittedly at a slower speed) - how much damage to the heads does that
cause? To the media?

>3. Pump a concentrated hydrogen/oxygen mix into the hard drive platter
>chamber
> while the heads are grinding away.

If you are going to be cracking the case (airflow through the vent is
meant to equalize pressures, not cause an air exchange), why not open
it up the rest of the way, and yank the platters so that you can put
them directly in a fire and melt them.

>Would the heat from the grinding be enough to ignite the H2/O2 mix and
>ensure that data can't be recovered?

No. Not enough energy in the H2/O2 that would remain in a typical hard
disk without exploding and blowing open the case. Such an explosion
might damage the drive to make it unusable, but wouldn't damage the media
enough to preclude data recovery.

>Would this mechanism be good enough to keep copies of a large company's
>trade secrets from a competing large company?

No.

1. Go find a recent copy of a hardware book such as Scott Mueller's
"Upgrading and Repairing PCs" from Que, Roche's "Hardware Bible", and
learn about hard disk construction.

2. http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html for a
classic paper on removing information from computer disks.

Old guy

In article <41a7863c$1 [at] news.velocitynet.com.au>, E. wrote:
>mike3 wrote:

>> Would this make a good mechanism to securely destroy a hard drive?

>Open top of drive. Place open drive in plastic container. Pour in
>Coca-cola so drive is immersed. Leave for 4 days.

HEY!!! Then what are you going to do with that toxic waste afterwards?

(I know that was in jest - Coke isn't a strong enough acid to do the job.
Even soaking the platters in "swimming pool acid" [used to adjust the pH
of the pool water] for a week isn't reliable.) When in doubt - use explosives.

Old guy

In article <slrncqfbjh.fl0.ibuprofin [at] compton.phx.az.us>,
Moe Trin <no.mail.accepted.sorry> wrote:
:>Would the heat from the grinding be enough to ignite the H2/O2 mix and
:>ensure that data can't be recovered?

:No. Not enough energy in the H2/O2 that would remain in a typical hard
:disk without exploding and blowing open the case. Such an explosion
:might damage the drive to make it unusable, but wouldn't damage the media
:enough to preclude data recovery.

See my previous posting on this topic; I gave the concentrations at
which hydrogen will burn instead of exploding. Low concentration would
probably be better, as the relative concentration of hydrogen
would at worst go lower and stop the burning; if one went for the
high concentration of hydrogen side of the curve, then one runs the
risk that the burning of the hydrogen will change the relative
concentrations to the point that an explosion would start.
--
"Mathematics? I speak it like a native." -- Spike Milligan

In article <slrncqfbjh.fl0.ibuprofin [at] compton.phx.az.us>,
Moe Trin <no.mail.accepted.sorry> wrote:
>In article <1d54b7e4.0411251822.729ae8cc [at] posting.google.com>, mike3 wrote:
>
>>Would this make a good mechanism to securely destroy a hard drive?
>>
>>1. Crash the heads into the platters with the drive at top speed
>
>Modern (since the early 1990s) hard drives have a very hard and smooth
>surface on the platters. Crashes do occur in real life, and normally
>cause no harm. "Top speed" implies the disk powered up and running
>normally (heads NOT parked). How do you propose to cause the 50+Gs to
>crash the heads while in this condition? Hard drives have gotten a lot
>more resilient since Reynold Johnson's "baloney slicer" system in 1956.
>
>>2. Seek them from one edge of the platters to the other back and forth
>>to \
>> ensure good grinding
>
>See above. Every time you power down a drive, you "crash" the heads
>(admittedly at a slower speed) - how much damage to the heads does that
>cause? To the media?
>
>>3. Pump a concentrated hydrogen/oxygen mix into the hard drive platter
>>chamber
>> while the heads are grinding away.
>
>If you are going to be cracking the case (airflow through the vent is
>meant to equalize pressures, not cause an air exchange), why not open
>it up the rest of the way, and yank the platters so that you can put
>them directly in a fire and melt them.
>
>>Would the heat from the grinding be enough to ignite the H2/O2 mix and
>>ensure that data can't be recovered?
>
>No. Not enough energy in the H2/O2 that would remain in a typical hard
>disk without exploding and blowing open the case. Such an explosion
>might damage the drive to make it unusable, but wouldn't damage the media
>enough to preclude data recovery.
>
>>Would this mechanism be good enough to keep copies of a large company's
>>trade secrets from a competing large company?
>
>No.
>
>1. Go find a recent copy of a hardware book such as Scott Mueller's
>"Upgrading and Repairing PCs" from Que, Roche's "Hardware Bible", and
>learn about hard disk construction.
>
>2. http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html for a
>classic paper on removing information from computer disks.
>
> Old guy
>


An interetesting paper, but it's dated 1996 and has to reflect the
disks that were shipping then. Today's disks have about 100x the data
density (GB/sq inch) and it has to change how much erased data can be
read. I've nver seen this discussed, but I bet it's lots harder to
read data that's been overwritten.

--
a d y k e s [at] p a n i x . c o m
----

mike3 <mike4ty4 [at] yahoo.com> wrote:
> Hi.

> Would this make a good mechanism to securely destroy a hard drive?

> 1. Crash the heads into the platters with the drive at top speed

> 2. Seek them from one edge of the platters to the other back and forth
> to \
> ensure good grinding

> 3. Pump a concentrated hydrogen/oxygen mix into the hard drive platter
> chamber
> while the heads are grinding away.

> Would the heat from the grinding be enough to ignite the H2/O2 mix and
> ensure that data can't be recovered? Would this mechanism be good
> enough to keep copies of a large company's trade secrets from a
> competing large company?

The simplest low-tech method is to take the platters out and apply
$2 disk sander with coarse paper in an electric drill to them, then
bend them in half.

--
Jim Pennino

Remove -spam-sux to reply.

jimp [at] specsol-spam-sux.com wrote:
> mike3 <mike4ty4 [at] yahoo.com> wrote:
>
>>Hi.
>
>
>>Would this make a good mechanism to securely destroy a hard drive?
>
>
>>1. Crash the heads into the platters with the drive at top speed
>
>
>>2. Seek them from one edge of the platters to the other back and forth
>>to \
>> ensure good grinding
>
>
>>3. Pump a concentrated hydrogen/oxygen mix into the hard drive platter
>>chamber
>> while the heads are grinding away.
>
>
>>Would the heat from the grinding be enough to ignite the H2/O2 mix and
>>ensure that data can't be recovered? Would this mechanism be good
>>enough to keep copies of a large company's trade secrets from a
>>competing large company?
>
>
> The simplest low-tech method is to take the platters out and apply
> $2 disk sander with coarse paper in an electric drill to them, then
> bend them in half.

Next time you could use the $0 method: store sensitive data in encrypted
files or partitions. Physical destruction won't be necessary.

-- Lassi

ibuprofin [at] painkiller.example.tld (Moe Trin) wrote in message news:<slrncqfbjh.fl0.ibuprofin [at] compton.phx.az.us>...
> In article <1d54b7e4.0411251822.729ae8cc [at] posting.google.com>, mike3 wrote:
>
> >Would this make a good mechanism to securely destroy a hard drive?
> >
> >1. Crash the heads into the platters with the drive at top speed
>
> Modern (since the early 1990s) hard drives have a very hard and smooth
> surface on the platters. Crashes do occur in real life, and normally
> cause no harm. "Top speed" implies the disk powered up and running
> normally (heads NOT parked). How do you propose to cause the 50+Gs to
> crash the heads while in this condition? Hard drives have gotten a lot
> more resilient since Reynold Johnson's "baloney slicer" system in 1956.
>

Well, you would have to install the mechanism in a very good clean
room as you would have to open up the drive. My idea would be
something that applies direct pressure to the heads -- shouldn't be
too difficult to make. The point of the destruct system is when you no
longer have physical access to the drive to destroy it with "by hand"
methods -- such as when teh computer's been stolen.

> >2. Seek them from one edge of the platters to the other back and forth
> >to \
> > ensure good grinding
>
> See above. Every time you power down a drive, you "crash" the heads
> (admittedly at a slower speed) - how much damage to the heads does that
> cause? To the media?
>

You 'land' the heads -- they 'park' off the media. 'Crashing' the
heads means that you drop them onto the platter directly when it's
spinnig at top speed.

> >3. Pump a concentrated hydrogen/oxygen mix into the hard drive platter
> >chamber
> > while the heads are grinding away.
>
> If you are going to be cracking the case (airflow through the vent is
> meant to equalize pressures, not cause an air exchange), why not open
> it up the rest of the way, and yank the platters so that you can put
> them directly in a fire and melt them.
>

You keep missing the point -- I'm talking about installing a *self
destruct mechanism* to destroy the hard drive remotely when physical
access has been lost. All you'd need to star thte mechaism would be
just to broadcast the specific code that that particular drive
recognizes over a great distance, and you could neutralize the drive.



> >Would the heat from the grinding be enough to ignite the H2/O2 mix and
> >ensure that data can't be recovered?
>
> No. Not enough energy in the H2/O2 that would remain in a typical hard
> disk without exploding and blowing open the case. Such an explosion
> might damage the drive to make it unusable, but wouldn't damage the media
> enough to preclude data recovery.
>
> >Would this mechanism be good enough to keep copies of a large company's
> >trade secrets from a competing large company?
>
> No.
>
> 1. Go find a recent copy of a hardware book such as Scott Mueller's
> "Upgrading and Repairing PCs" from Que, Roche's "Hardware Bible", and
> learn about hard disk construction.
>
> 2. http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html for a
> classic paper on removing information from computer disks.
>
> Old guy


So, what would you need for a secure _self destruct_ mechanism? That
means, to DESTROY the disk by COMMAND CODES. How about a chemical
destruction mechanism? You'd have two chemicals on either side of the
drive, which are normally inert, but when they mix, become a highly
corrosive brew that eats the metal of a hard drive. Then all you have
to do is have the drive in a sealed bay with the chemicals on each
side. Once the proper command is recieved, the chemicals would pour
into where the drive is, destroying it. The problem: Does anyone know
if there's any chemicals that do that?

mike3 wrote:
<snip>
>
> So, what would you need for a secure _self destruct_ mechanism? That
> means, to DESTROY the disk by COMMAND CODES. How about a chemical
> destruction mechanism? You'd have two chemicals on either side of the
> drive, which are normally inert, but when they mix, become a highly
> corrosive brew that eats the metal of a hard drive. Then all you have
> to do is have the drive in a sealed bay with the chemicals on each
> side. Once the proper command is recieved, the chemicals would pour
> into where the drive is, destroying it. The problem: Does anyone know
> if there's any chemicals that do that?



Thermite


JM

mike3 <mike4ty4 [at] yahoo.com> wrote:
[deleted]
> You keep missing the point -- I'm talking about installing a *self
> destruct mechanism* to destroy the hard drive remotely when physical
> access has been lost. All you'd need to star thte mechaism would be
> just to broadcast the specific code that that particular drive
> recognizes over a great distance, and you could neutralize the drive.

Nobody is "missing the point"! (In your OP) You never said you were
talking about a *self* destruct system. Perhaps you were thinking that,
but you didn't write any such thing. So perhaps before criticizing
someone for "missing the point", you should check what you actually
wrote? (And instead apologize for wasting everybodies time?)

[deleted]

In article <co9dgu$t1d$1 [at] nyytiset.pp.htv.fi>,
=?ISO-8859-15?Q?Lassi_Hippeläinen?=
<lahippel [at] IEEE.ORGasm-research.invalid> wrote:
:Next time you could use the $0 method: store sensitive data in encrypted
:files or partitions. Physical destruction won't be necessary.

Yeh, provide the attacker with a very large base of known
plaintext / cryptotext pairs [the operating system, the filesystem
table, headers for known document types], and give the attacker
unlimited access and time to make the attempt. That'll stay secure
for sure.
--
Look out, there are llamas!

In article <1d54b7e4.0411270117.2b333870 [at] posting.google.com>,
mike3 <mike4ty4 [at] yahoo.com> wrote:
:You keep missing the point -- I'm talking about installing a *self
:destruct mechanism* to destroy the hard drive remotely when physical
:access has been lost.

There was no mention of self-destruct mechanisms in the original posting.

If you were to use try to use the original proposal as a self-destruct
mechanism, then the hydrogen + oxygen mixture would have to be already
present in the drive in order for it to be ignited. Drives normally
operate a ambient pressures, and normally have a pressure equalization
vent (with particle filter), so if you were to create a drive with a
significant fraction of hydrogen internally, the H2 [being pretty much
the smallest gas around] would leak out in fairly short order, and that
couldn't be stopped without disabling the equalization vent.

If the hydrogen gas were permanently present, you'd also have issues
about hydrogen creep into the materials of the drive [hydrogen
penetrates into lots of materials, changing their chemical structures
and thus mechanical properties], and hydrogen combining with the
driveshaft lubricants, which would likely get you a nicely hydrogenated
lubricant with longer chain molecules and a much higher viscosity,
which would cause problems.

Thus, for the scheme to work, the hydrogen (and some oxygen, in case
the other company put the drive into a container of nitrogen or other
non-flamable gas) would have to be present in the drive but sealed
away until the self-destruct sequence began, and then would have to
be released into the drive over a fairly short period, filling the
drive but not enough time to vent out. That implies that the gasses
would have to be kept in a fairly small container under pressure,
and would expand into the larger container that was the drive platter
area. There's a small problem with this scheme, though: expanding
gasses are *cold*, which is not exactly what you want to hear when
you are trying to have the scheme heat the platters beyond their
Curie point.

And of course, nothing about the scheme works if the attacking
company just puts the drive in a clean room and opens it up,
in which case the expanding gas would have a very large container to
fill, leading to a hydrogen concentration too low to burn.


:All you'd need to star thte mechaism would be
:just to broadcast the specific code that that particular drive
:recognizes over a great distance, and you could neutralize the drive.

For a good self-destruct system, you don't want the attacker to
have a chance to neutralize the destruct mechanisms, so you would
want a "deadman's switch" -- you would want the destruct mechanism
set to go off if the drive -stopped- receiving a coded (and non-
periodic) signal. And hope the power doesn't go out to the systems
that broadcast the "everything's okay" signal ;-)
--
"Infinity is like a stuffed walrus I can hold in the palm of my hand.
Don't do anything with infinity you wouldn't do with a stuffed walrus."
-- Dr. Fletcher, Va. Polytechnic Inst. and St. Univ.

In article <1d54b7e4.0411270117.2b333870 [at] posting.google.com>,
mike3 <mike4ty4 [at] yahoo.com> wrote:
>ibuprofin [at] painkiller.example.tld (Moe Trin) wrote in message news:<slrncqfbjh.fl0.ibuprofin [at] compton.phx.az.us>...
>> In article <1d54b7e4.0411251822.729ae8cc [at] posting.google.com>, mike3 wrote:
>>
>> >Would this make a good mechanism to securely destroy a hard drive?
>> >
>> >1. Crash the heads into the platters with the drive at top speed
>>
>> Modern (since the early 1990s) hard drives have a very hard and smooth
>> surface on the platters. Crashes do occur in real life, and normally
>> cause no harm. "Top speed" implies the disk powered up and running
>> normally (heads NOT parked). How do you propose to cause the 50+Gs to
>> crash the heads while in this condition? Hard drives have gotten a lot
>> more resilient since Reynold Johnson's "baloney slicer" system in 1956.
>>
>
>Well, you would have to install the mechanism in a very good clean
>room as you would have to open up the drive. My idea would be
>something that applies direct pressure to the heads -- shouldn't be
>too difficult to make. The point of the destruct system is when you no
>longer have physical access to the drive to destroy it with "by hand"
>methods -- such as when teh computer's been stolen.
>
>> >2. Seek them from one edge of the platters to the other back and forth
>> >to \
>> > ensure good grinding
>>
>> See above. Every time you power down a drive, you "crash" the heads
>> (admittedly at a slower speed) - how much damage to the heads does that
>> cause? To the media?
>>
>
>You 'land' the heads -- they 'park' off the media. 'Crashing' the
>heads means that you drop them onto the platter directly when it's
>spinnig at top speed.
>
>> >3. Pump a concentrated hydrogen/oxygen mix into the hard drive platter
>> >chamber
>> > while the heads are grinding away.
>>
>> If you are going to be cracking the case (airflow through the vent is
>> meant to equalize pressures, not cause an air exchange), why not open
>> it up the rest of the way, and yank the platters so that you can put
>> them directly in a fire and melt them.
>>
>
>You keep missing the point -- I'm talking about installing a *self
>destruct mechanism* to destroy the hard drive remotely when physical
>access has been lost. All you'd need to star thte mechaism would be
>just to broadcast the specific code that that particular drive
>recognizes over a great distance, and you could neutralize the drive.
>
>
>
>> >Would the heat from the grinding be enough to ignite the H2/O2 mix and
>> >ensure that data can't be recovered?
>>
>> No. Not enough energy in the H2/O2 that would remain in a typical hard
>> disk without exploding and blowing open the case. Such an explosion
>> might damage the drive to make it unusable, but wouldn't damage the media
>> enough to preclude data recovery.
>>
>> >Would this mechanism be good enough to keep copies of a large company's
>> >trade secrets from a competing large company?
>>
>> No.
>>
>> 1. Go find a recent copy of a hardware book such as Scott Mueller's
>> "Upgrading and Repairing PCs" from Que, Roche's "Hardware Bible", and
>> learn about hard disk construction.
>>
>> 2. http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html for a
>> classic paper on removing information from computer disks.
>>
>> Old guy
>
>
>So, what would you need for a secure _self destruct_ mechanism? That
>means, to DESTROY the disk by COMMAND CODES. How about a chemical
>destruction mechanism? You'd have two chemicals on either side of the
>drive, which are normally inert, but when they mix, become a highly
>corrosive brew that eats the metal of a hard drive. Then all you have
>to do is have the drive in a sealed bay with the chemicals on each
>side. Once the proper command is recieved, the chemicals would pour
>into where the drive is, destroying it. The problem: Does anyone know
>if there's any chemicals that do that?

On a much more practical level, there are encrypted file systems, and
NTFS has an encryption option. Properly administered, data on these
machines will be useless to the bad Guys.

I've seen a descrtption of miniscule explosive charges that are stuck
to the top of electronics chips and wired under software control. When
the charge goes off the chip is completely destroyed. If that chip
happened to contain the crypto keys for the data on the disk, then
your data is gone gone gone.

I believe IBM makes (or made) laptop hard disks that did encryption on
the drive electronics, and the driver software asked the user for a
PIN code before the laptop could boot up. If the user forgot his PIN
and called IBM, all they could do is to reformat the disk. No james
Bond stuff required.









--
a d y k e s [at] p a n i x . c o m
----

In article <coane4$3li$1 [at] panix5.panix.com>, Al Dykes <adykes [at] panix.com> wrote:
:I believe IBM makes (or made) laptop hard disks that did encryption on
:the drive electronics, and the driver software asked the user for a
:PIN code before the laptop could boot up. If the user forgot his PIN
:and called IBM, all they could do is to reformat the disk. No james
:Bond stuff required.

I don't recall the company involved, but the description you give above
matches a product that was out a few years ago and was supposed to be
foolproof. After a while of the device being on the market, someone
managed to figure out a way of booting that allowed the user to
bypass the PIN, thus laying bare the entire drive contents.

I don't recall the details now; the conclusion was along the lines that
the manufacturer didn't actually encrypt the data on the drive itself, it
just made it so that you couldn't get at the plaintext unless you had
the right pin, so when that step was bypassed everything was wide open.


In practice, you can't use a single encryption over a whole drive,
because you have to be able to randomly read or wrote from the middle of
it without having to decrypt everything before that point (read) or
re-encrypt everything after that point (write.) And directory structures
have to be fairly consistant -- you can't even do those separately
from the drive data, as you don't want to have to go through all of
the directory information in order to be able to get at particular files.
Because of these considerations, you end up with a lot of
places on the disk that one has known or easily guessible plaintext for,
and one has to use pretty much the same key over and over again
rather than block chaining over the entire drive; these drawbacks
noticably lower the encryption strength of the overall system.
--
The image data is transmitted back to Earth at the speed of light
and usually at 12 bits per pixel.

In article <coaok5$eb0$1 [at] canopus.cc.umanitoba.ca>,
Walter Roberson <roberson [at] ibd.nrc-cnrc.gc.ca> wrote:
>In article <coane4$3li$1 [at] panix5.panix.com>, Al Dykes <adykes [at] panix.com> wrote:
>:I believe IBM makes (or made) laptop hard disks that did encryption on
>:the drive electronics, and the driver software asked the user for a
>:PIN code before the laptop could boot up. If the user forgot his PIN
>:and called IBM, all they could do is to reformat the disk. No james
>:Bond stuff required.
>
>I don't recall the company involved, but the description you give above
>matches a product that was out a few years ago and was supposed to be
>foolproof. After a while of the device being on the market, someone
>managed to figure out a way of booting that allowed the user to
>bypass the PIN, thus laying bare the entire drive contents.
>
>I don't recall the details now; the conclusion was along the lines that
>the manufacturer didn't actually encrypt the data on the drive itself, it
>just made it so that you couldn't get at the plaintext unless you had
>the right pin, so when that step was bypassed everything was wide open.
>
>
>In practice, you can't use a single encryption over a whole drive,
>because you have to be able to randomly read or wrote from the middle of
>it without having to decrypt everything before that point (read) or
>re-encrypt everything after that point (write.) And directory structures

Offhand I can't see any problem with en/decrypting data in 512 byte
blocks as sectors are read/written to disk. The electronics on the
disk drive can do this, when enabled with a PIN from the user. A
custom BIOS would be necessary to prompt the user for the PIN at boot
time. No PIN, no data. Blow up the chip that has the crypto key in
it and your data's gone.

I've never worked with the IBM system, and it's possible the disk just
has a spin-up password. This would effectivly prevent you and me from
stealing the data, but not stop the Bad Guys that can read data from
platters, assuming that's still possible.



>have to be fairly consistant -- you can't even do those separately
>from the drive data, as you don't want to have to go through all of
>the directory information in order to be able to get at particular files.
>Because of these considerations, you end up with a lot of
>places on the disk that one has known or easily guessible plaintext for,
>and one has to use pretty much the same key over and over again
>rather than block chaining over the entire drive; these drawbacks
>noticably lower the encryption strength of the overall system.
>--
> The image data is transmitted back to Earth at the speed of light
> and usually at 12 bits per pixel.


--
a d y k e s [at] p a n i x . c o m
----

In article <coas47$ijt$1 [at] panix5.panix.com>, Al Dykes <adykes [at] panix.com> wrote:
|In article <coaok5$eb0$1 [at] canopus.cc.umanitoba.ca>,
|Walter Roberson <roberson [at] ibd.nrc-cnrc.gc.ca> wrote:

|>In practice, you can't use a single encryption over a whole drive,
|>because you have to be able to randomly read or wrote from the middle of
|>it without having to decrypt everything before that point (read) or
|>re-encrypt everything after that point (write.) And directory structures

|Offhand I can't see any problem with en/decrypting data in 512 byte
|blocks as sectors are read/written to disk.

If you are using the same key each time, that scheme would suffer
a lot from "known plaintext" attacks. For example,
All blocks of NULLs would encrypt exactly the same way, and
the first 64 bytes of most non-text files would be relatively
consistant amongst filetypes, allowing you a fairly good idea
of what kind of file something was without decrypting it.

--
Is "meme" descriptive or perscriptive? Does the knowledge that
memes exist not subtly encourage the creation of more memes?
-- A Child's Garden Of Memes

adykes [at] panix.com (Al Dykes) writes:

>Offhand I can't see any problem with en/decrypting data in 512 byte
>blocks as sectors are read/written to disk. The electronics on the
>disk drive can do this, when enabled with a PIN from the user. A
>custom BIOS would be necessary to prompt the user for the PIN at boot
>time. No PIN, no data. Blow up the chip that has the crypto key in
>it and your data's gone.

>I've never worked with the IBM system, and it's possible the disk just
>has a spin-up password. This would effectivly prevent you and me from
>stealing the data, but not stop the Bad Guys that can read data from
>platters, assuming that's still possible.

As far as I know, the IBM drives have a spin-up password; they cannot
be recovered, the IBM documentation says:

"If you forget your hard disk password, there is no way to reset your
password or recover data in the hard disk drive. Neither an IBM
authorized reseller nor IBM marketing representative can make the hard
disk drive usable."

Some people take hardware security seriously.

But there are companies claiming to be capable of recovery:

http://www.nortek.on.ca/hard_disk_password.html

The data is not likely to be encrypted; such encryption would slow
the drives down considerably and would probably have export control
consequences which IBM could do well without at the time it originally
started shipping the drives.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

roberson [at] ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

>|Offhand I can't see any problem with en/decrypting data in 512 byte
>|blocks as sectors are read/written to disk.

>If you are using the same key each time, that scheme would suffer
>a lot from "known plaintext" attacks. For example,
>All blocks of NULLs would encrypt exactly the same way, and
>the first 64 bytes of most non-text files would be relatively
>consistant amongst filetypes, allowing you a fairly good idea
>of what kind of file something was without decrypting it.

Right; but for random access disks "CBC" mode is not possible
unless you can be sure that all accesses will be of equal size
and on the appropriate boundaries. Or you would need to reset the
IV every 512 bytes (which still doesn't help much).

AES CTR (counter) mode is much more promissing; this basically turns
AES into a Random number generator with a different random number
for each encrypted block:

Encrypt(Key, Nonce + Counter) Xor^ Plaintext

where Nonce is a random but fixed number and Counter is the block
index (block cipher blocks, not disk blocks)

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

In article <41a9d01d$0$78749$e4fe514c [at] news.xs4all.nl>,
Casper H.S. Dik <Casper.Dik [at] Sun.COM> wrote:
:Right; but for random access disks "CBC" mode is not possible
:unless you can be sure that all accesses will be of equal size
:and on the appropriate boundaries. Or you would need to reset the
:IV every 512 bytes (which still doesn't help much).

That's pretty much what I said ;-)


:AES CTR (counter) mode is much more promissing; this basically turns
:AES into a Random number generator with a different random number
:for each encrypted block:

: Encrypt(Key, Nonce + Counter) Xor^ Plaintext

:where Nonce is a random but fixed number and Counter is the block
:index (block cipher blocks, not disk blocks)

How would you know the proper nonce and counter to use for
any particular disk block? You have distinguished between the
nonce and the key, so either "nonce + counter" is calculated by
a constant formula for any given disk block, or else the user
would have to enter two "keys", one of which is really the nonce.

Recall that this isn't a message transmission stream where a nonce
can be generated and security interchanged during the authentication
phase.

If "nonce + counter" is calculated by a constant formula for any
particular disk sector, then if the attacker can get access to
the system while it is operational with the valid key, they can
read the encrypted contents of a disk block and then have the system
write the block with known contents (e.g., all blanks.) They would
then read off the encrypted result and xor it with the contents
they knew they wrote there, and that would give them
the Encrypt(Key, Nonce + Counter) that was valid for that disk block.
They would take that value and xor it with the previously recorded
encrypted contents, and the result they would get back would be
the original unencrypted content of the block.

Further to this: if the attackers can gain read access to the encrypted
drive even when it is not writing under the aegis of the appropriate
key, they can image the disk and withdraw. At a later time when
some interesting information has been written to the disk, they can
come back and re-image it. If they then xor the two recorded images,
the Encrypt(Key, Nonce + Counter) for each disk block will cancel
out, leaving them with the xor of the changes to the drive contents.
In any block in which the original plaintext content was NULLs
[e.g. because nothing had been written there yet], the new disk
block content after the series of xor's will be the plaintext of the
new disk block contents; similarily, in any block in which the
original plaintext content was not null but was overwritten with NULLs
[e.g., because the block was released from use], the new disk block
content after the series of xor's will be the plaintext of the
original block contents.

Casper H.S. Dik <Casper.Dik [at] Sun.COM> writes:

]adykes [at] panix.com (Al Dykes) writes:


]As far as I know, the IBM drives have a spin-up password; they cannot
]be recovered, the IBM documentation says:

] "If you forget your hard disk password, there is no way to reset your
] password or recover data in the hard disk drive. Neither an IBM
] authorized reseller nor IBM marketing representative can make the hard
] disk drive usable."

Of course they would say that, if it were true or not. And the chances of
an authorized reseller or a marketing representative being able to
technically carry out the task is zero. Note that they do not say that IBM
is unable to do it. This is like saying-- our floorcleaners are not
authorized to fix your computer.

]Some people take hardware security seriously.

No-- some people take disingenuous advertising copy seriously.

roberson [at] ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

]In article <coas47$ijt$1 [at] panix5.panix.com>, Al Dykes <adykes [at] panix.com> wrote:
]|In article <coaok5$eb0$1 [at] canopus.cc.umanitoba.ca>,
]|Walter Roberson <roberson [at] ibd.nrc-cnrc.gc.ca> wrote:

]|>In practice, you can't use a single encryption over a whole drive,
]|>because you have to be able to randomly read or wrote from the middle of
]|>it without having to decrypt everything before that point (read) or
]|>re-encrypt everything after that point (write.) And directory structures

]|Offhand I can't see any problem with en/decrypting data in 512 byte
]|blocks as sectors are read/written to disk.

]If you are using the same key each time, that scheme would suffer
]a lot from "known plaintext" attacks. For example,
]All blocks of NULLs would encrypt exactly the same way, and
]the first 64 bytes of most non-text files would be relatively
]consistant amongst filetypes, allowing you a fairly good idea
]of what kind of file something was without decrypting it.


A lot less than if it was in the clear. And if they used a chaining scheme
even the nulls would not encrypt the same way.
C_i=Crypt(C_(i-1)^M_i), M_i= DeCrypt(C_i)^C_(i-1).
Most crypto schemes are
specifically designed to resist known plaintext attacks.

In article <cod6ph$o3$1 [at] nntp.itservices.ubc.ca>,
Bill Unruh <unruh [at] string.physics.ubc.ca> wrote:
>Casper H.S. Dik <Casper.Dik [at] Sun.COM> writes:
>
>]adykes [at] panix.com (Al Dykes) writes:
>
>
>]As far as I know, the IBM drives have a spin-up password; they cannot
>]be recovered, the IBM documentation says:
>
>] "If you forget your hard disk password, there is no way to reset your
>] password or recover data in the hard disk drive. Neither an IBM
>] authorized reseller nor IBM marketing representative can make the hard
>] disk drive usable."
>
>Of course they would say that, if it were true or not. And the chances of
>an authorized reseller or a marketing representative being able to
>technically carry out the task is zero. Note that they do not say that IBM
>is unable to do it. This is like saying-- our floorcleaners are not
>authorized to fix your computer.
>
>]Some people take hardware security seriously.
>
>No-- some people take disingenuous advertising copy seriously.
>
>

"there is no way to reset your password or recover data.."

Sounds pretty clear to me.

What motivation would IBM have to lie about this ? If they had the
capaility to recover data and used it for some customer the fact would
get out and they'd look like fools, and the other corproate customers
that bought these systems would be looking for another brand, on the
spot.

--
a d y k e s [at] p a n i x . c o m
----

roberson [at] ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:


]:AES CTR (counter) mode is much more promissing; this basically turns
]:AES into a Random number generator with a different random number
]:for each encrypted block:

]: Encrypt(Key, Nonce + Counter) Xor^ Plaintext

]:where Nonce is a random but fixed number and Counter is the block
]:index (block cipher blocks, not disk blocks)

]How would you know the proper nonce and counter to use for
]any particular disk block? You have distinguished between the

Nonce = general for disk. Counter= block number.

]nonce and the key, so either "nonce + counter" is calculated by
]a constant formula for any given disk block, or else the user
]would have to enter two "keys", one of which is really the nonce.

encrypt(encrypt(key,Nonce+counter)XOR plaintext)
or probably even just
encrypt(key, counter XOR plaintext)

]Recall that this isn't a message transmission stream where a nonce
]can be generated and security interchanged during the authentication
]phase.

]If "nonce + counter" is calculated by a constant formula for any
]particular disk sector, then if the attacker can get access to
]the system while it is operational with the valid key, they can
]read the encrypted contents of a disk block and then have the system
]write the block with known contents (e.g., all blanks.) They would
]then read off the encrypted result and xor it with the contents
]they knew they wrote there, and that would give them
]the Encrypt(Key, Nonce + Counter) that was valid for that disk block.
]They would take that value and xor it with the previously recorded
]encrypted contents, and the result they would get back would be
]the original unencrypted content of the block.

]Further to this: if the attackers can gain read access to the encrypted
]drive even when it is not writing under the aegis of the appropriate
]key, they can image the disk and withdraw. At a later time when
]some interesting information has been written to the disk, they can
]come back and re-image it. If they then xor the two recorded images,
]the Encrypt(Key, Nonce + Counter) for each disk block will cancel
]out, leaving them with the xor of the changes to the drive contents.
]In any block in which the original plaintext content was NULLs
][e.g. because nothing had been written there yet], the new disk
]block content after the series of xor's will be the plaintext of the
]new disk block contents; similarily, in any block in which the
]original plaintext content was not null but was overwritten with NULLs
][e.g., because the block was released from use], the new disk block
]content after the series of xor's will be the plaintext of the
]original block contents.

adykes [at] panix.com (Al Dykes) writes:

]In article <cod6ph$o3$1 [at] nntp.itservices.ubc.ca>,
]Bill Unruh <unruh location:string.physics.ubc.ca> wrote:
]>Casper H.S. Dik <Casper.Dik [at] Sun.COM> writes:
]>
]>]adykes [at] panix.com (Al Dykes) writes:
]>
]>
]>]As far as I know, the IBM drives have a spin-up password; they cannot
]>]be recovered, the IBM documentation says:
]>
]>] "If you forget your hard disk password, there is no way to reset your
]>] password or recover data in the hard disk drive. Neither an IBM
]>] authorized reseller nor IBM marketing representative can make the hard
]>] disk drive usable."
]>
]>Of course they would say that, if it were true or not. And the chances of
]>an authorized reseller or a marketing representative being able to
]>technically carry out the task is zero. Note that they do not say that IBM
]>is unable to do it. This is like saying-- our floorcleaners are not
]>authorized to fix your computer.
]>
]>]Some people take hardware security seriously.
]>
]>No-- some people take disingenuous advertising copy seriously.
]>
]>

]"there is no way to reset your password or recover data.."

No, the context is "If you forget.." and that can be interpreted as "no way
you can.." Their next sentence negates teh generality of the former. To
state that there an "IBM marketing representative" cannot reset your
password is like my statement about floor cleaners. I would not expect my
marketing representative to be able to do it, unless it were completely
trivial. As I said, without further evidence I regard this statement as
deliberately disingenuous.

And if they did do it for someone, they would almost certainly demand they
sign a non-disclosure agreement before they did it.



]Sounds pretty clear to me.

]What motivation would IBM have to lie about this ? If they had the
]capaility to recover data and used it for some customer the fact would
]get out and they'd look like fools, and the other corproate customers
]that bought these systems would be looking for another brand, on the
]spot.

]--
]a d y k e s [at] p a n i x . c o m
]----

unruh location:string.physics.ubc.ca (Bill Unruh) writes:

]adykes [at] panix.com (Al Dykes) writes:
]]What motivation would IBM have to lie about this ? If they had the
]]capaility to recover data and used it for some customer the fact would
]]get out and they'd look like fools, and the other corproate customers
]]that bought these systems would be looking for another brand, on the
]]spot.

Motivation? How about the govenment-- "Make damn sure that you build in a
password recovery system that we can use, or watch all your gov't contracts
disappear". I would say that the probability of password recovery is 100%.

In article <cod8kl$1eq$1 [at] nntp.itservices.ubc.ca>,
Bill Unruh <unruh [at] string.physics.ubc.ca> wrote:
>unruh location:string.physics.ubc.ca (Bill Unruh) writes:
>
>]adykes [at] panix.com (Al Dykes) writes:
>]]What motivation would IBM have to lie about this ? If they had the
>]]capaility to recover data and used it for some customer the fact would
>]]get out and they'd look like fools, and the other corproate customers
>]]that bought these systems would be looking for another brand, on the
>]]spot.
>
>Motivation? How about the govenment-- "Make damn sure that you build in a
>password recovery system that we can use, or watch all your gov't contracts
>disappear". I would say that the probability of password recovery is 100%.
>
>


Yes, there might be a back door but part of the agreement would be to
_NEVER_ admit it to the customer.

If you are in a business where you have to worry about Men In Black
reading your data you've got lots of things to worry about and need
layers of defense. A keystroke sniffer could give them your PIN and
they'd be able to read your data without the backdoor.








--
a d y k e s [at] p a n i x . c o m
----

In article <cod72v$ub$1 [at] nntp.itservices.ubc.ca>,
Bill Unruh <unruh [at] string.physics.ubc.ca> wrote:
:roberson [at] ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

:]If you are using the same key each time, that scheme would suffer
:]a lot from "known plaintext" attacks. For example,
:]All blocks of NULLs would encrypt exactly the same way, and
:]the first 64 bytes of most non-text files would be relatively
:]consistant amongst filetypes, allowing you a fairly good idea
:]of what kind of file something was without decrypting it.


:A lot less than if it was in the clear. And if they used a chaining scheme
:even the nulls would not encrypt the same way.
:C_i=Crypt(C_(i-1)^M_i), M_i= DeCrypt(C_i)^C_(i-1).

Using a chaining scheme would be tricky to mesh in with random
access, particularily if the encryption was being handled at the
hardware level (which doesn't know the role of any particular block.)


:Most crypto schemes are
:specifically designed to resist known plaintext attacks.

But this isn't "most crypto schemes" that we are talking about:
we are talking about a system that essentially has to treat
each 512 byte block separately.

Walter Roberson wrote:
>
> In article <co9dgu$t1d$1 [at] nyytiset.pp.htv.fi>,
> =?ISO-8859-15?Q?Lassi_Hippeläinen?=
> <lahippel [at] IEEE.ORGasm-research.invalid> wrote:
> :Next time you could use the $0 method: store sensitive data in encrypted
> :files or partitions. Physical destruction won't be necessary.
>
> Yeh, provide the attacker with a very large base of known
> plaintext / cryptotext pairs [the operating system, the filesystem
> table, headers for known document types], and give the attacker
> unlimited access and time to make the attempt. That'll stay secure
> for sure.
> --
> Look out, there are llamas!

Modern ciphers *are* resistant to known plaintext attacks.

-- Lassi

roberson [at] ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

>How would you know the proper nonce and counter to use for
>any particular disk block? You have distinguished between the
>nonce and the key, so either "nonce + counter" is calculated by
>a constant formula for any given disk block, or else the user
>would have to enter two "keys", one of which is really the nonce.

The "nonce" is part of the key but used differently in the
algorithm, just like the initial IV is a part of the
key in some algorithms; the counter would be derived from the
address which presumably is always the same for the same
block of the disk.

>Recall that this isn't a message transmission stream where a nonce
>can be generated and security interchanged during the authentication
>phase.

No, it's indeed part of the key.

>If "nonce + counter" is calculated by a constant formula for any
>particular disk sector, then if the attacker can get access to
>the system while it is operational with the valid key, they can
>read the encrypted contents of a disk block and then have the system
>write the block with known contents (e.g., all blanks.) They would
>then read off the encrypted result and xor it with the contents
>they knew they wrote there, and that would give them
>the Encrypt(Key, Nonce + Counter) that was valid for that disk block.
>They would take that value and xor it with the previously recorded
>encrypted contents, and the result they would get back would be
>the original unencrypted content of the block.

I would assume that an attacker who get access to a system which is
operating and keyed with proper key+nonce can always read the
disk content be accessing it through the proper (decrypting) way.

If you can get the system to write an encrypted block, surely you
can get them to read it too?

>Further to this: if the attackers can gain read access to the encrypted
>drive even when it is not writing under the aegis of the appropriate
>key, they can image the disk and withdraw. At a later time when
>some interesting information has been written to the disk, they can
>come back and re-image it. If they then xor the two recorded images,
>the Encrypt(Key, Nonce + Counter) for each disk block will cancel
>out, leaving them with the xor of the changes to the drive contents.
>In any block in which the original plaintext content was NULLs
>[e.g. because nothing had been written there yet], the new disk
>block content after the series of xor's will be the plaintext of the
>new disk block contents; similarily, in any block in which the
>original plaintext content was not null but was overwritten with NULLs
>[e.g., because the block was released from use], the new disk block
>content after the series of xor's will be the plaintext of the
>original block contents.

If you can observe the encrypted contents of a system, it is likely
that you can also observe much more, such as key material used and so on.

There is protection offered against disks or computeres stolen.


Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

unruh [at] string.physics.ubc.ca (Bill Unruh) writes:

>]Some people take hardware security seriously.

>No-- some people take disingenuous advertising copy seriously.

There's a difference between "there's a password and we don't know
how to get around it without using serious tools". And there's a BIOS
password but there's also a backdoor password.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

In article <41ab2f4d$0$65124$e4fe514c [at] news.xs4all.nl>,
Casper H.S. Dik <Casper.Dik [at] Sun.COM> wrote:
>roberson [at] ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
>
>>How would you know the proper nonce and counter to use for
>>any particular disk block? You have distinguished between the
>>nonce and the key, so either "nonce + counter" is calculated by
>>a constant formula for any given disk block, or else the user
>>would have to enter two "keys", one of which is really the nonce.
>
>The "nonce" is part of the key but used differently in the
>algorithm, just like the initial IV is a part of the
>key in some algorithms; the counter would be derived from the
>address which presumably is always the same for the same
>block of the disk.
>
>>Recall that this isn't a message transmission stream where a nonce
>>can be generated and security interchanged during the authentication
>>phase.
>
>No, it's indeed part of the key.
>
>>If "nonce + counter" is calculated by a constant formula for any
>>particular disk sector, then if the attacker can get access to
>>the system while it is operational with the valid key, they can
>>read the encrypted contents of a disk block and then have the system
>>write the block with known contents (e.g., all blanks.) They would
>>then read off the encrypted result and xor it with the contents
>>they knew they wrote there, and that would give them
>>the Encrypt(Key, Nonce + Counter) that was valid for that disk block.
>>They would take that value and xor it with the previously recorded
>>encrypted contents, and the result they would get back would be
>>the original unencrypted content of the block.
>
>I would assume that an attacker who get access to a system which is
>operating and keyed with proper key+nonce can always read the
>disk content be accessing it through the proper (decrypting) way.
>
>If you can get the system to write an encrypted block, surely you
>can get them to read it too?
>
>>Further to this: if the attackers can gain read access to the encrypted
>>drive even when it is not writing under the aegis of the appropriate
>>key, they can image the disk and withdraw. At a later time when
>>some interesting information has been written to the disk, they can
>>come back and re-image it. If they then xor the two recorded images,
>>the Encrypt(Key, Nonce + Counter) for each disk block will cancel
>>out, leaving them with the xor of the changes to the drive contents.
>>In any block in which the original plaintext content was NULLs
>>[e.g. because nothing had been written there yet], the new disk
>>block content after the series of xor's will be the plaintext of the
>>new disk block contents; similarily, in any block in which the
>>original plaintext content was not null but was overwritten with NULLs
>>[e.g., because the block was released from use], the new disk block
>>content after the series of xor's will be the plaintext of the
>>original block contents.
>
>If you can observe the encrypted contents of a system, it is likely
>that you can also observe much more, such as key material used and so on.
>
>There is protection offered against disks or computeres stolen.
>Casper
>--


If the Bad Guys can put their hands on your system, unsupervised,
you've probably lost the game.

The conjectured sector-level hardware encryption of a disk containing
a Well Known operating system on it probably has some inherant
"known-text" exploit exposure, but the crypto algorithm would chosen
to make the attack as hard as possible, and major supercomputer assets
would have to be brought to bear to crack each disk. Your data is
effectivly encrypted for commercial purposes.

IMO, the existance of a back door known to IBM would be so sensitive
that it would only be used in National Security cases where the
existance of the back door would never be admitted in open court and
protected for 50 years, or whatever. Since IBM also sells crypto
systems to financial institutions and other governments, if the
existence of a back door even came to light it would be a major
embarassment.

I'm not a crypto guy, but I have years of Risk Management experience
and have handled crypto material while working for a major bank.

--
a d y k e s [at] p a n i x . c o m
----

mike4ty4 [at] yahoo.com (mike3) wrote in
news:1d54b7e4.0411270117.2b333870 [at] posting.google.com:

> How about a chemical
> destruction mechanism? You'd have two chemicals on either side of the
> drive, which are normally inert, but when they mix, become a highly
> corrosive brew that eats the metal of a hard drive. Then all you have
> to do is have the drive in a sealed bay with the chemicals on each
> side. Once the proper command is recieved, the chemicals would pour
> into where the drive is, destroying it. The problem: Does anyone know
> if there's any chemicals that do that?
>

I'm not too sure about the necessary proportions, but
sodium reacting with water should do the trick fairly
nicely. Some nice sodium hydroxide is formed, and there's
the chance for the produced hydrogen to explode with
the heat produced by the reaction.

Or you could just wire up a strong explosive charge.

And as has been said, this should probably be handled by
a dead-man switch, not some "remote signal."

In article <Xns95B2AFB33700EjasonRlarue [at] 216.77.188.18>,
Jason LaRue <aqdqmqiqnq [at] inqteluser.coqm> wrote:
:I'm not too sure about the necessary proportions, but
:sodium reacting with water should do the trick fairly
:nicely. Some nice sodium hydroxide is formed, and there's
:the chance for the produced hydrogen to explode with
:the heat produced by the reaction.

When I was somewhat younger, I distinctly recall that there was
a druggist one could go to to buy fairly pure sodium (in oil).
That is, they would sell it to people off the street. I didn't
quite have the nerve to go buy some myself (I was perhaps 12.)

These days you pretty much need a permit, and you have to buy from
an industrial supplier such as Fischer Scientific.

Heck, these days I rarely even see "Junior Chemistry Set" being sold.
(I was the kind of kid who had the expansion sets. I also invented
a very nice artificial lilac fragrence one time, but, alas, I was
also the kind of kid who didn't make notes about what I was putting in...)
--
IMT made the sky
Fall.