On April 26, 2002 16:00, Roberto Alsina wrote:
> >    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.

  Yes, that's basically the idea, but I was thinking more about the crypto 
library itself.  The cipher implementations for instance.

> 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

   In some cases we wouldn't want all that information to be in there, but 
yes, that's correct as well.

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

  This will tie in nicely with KWallet too (which should be in 3.1).  The user 
could keep common passwords in a wallet so they can have a single sign-on 
(don't think Passport) to decrypt multiple files automatically.

> 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?

   Yes.  That part as you see is easy.  The hard part is coming up with a 
flexible, reusable, appropriate crypto backend.  Something that won't confuse 
the user too much, but is safe and powerful, follows KDE development models, 
and is light.

> > - 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?

  Essentially.  We'll need an API for the plugins, some implementations, and a 
manager.

> > - 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 ;-)

   Yes

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

  Correct.  The problem is that crypto algorithms are generally optimized for 
speed, so they contain large tables.  We don't want to use those libraries, 
though if they are GPL/pd/somehow_free I guess we could use the 
implementations (giving the authors appropriate credit) that are already out 
there, just refactoring them to work in KDE.  It's easy to make a test 
structure to ensure we don't break the algorithms when we migrate them.  This 
was my original plan.  (My first test of this was with the KOffice filter.  
It's just test code so it's not clean enough yet.  I used blowfish and I 
tested it against several reference implementations.)

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

   My point is that we can't use a library like OpenSSL or Crypto++ or foobar 
because they are too heavy for something that could permeate throughout KDE 
applications.  However we don't want to have random crypto algorithms strewn 
throughout CVS either.  We need something structured.  We see the problem 
already happening in kdecore/kmdcodecs.

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

   In some cases, as I said above, it will be sufficient to have a good test 
bucket to compare against reference implementations.  The reviewing part 
comes more when things like password transformations, random data, etc are 
used.  These can't be tested against a predefined bucket. :)

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

   Sure that sounds reasonable.  I would really love to see a proper framework 
develop for this though.






