El divendres, 11 d’octubre de 2019, a les 17:59:17 CEST, Johan Ouwerkerk va 
escriure:
> 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!

CipherUnitTest::aes256 does encryption and decryption as far as i can see.

Cheers,
  Albert

> 
> Kind regards,
> 
> - Johan Ouwerkerk
> 
> 
> 
> 
>  -
> 
> On Sat, Oct 5, 2019 at 9:09 AM Ivan Čukić <ivan.cu...@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.cu...@kde.org, https://cukic.co/
> > gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232  07AE 01C6 CE2B FF04 1C12
> >
> >
> >
> 




Reply via email to