On 28/01/2019 20:30, Robert Nichols wrote:
On 1/28/19 8:03 AM, Ian Malone wrote:
I wouldn't recommend just doing /dev/zero if the CIA,
or even a moderately funded newspaper might specifically be after your
data,
I would be interested to know if you can name any data recovery service
that has
On Sat, Feb 02, 2019 at 02:48:11PM +0100, Wolfgang Pfeiffer wrote:
So the warning cryptsetup is giving here:
-
cryptsetup open --type plain -d /dev/urandom /dev/sdd dmcrypt.test
WARNING: Device /dev/sdd already contains a 'ext4' superblock signature.
WARNING!
Detected
On Tue, Jan 29, 2019 at 03:48:01PM -0800, Gordon Messmer wrote:
On 1/27/19 6:47 PM, Wolfgang Pfeiffer wrote:
[ .. ]
It sounds like you're unfamiliar with the implementation, and possibly
with filesystems and block devices in general. I'll try to explain,
with some simplifications. You
On 1/30/19 12:48 AM, Gordon Messmer wrote:
> Both the filesystem and your data are encrypted when using dm-crypt (whether
> you use LUKS or not). However, creating a dm-crypt device doesn't modify the
> pre-existing data. It only writes encrypted data to the disk when data is
> written to
On Tue, 2019-01-29 at 16:20 -0800, Gordon Messmer wrote:
> On 1/28/19 2:12 AM, Patrick O'Callaghan wrote:
> > Another point: several people have mentioned using /dev/urandom. It's
> > important to note that this is a *pseudo-random* generator. It starts
> > from a random seed, but from that
On 1/28/19 2:12 AM, Patrick O'Callaghan wrote:
Another point: several people have mentioned using /dev/urandom. It's
important to note that this is a *pseudo-random* generator. It starts
from a random seed, but from that generates a completely deterministic
pattern. If you have the seed, you
On 1/27/19 6:47 PM, Wolfgang Pfeiffer wrote:
Yes, something like that is what I suspect: The actual data on disk
would be left untouched when the *disk/partition* is encrypted. I had
a look through documents explaining luks, and again and again the
topic is "disk" encryption, not "data"
On Tue, 29 Jan 2019 at 03:32, Robert Nichols wrote:
>
> On 1/28/19 8:03 AM, Ian Malone wrote:
> >I wouldn't recommend just doing /dev/zero if the CIA,
> > or even a moderately funded newspaper might specifically be after your
> > data,
>
> I would be interested to know if you can name any data
On 1/28/19 9:15 PM, fred roller wrote:
run photorec and see what it pulls.
That won't find anything. You need a machine that can directly analyze
the magnetic fields on the disk. That's why for most uses, even writing
zeros is enough.
___
users
run photorec and see what it pulls.
On Mon, Jan 28, 2019 at 7:32 PM Robert Nichols
wrote:
> On 1/28/19 8:03 AM, Ian Malone wrote:
> >I wouldn't recommend just doing /dev/zero if the CIA,
> > or even a moderately funded newspaper might specifically be after your
> > data,
>
> I would be
On 1/28/19 8:03 AM, Ian Malone wrote:
I wouldn't recommend just doing /dev/zero if the CIA,
or even a moderately funded newspaper might specifically be after your
data,
I would be interested to know if you can name any data recovery service that
has ever demonstrated the ability to recover
On Mon, 28 Jan 2019 at 15:43, Patrick O'Callaghan wrote:
>
> On Mon, 2019-01-28 at 14:03 +, Ian Malone wrote:
> >
> > /dev/urandom isn't purely pseudorandom, it does use entropy from the
> > pool, it will become pseudorandom when entropy runs out and become
> > random again when more entropy
On 1/28/19 8:28 AM, sixpack13 wrote:
Zit: "This is repeating really old information. On my not new laptop /dev/urandom
can provide over 250MB/s."
yep, I thought this already.
I better had mention the date of the article.
lesson learned !
I was referring to the website post, not you. I
Zit: "This is repeating really old information. On my not new laptop
/dev/urandom can provide over 250MB/s."
yep, I thought this already.
I better had mention the date of the article.
lesson learned !
___
users mailing list --
On Mon, 2019-01-28 at 14:03 +, Ian Malone wrote:
> > Another point: several people have mentioned using /dev/urandom. It's
> > important to note that this is a *pseudo-random* generator. It starts
> > from a random seed, but from that generates a completely deterministic
> > pattern. If you
On Mon, 28 Jan 2019 at 10:13, Patrick O'Callaghan wrote:
>
> On Sun, 2019-01-27 at 20:46 -0800, jdow wrote:
> > On 20190127 14:44:52, Patrick O'Callaghan wrote:
> > > On Sun, 2019-01-27 at 19:56 +0100, Wolfgang Pfeiffer wrote:
> > > > > Given that encrypting the disk means (at a minimum) reading
On 2019-01-28 at 10:12:28 Patrick O'Callaghan wrote:
> Another point: several people have mentioned using /dev/urandom. It's
> important to note that this is a *pseudo-random* generator. It starts
> from a random seed, but from that generates a completely deterministic
> pattern. If you have the
On Sun, 2019-01-27 at 20:46 -0800, jdow wrote:
> On 20190127 14:44:52, Patrick O'Callaghan wrote:
> > On Sun, 2019-01-27 at 19:56 +0100, Wolfgang Pfeiffer wrote:
> > > > Given that encrypting the disk means (at a minimum) reading the entire
> > > > contents and rewriting it,
> > >
> > > No. I
On 1/27/19 7:34 AM, sixpack13 wrote:
from a german IT magazine I got this:
https://www.heise.de/select/ct/2016/03/1454233793502849#titel_1454233793502849_10
openssl enc -aes-256-ctr -pass pass: "$(dd if=/dev/urandom bs=128 count=1 2>/dev/null |
base64)" -nosalt < /dev/zero > /dev/sdX
I've
On 1/27/19 6:47 PM, Wolfgang Pfeiffer wrote:
On Sun, Jan 27, 2019 at 10:44:52PM +, Patrick O'Callaghan wrote:
If it's not being read and rewritten, it's not being encrypted.
Yes, something like that is what I suspect: The actual data on disk
would be left untouched when the
On 20190127 14:44:52, Patrick O'Callaghan wrote:
On Sun, 2019-01-27 at 19:56 +0100, Wolfgang Pfeiffer wrote:
Given that encrypting the disk means (at a minimum) reading the entire
contents and rewriting it,
No. I don't think data is written and rewritten. See below.
If it's not being read
On Sun, Jan 27, 2019 at 10:44:52PM +, Patrick O'Callaghan wrote:
On Sun, 2019-01-27 at 19:56 +0100, Wolfgang Pfeiffer wrote:
> Given that encrypting the disk means (at a minimum) reading the entire
> contents and rewriting it,
No. I don't think data is written and rewritten. See below.
On 1/27/19 3:23 PM, Patrick O'Callaghan wrote:
I think the writer *thought* it was encrypting the disk. I may be
wrong, but that's what I was responding to rather than the minutiae of
the actual command.
Ah. Yeah, now that I read his subsequent reply, I can see why.
On 1/27/19 3:12 PM, Mike Wright wrote:
simply wiping the key header.
Command example?
A LUKS2 header is 4M, and other versions will be smaller, so:
dd if=/dev/zero of=/dev/sdXN bs=4M count=1
___
users mailing list -- users@lists.fedoraproject.org
too bad it's not an old spnner... just leave it on your speaker magnet
overnight. reformat in the morning.
:P
Fred
On Sun, Jan 27, 2019 at 3:24 PM Patrick O'Callaghan
wrote:
> On Sun, 2019-01-27 at 15:06 -0800, Gordon Messmer wrote:
> > On 1/27/19 2:44 PM, Patrick O'Callaghan wrote:
> > > If
On Sun, 2019-01-27 at 15:06 -0800, Gordon Messmer wrote:
> On 1/27/19 2:44 PM, Patrick O'Callaghan wrote:
> > If it's not being read and rewritten, it's not being encrypted. It's as
> > simple as that. A cryptosystem that doesn't read the plaintext? How
> > does that work?
>
> The suggestion
On 1/27/19 2:44 PM, Patrick O'Callaghan wrote:
If it's not being read and rewritten, it's not being encrypted. It's as
simple as that. A cryptosystem that doesn't read the plaintext? How
does that work?
The suggestion you're replying to didn't encrypt the drive in place. It
read a stream of
On Sun, 2019-01-27 at 19:56 +0100, Wolfgang Pfeiffer wrote:
> > Given that encrypting the disk means (at a minimum) reading the entire
> > contents and rewriting it,
>
> No. I don't think data is written and rewritten. See below.
If it's not being read and rewritten, it's not being encrypted.
On 20190127 10:56:25, Wolfgang Pfeiffer wrote:
On Sun, Jan 27, 2019 at 11:32:52AM +, Patrick O'Callaghan wrote:
On Sun, 2019-01-27 at 02:29 +0100, Wolfgang Pfeiffer wrote:
I think, yes: simply encrypting the whole disk should do it: IIRC this
should be *a lot* faster than piping
On Sun, Jan 27, 2019 at 11:32:52AM +, Patrick O'Callaghan wrote:
On Sun, 2019-01-27 at 02:29 +0100, Wolfgang Pfeiffer wrote:
I think, yes: simply encrypting the whole disk should do it: IIRC this
should be *a lot* faster than piping /dev/urandom to a disk,
Given that encrypting the disk
from a german IT magazine I got this:
https://www.heise.de/select/ct/2016/03/1454233793502849#titel_1454233793502849_10
openssl enc -aes-256-ctr -pass pass: "$(dd if=/dev/urandom bs=128 count=1
2>/dev/null | base64)" -nosalt < /dev/zero > /dev/sdX
I've never tested it, so I don't know if it
On Sun, 2019-01-27 at 02:29 +0100, Wolfgang Pfeiffer wrote:
> I think, yes: simply encrypting the whole disk should do it: IIRC this
> should be *a lot* faster than piping /dev/urandom to a disk,
Given that encrypting the disk means (at a minimum) reading the entire
contents and rewriting it,
Allegedly, on or about 26 January 2019, Patrick O'Callaghan sent:
> Since magnetic domains have hysteresis, suitable equipment can
> recover the previous state at a physical level. That's why proper
> trashing takes several passes.
Some drives are supposed have a built in secure erase function.
On 1/26/19 5:29 PM, Wolfgang Pfeiffer wrote:
I think, yes: simply encrypting the whole disk should do it: IIRC this
should be *a lot* faster than piping /dev/urandom to a disk, or even
using shred:
Encrypting the whole disk involves writing the same amount of data, so
it can't be faster.
On 1/26/19 2:45 PM, Jonathan Ryshpan wrote:
They both do it at about the same speed, about 40Mbytes/sec., which is
probably about the max transfer rate to the drive. Another instance of
shred
$ shred -v -n1 /dev/sdb
applied to an internal drive (which I also plan to dispose of) ran at
least
On Fri, Jan 25, 2019 at 06:45:25PM -0800, Jonathan Ryshpan wrote:
I'm using shred on some 2Tb USB disk drive that I plan to give away.
So far it has taken 8 hours to shred 50% of the drive, which implies
that it will take about 16 hours to shred the whole drive. I have
another 2 drives to go.
On Sat, 2019-01-26 at 11:09 -0800, Samuel Sieb wrote:
> On 1/25/19 6:45 PM, Jonathan Ryshpan wrote:
> > I'm using shred on some 2Tb USB disk drive that I plan to give away. So
> > far it has taken 8 hours to shred 50% of the drive, which implies that
> > it will take about 16 hours to shred the
Allegedly, on or about 26 January 2019, sixpack13 sent:
> maybe "hdparm security erase" is an option (don't know if disk
> content is afterwards still recoverable)
Of course you could leave a drive filled with non-private files, just
to lead them down the garden path. ;-)
--
[tim@localhost
On Sat, 2019-01-26 at 20:01 +, Jonathan Dieter wrote:
> On Fri, 2019-01-25 at 20:24 -0800, Gordon Messmer wrote:
> > On 1/25/19 6:45 PM, Jonathan Ryshpan wrote:
> > > Is there a quicker way to protect my data when I give the drives away,
> > > other than smashing the drives to bits?
> >
> >
On Fri, 2019-01-25 at 20:24 -0800, Gordon Messmer wrote:
> On 1/25/19 6:45 PM, Jonathan Ryshpan wrote:
> > Is there a quicker way to protect my data when I give the drives away,
> > other than smashing the drives to bits?
>
> The quickest would be to encrypt the drives from the beginning. When
maybe "hdparm security erase" is an option (don't know if disk content is
afterwards still recoverable)
https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
It works with spinning drives too.
At least bother of my Samsung drives are supported. (time: 500 GB 112 min)
I'm not quit sure, but I
On 01/26/2019 12:04 PM, Samuel Sieb wrote:
Sure, but do you expect someone to find your hard drive and put that
much money and effort into extracting your data? For most people, it's
just that you don't want some random person finding your hard drive in a
second hand store and checking out
On Sat, 2019-01-26 at 11:04 -0800, Samuel Sieb wrote:
> On 1/26/19 2:47 AM, Patrick O'Callaghan wrote:
> > On Fri, 2019-01-25 at 22:43 -0800, ToddAndMargo via users wrote:
> > > On 1/25/19 9:38 PM, fred roller wrote:
> > > > You can wipe your drive with:
> > > >
> > > > dd if=/dev/zero
On 1/25/19 6:45 PM, Jonathan Ryshpan wrote:
I'm using shred on some 2Tb USB disk drive that I plan to give away. So
far it has taken 8 hours to shred 50% of the drive, which implies that
it will take about 16 hours to shred the whole drive. I have another 2
drives to go.
Is there a quicker
On 1/26/19 9:50 AM, Beartooth wrote:
On Fri, 25 Jan 2019 18:45:25 -0800, Jonathan Ryshpan wrote:
I'm using shred on some 2Tb USB disk drive that I plan to give away.
So far it has taken 8 hours to shred 50% of the drive, which implies
that it will take about 16 hours to shred the whole drive.
On 1/26/19 2:47 AM, Patrick O'Callaghan wrote:
On Fri, 2019-01-25 at 22:43 -0800, ToddAndMargo via users wrote:
On 1/25/19 9:38 PM, fred roller wrote:
You can wipe your drive with:
dd if=/dev/zero of=/dev/[device to be wiped]
/dev/zero is the fastest I have found.
All that does is set
On Sat, Jan 26, 2019 at 05:50:20PM -, Beartooth wrote:
> On Fri, 25 Jan 2019 18:45:25 -0800, Jonathan Ryshpan wrote:
>
> > I'm using shred on some 2Tb USB disk drive that I plan to give away.
> > So far it has taken 8 hours to shred 50% of the drive, which implies
> > that it will take about
On Fri, 25 Jan 2019 18:45:25 -0800, Jonathan Ryshpan wrote:
> I'm using shred on some 2Tb USB disk drive that I plan to give away.
> So far it has taken 8 hours to shred 50% of the drive, which implies
> that it will take about 16 hours to shred the whole drive. I have
> another 2 drives to go.
On Fri, 2019-01-25 at 22:43 -0800, ToddAndMargo via users wrote:
> On 1/25/19 9:38 PM, fred roller wrote:
> > You can wipe your drive with:
> >
> > dd if=/dev/zero of=/dev/[device to be wiped]
>
> /dev/zero is the fastest I have found.
All that does is set every bit to 0. Since magnetic domains
adding
status=progress
to the dd command i believe will let you know how long it has so you can
keep an eye on it in the terminal.
On Fri, Jan 25, 2019 at 11:32 PM Samuel Sieb wrote:
> On 1/25/19 10:58 PM, Jonathan Ryshpan wrote:
> > I'll give dd a try; but I don't see offhand why
> > dd
On 1/25/19 10:58 PM, Jonathan Ryshpan wrote:
I'll give dd a try; but I don't see offhand why
dd if=/dev/urandom of=/dev/sdc bs=1M
should be quicker than what I'm using now, namely
shred -v -n1 /dev/sdc
I don't know how it generates the data to overwrite with. Does it use a
lot of
On Fri, 2019-01-25 at 21:58 -0800, Samuel Sieb wrote:
> On 1/25/19 6:45 PM, Jonathan Ryshpan wrote:
> > I'm using shred on some 2Tb USB disk drive that I plan to give away. So
> > far it has taken 8 hours to shred 50% of the drive, which implies that
> > it will take about 16 hours to shred the
On 1/25/19 9:38 PM, fred roller wrote:
You can wipe your drive with:
dd if=/dev/zero of=/dev/[device to be wiped]
/dev/zero is the fastest I have found.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to
On 1/25/19 6:45 PM, Jonathan Ryshpan wrote:
I'm using shred on some 2Tb USB disk drive that I plan to give away. So
far it has taken 8 hours to shred 50% of the drive, which implies that
it will take about 16 hours to shred the whole drive. I have another 2
drives to go.
Is there a quicker
You can wipe your drive with:
dd if=/dev/zero of=/dev/[device to be wiped]
followed by:
dd if=/dev/urandom of=/dev/[device to be wiped]
repeat 7 times per device if you want the DoD standard for wiping a drive.
If you would like to save time/trouble drop the sequence in a script.
Plenty of
On 1/25/19 6:45 PM, Jonathan Ryshpan wrote:
Is there a quicker way to protect my data when I give the drives away,
other than smashing the drives to bits?
The quickest would be to encrypt the drives from the beginning. When you
want to discard the drives, you just need to wipe the LUKS
On 1/25/19 7:09 PM, ToddAndMargo via users wrote:
This will also discharge all your cells too.
Sorry, I though it was an SSD.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
On 1/25/19 6:45 PM, Jonathan Ryshpan wrote:
I'm using shred on some 2Tb USB disk drive that I plan to give away. So
far it has taken 8 hours to shred 50% of the drive, which implies that
it will take about 16 hours to shred the whole drive. I have another 2
drives to go.
Is there a quicker
I'm using shred on some 2Tb USB disk drive that I plan to give away.
So far it has taken 8 hours to shred 50% of the drive, which implies
that it will take about 16 hours to shred the whole drive. I have
another 2 drives to go.
Is there a quicker way to protect my data when I give the drives
59 matches
Mail list logo
