3 Apr
2022
3 Apr
'22
8:51 a.m.
From here:
https://setiathome.berkeley.edu/forum_thread.php?id=85870&postid=209677…
They are bog standard Sun Enterprise systems, drive removed and destroyed
for privacy reason. They are only interesting for what they've done. By
university rules, our group can essentially "permanent loan" them to a
non-profit, but any sale or transfer of ownership is up to
University Excess and Salvage.
A bit of history disappearing, which is nothing new in this group.
3 Apr
3 Apr
1:16 p.m.
On 2022-04-03 11:51, Eric J. Korpela via cctalk wrote:
I think in this group, we have plenty of DLT IV tape drives?
How many tapes are we talking?
From here:
https://setiathome.berkeley.edu/forum_thread.php?id=85870&postid=209677…
They are bog standard Sun Enterprise systems, drive removed and destroyed
for privacy reason. They are only interesting for what they've done. By
university rules, our group can essentially "permanent loan" them to a
non-profit, but any sale or transfer of ownership is up to
University Excess and Salvage.
A bit of history disappearing, which is nothing new in this group. 
3:09 p.m.
Ah setiathome. Those systems in the photo will have handled a lot of my personal data -
well, compared to random other earthlings.
I don't really have fond memories of that series of Sun Enterprise though - what are
they, 3000 or 3500? Many a times that I stubbed my toes on that v-shaped thing protruding
off the back side. Those systems only made sense for a cluster because they lacked
internal reliability and power supply reduncancy - but cluster software back then
didn't work too well, and I'm not sure anyone actually used that series as it was
intended from the design - always as a cluster. Anyway, lots of very heavy metal frames,
good enough to stub your toes on for sure - what I've come to call 'a stable
platform' ie something you can put your weight on without worrying.
Main issue for the 3000/3500 series were the power supplies as I recall, if you didn't
get lucky, a 3500 would be a lot less reliable than a 250 - that didn't have all of
the extra whoohow, but would work fine even after unbelievable abuse.
Anyway, I still have some of the heatsinks that dropped off the several 3500 I had the
privilege of knowing - one of them is now glued to the cpu of my spare server board.
On 3 Apr 2022, at 17:51, Eric J. Korpela via cctalk
<cctalk at classiccmp.org> wrote:
From here:
https://setiathome.berkeley.edu/forum_thread.php?id=85870&postid=209677…
They are bog standard Sun Enterprise systems, drive removed and destroyed
for privacy reason. They are only interesting for what they've done. By
university rules, our group can essentially "permanent loan" them to a
non-profit, but any sale or transfer of ownership is up to
University Excess and Salvage.
A bit of history disappearing, which is nothing new in this group.
4 Apr
4 Apr
7:20 a.m.
New subject: Data recovery (was: Re: SETI@home (ca. 2000) servers heading to salvage)
On 4/3/22 10:51, Eric J. Korpela via cctalk wrote:
drive removed and destroyed for privacy reason.
For those in the know, how much success - assuming a "money is no object"
approach - do data recovery companies have in retrieving data from drives
that have a) been overwritten with zeros using dd or similar, and b) been
overwritten with random data via a more comprehensive tool?
cheers,
Jules
7:28 a.m.
New subject: Data recovery (was: Re: SETI@home (ca. 2000) servers heading to salvage)
On Apr 4, 2022, at 10:20 AM, Jules Richardson via
cctalk <cctalk at classiccmp.org> wrote:
On 4/3/22 10:51, Eric J. Korpela via cctalk wrote:
There's a research group in, I think, UCSD which studies that question. From what I
recall, in modern hard disk drives with microscopic tracks and not a whole lot of margin
anywhere, one overwrite is plenty good. The legendary multiple erase schemes are mostly
rumors -- I looked long and hard for the supposed government standards that specify these
and found they don't seem to exist -- and no longer useful.
SSDs are a different story entirely because there you don't write over the actual
data; instead a write updates internal metadata saying where the most recent version of
block number xyz lives. So, given that you tend to have a fair amount (10 or 20 percent
if not more) of "spare space" in the SSD, previous data are likely to be hanging
around. I suspect if you write long enough you could traverse all that, but how to do
that depends on the internals of the firmware. That's likely to be confidential and
may not even be reliably known.
There are SSD SEDs. If designed correctly those would give you cryptographically strong
security and "instant erase". Not all disk designers know how to do these
designs correctly. If I needed an SED (of any kind) I'd insist on a detailed
disclosure of its keying and key management. Prying that out of manyfacturers is hard.
I've done it, but it may be that my employer's name and unit volume was a factor.
paul
drive removed and destroyed for privacy reason.
For those in the know, how much success - assuming a "money is no object"
approach - do data recovery companies have in retrieving data from drives that have a)
been overwritten with zeros using dd or similar, and b) been overwritten with random data
via a more comprehensive tool? 
7:34 a.m.
New subject: Data recovery (was: Re: SETI@home (ca. 2000) servers heading to salvage)
Good data Paul! SSD's are a different beast, if you're going to put data
on them that you do not want recovered I would recommend encrypting the
drive before using it, then when done delete/destroy the key. That
should turn your drive into a useless (but format-able) chunk of silicon.
C
On 4/4/2022 8:28 AM, Paul Koning via cctalk wrote:
SSDs are a different story entirely because there you
don't write over the actual data; instead a write updates internal metadata saying
where the most recent version of block number xyz lives. So, given that you tend to have
a fair amount (10 or 20 percent if not more) of "spare space" in the SSD,
previous data are likely to be hanging around. I suspect if you write long enough you
could traverse all that, but how to do that depends on the internals of the firmware.
That's likely to be confidential and may not even be reliably known.
There are SSD SEDs. If designed correctly those would give you cryptographically strong
security and "instant erase". Not all disk designers know how to do these
designs correctly. If I needed an SED (of any kind) I'd insist on a detailed
disclosure of its keying and key management. Prying that out of manyfacturers is hard.
I've done it, but it may be that my employer's name and unit volume was a factor.
7:43 a.m.
New subject: Data recovery (was: Re: SETI@home (ca. 2000) servers heading to salvage)
SSD's are a different beast, if you're going
to put data
on them that you do not want recovered I would recommend encrypting the
drive before using it, then when done delete/destroy the key. That
should turn your drive into a useless (but format-able) chunk of silicon.
That's our take on it. SSDs get FDE or they don't leave. Secure Erase is nice for
blowing away old formatting/partitioning, but we're not trusting it on sensitive
customer data.
Thanks,
Jonathan
7:55 a.m.
New subject: Data recovery (was: Re: SETI@home (ca. 2000) servers heading to salvage)
That's what a sanitize operation does. It forgets the key and reformats the
metadata with a new key.
Also, with SSDs, any erase block that's erased is going to not have any
data that's recoverable.
First, the erase voltage is huge, moving the cell to a negative
voltage (the only abode that's
negative is all 1's). Next, the microprocessor in the NAND dies are going
to 'pre-program' the
abodes to a uniform negative voltage that's easier to program when you
start putting data on
the ages. Finally, most (nearly all) NAND dies have randomization circuitry
that randomizes the
data after you send it to the drive (or whitens it) that you'll need the
psuedorandom seed to read
it back coherently.
The problem, though, comes with erase blocks that have broken and no longer
erase. These
retired blocks can contain data still, but given the
randomization/whitening and/or some
global encryption key, the data can be difficult or impossible to
meaningfully recover, even
when other pathologies don't degrade the block more (not least is aging: if
the block was
retired a long time ago, the NAND cells, being tiny capacitors, will bleed
the charge off to
the erased state +/-).
As with most forms of data destruction, putting a metal spike through the
NAND dies
themselves would likely suffice :) But it is a tad destructive....
Warner
On Mon, Apr 4, 2022 at 8:34 AM Chris Zach via cctalk <cctalk at classiccmp.org>
wrote:
Good data Paul! SSD's are a different beast, if
you're going to put data
on them that you do not want recovered I would recommend encrypting the
drive before using it, then when done delete/destroy the key. That
should turn your drive into a useless (but format-able) chunk of silicon.
C
On 4/4/2022 8:28 AM, Paul Koning via cctalk wrote:
SSDs are a different story entirely because there
you don't write over
the actual data; instead a write updates internal metadata
saying where the
most recent version of block number xyz lives. So, given that you tend to
have a fair amount (10 or 20 percent if not more) of "spare space" in the
SSD, previous data are likely to be hanging around. I suspect if you write
long enough you could traverse all that, but how to do that depends on the
internals of the firmware. That's likely to be confidential and may not
even be reliably known.
There are SSD SEDs. If designed correctly those would give you
cryptographically
strong security and "instant erase". Not all disk
designers know how to do these designs correctly. If I needed an SED (of
any kind) I'd insist on a detailed disclosure of its keying and key
management. Prying that out of manyfacturers is hard. I've done it, but
it may be that my employer's name and unit volume was a factor.
8:37 a.m.
New subject: Data recovery (was: Re: SETI@home (ca. 2000) servers heading to salvage)
On Apr 4, 2022, at 10:55 AM, Warner Losh via cctalk
<cctalk at classiccmp.org> wrote:
That's what a sanitize operation does. It forgets the key and reformats the
metadata with a new key.
Yes, but the devil is in the details. For example, for the SSD case, it is necessary
verify that the flash block that previously held the key information has been explicitly
erased (successfully) and not merely put on the free list. That's a detail I once
pried out of a manufacturer, insisting they were required to answer in order to get the
business.
paul
9:06 a.m.
New subject: Data recovery (was: Re: SETI@home (ca. 2000) servers heading to salvage)
For those in the know, how much success - assuming a
"money is no object"
approach - do data recovery companies have in retrieving data from drives
that have a) been overwritten with zeros using dd or similar, and b) been
overwritten with random data via a more comprehensive tool?
cheers,
Jules
I am pretty sure someone had a bounty out there, they give you a hard
drive that had a phase on it that is stored linear on the platter. They
write over it once with zeros. If you can recover the phrase then you win
the bounty.
It's unclaimed.
Everyone talks about some theoretical ideas but no proof of it being done.
My understanding is once you erase the data it's difficult to tell the
difference between something recently erased and the noise floor. This was
last time I looked into this which was a while ago. Maybe nation state
has some ability but you or your customers data isn't worth the hassle.
Prior employer would just have hundreds/thousands of pounds of hard drives
ground up though. To eliminate any risk of data leakage. I am sure the
same is done with SSDs by other companies and the US Government.
Probably grinding up $9000 8TB SSDs all day.
--
: Ethan O'Toole
993
days inactive
994
days old
11 comments
10 participants
participants (10)
-
cclist＠sytse.net -
cz＠alembic.crystel.com -
emu＠e-bbes.com -
ethan＠757.org -
imp＠bsdimp.com -
jules.richardson99＠gmail.com -
korpela＠berkeley.edu -
linimon＠lonesome.com -
lists＠glitchwrks.com -
paulkoning＠comcast.net