One of my pet peeves with teaching FP in C++ is that if we want to have efficient code, we need to catch functions and other callable objects as template arguments.

Because of this, we do not have function signatures that are self-documenting. Consider a function that outputs items that satisfy a predicate to the standard output:

template <typename Predicate>
void write_if(const std::vector<int> &xs, Predicate p) {
    std::copy_if(begin(xs),
                 end(xs),
                 std::ostream_iterator<int>(std::cout, " "));
                 p);
}

We see that the template parameter is named Predicate, so we can imply that it needs to return a bool (or something convertible to bool), and we can deduce from the function name and the type of the first argument that it should be a function that takes an int.

This is a lot of reasoning just to be able to tell what we can pass to the function.

For this reason, Bartosz uses std::function in his blog posts – it tells us exactly which functions we can pass in. But std::function is slow.

So, we either need to have a bad API or a slow API.

With concepts, the things will change.

We will be able to define a really short (and a bit dirty) concept that will check whether the functions we get are of the right signature:

Edit: Changed the concept name to Callable to fit the naming in the standard [func.def] since it supports any callable, not just function objects

template <typename F, typename CallableSignature>
concept bool Callable =
    std::is_convertible<F, std::function<CallableSignature>>::value;

void foo(Callable<int(int)> f)
   // or Callable<auto (int) -> int>
{
        std::cout << std::invoke(f, 42) << std::endl;
}

We will be able to call foo with any callable that looks like a int-to-int function. And we will get an error ‘constraint Callable<int(int)> is not satisfied’ for those that do not have the matching signature.

An alternative approach is to use std::is_invocable type trait (thanks Agustín Bergé for writing the original proposal and pointing me to it). It will provide us with a cleaner definition for the concept, though the usage syntax will have to be a bit different if we want to keep the concept definition short and succulent.

template <typename F, typename R, typename ...Args>
concept bool Callable =
    std::is_invocable<R, F, Args...>::value;

void foo(Callable<int, int> f)
{
    std::cout << std::invoke(f, 42) << std::endl;
}

When we get concepts (C++20, hopefully), we will have the best of both worlds – we will have an optimal way to accept callable objects as function arguments, and not sacrificing the API to do it.

Book discount

Today, Functional Programming in C++ is again the Deal of the Day – you get half off if you use the code dotd032317au at cukic.co/to/manning-dotd

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. :)

Plasma Vault

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. From there, you can create new vaults, open and close them.

There is one big difference 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.

Wizards

For Vault, 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.

Errors

As for the errors, none can be ignored. There is no option to have “silent failures”. All errors need to be visually explicit.

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, encfs, the newcommer cryfs and the user-friendly wrapper for dm-crypt called Tomb.

EncFS

EncFS is one of the old solutions which provides a transparent FUSE-based overlay file-system.

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. For example, 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

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.

Tomb

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:

[General]
enableExperimentalBackends=true

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.

Vaults versus whole-system encryption

This is the thing I get asked often – why would someone want to use Vaults when we can encrypt the whole system, including the swap partition?

I have two answers here.

The first is that this is not an either-or question. It is not Vaults versus whole-system encryption, it is Vaults AND/OR whole-system encryption.

If you want to be as secure as possible, use both.

The second answer is the reason why the whole-system encryption is not enough. When we enter the decryption password, all the data is readable until the system is powered off.

If an attacker gets the access to the system while it is powered on, all the data is accessible.

Vaults provide an additional layer of security – compartmentalization of sensitive data. You can open and close them as you wish, and usually you keep them closed. If an attacker is able to access your system, he can only access the data from the vaults open at that time.

Vaults and activities

One feature that plays really nicely with the compartmentalization is that Vaults can be connected to activities.

For each Vault, you can choose the activities that it should be available in. This means that it will show up only in those activities, and that it will automatically get closed when you switch from the activity it belongs to.

This way, the user does not need to think about closing the vaults manually – that operation becomes the part of the workflow.

Once upon a time, the Qt people joked about switching Qt to snake_case in one of the April Fools posts.

But even if it was a joke, it did trigger me and Vishesh to talk (argue?) about it during one of aKademies.

One of the strange things I’ve noticed is that when I’m writing code that is Qt-based, I tend to use camelCase most of the time, but at the same time (in the same project) I tend to use snake_case when I’m creating generic functions. For example, a for-each algorithm that works on associative containers would be called for_each_assoc instead of forEachAssoc. This is the place where Vishesh did not agree with me.

You might ask me why I’m bringing this up now, quite a few years after the discussion.

I’ve been digging through Qt code, and I’ve encountered this:

inline QModelIndex create_index(
        int row, int column,
        QHash<QModelIndex, Mapping*>::const_iterator it) const
{
    return q_func()->createIndex(row, column, *it);
}

void _q_sourceDataChanged(const QModelIndex &source_top_left,
                          const QModelIndex &source_bottom_right,
                          const QVector<int> &roles);

void _q_sourceHeaderDataChanged(
        Qt::Orientation orientation, int start, int end);

