Re: [dm-crypt] Asustor NAS and cryptsetup 1.6.1

["msalists@gmx.net" <msalists@gmx.net>]

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
>>> <mailto:msalists@gmx.net> <msalists@gmx.net
>>> <mailto: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 <mailto: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