On 20190127 10:56:25, Wolfgang Pfeiffer wrote:
On Sun, Jan 27, 2019 at 11:32:52AM +0000, 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 means (at a minimum) reading the entire
contents and rewriting it,
No. I don't think data is written and rewritten. See below.
First off: thanks a lot, poc, for writing: because although I can't
agree with you so far on this, I found what I'd consider as being a
mistake in the procedure I suggested.
My tests show, that an external 500 GB (USB 2) disk is encrypted in
not even 10 secs (yes: 10. No typo). I think this is because
cryptsetup doesn't rewrite data from non-encrypted to encrypted. Don't
ask me why .. and the speed *might* have to do with the fact that only
~17% of the disk was filled with data
But thanks to your intervention, poc, I found that the initial command that
I quoted from the cryptsetup FAQ doesn't seem to actually encrypt the disk.
Bug? My mistake? No idea what went wrong. So I changed things.
My workaround, nearly as fast:
Create a randomly generated password key and pipe it into a file,
max. is here 8192kB (people can find the max size on their systems with
cryptsetup --help)
That's how it seems to work here - and careful everyone ofc: you
destroy a disk with some of the following:
0:
# Create the key-file:
head -c 8192K /dev/urandom > lukskey
1:
# Encrypt the disk:
cryptsetup -s 512 -d lukskey -c aes-xts-plain64 luksFormat /dev/sd[?]
# Again: didn't take 10 secs.
# Find your own favorite cipher (-c) and use it
# and re. /dev/sd[?] - yes: no partition seems being necessary to just
# destroy the disk
2:
# Check if the disk is encrypted:
cryptsetup luksDump /dev/sd[?]
3:
# And you can open the container like so:
cryptsetup -v open -d lukskey /dev/sd[?] test
Key slot 0 unlocked.
Command successful.
# Close it after usage:
cryptsetup -v close test
4:
Destroy the key, once you're finished (careful: the data on disk is
useless without it .. )
That's it. To pipe /dev/zero into that disk (I used dd), as sht. like
this was mentioned in the FAQ: with that USB2 disk here that took a
long time: ~ 53 minutes for just ~ 130 GB.
Let me know, please, in case of a mistake ..
TIA.
HTH, Regards
Wolfgang
If you really want a secure erase use dd. (bs=1M makes it very fast compared to
leaving bs unset.) During operation most OSs use filesystems that do not rewrite
using the existing blocks allocated to a file. So the old data is present on the
disk if somebody goes looking for it. If you have data important enough to
require removing it from the drive then be sure to get those blocks as well as
the ones currently used. dd is about the only way to guarantee this.
If you have an SSD even dd is not sufficient because the blocks in the spares
pool are used to replace active blocks to even out wear on the disk.
Guaranteeing those blocks are gone requires specialized software.
10 seconds to encrypt a 500G disk is not a realistic number. Something else was
going on you did not understand unless. That means the disk was reading 50
Gigabytes per second at the same time it was writing 50 Gigabytes per second.
Does that sound at all reasonable to you? A key may have been set on the drive
with the drive taking it upon itself to encrypt the data in the background.
If the cryptsetup command does not grab large chunks of disk at a time for reads
and writes dd with /dev/random and 1M or even 64M block size (bs) may be faster.
All it has to do is write with no reads. And the very large blocks pull I/O
overhead, seek times, and rotational latency out of the picture. These can kill
your speeds with a default block size of 512 bytes.
If the disk even MIGHT have an error on it and you use dd then add
"conv=noerror" to the command string.
{^_^}
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
