[dm-crypt] Asustor NAS and cryptsetup 1.6.1

Claudio Moretti flyingstar16 at gmail.com
Tue Dec 30 01:37:00 CET 2014

Hi Mark,

my 2c regarding 3.: you might try - if the NAS allows you to - cd to / and

$ grep -rl YourPassword *

I hope it doesn't work, but if it does at least you'll know where your
password is stored (in cleartext)...



On Mon, Dec 29, 2014 at 8:06 PM, msalists at gmx.net <msalists at gmx.net> wrote:

> 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/. at 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
> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20141230/6e14e0a4/attachment.html>

More information about the dm-crypt mailing list