On April 27, 2002 13:46, Roberto Alsina wrote:
> >    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.
>
> A candidate: libmcrypt
>
> http://mcrypt.hellug.gr/
>
> Uses standard algorithms (3DES, IDEA, etc, has a lot of them)
>
> There is already a CLI tool using it, so you could open the files outside
> of KDE (that is a must).
>
> There is a library form, so it can be called from KDE.
>
> License is lgpl, so we can use it or tune it.
>
> It seems to be under active development (ie: not stagnant)

   Actually this library looks really good, and is exactly what we need (in 
conjunction with libmhash).  I think we could easily make a manager to enable 
and disable the various algorithms, and I'm sure we could make a good KDE 
wrapper.  This one has my vote, and it would sure save us a lot of work.  It 
looks very light.  Do you know how portable it is?  From the web page it 
mentions Linux, FreeBSD and OpenBSD.  I'm sure it's more portable than that, 
but the random functions are an issue.  We don't want KDE falling back to 
rand() under any circumstances.  I already deal with enough of these issues 
with OpenSSL (~50% of all bug reports are random problems).

   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?




