[dm-crypt] Asustor NAS and cryptsetup 1.6.1

[dm-crypt] Asustor NAS and cryptsetup 1.6.1

[msalists]

Hello,

sorry for my original post, did not mean it to come across as HTML. Here 
it is again in plain-text (hopefully!!!)...

I am new to cryptsetup and trying to figure out some things.
The background: I purchased an Asustore AS-304T NAS device that uses 
cryptsetup to set up encrypted shared folders.
I am trying to make sure that I will be able to access all my data on 
the disks outside of the NAS device using a regular PC with linux 
installed, in case the NAS device itself fails and I need to get to my data.
I will probably post some questions about this later.

For now, I have a question about the version of cryptsetup used by the 
device.
I have set up a test system with a RAID1 volume and an encrypted folder 
on it using the regular Asustor maintenance interface.
Logging in to the device as root, "cryptsetup --version" shows 
"cryptsetup 1.6.1" as installed version.

Thus my first question: I saw that the current version seems to be 1.6.6
What is the status of 1.6.1? Is it a stable production release that can 
be used without problems? Or are there critical issues that would 
require using a newer version than 1.6.1 ? I went through the release 
notes of the versions above 1.6.1, but it is not clear how critical the 
fixes/changes since version 1.6.1 are
Also, what other sub-components or libraries besides cryptsetup should I 
check?

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?
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!
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.
3. There is an "auto-mount"option for encrypted folders that allow 
shutting down and rebooting the device without having to re-enter the 
encryption pass-phrase in order to access the encrypted folder - it is 
just there and mounted automatically. Not sure if this is still 
"secure"" or if this means that my pass-phrase is stored somewhere on 
the device in clear unencrypted form (I suspect the latter).

So I am wondering if there are things in their setup that are 
fundamentally flawed.

Thank you in advance!

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

[Arno Wagner]

On Sat, Dec 27, 2014 at 08:47:10 CET, msalists@gmx.net wrote:
> Hello,
> 
> sorry for my original post, did not mean it to come across as HTML.
> Here it is again in plain-text (hopefully!!!)...

Yes, fine now.
 
> I am new to cryptsetup and trying to figure out some things.
> The background: I purchased an Asustore AS-304T NAS device that uses
> cryptsetup to set up encrypted shared folders.
> I am trying to make sure that I will be able to access all my data
> on the disks outside of the NAS device using a regular PC with linux
> installed, in case the NAS device itself fails and I need to get to
> my data.
> I will probably post some questions about this later.
> 
> For now, I have a question about the version of cryptsetup used by
> the device.
> I have set up a test system with a RAID1 volume and an encrypted
> folder on it using the regular Asustor maintenance interface.
> Logging in to the device as root, "cryptsetup --version" shows
> "cryptsetup 1.6.1" as installed version.
> 
> Thus my first question: I saw that the current version seems to be 1.6.6
> What is the status of 1.6.1? Is it a stable production release that
> can be used without problems? Or are there critical issues that
> would require using a newer version than 1.6.1 ? I went through the
> release notes of the versions above 1.6.1, but it is not clear how
> critical the fixes/changes since version 1.6.1 are
> Also, what other sub-components or libraries besides cryptsetup
> should I check?

It works a bit different for cryptsetup: The on-disk format
hasd been stable for a long time. The only thing that changed 
a while back are the defaults, most notably that LUKS
moved to AES-XTS. You can use any 1.6.x version interchangeably 
without securty issues, as long as you stick to the defaults.
If in doubt, read the release-notes here:
  http://code.google.com/p/cryptsetup/wiki/Cryptsetup166

FAQ Section 8 also has some issues (AFAIK all known ones):
  http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions

> 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.

> 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.

> 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.

> 3. There is an "auto-mount"option for encrypted folders that allow
> shutting down and rebooting the device without having to re-enter
> the encryption pass-phrase in order to access the encrypted folder -
> it is just there and mounted automatically. Not sure if this is
> still "secure"" or if this means that my pass-phrase is stored
> somewhere on the device in clear unencrypted form (I suspect the
> latter).

I do too. In fact, this option is a red flag that there is likely
something very wrong with the implementation and that convenience
was (as so often in consumer-devices) prioritized over security.

