Difference between revisions of "Talk:Securely wipe disk"

From ArchWiki
Jump to: navigation, search
(Logical emulation of block size: fdisk does it / updated Section on fdisk)
m (Badblocks insecure: edit html --> wiki-formatting / remove unneded spaces and newlines (makes the version-diff look ugly))
Line 51: Line 51:
  
 
=== Badblocks insecure ===
 
=== Badblocks insecure ===
I wrote this down at the Gentoo wiki. Since I've been getting into Arch I thought I would share...<br />
+
I wrote this down at the Gentoo wiki. Since I've been getting into Arch I thought I would share...
Here's an example<br />
+
  
If you write to a device with the command...<br />
+
Here's an example:
''<nowiki>/sbin/badblocks -c 10240 -s -w -t random -v /dev/loop0</nowiki>''<br />
+
... or somthing similar as recommended in many places.<br />
+
  
Then...<br />
+
If you write to a device with the command...
''xxd /dev/loop0''<br />
+
# /sbin/badblocks -c 10240 -s -w -t random -v /dev/loop0
 +
... or somthing similar as recommended in many places.
 +
 
 +
Then...
 +
# xxd /dev/loop0
 
  ---SNIP---
 
  ---SNIP---
 
  002e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
 
  002e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
Line 73: Line 74:
 
  ---SNIP---
 
  ---SNIP---
  
Then... looking for the data at 0x002e800...<br />
+
Then... looking for the data at 0x002e800...
''xxd /dev/loop0 | grep "214c 2113 01ce 9965 3253 134a da50 99dd"''<br />
+
# xxd /dev/loop0 | grep "214c 2113 01ce 9965 3253 134a da50 99dd"
You'll get<br />
+
You'll get
 
  ---SNIP---
 
  ---SNIP---
 
  002e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
 
  002e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
Line 96: Line 97:
 
This guy is correct. Remember badblocks is a random '''pattern''' it just repeats its randomness over and over again.  
 
This guy is correct. Remember badblocks is a random '''pattern''' it just repeats its randomness over and over again.  
  
 +
0800000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 +
1200000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 +
1c00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 +
2600000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 +
3000000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''0''
 +
3a00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''A''
 +
4400000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''4''
 +
4e00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''e''
 +
5800000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 +
6200000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 +
6c00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 +
7600000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 +
8000000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 +
8a00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 +
9400000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 +
9e00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 +
a800000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 +
b200000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 +
bc00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 +
c600000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''0''
 +
d000000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''a''
 +
da00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''4''
 +
e400000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''e''
 +
ee00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 +
10200000:cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
  
  0800000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
+
As you can see the pattern is repeating and it isn't very long between each time it repeats. This hardly makes it any more secure. --[[User:Tama00|Tama00]] 15:11, 19 November 2010 (EST)
  1200000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
+
  1c00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
+
  2600000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
+
  3000000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''0''
+
  3a00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''A''
+
  4400000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''4''
+
  4e00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''e''
+
  5800000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
+
  6200000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
+
  6c00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
+
  7600000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
+
  8000000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
+
  8a00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
+
  9400000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
+
  9e00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
+
  a800000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
+
  b200000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
+
  bc00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
+
  c600000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''0''
+
  d000000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''a''
+
  da00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''4''
+
  e400000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''e''
+
  ee00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
+
  10200000:cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
+
 
+
 
+
As you can see the pattern is repeating and it isn't very long between each time it repeats. This hardly makes it any more secure.
+
 
+
--[[User:Tama00|Tama00]] 15:11, 19 November 2010 (EST)
+
 
: Warning is added to the article. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 03:22, 8 June 2012 (UTC)
 
: Warning is added to the article. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 03:22, 8 June 2012 (UTC)
 
:: Wouldn't it make more sense to completely remove it from the article instead? Seeing as it apparently provides no security benefit compared to using zero bytes... --[[User:Sas|Sas]] ([[User talk:Sas|talk]]) 12:39, 4 July 2012 (UTC)
 
:: Wouldn't it make more sense to completely remove it from the article instead? Seeing as it apparently provides no security benefit compared to using zero bytes... --[[User:Sas|Sas]] ([[User talk:Sas|talk]]) 12:39, 4 July 2012 (UTC)
 
::: At the same time, using badblock to erase data has no major problem. In Arch the decision should be made by users themself. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 04:41, 5 July 2012 (UTC)
 
::: At the same time, using badblock to erase data has no major problem. In Arch the decision should be made by users themself. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 04:41, 5 July 2012 (UTC)

Revision as of 09:33, 1 October 2012

Average block size

Based on my intuition I agree with Nonix's statement in the Accuracy template, which is located at the top of the Overwrite the disk section. A common block size of 4096 bytes is equivalent to 4KB. ~ Filam (talk) 03:29, 21 September 2012 (UTC)

Just fixed it!
(For the record only: The article suggested using blocksizes of 4MB!) --Nonix (talk) 10:55, 21 September 2012 (UTC)
Badblocks per default does test 64 KB in 1 KB blocks at a time. Here it's suggested up to now to test 10 MB in 1 KB blocks. (-c 10240) Is something wrong with the general aim of the #Block size section to align blocksize to physical geometry and write it block by block? Or is this aimed at no-HDD Storage? Note what Wikipedia has to say in the matter. On the other hand they say only "scan"-speed, not writing speed. Review is needed here. --Nonix (talk) 00:06, 27 September 2012 (UTC)

Logical emulation of block size

I was unsure about the capabilities of dumpe2fs, so i wrote a new accuracy-TP. It works on Filesystem-layer so i think it's not suitable for 512e. Besides it assumes a working filesystem directly written on the device. Feel free to remove the Template if you know better. :) --Nonix (talk) 10:55, 21 September 2012 (UTC)

