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)...my 2c regarding 3.: you might try - if the NAS allows you to - cd to / and
$ grep -rl YourPassword *
Cheers,
Claudio
On Mon, Dec 29, 2014 at 8:06 PM, msalists@xxxxxxx <msalists@xxxxxxx> wrote:
Hi Arno,
thank you for your explanations
There are two things that are happening by means of the NAS web admin interface: the creation (one-time) and the mounting (daily).Furthermore, using "cryptsetup status EncTest.1" to show some basicsCBC-plain has a fingerprint-leackage issue (a specially prepared
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?
file can be seen from outside the encryption without using the
key). Better use aes-cbc-essiv:sha256, the current default.
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:Why do you think this is an issue? This is block-device encryption,
1. The initially created empty container is "huge": it uses up 45GB
without me storing any data inside!
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.
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...2. The management interface does not seem to offer any way to createPLAIN does not have headers. For that you need LUKS.
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.
Thank you,
Mark
_______________________________________________
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