> So I am wondering if there are things in their setup that are
> fundamentally flawed.

I have no idea about that specific device, but 3. is highly
suspicuous and 2. probably means that they either have no
password management or that they implemented something possibly
flawed themselves.

Arno

> Thank you in advance!
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

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

[msalists]

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

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

[Quentin Lefebvre]

On 29/12/2014 20:06, msalists@gmx.net wrote :
> 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?

As you may have understood, in plain mode, there is no header, so no way 
for cryptsetup to guess the algorithm used. Thus, if it is a non-default 
one, it must be specified also at mount time.

Best regards,
Quentin

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

[msalists]

On 2014-12-29 11:29, Quentin Lefebvre wrote:
> On 29/12/2014 20:06, msalists@gmx.net wrote :
>> 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?
>
> As you may have understood, in plain mode, there is no header, so no 
> way for cryptsetup to guess the algorithm used. Thus, if it is a 
> non-default one, it must be specified also at mount time.
>

Hm, makes sense. Is there some kind of a config file that I could 
specify the parameters in, and that would be read prior to using the 
defaults - similar to how some parameters for mount can be specified in 
/etc/fstab ?

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

[msalists]

They are reluctant to give out any details, but are saying that they 
will be releasing a new version of their software in the coming weeks 
that uses ecryptfs instead.
Is this a step forward or backward (or rather just "sideways")?

Mark

On 2014-12-30 02:04, Arno Wagner wrote:
> On Tue, Dec 30, 2014 at 03:32:58 CET, msalists@gmx.net wrote:
>> On 2014-12-29 11:29, Quentin Lefebvre wrote:
>>> On 29/12/2014 20:06, msalists@gmx.net wrote :
>>>> 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?
>>> As you may have understood, in plain mode, there is no header, so
>>> no way for cryptsetup to guess the algorithm used. Thus, if it is
>>> a non-default one, it must be specified also at mount time.
>>>
>> Hm, makes sense. Is there some kind of a config file that I could
>> specify the parameters in, and that would be read prior to using the
>> defaults - similar to how some parameters for mount can be specified
>> in /etc/fstab ?
> Only if the NAS-makers added one. cryptsetup does not have
> a mechanism for this.
>
> Arno

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

[Sven Eschenberg]

Hummm, good question.

I think backwards. ecryptfs basicly does a per file encryption. So you'll
have a normal filesystem which holds encrypted files. The downside is bad
performance as it uses FUSE, it potentiolly discloses the structure of the
filesystem (while filenames are scrambled the tree structure is visible).
It is easier to backup as you can easily backup the encrypted files and do
not need to dump the whole block device. (The price for this is disclosing
the fs structure)

Regards

-Sven


On Tue, December 30, 2014 19:18, msalists@gmx.net wrote:
> They are reluctant to give out any details, but are saying that they
> will be releasing a new version of their software in the coming weeks
> that uses ecryptfs instead.
> Is this a step forward or backward (or rather just "sideways")?
>
> Mark
>
> On 2014-12-30 02:04, Arno Wagner wrote:
>> On Tue, Dec 30, 2014 at 03:32:58 CET, msalists@gmx.net wrote:
>>> On 2014-12-29 11:29, Quentin Lefebvre wrote:
>>>> On 29/12/2014 20:06, msalists@gmx.net wrote :
>>>>> 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?
>>>> As you may have understood, in plain mode, there is no header, so
>>>> no way for cryptsetup to guess the algorithm used. Thus, if it is
>>>> a non-default one, it must be specified also at mount time.
>>>>
>>> Hm, makes sense. Is there some kind of a config file that I could
>>> specify the parameters in, and that would be read prior to using the
>>> defaults - similar to how some parameters for mount can be specified
>>> in /etc/fstab ?
>> Only if the NAS-makers added one. cryptsetup does not have
>> a mechanism for this.
>>
>> Arno
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

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

[Arno Wagner]

ecryptfs leaks a lot of data like filenames, sizes, modifiaction 
times, etc. These can be critical. For example, sometimes 
file-sizes are misused as "fingerprints".
 
I would say definitely backwards security-wise, for possibly
some better usability.

Arno

