-------------------------------------------------------------------------------
Key Storage Systems

In many ways a "Password Vault" (storing website and account passwords) is
a simplistic version of this.  Strong passwords are stored and used for the
remote system, letting you use a single user password, (that should be kept
local) for the password vault itself.  (See below)

But true "Key Storage Systems" can do a lot more than just be a "Password
Vault" for web site passwords.  They can hold the passwords for Encrytped files
systems, and can also store the extra information needed to mount such systems.

It is not meant to be a single password to unlock everything, but only unlock
all the information needed to do some purpose.

That is the user gives a password that unlocks 'Key Store', which then provides
all the information needed to mount a Encrypted file system.  That includes
a strong (randomaly generated) master password for the FS, the commands needed
to mount the file system, the encrypted data location, where to mount it, and
perhaps even the configuration file needed.

This extra level of indirection allows the real data to be encrypted with
a strong, purely randomly generated key, while storing that key and all the
other configuation information in a completely separate area under the users
password. The user does not need to personally know all that hard to remember
information, such as the long random password, or the details of where and how
the data or file system is stored.

Not only that but by using 'key files', the users password can be changed
easilly, simply by re-encrypting the 'key file' without needing to decrypt,
copy, and re-encrypt the actual data, which for a large filesystem can take
a very long time.  Basically the hard to remember master password, and
encryption remains the same.

You can even give different users their own 'key file' with their own separate
password, to decrypt the same data. Individual users do not need to share the
password, and administaions can control access via each users individual 'key
file', though one user can remove access to the other users.

This two-stage password indirection is used by LUKS disk encryption and
is presented in the paper...
   "TKS1, An anti-forensic, two level, and iterated key setup scheme."
       http://clemens.endorphin.org/TKS1-draft.pdf

Also see..
   Dual password encryption with EncFS
     http://magazine.redhat.com/2007/06/13/dual-password

-------------------------------------------------------------------------------
Password Vaults

Password Vaults are basically encrypted password files that hold the password
you use for remote accounts and more specifically Web servers.

Many of these are themselves are network services so you have access to your
password from multiple devices and locations.  The techniques of such systems
ensures that the password needed is kept local, and not passed to the remote
hosting service, however it seems to me it would be trivial for them to collect
master password using 'fake' web sites.

So really though they make it seem secure, their is still some level of trust
involved.

-------------------------------------------------------------------------------
Gnome Keyring

This is a daemon holding a encrypted data store open, so that you have access
to passwords or other secrets, at least for the duration the user is logged
in.  For example passwords for web pages, network VPN connections, or logins
on other computers.

This is a more permanent store (password vault), as it is saved to disk, so
can store secrets between sessions, and does not have any timeout facility
for the 'secrets' being stored.  The password to unlock the encrypted store
is typically the users login password, but can be bypassed by setting a empty
password.

It also relies on the "dbus" interprocess communication system being active.
Which is part of the gnome window manager setup, so it only works while the
user is logged in, and does not work well with remote systems.

See "keyring_gnome.txt" for more information.

-------------------------------------------------------------------------------
KS - Key Store Program

Using the above 'two-stage password indirection' idea I developed "ks" (written
in perl) that understands running EncFS to mount file systems using
a completely randomised password.

   https://antofthy.gitlab.io/software/#ks

'Key Store' stores the 'key files' in file system such as a removable USB
stick, so that you can also include some physical security of the access keys,
if you so desire.

The key files not only holds a totally random master key, but also all the
other details of the encryption: such as the actual ".encfs6.xml" configuration
file to use, the location of the encrypted data, optionally where it should be
mounted (if desired).

It has extra benifits too. The command used to to access (mount or display) the
data, is also stored in the key files.  So it is not limited to just EncFS.
You can set up a key file that if used, runs a command that will destroy the
encryption information, preventing it from being used.

For example...

The "key files" themselves are basically encrypted files, that can be access
using a "label".  For example "ks -e webpwd" would let you edit a specific "key
file" that for example holds your web site password, or other simple text file
of data.  That is the "key file" itself is the data, with the master key
information not being used.

The keystore can even hold a encrypted shell script that can be run, without
making the sheel script itself readable (unless you have the password).

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