encrypted file integration into KDE

[Ingo Klöcker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 28 April 2002 01:36, George Staikos wrote:
> On April 27, 2002 18:18, Ingo Klöcker wrote:
> > > >    Does this CLI tool deal with headers added to the file?  I
> > > > don't see how we can encrypt files without adding a header, and
> > > > I'll be impressed to see that this thing can jump over headers
> > > > automatically.  Or do we encrypt and then base64 encode the way
> > > > PGP does?
> >
> > Why don't you simply use the OpenPGP standard? Please don't
> > reinvent the wheel. The huge advantage of using OpenPGP (through
> > GnuPG resp. gpgme) for encryption is that files encrypted in an
> > OpenPGP compliant manner can be decrypted by every other program
> > that supports OpenPGP. So please don't implement a KDE specific
> > thing which can't be processed outside of KDE.
> >
> > BTW, OpenPGP programs usually don't base64 encode encrypted files.
> > But it's possible to put the OpenPGP data in an ASCII armor (via
> > base64 encoding).
>
>    I'm not against this approach.  I'm sure I suggested it for
> encrypting files several times since it could be hacked together
> quickly.  That doesn't change the fact that we need a good crypto
> library.
>
>    My concerns with this approach (ie. things that may need to be
> addressed still) include (but are not limited to):
>
> 1) can metadata be added to these files without breaking
> compatibility with other systems?  This will seriously mess up all
> the mimetype stuff if we can't.

Maybe the Literal Data Packet could be used for this (cf. RFC2440, 
section 5.9).

> 2) it's rather inefficient and more error prone to call out to an
> executable as opposed to having a library we can work with. 
> (spawning processes can be very expensive on non-Linux too)  This
> would be even more of a problem if we created a KRobustFileClass
> which could automatically do the encryption and decryption work. 
> Having a class like this that can spawn executables sounds rather
> ugly to me.  Perhaps there is a library, or will be a library so we
> can implement this internally?

There is the gpgme (GnuPG made easy) library which simplifies the usage 
of GnuPG very much. I can't tell you anything about it's efficiency.

> 3) how flexible is PGP with respect to algorithms used?  For instance
> can I say to use AES or rot13 instead of whatever it uses by default?

Of course only secure algorithms are supported, i.e. no rot13. GnuPG 
1.0.6 supports the following symmetric cipher algorithms:
3DES, CAST5, BLOWFISH, RIJNDAEL, RIJNDAEL192, RIJNDAEL256, TWOFISH
and additionally IDEA via a plugin.

> Will this cause problems with other implementations of PGP?

No. Of course not all implementations support all algorithms. Support 
for 3DES is a mandatory requirement in OpenPGP. All newer 
implementations should also support RIJNDAEL (aka AES).

> With
> our own implementation, we could easily have it pop up a konqueror
> download window to obtain the proper plugin.  Users do want the
> ability to choose their weapon.

Except for the IDEA plugin all algorithms are already included in GnuPG.

BTW, IMO asymmetric encryption should also be supported. I'd prefer 
asymmetric encryption because I only have to remember the passphrase of 
my OpenPGP key and not 100 different passphrases for 100 different 
symmetrically encrypted files. "Why not use the same passphrase for all 
files?", you might want to ask. The answer is simple:
If you want to share a symmetrically encrypted file with other people 
you'll have to share the passphrase with them. For security reasons you 
should therefore always use different passphrases for different files. 
You could of course re-encrypt the file you want to share with someone 
else with another shared passphrase. But how do you exchange this 
shared passphrase?
As you can see I don't think that symmetric encryption of files makes 
much sense because of the problem with sharing encrypted files.

Regards,
Ingo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8y0Q9GnR+RTDgudgRAso7AJ9owUcb5ySyyuSWtIFigzcAkeKF6gCghkct
A79oq5cAbul/5LWuz9bN40U=
=QY1w
-----END PGP SIGNATURE-----