Framework for encrypted storage for apps

[Johan Ouwerkerk]

Hi all,

Many thanks for the responses so far. To address the various points raised:

It is acceptable for me if the user must type their password. Keychain
integration etc. are optional extras. QCA looks like it might be a
good fit for what I need.
One question I have with regards to keychain integration here is: are
the Windows and MacOS X platforms "properly" secure or at least
properly designed for this? That is: would it be a good addition to
use Qt Keychain for integrating with Keychains optionally on MacOS X
and/or Windows, and wail and gnash teeth for the fact it won't work on
Linux/FreeBSD?

However I feel somewhat intimidated by QCA's lack of proper publicly
accessible documentation. To give an overview of what I have tried
thus far:

 - KDE apidox which appeared to consist of a single overview page,
with a broken image (dead URL) and a dead link to examples (404):
https://api.kde.org/kdesupport-api/qca-apidocs/
 - inqlude (https://inqlude.org/libraries/qca.html) which had a link
that redirects via someone's private site to KDE Userbase which
appears to be about Qt 4.2 times (https://userbase.kde.org/QCA) and
another link that is dead (404)
 - On the advice of tsdegos on Matrix, I tried figuring out via the
headers /include what is was supposed to do. I did not get very far. I
am probably just too unfamiliar with the code structure and especially
how this is supposed to interact with the backing plugins to figure
out by myself how to do e.g. "key derivation", "salting" or
"encryption" by just looking at these headers.
 - However I did find an example on the Internet which at first glance
looks to explain how to do PBKDF#2 with QCA at least:
https://developersarea.wordpress.com/2014/11/27/cryptographic-hashes-in-qt-hmac-sha1-pbkdf2-md5/
(Scroll to the bottom of that blog post for the PBKDF#2 bits) Does
that also look reasonable to you, or are there glaring issues beside
the uses of QStrings for nearly everything?
 - I find it fairly hard to Google for this, because search terms like
"qca qt secure random" simply don't appear to return useful results
here. My background here is mostly some familiarity with JCA, so I'm
looking for things like "key derivation", "pbkdf", "secure random" in
combination with "qca" and "qt". I

So suppose I use QCA, I still have a few questions about how to go about this:

 - How do I obtain a "secure random" primitive in QCA? I can of course
make do by reading bytes from /dev/random on Linux, but it would be
nicer to have a portable primitive -- especially since the OpenSSL
plugin should be able to access such an implementation (OpenSSL).
 - How do I set up padding? I mean, sure I can pad my input manually
until I have a next multiple of #keysize bits/bytes. Is that solid
practice or does QCA already provide proper padding schemes out of the
box like PKCS#7?
  - How do I even construct the encryption itself? I can't seem to
find anything other thant public/private key encryption examples
(using some public key with OAEP), but I would like AES with a
suitable scheme/mode here. Mainly I would like a MAC on the encrypted
data because I want to be able to assert that the ciphertext is not
accidentally corrupted, say. After all if I can store the secrets in
an encrypted and robust fashion, then I can let the user export their
data safely for backup purposes.

So basically I guess that what I am asking: any examples, suggestions
or other pointers which I can use as further starting points/context
to figure this out? Thanks a lot in advance for all your help!

Kind regards,

- Johan Ouwerkerk




 -

On Sat, Oct 5, 2019 at 9:09 AM Ivan Čukić <ivan.cukic at kde.org> wrote:
>
> 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
>
>
>