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

Re: A question about cryptsetup "plain" mode.

This is due to 
a) CBC mode
b) a cipher block size larger than 1 byte

Or in short, the decryption of that 1 additional byte 
scrambles everything after it. Have a look at cipher-modes
and blockciphers to understand this better.


On Mon, Jan 30, 2012 at 10:09:20PM -0500, Matt Lee wrote:
> I understand that in plain mode, the key is derived from the passphrase.
> I did a little experimentation to try to understand how this works a little
> better, but my results were not as expected.
> I did the following:
> First I created a file for use as a test container:
> <code>dd if=/dev/urandom of=test.dd bs=1 count=1024</code>
> 1+0 records in
> 1+0 records out
> 1024 bytes (1.0 kB) copied, 0.000143915 s, 7.1 MB/s
> Next, I mapped a device using a simple passphrase:
> <code>cryptsetup create crypto test.dd</code>
> Enter passphrase: [entered passphrase "test"]
> Next, I zeroed the device:
> <code>dd if=/dev/zero of=/dev/mapper/crypto</code>
> Then I verified the the device was zeroed-out:
> <code>hexdump /dev/mapper/crypto</code>
> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0000400
> So far so good.  I unmapped the device:
> <code>cryptsetup remove crypto</code>
> Here, I made a random file with a size of 1 byte:
> <code>dd if=/dev/urandom of=whatever bs=1 count=1</code>
> 1+0 records in
> 1+0 records out
> 1 byte (1 B) copied, 1.4503e-05 s, 69.0 kB/s
> ...and attached it to the beginning of my test container:
> <code>cat whatever test.dd > test2.dd</code>
> Then, I mapped out the device again with the exact same settings as before,
> except now my test container has the one extra random byte added to the
> beginning:
> <code>cryptsetup create crypto test2.dd</code>
> Enter passphrase: [entered same passphrase "test"]
> Here is where I got the unexpected results.  Since the key is derived from
> the passphrase, I though the hexdump would show 1 byte's worth of random
> data, followed by all zeroes.  Instead, adding that one byte to the
> beginning of the container threw everything completely off, and I got all
> random data:
> <code>hexdump /dev/mapper/crypto</code>
> 0000000 93cd 77dd 88cb afa5 3797 c95f 75f0 1330
> 0000010 bb4e c250 1fde af35 39e8 5d58 f67d cb9a
> 0000020 b9ba 5227 7424 d6cf 9992 202d 5b98 f084
> ...etc, etc.
> Can anyone explain these results to me so I can better understand what is
> actually going on here?
> Thanks for your time!

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@xxxxxxxx
> http://www.saout.de/mailman/listinfo/dm-crypt

Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 
dm-crypt mailing list

[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux