From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Mon, 29 Dec 2014 20:06:40 +0100 (CET) Received: from [192.168.99.197] ([70.187.182.227]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MWwp6-1YK17q1sm4-00VzqV for ; Mon, 29 Dec 2014 20:06:39 +0100 Message-ID: <54A1A63D.5060604@gmx.net> Date: Mon, 29 Dec 2014 11:06:37 -0800 From: "msalists@gmx.net" MIME-Version: 1.0 References: <549E63FE.8020602@gmx.net> <20141227101133.GA21707@tansi.org> In-Reply-To: <20141227101133.GA21707@tansi.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] Asustor NAS and cryptsetup 1.6.1 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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