encrypted file integration into KDE

[Roberto Alsina]

On Fri, 26 Apr 2002, George Staikos wrote:

> On April 26, 2002 13:04, ralsina at kde.org wrote:
> > Hello,
> >
> > While wandering around, I found a few libs that provide nice and simple
> > usage of rather strong symmetrical password algorithms.
> >
> > I was thinking: it would be great to have the possibility to have
> > encrypted on-disk storage for KDE apps, but to do it nicely, it would hae
> > to be available for all apps.
> >
> > For example, this should allow both encrypted kjots/knotes (for example,
> > for password info for netadmin types) and kword docs, or even encrypted
> > images visible only on konqueror/kview!.
> >
> > Anyone has ideas on how this could be integrated?
> 
>    I've been playing around with this idea for about two years now.  I think 
> it's a great idea.  However we have the same problems as with other crypto 
> issues right now...  
> 
> - we need to standardize an API and design a library first.  This will help 
> with other issues listed below.

Well, the part about encoding/decoding seems to be pretty simple.

I was thinking something like KTar, where it would detect that the
encrypted file is a container of encrypted data (some magic number), then
a filter to decrypt it.

The filter would have to get from the encrypted file the following
information:

* algorithm used
* information about the file being encrypted. This could be hidden, but
  something that would let you know it's an image, just not see it, would
  be a practical application

Then it needs to get from the user the information needed to decrypt,
which of course varies per-algorithm, but for a simple symmetrical thingie
is just a password.

Then Konqueror can open the encrypted file using the above data, the
api to decrypt should look pretty much like KTar, only with plugins for
algos?

> - some algorithms cannot be imported/exported in various country 
> configurations.  We need a plugin system so that applications will run if the 
> needed algorithm is missing, and so algorithms can be packaged separately and 
> individually.

Well, the qt plugin system should work for this?

> - using preexisting libraries is basically out of the question due to size 
> (bloat) issues.  We already have to go through the pain of dlopen()ing 
> OpenSSL.  It's not fun.  We have to come up with a new design.

If the plugin structure is sound, we need ONE algorithm to make this work,
even if it's XOR ;-)

There are some crypto libs out there that have already done all the hard
algo work, and our version will probably not be any smaller.

OpenSSL is huge because it tries to do a complex thing, all I want is make
the file hard to read :-)

> - this needs very thorough testing.  I started implementing koffice encryption 
> but did not finish yet because I don't want to rush it.  There are many 
> details to watch, and implementations need to be examined by peers with 
> experience in the field.

That is a reason to use a crypto lib, and not a homebrew one.

> An alternative is to use PGP which encrypts files nicely.  However this is not 
> as easy to integrate smoothly.  It is also not as nice because of pgp key 
> management requirements.  Simple password encryption is nicer for the user.  
> (hmm maybe pgp does this now?)

It does :-)

> We could make quick hacks that do the job now, but let's not create a hack 
> that will have to stay in KDE [basically forever] because of backwards 
> compatibility, even if we come up with a good solution later.

Oh, we can make a quick hack and NOT out it into kde while it matures.

 ("\''/").__..-''"`-. .         Roberto Alsina
 `9_ 9  )   `-. (    ).`-._.`)  ralsina at kde.org
 (_Y_.)' ._   ) `._`.  " -.-'   KDE Developer (MFCH)
  _..`-'_..-_/ /-'_.'           
(l)-'' ((i).' ((!.'             Buenos Aires - Argentina
I would like to believe in God [..]. But I just believe in Billy Wilder.