Asustor NAS and cryptsetup 1.6.1
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!
Quoted 4 lines · On Sat, Dec 27, 2014 at 08:47:10 CET, [email protected] 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.
Quoted 16 lines
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.
Quoted 8 lines
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
Quoted 6 lines
Furthermore, using "cryptsetup status EncTest.1" to show some basics about the created test container shows this:
/dev/mapper/EncTest.1is active and is in use.
type: PLAIN
cipher: aes-cbc-plain
keysize: 256 bits
Quoted 8 lines
device: /dev/loop0 loop: /volume1/.@loopfiles/EncTest offset: 0 sectors size: 11619787984 sectors mode: read/writeIs 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.
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 7 lines
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.
Quoted 2 lines
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
Quoted 6 lines
Thank you in advance!
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] 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
Hi Arno,
thank you for your explanations
Quoted 12 lines
Quoted 12 lines
Furthermore, using "cryptsetup status EncTest.1" to show some basics about the created test container shows this:
/dev/mapper/EncTest.1is active and is in use.
type: PLAIN
cipher: aes-cbc-plain
keysize: 256 bitsdevice: /dev/loop0 loop: /volume1/.@loopfiles/EncTest offset: 0 sectors size: 11619787984 sectors mode: read/write
Quoted 5 lines
Quoted 2 lines
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?
Quoted 5 lines
Quoted 3 lines
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.
Quoted 4 lines
Quoted 3 lines
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
Quoted 5 lines · On 29/12/2014 20:06, [email protected] 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
Quoted 9 lines · Quentin Lefebvre
Quoted 5 lines · On 29/12/2014 20:06, [email protected] 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 ?
A message that is not in the archive (sent off-list or not yet received): [email protected]
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
Quoted 20 lines · Arno Wagner
Quoted 7 lines · On Tue, Dec 30, 2014 at 03:32:58 CET, [email protected] wrote:
Quoted 6 lines · Quentin Lefebvre
Quoted 5 lines · On 29/12/2014 20:06, [email protected] 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?
Quoted 8 lines
Quoted 4 lines
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
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
Quoted 34 lines · On Tue, December 30, 2014 19:18, [email protected] 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
Quoted 12 lines · Arno Wagner
Quoted 11 lines · On Tue, Dec 30, 2014 at 03:32:58 CET, [email protected] wrote:
Quoted 10 lines · Quentin Lefebvre
Quoted 5 lines · On 29/12/2014 20:06, [email protected] 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.
Quoted 8 lines
Quoted 4 lines
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
[email protected]
http://www.saout.de/mailman/listinfo/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
Quoted 33 lines · On Tue, Dec 30, 2014 at 19:18:38 CET, [email protected] 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
Quoted 12 lines · Arno Wagner
Quoted 11 lines · On Tue, Dec 30, 2014 at 03:32:58 CET, [email protected] wrote:
Quoted 10 lines · Quentin Lefebvre
Quoted 5 lines · On 29/12/2014 20:06, [email protected] 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.
Quoted 8 lines
Quoted 4 lines
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
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] 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
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
Quoted 75 lines · On Mon, Dec 29, 2014 at 8:06 PM, [email protected] <[email protected]> wrote:
Hi Arno,
thank you for your explanations
Furthermore, using "cryptsetup status EncTest.1" to show some basics
Quoted 11 lines
Quoted 11 lines
about the created test container shows this:
/dev/mapper/EncTest.1is active and is in use.
type: PLAIN
cipher: aes-cbc-plain
keysize: 256 bitsdevice: /dev/loop0 loop: /volume1/.@loopfiles/EncTest offset: 0 sectors size: 11619787984 sectors mode: read/writeQuoted 7 lines
Quoted 3 lines
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:
Quoted 6 lines
Quoted 3 lines
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
Quoted 6 lines
Quoted 4 lines
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
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
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
Quoted 105 lines · Claudio Moretti
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, [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>> 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.1is 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/writeIs 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
[email protected] <mailto:[email protected]>
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/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
Quoted 125 lines · On Tue, Dec 30, 2014 at 02:00:20 CET, [email protected] 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
Quoted 104 lines · Claudio Moretti
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, [email protected]
<mailto:[email protected]> <[email protected]
<mailto:[email protected]>> 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.1is 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/writeIs 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
[email protected] <mailto:[email protected]>
http://www.saout.de/mailman/listinfo/dm-cryptQuoted 4 lines
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] 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
Yes, they use busybox
Quoted 132 lines · 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
Quoted 124 lines · On Tue, Dec 30, 2014 at 02:00:20 CET, [email protected] 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
Quoted 104 lines · Claudio Moretti
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, [email protected]
<mailto:[email protected]> <[email protected]
<mailto:[email protected]>> 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.1is 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/writeIs 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
[email protected] <mailto:[email protected]>
http://www.saout.de/mailman/listinfo/dm-cryptQuoted 4 lines
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt