Framework for encrypted storage for apps

[Ivan Čukić]

Hi Johan, 

One important question here is how do you want the secrets to be unlocked.
Is the user going to type in some master password every time the otpclient is 
started?

If that is the case, you can use QCA to encrypt and decrypt the data you need
to store securely.

If that is not the case - if you don't want to always ask the user for the 
password, then you can expect quite a complicated story of how to make 
something like kwallet safe.

>  1. (On KDE) these libraries wind up calling dbus. We would like to
> avoid plain text out-of-process communication of secrets, especially
> communication through a 'shared' channel (for obvious reasons).
>  2. In particular with KDE Wallet it was suggested that the wallet
> itself may, in fact, not be encrypted.

Another huge problem of kwallet is that it can not authenticate which 
application is asking for the password. I was told that this could be easier 
to do with flatpaks, but it will still need significant changes to how kwallet 
works.

> Another possible contender is Plasma Vault, but we don't really know
> how that would work in the context of an app, especially a flatpak
> app.

An approach like the one taken in Plasma Vault could work for applications,
but it would (like the QCA option previously mentioned) require the user to
type in the password every time. The problem with using Plasma Vault is
that it works with fuse mounts - so the decrypted data si visible through the 
filesystem. (though, flatpaks could maybe have some solution there as well, 
not my area)

Cheers,
Ivan


-- 
dr Ivan Čukić
KDE, ivan.cukic at kde.org, https://cukic.co/
gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232  07AE 01C6 CE2B FF04 1C12