-------------------------------------------------------------------------------
Encrypted Virtual File system

OBSOLETE
  This has been replaced by dmcrypt and fusemount (user mount) systems.
    https://antofthy.gitlab.io/info/crypto/linux_dmcrypt.txt

Basically this sets up a loopback device to for the block device encryption

-------------------------------------------------------------------------------
Mount via a "loop" device, to provide some extra options,
namely encryption, and offset.  EG: a 100Mb file system

   dd if=/dev/zero of=/tmp/crypted_image count=1 bs=1M  seek=100
   losetup -e XOR /dev/loop0 /tmp/crypted_image
   Password: xxxxxx
   mkfs -t ext2 /dev/loop0
   mount /dev/loop0 /mnt -t ext2
   ...
   umount /dev/loop0
   losetup -d /dev/loop0

The mount command itself however can call the losetup command internally,
and will then automatically free the loopback device when finished.
You can specify a specific loop back device, though if not given the first
free loop device will be used.

EG: remount the above file system directly
   mount -o loop=encryption=xor /tmp/crypted_image /mnt
   umount /tmp/crypted_image

Or specifing a specific loop device (with des encryption)...

   mount /tmp/crypt_image /mnt -t ext2 -o loop=/dev/loop0,encryption=des
   Password:
   ...

This will however list the source of the encrypted filesystem in df and mount
listings. Regardless, while the loop device is in use you can see the source
of the filesystem with....

   losetup /dev/loop0

Do NOT use "xor" encryption, without somehow using extrememly large binary
keys.  The encryption keys are unfortunatally visible in the encrytped file,
in blocks filled with zero bytes (the first block for example).  That specific
problem can be rectified by creating the original file using /dev/random rather
than /dev/zero, but it is still insecure.

I cannot get "des" to work, erro given...
    ioctl: LOOP_SET_STATUS: Invalid argument

From Loopback-Encrypted-Filesystem-HOWTO-3.html  explains how to install the
"serpent" encoding scheme into the kernal, for a more secure encryption.

----
From  http://mail.nl.linux.org/linux-crypto/2002-08/msg00015.html
This uses openssl to create a long password keyphase for better encryption.

   Create 100M file system
      dd if=/dev/zero of=/home/user.img count=1 bs=1M  seek=<image size>
   The encryption key
      dd if=/dev/urandom bs=1c count=<keysize/8> | openssl enc \
          -<fs_key_cipher> > /home/user.key
   Setup encryption
      openssl enc -d -<fs_key_cipher> -in /home/user.key | losetup -e aes \
         -k <keysize> -p0 /dev/loop0 /home/user.img
   Make the file system
      mkfs -t ext2 /dev/loop0
   Mount the filesystem
      mkdir /mnt/crypt
      mount /dev/loop0  /mnt/crypt
   Finish up
      umount /dev/loop0
      losetup -d /dev/loop0

---
Making it more secure...

* First hide the file holding the encrypted filesytem in a non-obvious place.
  Thst is some place that may be overlooked...  Like "core.62548" or
  "/etc/config.in"

* Of course if you have this filename built into a shell script, then you have
  problems.  Prehaps the mounting shell script should decode itself for
  execution, then that mounts the encrypted filesystem.

  See Encrypted Shell Functions
    https://antofthy.gitlab.io/software/#encrypted_function

* Better still make some use of the loop device "offset" to add the extra
  information to a special encoded file at the start of the crypt file.
  That is the password you give decrypts a long encryption key, and offset
  information.  That can then be used to actually decrypt the real filesystem.

  In some ways this is how Luks Encryption works.
  It also hides any magic numbers, moving them away from the start of the file.

* The password encrypt or hash something to generate a very very large key
  (like the gziped system dictionary?)

-------------------------------------------------------------------------------