While the recent revelations
are not all that surprising,
they did stir the pot a bit
and made people at least a tad more
aware of the problems of personal privacy
in the modern age.
I’ll try to refrain from any comments on
the politics and hypocrisy of today’s world
as I don’t consider my blog and Planet KDE
to be a place for this.
Though, it will be hard. :)
I’ve mentioned in a recent blog post)
that I’ve been working on the integration
of different data encryption solutions into the Plasma workspace.
The point of the project is not to provide
a new encryption mechanism,
but to provide a user-friendly interface
to the existing ones
that will be integrated into Plasma
for improved security.
Integration points and the UI
The main interface is the Plasma applet
that will show up inside of your system tray / notification area.
you can create new vaults, open and close them.
There is one big differnce
between creating a UI for Plasma Vault
and creating an interface for regular applications and applets.
We usually tend to avoid
showing big chunks of text to the user,
and all errors to be unnoticeable.
When Plasma crashes,
it silently restarts and shows just a small icon
in the tray that will easily be ignored.
And yes, we also hate wizards.
and for other encryption tools,
we need to show more text
as the user needs to understand exactly
what is being done.
What are the benefits and
what are the disadvantages of most options.
All the security mechanisms in the world are just useless
if used improperly.
For this reason,
creating a new Vault is done
through a detailed wizard
that our translation teams are probably going
to hate me for.
The wizard allows the user to choose
what encryption system to use,
and configure the specifics for them.
As for the errors,
none can be ignored.
There is no option to have “silent failures”.
All errors need to be
Now, failures to create or open a vault
are quite obvious
you don’t have the access to the data,
but errors closing the vault are a different story.
If the vault can not be closed
due to an application accessing a file inside the vault,
the user might be unaware of the fact
that the data is still accessible to anyone
who might have the access to the system.
For this reason,
the Vault applet will show a nice red icon
until you manage to fix the error.
The icon and the error message
will not just go away after a few seconds
like it is the case with the device notifier applet.
I’m even pondering to add the option
to forcefully kill all the applications
that are using the vault,
but that will probably not end up
in the first release.
Currently available backends
When creating a vault,
there are a three backends that you can use.
The old, but almost true,
the user-friendly wrapper for
EncFS is one of the old solutions
which provides a transparent FUSE-based
This means that the encrypted files live
in your normal file system
and they get decrypted when they are accessed
through the virtual file system.
EncFS has been with us for quite a long time.
It has gone under an independent security audit
which detected a few problems with the design and implementation.
There are two bigger problems with EncFS.
The first one is that it creates one encrypted file for each file in the encrypted system,
and the encrypted files have the same directory structure as the directories in the encrypted system.
This classifies as a meta-information leak
because the attacker might be able to guess
some things from the number of files, the directory organization
and file sizes.
you might have encrypted the files copied from
an installation disc of some operating system you don’t have the license for
it would be easy to guess which OS it is
just by looking at the number of files
and the directory structure.
The more serious flaw
is that the encryption techniques used
are potentially vulnerable to cracking
in the cases where the attacker
can access multiple encrypted versions
of a file.
This means it is not a good idea to use EncFS
to encrypt your data that you sync
to the cloud.
CryFS is a more modern FUSE-based overlay file-system.
It does not have the problems that EncFS has.
Instead of creating one encrypted file for each file in the FUSE filesystem,
it splits them into chunks and encrypts all the chunks separately.
Because of this,
the attacker can not deduce
any information related to the number of files
just by looking at the encrypted data.
It also does not expose the directory structure
through the organization of the encrypted data.
While these are welcome improvements over EncFS,
it is worth noting that there are no
independent security audits of CryFS.
So, while it does not have the same problems that EncFS has,
it is possible that it has others.
This is the main reason why Plasma Vault supports both EncFS and CryFS
to give the user a choice between a solution
that has issues, but for which the issues are known,
and a solution that should be safer,
but for which we don’t really know whether it is.
The newest addition to the Plasma Vault family is Tomb.
It is considered experimental,
and in order to enable it in the first Plasma Vault release,
you will need to add the following to plasmavaultrc:
Unlike EncFS and CryFS,
Tomb does not create an overlay-file system.
It is just a simple script that makes it easy
to create encrypted container files
which get mounted like any other block device in your system.
It relies on
cryptsetup/dm-crypt for the actual encryption.
For this reason,
even if the Tomb project itself
is not as mature and as bug-free as it should be,
it can be considered secure.
Since it is just a wrapper over system-provided tools,
the only problem you might have with it
is that in the case of a bug,
it will not be able to mount your encrypted file.
In that case,
you would need to do it manually by calling
losetup/cryptsetup and friends,
The main disadvantage of Tomb is that
you need to define the size of the container file in advance
it will not grow automatically when you add new files.