void _q_sourceLayoutAboutToBeChanged(
        const QList<QPersistentModelIndex> &sourceParents,
        QAbstractItemModel::LayoutChangeHint hint);
void _q_sourceLayoutChanged(
        const QList<QPersistentModelIndex> &sourceParents,
        QAbstractItemModel::LayoutChangeHint hint);

void _q_sourceRowsAboutToBeInserted(const QModelIndex &source_parent,
                                    int start, int end);
void _q_sourceRowsInserted(const QModelIndex &source_parent,
                           int start, int end);

I’d say that Qt is a true framework for the new age of political correctness – it does not discriminate against any of the naming styles. :)

p.s. I’ve posted this just for fun, please do not post comments about which naming convention is better etc. No reason to start a flamewar here.

While the rest of the Plasma team is sprinting in Germany, I’m unfortunately tied down to my chair at home and trying to sprint as well.

Backends

The main work I’ve been doing since I announced Plasma Vaults was to refactor the hell out of the Vaults infrastructure to allow me to support more encryption engines.

I’ll blog about some of the more fun parts of this refactor later.

The main reason why I am mentioning this now is that we now have two different choices for Vault encryption.

The first is (as previously mentioned) EncFS, and the newly added one is the young but promissing CryFS.

CryFS is a more modern system that tries not to repeat the same errors that EncFS (and eCryptFs) have. It does not expose the number of files, directory organization, nor sizes of the files stored in the system, while not having any significant known drawbacks.

One thing that I’d like to say here is that the important word in the above sentence is known.

It is true that EncFS has known security issues thanks to the independent security audit by Taylor Hornby, so you know that it is not safe in certain use-cases.

But its huge advantage is that you know what its problems are. For the newer systems like CryFS, there is no known independent security audits (if you find one, please notify me).

This means that, at this point, the choice is between a known system with known faults that you will most likely be safe with if you use it correctly, and a new system that does not have those faults, but its faults are unknown.

I’m investigating a few systems more (including eCryptFs), but I’ll write about them when they get supported by Plasma Vaults.

A bit on the UI

I’ve also been polishing the UI a bit.

Instead of having a huge dialogue, the vault creation is now in a nice-looking wizard. I’m not a fan of wizards, but in this case it is a much better choice.

Apart from not looking as cluttered as the previous one, it also allows different backends to have different options (like choosing the cypher in CryFS).

Fun with icons

Alex has made a few nice icons for this, and now I’m experimenting how can I use them to improve the user experience.

One of the things I’m trying out is to set the default icon for the vault folder, so that, when you open the Vault, its folder’s icon changes to notify you that that its contents is encrypted.

Five years ago (I’m completely shocked how the time flies), we were working on Plasma Active, and one of the ideas was to allow the user to create private activities in which all the data would be encrypted.

Now, while the idea itself was solid, there were big problems with its realization. There was no way to force applications to separate the configuration and other data based on whether the user is in the encrypted activity or not. Especially since the same application can run in multiple activities.

For those reasons, the idea was abandoned. I didn’t like the fact that I spent a lot of time on it just for it to be thrown away, so encryption always stayed in my mind.

Enter Plasma Vaults

If the idea to have activities encrypted can not work because of the things not controllable by us, then we need to do something more obvious and transparent, so that the user can know exactly which data is secure, and which not.

Instead of having something as abstract as an activity encrypted, Plasma Vaults will allow you to create encrypted directories.

Sometimes we want to keep specific documents private. Sometimes we are actually forced to do so (I’ve seen enough work contracts that force you to keep the job-related data as secure as you know how to). And sometimes we have to share our computer with others while keeping our data completely private.

Plasma Vaults allow you to easily create and manage EncFS encrypted directories (other encryption systems might be supported in the future).

The vault creation dialogue will need more work. While most of the text in it is important, we’ll need to think of something to make it less daunting to look at.

Activities

One of the things that did not survive from the original concept is that the encrypted drive is tightly bound to an activity.

But still, that does not mean there can not be a connection between them. The vaults are usually related to the projects that we work on, and one of the main use-cases of activities is the project handling.

So, for each vault, you can choose which activities it should be available on. It will not be automatically unlocked when you enter said activities, but it will be automatically closed when you exit them.

This might be a bit annoying if you often switch between activities, but I’d always put security above convenience.

UI

Currently, the UI is not as polished as it should be. Some of the problems are in the Plasma Vault code itself, but some are in the KF5 widgets.

Alternatives

This is not the only way to keep your data private. Lately, most Linux installers allow you to create an encrypted home partition, or to encrypt the whole system including the swap.

But these cover a different use-case. They cover the case when your device gets lost while turned off.

They do not cover the possibility that someone might access your system while it is running. Plasma Vaults fill this void by making the attack surface smaller – instead of having all data unlocked at once, you can do it piece by piece – it is more granular.

This does not mean that using only Plasma Vaults will make your data more secure than encrypting the whole system, it just covers a different set of possible attacks. It is probably worth it to combine both if you are doing really secret work.