I removed Nonix's Accuracy template regarding logical emulation of block size since the article does not reference it. Therefore the accuracy of the article is not in question. However, it is a fair point of discussion. Nonix wrote:
Does dumpe2fs recognize 512e-discs? (4K physical sectors on the drive media with 512 byte logical emulation)
~ Filam (talk) 14:17, 21 September 2012 (UTC)


I updated the Section on fdisk. Fdisk should be the standard tool for the logical and physical Sector size printing-job. It can detect 512e as I read in a magazine tough I don't know if it always does. Any objections? --Nonix (talk) 11:01, 27 September 2012 (UTC)

Moved contributions from Talk:Dm-crypt_with_LUKS

How about including shred instead of or along with badblocks

I just used it recently and it worked great.

 # shred -v -n 1 /dev/sdb
 ...
 shred: /dev/sdb: pass 1/1 (random)...572GiB/932GiB 61%
 shred: /dev/sdb: pass 1/1 (random)...573GiB/932GiB 61%
 shred: /dev/sdb: pass 1/1 (random)...574GiB/932GiB 62%
 shred: /dev/sdb: pass 1/1 (random)...575GiB/932GiB 62%
 shred: /dev/sdb: pass 1/1 (random)...576GiB/932GiB 63%

Are there any objections or complaints about this tool? My experience was that it was A LOT faster then using /dev/random as well, and it provides display to the user of the progress. Id say it should be the first recommended option. MrSk1yj8 (talk) 29 July 2012

I agree and took the freedom to add shred. However, the random source is an intrinsic to dm-crypt. A great feature of shred is that you can choose to use a random source other than the default (see wiki example). So you can actually use /dev/urandom or whatever you prefer. That (together with -v progress view) makes it a great replacement to dd in my view. --Indigo (talk) 20:23, 17 September 2012 (UTC)

on the bashing of /dev/urandom

I don't take an opinion on whether old overwritten data can be read.

However, there is an unrelated reason to fill a LUKS partition from /dev/urandom before LUKS-initializing it (and after checking for bad blocks if you wanted to do that).

It makes it harder for people trying to read your disk and find out what's on it. If you filled it with zeroes, for example, then they would be able to tell which portions of the partition had been written to since you initialized it.

compate gentoo docs, http://en.gentoo-wiki.com/wiki/DM-Crypt_with_LUKS#Filling_the_disk_with_random_data

Idupree 22:45, 3 March 2010 (EST)

Agreed, /dev/urandom should be used to clear partitions, at least as default in the examples. If anyone wants to zero the partitions instead of using random data, they are free to do so. --Montschok 20:53, 11 August 2010 (EDT)

Badblocks insecure

I wrote this down at the Gentoo wiki. Since I've been getting into Arch I thought I would share...

Here's an example:

If you write to a device with the command...

# /sbin/badblocks -c 10240 -s -w -t random -v /dev/loop0

... or somthing similar as recommended in many places.

Then...

# xxd /dev/loop0
---SNIP---
002e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
002e810: 1a18 a663 0b58 0e53 054f b72f 8058 d7a1  ...c.X.S.O./.X..
002e820: a4f8 b5a5 c74e 0bf9 a11e 447b 6edd 5888  .....N....D{n.X.
002e830: f5fe ec00 56fa 535c 490b 8bc9 6363 6b07  ....V.S\I...cck.
002e840: 5b20 ac22 6eb7 1c0f d560 8a43 3de2 cc32  [ ."n....`.C=..2
002e850: e0b8 3236 b286 92fc 911e c5f4 8130 fbdc  ..26.........0..
002e860: 50a7 ffbe 5f1b cd34 7b57 78b8 3944 ea19  P..._..4{Wx.9D..
002e870: fc1c 50ae a2e2 aa33 0070 2781 a022 5ef1  ..P....3.p'.."^.
002e880: ca5d af29 787d 5df3 d4d5 ab0e 1995 2715  .].)x}].......'.
002e890: b177 c454 5a6e 875a deaf dc7f d13a 709b  .w.TZn.Z.....:p.
---SNIP---

Then... looking for the data at 0x002e800...

# xxd /dev/loop0 | grep "214c 2113 01ce 9965 3253 134a da50 99dd"

You'll get

---SNIP---
002e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
0a2e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
142e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
1e2e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
282e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
322e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
3c2e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
462e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
502e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
5a2e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
642e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
6e2e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
---SNIP---

Tell me if I'm wrong, but that kinda seems to defeat the purpose of randomizing the HDD

--

This guy is correct. Remember badblocks is a random pattern it just repeats its randomness over and over again.

0800000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
1200000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
1c00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
2600000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
3000000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. 0
3a00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. A
4400000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. 4
4e00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. e
5800000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
6200000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
6c00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
7600000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
8000000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
8a00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
9400000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
9e00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
a800000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
b200000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
bc00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
c600000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. 0
d000000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. a
da00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. 4
e400000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. e
ee00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
10200000:cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.

As you can see the pattern is repeating and it isn't very long between each time it repeats. This hardly makes it any more secure. --Tama00 15:11, 19 November 2010 (EST)

Warning is added to the article. -- Fengchao (talk) 03:22, 8 June 2012 (UTC)
Wouldn't it make more sense to completely remove it from the article instead? Seeing as it apparently provides no security benefit compared to using zero bytes... --Sas (talk) 12:39, 4 July 2012 (UTC)
At the same time, using badblock to erase data has no major problem. In Arch the decision should be made by users themself. -- Fengchao (talk) 04:41, 5 July 2012 (UTC)