On 3/06/2014 5:38 AM, ken wrote: > On 06/02/2014 03:34 PM Andrew McGlashan wrote: >> On 3/06/2014 5:25 AM, ken wrote: >>> Are you aware of FOSS 'wipe'? >> >> Yes, thanks Ken. I watched wipe go through clearing an SSH >> drive when setting up a quick test of Kali Linux on a new laptop. >> It was slow, but it worked -- when it finished, Kali had trouble >> allocating /itself/ enough root file system space, so I had to >> manually partition and try again. >> >> Anyway, wipe is best run early. I'll keep wipe in mind and the other >> tools too if the /dev/zero write gives more grief. >> >> It's still a bit too early to tell, but the /dev/zero writing is >> okay so far, but a little less than an hour in as I type .... for >> the first crypt volume. >> >> Cheers and Thanks >> A. >> > > It would be better to write /dev/random or /dev/urandom than > /dev/zero... if you want to stay with whatever it is you're using.
Well, I finally got one of the volumes complete, by starting again where it left off previously.... 2 goes and it's done, but just one volume. Below the next paragraph .... I demonstrate the effect of writing /dev/zero to the crypted device -- taking in to account that the "bulk data" begins at offset 4096*512 byte sectors. NB: if the volume is open, then yes, you can see where the data is, but if the volume is closed, then all you get is encrypted data; which does not show evidence of where actual data is residing, nor anything to let anyone know what is and what is not data inside the non-mounted crypt volume. Now if you wanted to do a full backup of the open crypt volume to a file (without filling the volume with loads of real data), you could use GPG and it will compress the heck out of the data because /dev/zero will compress well. Doing a GPG backup of the closed crypt volume would not compress well. Obviously the more /real/ data there is on the open crypt volume, the larger a GPG backup file will be. Besides, this is just for example, backing up with GPG might not be a good idea (tm). Although if you use duplicity [1], it might be an excellent idea, but I don't know enough about that yet. # # create LUKS container, avoiding /bad/ defaults # cryptsetup -c aes-xts-plain64 -s 512 -h sha512 -i 5000 -y --use-random luksFormat /dev/md2 WARNING! ======== This will overwrite data on /dev/md2 irrevocably. Are you sure? (Type uppercase yes): YES Enter LUKS passphrase: Verify passphrase: # # wire /dev/zero to first 100 characters of "bulk data" # # - outside of crypt.... (device plus offset to start) # dd if=/dev/zero of=/dev/md2 seek=2097152 bs=1 count=100 100+0 records in 100+0 records out 100 bytes (100 B) copied, 0.0296961 s, 3.4 kB/s # # show data (100 /dev/zero chars converted to base64) # # - this is INSIDE the crypt container's "bulk data" area. # dd if=/dev/md2 skip=2097152 bs=1 count=100 skip=2097152|base64 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 100+0 records in 100+0 records out 100 bytes (100 B) copied, 0.000862184 s, 116 kB/s AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== # # Open the LUKS volume # cryptsetup luksOpen /dev/md2 md2_crypt Enter passphrase for /dev/md2: # # Status of LUKS volume # cryptsetup status md2_crypt /dev/mapper/md2_crypt is active. type: LUKS1 cipher: aes-xts-plain64 keysize: 512 bits device: /dev/md2 offset: 4096 sectors size: 7767312000 sectors mode: read/write # # Now write 100 /dev/zero chars to "bulk data" directory using # # mounted crypt volume # dd if=/dev/zero of=/dev/mapper/md2_crypt bs=1 count=100 100+0 records in 100+0 records out 100 bytes (100 B) copied, 0.0331047 s, 3.0 kB/s # # Close the LUKS volume # cryptsetup luksClose md2_crypt # # Show data (the 100 chars) on raw mirror volume outside of cryptsetup # # - that is, the non-mounted LUKS volume, make sure to skip # # to "bulk data" area. # dd if=/dev/md2 skip=2097152 bs=1 count=100 skip=2097152|base64 8xIeksAUxtlwSRLZktiCEsVCuzNIUo/aDKOKOVMxOjzoWBzIwDPy4P+FFWBy7cnnqlZgsH0C74E5 4TadZM6hma5KvOg36b4E8ryVv6tF5LqGXo2bklb5Ts+5+Zp/sw2erQiyFA== 100+0 records in 100+0 records out 100 bytes (100 B) copied, 0.000932854 s, 107 kB/s [1] http://wiki.kartbuilding.net/index.php/Duplicity_-_secure_incremental_backup Cheers A. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53934d0c.7080...@affinityvision.com.au
