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
http://www.saout.de/mailman/listinfo/dm-crypt
