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@xxxxxxx
<mailto:msalists@xxxxxxx> <msalists@xxxxxxx <mailto:msalists@xxxxxxx>>
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@xxxxxxxx <mailto:dm-crypt@xxxxxxxx>
http://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
