[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cryptsetup problem

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

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
100+0 records in
100+0 records out
100 bytes (100 B) copied, 0.000862184 s, 116 kB/s

# # 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
100+0 records in
100+0 records out
100 bytes (100 B) copied, 0.000932854 s, 107 kB/s



Reply to: