[clue] bizarre block size Was Related To: secure erase techniques?

[marcus hall]

On Tue, May 31, 2011 at 05:30:24PM +0200, Raymond DeRoo wrote:
> Folks--
> 
> A few have asked me why I choose the options to dd that I provided. Since enough asked I thought a reply to the list would be in order, for those not overly interested in techno mumbo jumbo please make judicious use of your DELETE key.
> 
> 
> Let my start by saying there was an error in the line I provided, it should have used 383 for both values and not 387. So question still remains "why"?
> 
> Depend upon your distro a default block sizing of either 512 or 1024 will used by when non is provided. Additionally most applications and file system also allocate space on byte boundaries. Remembering that the goal here is to scramble the data, and to help reduce the "magnetic ghost image", I choose a non-standard block size. So why the value of 383 specifically? Well it changes each time I need to do this, but I nearly always choose a value that is a prime number. Now the value being prime does not, in and of itself, lead to any greater amount of security, but having the data aligned on non-standard boundaries does make the work of recovery specialist all the more difficult. 
> 

You do realize that by the time the data gets to the device, the OS combines
the fragments of the blocks and writes the data to the disk in complete blocks
anyhow, right?  There used to be a "raw access device" that allowed direct
I/O to block devices bypassing the block buffers, but even then if you were
to send unaligned and partial writes to the disk drive, the controller on the
drive would perform the same read/update/write access and write full blocks
to the disk platter, so in the end I don't think that it would really make
any difference in what the result on the disk is...

Also, there really is no need to supply a count= parameter to dd in this
case, since it will continue to write blocks until the write fails, which
should be at the end of the disk...

marcus hall
marcus at tuells.org