On Tue, Dec 30, 2014 at 19:18:38 CET, msalists@gmx.net wrote:
> They are reluctant to give out any details, but are saying that they
> will be releasing a new version of their software in the coming
> weeks that uses ecryptfs instead.
> Is this a step forward or backward (or rather just "sideways")?
> 
> Mark
> 
> On 2014-12-30 02:04, Arno Wagner wrote:
> >On Tue, Dec 30, 2014 at 03:32:58 CET, msalists@gmx.net wrote:
> >>On 2014-12-29 11:29, Quentin Lefebvre wrote:
> >>>On 29/12/2014 20:06, msalists@gmx.net wrote :
> >>>>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?
> >>>As you may have understood, in plain mode, there is no header, so
> >>>no way for cryptsetup to guess the algorithm used. Thus, if it is
> >>>a non-default one, it must be specified also at mount time.
> >>>
> >>Hm, makes sense. Is there some kind of a config file that I could
> >>specify the parameters in, and that would be read prior to using the
> >>defaults - similar to how some parameters for mount can be specified
> >>in /etc/fstab ?
> >Only if the NAS-makers added one. cryptsetup does not have
> >a mechanism for this.
> >
> >Arno
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

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

[Claudio Moretti]

[-- Attachment #1: Type: text/plain, Size: 3253 bytes --]

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)...

Cheers,

Claudio

On Mon, Dec 29, 2014 at 8:06 PM, msalists@gmx.net <msalists@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/.@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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

[-- Attachment #2: Type: text/html, Size: 4892 bytes --]

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

[msalists]

Haha - I had the same idea :-)
Unfortunately, it failed with something to the extend of "there are too 
many files for me to expand the wildcard over".
I'll try some different syntax later (like a for loop over a find or so)...

I asked support and they are forwarding to R&D, so we'll see what they 
say...

Mark


On 2014-12-29 16:37, Claudio Moretti wrote:
> 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)...
>
> Cheers,
>
> Claudio
>
> On Mon, Dec 29, 2014 at 8:06 PM, msalists@gmx.net 
> <mailto:msalists@gmx.net> <msalists@gmx.net <mailto:msalists@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/.@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@saout.de <mailto:dm-crypt@saout.de>
>     http://www.saout.de/mailman/listinfo/dm-crypt
>
>
>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

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

[Arno Wagner]

Probably a BusyBox with very small shell-memory. If
you have "find", you can try something like this:

  find / -type f -exec grep YourPassword \{\} \;

Arno

On Tue, Dec 30, 2014 at 02:00:20 CET, msalists@gmx.net wrote:
> Haha - I had the same idea :-)
> Unfortunately, it failed with something to the extend of "there are
> too many files for me to expand the wildcard over".
> I'll try some different syntax later (like a for loop over a find or so)...
> 
> I asked support and they are forwarding to R&D, so we'll see what
> they say...
> 
> Mark
> 
> 
> On 2014-12-29 16:37, Claudio Moretti wrote:
> >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)...
> >
> >Cheers,
> >
> >Claudio
> >
> >On Mon, Dec 29, 2014 at 8:06 PM, msalists@gmx.net
> ><mailto:msalists@gmx.net> <msalists@gmx.net
> ><mailto:msalists@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/.@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@saout.de <mailto:dm-crypt@saout.de>
> >    http://www.saout.de/mailman/listinfo/dm-crypt
> >
> >
> >
> >
> >_______________________________________________
> >dm-crypt mailing list
> >dm-crypt@saout.de
> >http://www.saout.de/mailman/listinfo/dm-crypt
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

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

[msalists]

Yes, they use busybox

