From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 ; Tue, 30 Dec 2014 03:11:20 +0100 (CET) Received: from [192.168.99.197] ([70.187.182.227]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MSHax-1YGb6b2mJX-00TRfB for ; Tue, 30 Dec 2014 03:11:20 +0100 Message-ID: <54A209C5.7020009@gmx.net> Date: Mon, 29 Dec 2014 18:11:17 -0800 From: "msalists@gmx.net" MIME-Version: 1.0 References: <549E63FE.8020602@gmx.net> <20141227101133.GA21707@tansi.org> <54A1A63D.5060604@gmx.net> <54A1F924.2020500@gmx.net> <20141230014608.GA3294@tansi.org> In-Reply-To: <20141230014608.GA3294@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" Yes, they use busybox On 2014-12-29 17:46, Arno Wagner wrote: > Probably a BusyBox with very small shell-memory. If > you have "find", you can try something like this: > > find / -type f -exec grep YourPassword \{\} \; > > Arno > > On Tue, Dec 30, 2014 at 02:00:20 CET, msalists@gmx.net wrote: >> 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@gmx.net >>> >> > 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@saout.de >>> http://www.saout.de/mailman/listinfo/dm-crypt >>> >>> >>> >>> >>> _______________________________________________ >>> dm-crypt mailing list >>> dm-crypt@saout.de >>> http://www.saout.de/mailman/listinfo/dm-crypt >> _______________________________________________ >> dm-crypt mailing list >> dm-crypt@saout.de >> http://www.saout.de/mailman/listinfo/dm-crypt