On Sat, Dec 27, 2014 at 08:47:10 CET, msalists@xxxxxxx 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@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
