How can gnu_ddrescue be resumed to wipe a hard disk? [closed]
Hard drives (non-SSD) are generally wiped with the command dd if=/dev/urandom of=/dev/sdX conv=fsync status=progress. Since power outages do occur, this lends to restarting the wipe process multiple times. Additionally, there are often requirements to move equipment.
dd as far as i know and based on my research does not support the ability to resume interruptions.
Posts on ddrescue are primarily focused on copying bitwise data from source to destination. Additionally they are concerned about resuming the copying process.
Based on a post to wipe unwritable sectors, it suggests that ddrescue can be used to wipe disks.
Can ddrescue be resumed if wiping disks and if so how when using a live CDs or DVDs?
Alternatively, what other options are there if ddrescue is unable to support this requirement?
ddrescue is not currently in use. If it does support the requirement to resume an interrupted process, it'll be used going forward.
dd ddrescue
asked Jan 7 at 16:51
MotivatedMotivated
1977
closed as unclear what you're asking by frostschutz, RalfFriedl, nwildner, Mr Shunz, msp9011 Jan 8 at 14:06
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
|
show 5 more comments
Hard drives (non-SSD) are generally wiped with the command dd if=/dev/urandom of=/dev/sdX conv=fsync status=progress. Since power outages do occur, this lends to restarting the wipe process multiple times. Additionally, there are often requirements to move equipment.
dd as far as i know and based on my research does not support the ability to resume interruptions.
Posts on ddrescue are primarily focused on copying bitwise data from source to destination. Additionally they are concerned about resuming the copying process.
Based on a post to wipe unwritable sectors, it suggests that ddrescue can be used to wipe disks.
Can ddrescue be resumed if wiping disks and if so how when using a live CDs or DVDs?
Alternatively, what other options are there if ddrescue is unable to support this requirement?
ddrescue is not currently in use. If it does support the requirement to resume an interrupted process, it'll be used going forward.
dd ddrescue
asked Jan 7 at 16:51
MotivatedMotivated
1977
closed as unclear what you're asking by frostschutz, RalfFriedl, nwildner, Mr Shunz, msp9011 Jan 8 at 14:06
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Can you elaborate a bit? Is this a theoretical question or are you already usingddrescue? If you are using it - what exactly are you doing? I can think of ways to wipe a hard drive with ddrescue but it's not what it was designed to do...
– frostschutz
Jan 7 at 17:02
@frostschutz - I have updated the question with a post that touches on the use ofddrescue.
– Motivated
Jan 7 at 17:39
If want to quickly zero a disk, don't use/dev/urandomas a first pass. It's probably better to fill the drive with zero bits first. That will destroy almost all the data very quickly... then do the random bit flipping... with a final flip back to zero.... Unless you are looking for MIL-spec procedures... and for that I would recommend using something like wipe ... but definitely not manually runddcommands.
– RubberStamp
Jan 7 at 18:40
@RubberStamp - Can you reference an authoritative source that touches on writing zeros first? References such as Arch Linux for example (wiki.archlinux.org/index.php/…) suggest otherwise. It also appears thatwipeis no longer maintained - (wiki.archlinux.org/index.php/Securely_wipe_disk#wipe). Why do you say not to manually runddcommands?
– Motivated
Jan 8 at 5:22
@RubberStamp You actually don't need to do multiple wipes. It's totally fine to do a single overwrite.
– forest
Jan 8 at 8:23
|
show 5 more comments
Hard drives (non-SSD) are generally wiped with the command dd if=/dev/urandom of=/dev/sdX conv=fsync status=progress. Since power outages do occur, this lends to restarting the wipe process multiple times. Additionally, there are often requirements to move equipment.
dd as far as i know and based on my research does not support the ability to resume interruptions.
Posts on ddrescue are primarily focused on copying bitwise data from source to destination. Additionally they are concerned about resuming the copying process.
Based on a post to wipe unwritable sectors, it suggests that ddrescue can be used to wipe disks.
Can ddrescue be resumed if wiping disks and if so how when using a live CDs or DVDs?
Alternatively, what other options are there if ddrescue is unable to support this requirement?
ddrescue is not currently in use. If it does support the requirement to resume an interrupted process, it'll be used going forward.
dd ddrescue
asked Jan 7 at 16:51
MotivatedMotivated
1977
Hard drives (non-SSD) are generally wiped with the command dd if=/dev/urandom of=/dev/sdX conv=fsync status=progress. Since power outages do occur, this lends to restarting the wipe process multiple times. Additionally, there are often requirements to move equipment.
dd as far as i know and based on my research does not support the ability to resume interruptions.
Posts on ddrescue are primarily focused on copying bitwise data from source to destination. Additionally they are concerned about resuming the copying process.
Based on a post to wipe unwritable sectors, it suggests that ddrescue can be used to wipe disks.
Can ddrescue be resumed if wiping disks and if so how when using a live CDs or DVDs?
Alternatively, what other options are there if ddrescue is unable to support this requirement?
ddrescue is not currently in use. If it does support the requirement to resume an interrupted process, it'll be used going forward.
dd ddrescue
dd ddrescue
asked Jan 7 at 16:51
MotivatedMotivated
1977
asked Jan 7 at 16:51
MotivatedMotivated
1977
edited Jan 7 at 17:45
Motivated
asked Jan 7 at 16:51
MotivatedMotivated
1977
asked Jan 7 at 16:51
MotivatedMotivated
1977
asked Jan 7 at 16:51
MotivatedMotivated
1977
1977
closed as unclear what you're asking by frostschutz, RalfFriedl, nwildner, Mr Shunz, msp9011 Jan 8 at 14:06
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as unclear what you're asking by frostschutz, RalfFriedl, nwildner, Mr Shunz, msp9011 Jan 8 at 14:06
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Can you elaborate a bit? Is this a theoretical question or are you already usingddrescue? If you are using it - what exactly are you doing? I can think of ways to wipe a hard drive with ddrescue but it's not what it was designed to do...
– frostschutz
Jan 7 at 17:02
@frostschutz - I have updated the question with a post that touches on the use ofddrescue.
– Motivated
Jan 7 at 17:39
If want to quickly zero a disk, don't use/dev/urandomas a first pass. It's probably better to fill the drive with zero bits first. That will destroy almost all the data very quickly... then do the random bit flipping... with a final flip back to zero.... Unless you are looking for MIL-spec procedures... and for that I would recommend using something like wipe ... but definitely not manually runddcommands.
– RubberStamp
Jan 7 at 18:40
@RubberStamp - Can you reference an authoritative source that touches on writing zeros first? References such as Arch Linux for example (wiki.archlinux.org/index.php/…) suggest otherwise. It also appears thatwipeis no longer maintained - (wiki.archlinux.org/index.php/Securely_wipe_disk#wipe). Why do you say not to manually runddcommands?
– Motivated
Jan 8 at 5:22
@RubberStamp You actually don't need to do multiple wipes. It's totally fine to do a single overwrite.
– forest
Jan 8 at 8:23
|
show 5 more comments
Can you elaborate a bit? Is this a theoretical question or are you already usingddrescue? If you are using it - what exactly are you doing? I can think of ways to wipe a hard drive with ddrescue but it's not what it was designed to do...
– frostschutz
Jan 7 at 17:02
@frostschutz - I have updated the question with a post that touches on the use ofddrescue.
– Motivated
Jan 7 at 17:39
If want to quickly zero a disk, don't use/dev/urandomas a first pass. It's probably better to fill the drive with zero bits first. That will destroy almost all the data very quickly... then do the random bit flipping... with a final flip back to zero.... Unless you are looking for MIL-spec procedures... and for that I would recommend using something like wipe ... but definitely not manually runddcommands.
– RubberStamp
Jan 7 at 18:40
@RubberStamp - Can you reference an authoritative source that touches on writing zeros first? References such as Arch Linux for example (wiki.archlinux.org/index.php/…) suggest otherwise. It also appears thatwipeis no longer maintained - (wiki.archlinux.org/index.php/Securely_wipe_disk#wipe). Why do you say not to manually runddcommands?
– Motivated
Jan 8 at 5:22
@RubberStamp You actually don't need to do multiple wipes. It's totally fine to do a single overwrite.
– forest
Jan 8 at 8:23
Can you elaborate a bit? Is this a theoretical question or are you already using
ddrescue? If you are using it - what exactly are you doing? I can think of ways to wipe a hard drive with ddrescue but it's not what it was designed to do...– frostschutz
Jan 7 at 17:02
Can you elaborate a bit? Is this a theoretical question or are you already using
ddrescue? If you are using it - what exactly are you doing? I can think of ways to wipe a hard drive with ddrescue but it's not what it was designed to do...– frostschutz
Jan 7 at 17:02
@frostschutz - I have updated the question with a post that touches on the use of
ddrescue.– Motivated
Jan 7 at 17:39
@frostschutz - I have updated the question with a post that touches on the use of
ddrescue.– Motivated
Jan 7 at 17:39
If want to quickly zero a disk, don't use
/dev/urandom as a first pass. It's probably better to fill the drive with zero bits first. That will destroy almost all the data very quickly... then do the random bit flipping... with a final flip back to zero.... Unless you are looking for MIL-spec procedures... and for that I would recommend using something like wipe ... but definitely not manually run dd commands.– RubberStamp
Jan 7 at 18:40
If want to quickly zero a disk, don't use
/dev/urandom as a first pass. It's probably better to fill the drive with zero bits first. That will destroy almost all the data very quickly... then do the random bit flipping... with a final flip back to zero.... Unless you are looking for MIL-spec procedures... and for that I would recommend using something like wipe ... but definitely not manually run dd commands.– RubberStamp
Jan 7 at 18:40
@RubberStamp - Can you reference an authoritative source that touches on writing zeros first? References such as Arch Linux for example (wiki.archlinux.org/index.php/…) suggest otherwise. It also appears that
wipe is no longer maintained - (wiki.archlinux.org/index.php/Securely_wipe_disk#wipe). Why do you say not to manually run dd commands?– Motivated
Jan 8 at 5:22
@RubberStamp - Can you reference an authoritative source that touches on writing zeros first? References such as Arch Linux for example (wiki.archlinux.org/index.php/…) suggest otherwise. It also appears that
wipe is no longer maintained - (wiki.archlinux.org/index.php/Securely_wipe_disk#wipe). Why do you say not to manually run dd commands?– Motivated
Jan 8 at 5:22
@RubberStamp You actually don't need to do multiple wipes. It's totally fine to do a single overwrite.
– forest
Jan 8 at 8:23
@RubberStamp You actually don't need to do multiple wipes. It's totally fine to do a single overwrite.
– forest
Jan 8 at 8:23
|
show 5 more comments
1 Answer
1
active
oldest
votes
You don't need ddrescue for this. You can use plain dd and make it print progress when wiping:
dd if=/dev/urandom of=/dev/sdX bs=256k 2>/media/usb/progress.txt &
while kill -USR1 $!; do sleep 10; done
This will begin wiping the disk, sending the process to the background, and then telling it to write its progress to a log file kept on a USB stick every 10 seconds. If the power is cut, you will be able to see approximately where it was left off, and then will be able to resume wiping from that position:
dd if=/dev/urandom of=/dev/sdX bs=256k seek=<number of records>
A single pass overwrite with random data is sufficient to make all data unrecoverable.
answered Jan 8 at 8:51
forestforest
55212
It depends on what standard and/or attack the OP is concerned about ... Mil-STD does several writes and also uses algorithmic write patterns across the disk itself ... Certifying that all data are not readable from the surface of a disk even under an electron microscope... Gutmann wipe ... Those COMSEC custodians can be rather difficult to work around...
– RubberStamp
Jan 8 at 11:49
@RubberStamp That is an old data destruction myth that has been retracted by the author himself. On modern high-density hard drives, a single pass with random data is sufficient to make it unreadable with any technology. Consider the fact that even low-density analog audio tape cannot be recovered after a single overwrite. As for the relevant government standards, those no longer specify multiple overwrites and instead demand physical destruction to get around the risk of damaged unwritable sectors retaining data.
– forest
Jan 8 at 12:12
Using/dev/urandomas the one and only write across the drive does not guarantee that all bits are flipped. So, the premise of your claim in your comment to the OP is not accurate... A 35 pass Gutmann is the extreme... a single pass pseudo-random write is worse than writing all ones in a single pass... Writing all zeros as a first pass would allow the OP to seek through the drive until the first non-zero bit and restart the zero process... Using a pre-built wiping program ensures that someone "out-there" has thought more deeply about the security of the algorithm than the non-expert.
– RubberStamp
Jan 8 at 12:50
@RubberStamp I think you are misunderstanding how hard drives store data. When you write a zero or a one, you aren't writing that literal bit to the disk due to a heavy amount of modulation (a null sector will be physically written as a pseudorandom stream of 512 bits with a few extra bits for ECC). Furthermore even if you did, a zero is not the absence of a bit. They are nothing more than flipped magnetic polarization. Which is one and which is zero is completely arbitrary. This has been true since MFM drives and still is today.
– forest
Jan 8 at 12:58
Due to the modulation, flipping 0→0 or 1→1 is exactly as "destructive" to the bit 0→1 or 1→0.
– forest
Jan 8 at 13:05
|
show 13 more comments
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You don't need ddrescue for this. You can use plain dd and make it print progress when wiping:
dd if=/dev/urandom of=/dev/sdX bs=256k 2>/media/usb/progress.txt &
while kill -USR1 $!; do sleep 10; done
This will begin wiping the disk, sending the process to the background, and then telling it to write its progress to a log file kept on a USB stick every 10 seconds. If the power is cut, you will be able to see approximately where it was left off, and then will be able to resume wiping from that position:
dd if=/dev/urandom of=/dev/sdX bs=256k seek=<number of records>
A single pass overwrite with random data is sufficient to make all data unrecoverable.
answered Jan 8 at 8:51
forestforest
55212
It depends on what standard and/or attack the OP is concerned about ... Mil-STD does several writes and also uses algorithmic write patterns across the disk itself ... Certifying that all data are not readable from the surface of a disk even under an electron microscope... Gutmann wipe ... Those COMSEC custodians can be rather difficult to work around...
– RubberStamp
Jan 8 at 11:49
@RubberStamp That is an old data destruction myth that has been retracted by the author himself. On modern high-density hard drives, a single pass with random data is sufficient to make it unreadable with any technology. Consider the fact that even low-density analog audio tape cannot be recovered after a single overwrite. As for the relevant government standards, those no longer specify multiple overwrites and instead demand physical destruction to get around the risk of damaged unwritable sectors retaining data.
– forest
Jan 8 at 12:12
Using/dev/urandomas the one and only write across the drive does not guarantee that all bits are flipped. So, the premise of your claim in your comment to the OP is not accurate... A 35 pass Gutmann is the extreme... a single pass pseudo-random write is worse than writing all ones in a single pass... Writing all zeros as a first pass would allow the OP to seek through the drive until the first non-zero bit and restart the zero process... Using a pre-built wiping program ensures that someone "out-there" has thought more deeply about the security of the algorithm than the non-expert.
– RubberStamp
Jan 8 at 12:50
@RubberStamp I think you are misunderstanding how hard drives store data. When you write a zero or a one, you aren't writing that literal bit to the disk due to a heavy amount of modulation (a null sector will be physically written as a pseudorandom stream of 512 bits with a few extra bits for ECC). Furthermore even if you did, a zero is not the absence of a bit. They are nothing more than flipped magnetic polarization. Which is one and which is zero is completely arbitrary. This has been true since MFM drives and still is today.
– forest
Jan 8 at 12:58
Due to the modulation, flipping 0→0 or 1→1 is exactly as "destructive" to the bit 0→1 or 1→0.
– forest
Jan 8 at 13:05
|
show 13 more comments
You don't need ddrescue for this. You can use plain dd and make it print progress when wiping:
dd if=/dev/urandom of=/dev/sdX bs=256k 2>/media/usb/progress.txt &
while kill -USR1 $!; do sleep 10; done
This will begin wiping the disk, sending the process to the background, and then telling it to write its progress to a log file kept on a USB stick every 10 seconds. If the power is cut, you will be able to see approximately where it was left off, and then will be able to resume wiping from that position:
dd if=/dev/urandom of=/dev/sdX bs=256k seek=<number of records>
A single pass overwrite with random data is sufficient to make all data unrecoverable.
answered Jan 8 at 8:51
forestforest
55212
It depends on what standard and/or attack the OP is concerned about ... Mil-STD does several writes and also uses algorithmic write patterns across the disk itself ... Certifying that all data are not readable from the surface of a disk even under an electron microscope... Gutmann wipe ... Those COMSEC custodians can be rather difficult to work around...
– RubberStamp
Jan 8 at 11:49
@RubberStamp That is an old data destruction myth that has been retracted by the author himself. On modern high-density hard drives, a single pass with random data is sufficient to make it unreadable with any technology. Consider the fact that even low-density analog audio tape cannot be recovered after a single overwrite. As for the relevant government standards, those no longer specify multiple overwrites and instead demand physical destruction to get around the risk of damaged unwritable sectors retaining data.
– forest
Jan 8 at 12:12
Using/dev/urandomas the one and only write across the drive does not guarantee that all bits are flipped. So, the premise of your claim in your comment to the OP is not accurate... A 35 pass Gutmann is the extreme... a single pass pseudo-random write is worse than writing all ones in a single pass... Writing all zeros as a first pass would allow the OP to seek through the drive until the first non-zero bit and restart the zero process... Using a pre-built wiping program ensures that someone "out-there" has thought more deeply about the security of the algorithm than the non-expert.
– RubberStamp
Jan 8 at 12:50
@RubberStamp I think you are misunderstanding how hard drives store data. When you write a zero or a one, you aren't writing that literal bit to the disk due to a heavy amount of modulation (a null sector will be physically written as a pseudorandom stream of 512 bits with a few extra bits for ECC). Furthermore even if you did, a zero is not the absence of a bit. They are nothing more than flipped magnetic polarization. Which is one and which is zero is completely arbitrary. This has been true since MFM drives and still is today.
– forest
Jan 8 at 12:58
Due to the modulation, flipping 0→0 or 1→1 is exactly as "destructive" to the bit 0→1 or 1→0.
– forest
Jan 8 at 13:05
|
show 13 more comments
You don't need ddrescue for this. You can use plain dd and make it print progress when wiping:
dd if=/dev/urandom of=/dev/sdX bs=256k 2>/media/usb/progress.txt &
while kill -USR1 $!; do sleep 10; done
This will begin wiping the disk, sending the process to the background, and then telling it to write its progress to a log file kept on a USB stick every 10 seconds. If the power is cut, you will be able to see approximately where it was left off, and then will be able to resume wiping from that position:
dd if=/dev/urandom of=/dev/sdX bs=256k seek=<number of records>
A single pass overwrite with random data is sufficient to make all data unrecoverable.
answered Jan 8 at 8:51
forestforest
55212
You don't need ddrescue for this. You can use plain dd and make it print progress when wiping:
dd if=/dev/urandom of=/dev/sdX bs=256k 2>/media/usb/progress.txt &
while kill -USR1 $!; do sleep 10; done
This will begin wiping the disk, sending the process to the background, and then telling it to write its progress to a log file kept on a USB stick every 10 seconds. If the power is cut, you will be able to see approximately where it was left off, and then will be able to resume wiping from that position:
dd if=/dev/urandom of=/dev/sdX bs=256k seek=<number of records>
A single pass overwrite with random data is sufficient to make all data unrecoverable.
answered Jan 8 at 8:51
forestforest
55212
edited Jan 8 at 13:20
answered Jan 8 at 8:51
forestforest
55212
answered Jan 8 at 8:51
forestforest
55212
answered Jan 8 at 8:51
forestforest
55212
55212
It depends on what standard and/or attack the OP is concerned about ... Mil-STD does several writes and also uses algorithmic write patterns across the disk itself ... Certifying that all data are not readable from the surface of a disk even under an electron microscope... Gutmann wipe ... Those COMSEC custodians can be rather difficult to work around...
– RubberStamp
Jan 8 at 11:49
@RubberStamp That is an old data destruction myth that has been retracted by the author himself. On modern high-density hard drives, a single pass with random data is sufficient to make it unreadable with any technology. Consider the fact that even low-density analog audio tape cannot be recovered after a single overwrite. As for the relevant government standards, those no longer specify multiple overwrites and instead demand physical destruction to get around the risk of damaged unwritable sectors retaining data.
– forest
Jan 8 at 12:12
Using/dev/urandomas the one and only write across the drive does not guarantee that all bits are flipped. So, the premise of your claim in your comment to the OP is not accurate... A 35 pass Gutmann is the extreme... a single pass pseudo-random write is worse than writing all ones in a single pass... Writing all zeros as a first pass would allow the OP to seek through the drive until the first non-zero bit and restart the zero process... Using a pre-built wiping program ensures that someone "out-there" has thought more deeply about the security of the algorithm than the non-expert.
– RubberStamp
Jan 8 at 12:50
@RubberStamp I think you are misunderstanding how hard drives store data. When you write a zero or a one, you aren't writing that literal bit to the disk due to a heavy amount of modulation (a null sector will be physically written as a pseudorandom stream of 512 bits with a few extra bits for ECC). Furthermore even if you did, a zero is not the absence of a bit. They are nothing more than flipped magnetic polarization. Which is one and which is zero is completely arbitrary. This has been true since MFM drives and still is today.
– forest
Jan 8 at 12:58
Due to the modulation, flipping 0→0 or 1→1 is exactly as "destructive" to the bit 0→1 or 1→0.
– forest
Jan 8 at 13:05
|
show 13 more comments
It depends on what standard and/or attack the OP is concerned about ... Mil-STD does several writes and also uses algorithmic write patterns across the disk itself ... Certifying that all data are not readable from the surface of a disk even under an electron microscope... Gutmann wipe ... Those COMSEC custodians can be rather difficult to work around...
– RubberStamp
Jan 8 at 11:49
@RubberStamp That is an old data destruction myth that has been retracted by the author himself. On modern high-density hard drives, a single pass with random data is sufficient to make it unreadable with any technology. Consider the fact that even low-density analog audio tape cannot be recovered after a single overwrite. As for the relevant government standards, those no longer specify multiple overwrites and instead demand physical destruction to get around the risk of damaged unwritable sectors retaining data.
– forest
Jan 8 at 12:12
Using/dev/urandomas the one and only write across the drive does not guarantee that all bits are flipped. So, the premise of your claim in your comment to the OP is not accurate... A 35 pass Gutmann is the extreme... a single pass pseudo-random write is worse than writing all ones in a single pass... Writing all zeros as a first pass would allow the OP to seek through the drive until the first non-zero bit and restart the zero process... Using a pre-built wiping program ensures that someone "out-there" has thought more deeply about the security of the algorithm than the non-expert.
– RubberStamp
Jan 8 at 12:50
@RubberStamp I think you are misunderstanding how hard drives store data. When you write a zero or a one, you aren't writing that literal bit to the disk due to a heavy amount of modulation (a null sector will be physically written as a pseudorandom stream of 512 bits with a few extra bits for ECC). Furthermore even if you did, a zero is not the absence of a bit. They are nothing more than flipped magnetic polarization. Which is one and which is zero is completely arbitrary. This has been true since MFM drives and still is today.
– forest
Jan 8 at 12:58
Due to the modulation, flipping 0→0 or 1→1 is exactly as "destructive" to the bit 0→1 or 1→0.
– forest
Jan 8 at 13:05
It depends on what standard and/or attack the OP is concerned about ... Mil-STD does several writes and also uses algorithmic write patterns across the disk itself ... Certifying that all data are not readable from the surface of a disk even under an electron microscope... Gutmann wipe ... Those COMSEC custodians can be rather difficult to work around...
– RubberStamp
Jan 8 at 11:49
It depends on what standard and/or attack the OP is concerned about ... Mil-STD does several writes and also uses algorithmic write patterns across the disk itself ... Certifying that all data are not readable from the surface of a disk even under an electron microscope... Gutmann wipe ... Those COMSEC custodians can be rather difficult to work around...
– RubberStamp
Jan 8 at 11:49
@RubberStamp That is an old data destruction myth that has been retracted by the author himself. On modern high-density hard drives, a single pass with random data is sufficient to make it unreadable with any technology. Consider the fact that even low-density analog audio tape cannot be recovered after a single overwrite. As for the relevant government standards, those no longer specify multiple overwrites and instead demand physical destruction to get around the risk of damaged unwritable sectors retaining data.
– forest
Jan 8 at 12:12
@RubberStamp That is an old data destruction myth that has been retracted by the author himself. On modern high-density hard drives, a single pass with random data is sufficient to make it unreadable with any technology. Consider the fact that even low-density analog audio tape cannot be recovered after a single overwrite. As for the relevant government standards, those no longer specify multiple overwrites and instead demand physical destruction to get around the risk of damaged unwritable sectors retaining data.
– forest
Jan 8 at 12:12
Using
/dev/urandom as the one and only write across the drive does not guarantee that all bits are flipped. So, the premise of your claim in your comment to the OP is not accurate... A 35 pass Gutmann is the extreme... a single pass pseudo-random write is worse than writing all ones in a single pass... Writing all zeros as a first pass would allow the OP to seek through the drive until the first non-zero bit and restart the zero process... Using a pre-built wiping program ensures that someone "out-there" has thought more deeply about the security of the algorithm than the non-expert.– RubberStamp
Jan 8 at 12:50
Using
/dev/urandom as the one and only write across the drive does not guarantee that all bits are flipped. So, the premise of your claim in your comment to the OP is not accurate... A 35 pass Gutmann is the extreme... a single pass pseudo-random write is worse than writing all ones in a single pass... Writing all zeros as a first pass would allow the OP to seek through the drive until the first non-zero bit and restart the zero process... Using a pre-built wiping program ensures that someone "out-there" has thought more deeply about the security of the algorithm than the non-expert.– RubberStamp
Jan 8 at 12:50
@RubberStamp I think you are misunderstanding how hard drives store data. When you write a zero or a one, you aren't writing that literal bit to the disk due to a heavy amount of modulation (a null sector will be physically written as a pseudorandom stream of 512 bits with a few extra bits for ECC). Furthermore even if you did, a zero is not the absence of a bit. They are nothing more than flipped magnetic polarization. Which is one and which is zero is completely arbitrary. This has been true since MFM drives and still is today.
– forest
Jan 8 at 12:58
@RubberStamp I think you are misunderstanding how hard drives store data. When you write a zero or a one, you aren't writing that literal bit to the disk due to a heavy amount of modulation (a null sector will be physically written as a pseudorandom stream of 512 bits with a few extra bits for ECC). Furthermore even if you did, a zero is not the absence of a bit. They are nothing more than flipped magnetic polarization. Which is one and which is zero is completely arbitrary. This has been true since MFM drives and still is today.
– forest
Jan 8 at 12:58
Due to the modulation, flipping 0→0 or 1→1 is exactly as "destructive" to the bit 0→1 or 1→0.
– forest
Jan 8 at 13:05
Due to the modulation, flipping 0→0 or 1→1 is exactly as "destructive" to the bit 0→1 or 1→0.
– forest
Jan 8 at 13:05
|
show 13 more comments
Can you elaborate a bit? Is this a theoretical question or are you already using
ddrescue? If you are using it - what exactly are you doing? I can think of ways to wipe a hard drive with ddrescue but it's not what it was designed to do...– frostschutz
Jan 7 at 17:02
@frostschutz - I have updated the question with a post that touches on the use of
ddrescue.– Motivated
Jan 7 at 17:39
If want to quickly zero a disk, don't use
/dev/urandomas a first pass. It's probably better to fill the drive with zero bits first. That will destroy almost all the data very quickly... then do the random bit flipping... with a final flip back to zero.... Unless you are looking for MIL-spec procedures... and for that I would recommend using something like wipe ... but definitely not manually runddcommands.– RubberStamp
Jan 7 at 18:40
@RubberStamp - Can you reference an authoritative source that touches on writing zeros first? References such as Arch Linux for example (wiki.archlinux.org/index.php/…) suggest otherwise. It also appears that
wipeis no longer maintained - (wiki.archlinux.org/index.php/Securely_wipe_disk#wipe). Why do you say not to manually runddcommands?– Motivated
Jan 8 at 5:22
@RubberStamp You actually don't need to do multiple wipes. It's totally fine to do a single overwrite.
– forest
Jan 8 at 8:23