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
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.
Reply to: