* [dm-crypt] Asustor NAS and cryptsetup 1.6.1
@ 2014-12-27 3:49 msalists
2014-12-27 7:38 ` Arno Wagner
0 siblings, 1 reply; 14+ messages in thread
From: msalists @ 2014-12-27 3:49 UTC (permalink / raw)
To: dm-crypt
[-- Attachment #1: Type: text/html, Size: 3535 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [dm-crypt] Asustor NAS and cryptsetup 1.6.1
2014-12-27 3:49 msalists
@ 2014-12-27 7:38 ` Arno Wagner
0 siblings, 0 replies; 14+ messages in thread
From: Arno Wagner @ 2014-12-27 7:38 UTC (permalink / raw)
To: dm-crypt
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [dm-crypt] Asustor NAS and cryptsetup 1.6.1
@ 2014-12-27 7:47 msalists
2014-12-27 10:11 ` Arno Wagner
0 siblings, 1 reply; 14+ messages in thread
From: msalists @ 2014-12-27 7:47 UTC (permalink / raw)
To: dm-crypt
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!
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [dm-crypt] Asustor NAS and cryptsetup 1.6.1
2014-12-27 7:47 [dm-crypt] Asustor NAS and cryptsetup 1.6.1 msalists
@ 2014-12-27 10:11 ` Arno Wagner
2014-12-29 19:06 ` msalists
0 siblings, 1 reply; 14+ messages in thread
From: Arno Wagner @ 2014-12-27 10:11 UTC (permalink / raw)
To: dm-crypt
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [dm-crypt] Asustor NAS and cryptsetup 1.6.1
2014-12-27 10:11 ` Arno Wagner
@ 2014-12-29 19:06 ` msalists
2014-12-29 19:29 ` Quentin Lefebvre
2014-12-30 0:37 ` Claudio Moretti
0 siblings, 2 replies; 14+ messages in thread
From: msalists @ 2014-12-29 19:06 UTC (permalink / raw)
To: dm-crypt
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [dm-crypt] Asustor NAS and cryptsetup 1.6.1
2014-12-29 19:06 ` msalists
@ 2014-12-29 19:29 ` Quentin Lefebvre
2014-12-30 2:32 ` msalists
2014-12-30 0:37 ` Claudio Moretti
1 sibling, 1 reply; 14+ messages in thread
From: Quentin Lefebvre @ 2014-12-29 19:29 UTC (permalink / raw)
To: msalists@gmx.net, dm-crypt
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [dm-crypt] Asustor NAS and cryptsetup 1.6.1
2014-12-29 19:06 ` msalists
2014-12-29 19:29 ` Quentin Lefebvre
@ 2014-12-30 0:37 ` Claudio Moretti
2014-12-30 1:00 ` msalists
1 sibling, 1 reply; 14+ messages in thread
From: Claudio Moretti @ 2014-12-30 0:37 UTC (permalink / raw)
To: msalists@gmx.net; +Cc: dm-crypt@saout.de
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [dm-crypt] Asustor NAS and cryptsetup 1.6.1
2014-12-30 0:37 ` Claudio Moretti
@ 2014-12-30 1:00 ` msalists
2014-12-30 1:46 ` Arno Wagner
0 siblings, 1 reply; 14+ messages in thread
From: msalists @ 2014-12-30 1:00 UTC (permalink / raw)
To: dm-crypt@saout.de
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [dm-crypt] Asustor NAS and cryptsetup 1.6.1
2014-12-30 1:00 ` msalists
@ 2014-12-30 1:46 ` Arno Wagner
2014-12-30 2:11 ` msalists
0 siblings, 1 reply; 14+ messages in thread
From: Arno Wagner @ 2014-12-30 1:46 UTC (permalink / raw)
To: dm-crypt
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [dm-crypt] Asustor NAS and cryptsetup 1.6.1
2014-12-30 1:46 ` Arno Wagner
@ 2014-12-30 2:11 ` msalists
0 siblings, 0 replies; 14+ messages in thread
From: msalists @ 2014-12-30 2:11 UTC (permalink / raw)
To: dm-crypt@saout.de
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [dm-crypt] Asustor NAS and cryptsetup 1.6.1
2014-12-29 19:29 ` Quentin Lefebvre
@ 2014-12-30 2:32 ` msalists
[not found] ` <20141230100413.GA11208@tansi.org>
0 siblings, 1 reply; 14+ messages in thread
From: msalists @ 2014-12-30 2:32 UTC (permalink / raw)
To: dm-crypt
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 ?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [dm-crypt] Asustor NAS and cryptsetup 1.6.1
[not found] ` <20141230100413.GA11208@tansi.org>
@ 2014-12-30 18:18 ` msalists
2014-12-30 19:16 ` Sven Eschenberg
2014-12-31 7:26 ` Arno Wagner
0 siblings, 2 replies; 14+ messages in thread
From: msalists @ 2014-12-30 18:18 UTC (permalink / raw)
To: dm-crypt@saout.de
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [dm-crypt] Asustor NAS and cryptsetup 1.6.1
2014-12-30 18:18 ` msalists
@ 2014-12-30 19:16 ` Sven Eschenberg
2014-12-31 7:26 ` Arno Wagner
1 sibling, 0 replies; 14+ messages in thread
From: Sven Eschenberg @ 2014-12-30 19:16 UTC (permalink / raw)
To: dm-crypt
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
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [dm-crypt] Asustor NAS and cryptsetup 1.6.1
2014-12-30 18:18 ` msalists
2014-12-30 19:16 ` Sven Eschenberg
@ 2014-12-31 7:26 ` Arno Wagner
1 sibling, 0 replies; 14+ messages in thread
From: Arno Wagner @ 2014-12-31 7:26 UTC (permalink / raw)
To: dm-crypt
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
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2014-12-31 7:26 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-27 7:47 [dm-crypt] Asustor NAS and cryptsetup 1.6.1 msalists
2014-12-27 10:11 ` Arno Wagner
2014-12-29 19:06 ` msalists
2014-12-29 19:29 ` Quentin Lefebvre
2014-12-30 2:32 ` msalists
[not found] ` <20141230100413.GA11208@tansi.org>
2014-12-30 18:18 ` msalists
2014-12-30 19:16 ` Sven Eschenberg
2014-12-31 7:26 ` Arno Wagner
2014-12-30 0:37 ` Claudio Moretti
2014-12-30 1:00 ` msalists
2014-12-30 1:46 ` Arno Wagner
2014-12-30 2:11 ` msalists
-- strict thread matches above, loose matches on Subject: below --
2014-12-27 3:49 msalists
2014-12-27 7:38 ` Arno Wagner
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.