Re: [dm-crypt] Asustor NAS and cryptsetup 1.6.1

["msalists@gmx.net" <msalists@gmx.net>]

Hi Arno,

thank you for your explanations


>> Furthermore, using "cryptsetup status EncTest.1" to show some basics
>> about the created test container shows this:
>> /dev/mapper/EncTest.1 is active and is in use.
>>    type:    PLAIN
>>    cipher:  aes-cbc-plain
>>    keysize: 256 bits
>>    device:  /dev/loop0
>>    loop:    /volume1/.@loopfiles/EncTest
>>    offset:  0 sectors
>>    size:    11619787984 sectors
>>    mode:    read/write
>>
>> Is this a plausible setup that makes sense, or is there something
>> wrong with this default?
> CBC-plain has a fingerprint-leackage issue (a specially prepared
> file can be seen from outside the encryption without using the
> key). Better use aes-cbc-essiv:sha256, the current default.
There are two things that are happening by means of the NAS web admin 
interface: the creation (one-time) and the mounting (daily).
For creating the container, I could log into the ssh shell as root and 
create the container manually and overwrite the default by specifying 
aes-cbc-essiv:sha256
However, subsequently mounting the container should happen through the 
web interface; doing it via ssh every time would be a pain.

Assuming I did create the container with aes-cbc-essiv:sha256; would 
cryptsetup automatically figure out the correct parameters when it is 
subsequently called without those parameters to mount the container?
Or do non-default parameters at creation time require the same 
non-default parameters again for subsequent mounts?

>> I have found out a few things that are making me a bit nervous:
>> 1. The initially created empty container is "huge": it uses up 45GB
>> without me storing any data inside!
> Why do you think this is an issue? This is block-device encryption,
> the container does not shrink or grow, it is created in its final size.

Well, not an issue as in "a real problem"; it's just a waste of space as 
I expect to never use more than 5% of that.
It also means that backups by means of just copying the entire encrypted 
container file requires a lot more (again wasted) space - or bandwidth 
in case of cloud storage.
I guess I could work around this issue again by manually creating the 
container.


>> 2. The management interface does not seem to offer any way to create
>> or download backups of the encryption headers for backup purposes as
>> suggested in https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#6._Backup_and_Data_Recovery.
> PLAIN does not have headers. For that you need LUKS.
Ok, I guess if there arent any headers, then I don't need to worry about 
backing them up or damaging them :-) . So as long as I don't forget the 
password, I'll be fine...

Thank you,

Mark