On 2014-12-29 17:46, Arno Wagner wrote:
> Probably a BusyBox with very small shell-memory. If
> you have "find", you can try something like this:
>
>    find / -type f -exec grep YourPassword \{\} \;
>
> Arno
>
> On Tue, Dec 30, 2014 at 02:00:20 CET, msalists@gmx.net wrote:
>> Haha - I had the same idea :-)
>> Unfortunately, it failed with something to the extend of "there are
>> too many files for me to expand the wildcard over".
>> I'll try some different syntax later (like a for loop over a find or so)...
>>
>> I asked support and they are forwarding to R&D, so we'll see what
>> they say...
>>
>> Mark
>>
>>
>> On 2014-12-29 16:37, Claudio Moretti wrote:
>>> 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)...
>>>
>>> Cheers,
>>>
>>> Claudio
>>>
>>> On Mon, Dec 29, 2014 at 8:06 PM, msalists@gmx.net
>>> <mailto:msalists@gmx.net> <msalists@gmx.net
>>> <mailto:msalists@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/.@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@saout.de <mailto:dm-crypt@saout.de>
>>>     http://www.saout.de/mailman/listinfo/dm-crypt
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> dm-crypt mailing list
>>> dm-crypt@saout.de
>>> http://www.saout.de/mailman/listinfo/dm-crypt
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt

[dm-crypt] Asustor NAS and cryptsetup 1.6.1

[msalists]

[-- Attachment #1: Type: text/html, Size: 3535 bytes --]

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

[Arno Wagner]

Please do not send HTML Email to this list....

On Sat, Dec 27, 2014 at 04:49:16 CET, msalists@gmx.net wrote:
> <html>
>   <head>
> 
>     <meta http-equiv="content-type" content="text/html; charset=utf-8">
>   </head>
>   <body bgcolor="#FFFFFF" text="#000000">
>     <font face="Arial">Hello,<br>
>       <br>
>       I am new to cryptsetup and trying to figure out some things.<br>
>       The background: I purchased an Asustore AS-304T NAS device that
>       uses cryptsetup to set up encrypted shared folders.<br>
>       I am trying to make sure that I will be able to access all my data
>       on the disks outside of the NAS device using a regular PC with
>       linux installed, in case the NAS device itself fails and I need to
>       get to my data.<br>
>       I will probably post some questions about this later.<br>
>       <br>
>       For now, I have a question about the version of cryptsetup used by
>       the device.<br>
>       I have set up a test system with a RAID1 volume and an encrypted
>       folder on it using the regular Asustor maintenance interface.<br>
>       Logging in to the device as root, "cryptsetup --version" shows "cryptsetup
>       1.6.1" as installed version.<br>
>       <br>
>       Thus my first question: I saw that the current version seems to be
>       1.6.6<br>
>       What is the status of 1.6.1? Is it a stable production release
>       that can be used without problems? Or are there critical issues
>       that would require using a newer version than 1.6.1 ? I went
>       through the release notes of the versions above 1.6.1, but it is
>       not clear how critical the fixes/changes since version 1.6.1 are<br>
>       Also, what other sub-components or libraries besides cryptsetup
>       should I check?<br>
>       <br>
>       Furthermore, using "cryptsetup status EncTest.1" to show some
>       basics about the created test container shows this:<br>
>       /dev/mapper/EncTest.1 is active and is in use.<br>
>         type:    PLAIN<br>
>         cipher:  aes-cbc-plain<br>
>         keysize: 256 bits<br>
>         device:  /dev/loop0<br>
>         loop:    /volume1/.@loopfiles/EncTest<br>
>         offset:  0 sectors<br>
>         size:    11619787984 sectors<br>
>         mode:    read/write<br>
>       <br>
>       Is this a plausible setup that makes sense, or is there something
>       wrong with this default?<br>
>       I have found out a few things that are making me a bit nervous:<br>
>       1. The initially created empty container is "huge":  </font><font
>       face="Arial"><font face="Arial">it uses up 4.5GB</font> without me
>       storing any data inside!<br>
>       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
> <a class="moz-txt-link-freetext" href="https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#6._Backup_and_Data_Recovery">https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#6._Backup_and_Data_Recovery</a>.<br>
>       3. There is an "auto-mount"option for encrypted folders that allow
>       shutting down and rebooting the device without having to re-enter
>       the encryption pass-phrase in order to access the encrypted folder
>       - it is just there and mounted automatically. Not sure if this is
>       still "secure"" or if this means that my pass-phrase is stored
>       somewhere on the device in clear unencrypted form (I suspect the
>       latter).<br>
>       <br>
>       So I am wondering if there are things in their setup that are
>       fundamentally flawed.<br>
>       <br>
>       Thank you in advance!<br>
>       <br>
>     </font>
>   </body>
> </html>

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


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier