Re: Asustor NAS and cryptsetup 1.6.1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxx 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@xxxxxxx
<mailto:msalists@xxxxxxx> <msalists@xxxxxxx
<mailto:msalists@xxxxxxx>> 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@xxxxxxxx <mailto:dm-crypt@xxxxxxxx>
    http://www.saout.de/mailman/listinfo/dm-crypt




_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt

_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt



[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux