Re: [CryptoAPI-devel] TODO list

[Herbert V. R. <hv...@hv...>]

On Thu, 2002-02-28 at 07:15, David Bryson wrote:
> I noticed that in the move to the new module the TODO, was missing.=20
> That may have been intentional ;-) but i'm not sure.  So at any rate I
> thought i'd ask which ones of these were still needed:
thx for the reminder! :-)

> TODO list
> ~~~~~~~~~
>=20
> short term:
>=20
> *) fix items listed in file BUGS and find new ones (without introducing=20
>    them... ;-)
...this is an endless iteration :-)
=20
> *) support for monolithic kernels (i.e. non-modular cryptoapi)
btw, that should be easier know...

the general procedure now is, to copy/symlink the content of
cryptoapi-core into your kernel source...

and then apply some kernel-version specific patch (i.e. the part of the
latest patch-int on kernel.org, except for the files contained in
Documentation/ and crypto/=20

oh, btw, this reminds me to create a cryptoapi-documentation module...

> *) verify ciphers against known test vectors
>    (especially non-AES ciphers)
that's still needed... I just found some blowfish test vector... but
that's it...
=20
> *) user space tool for converting encrypted volumes between different=20
>    IV blocksizes, passphrases, key lengths, ciphers...
> (tests/cvt_crypt.c)
that's not so important right now; people can convert their encrypted
space=20
=20
> *) check for byte order portability issues=20
btw, the blowfish cipher is such a known issue... see also jari's last
mail...
=20
> *) support 2.2.x kernel eventually
it's getting less important every day... but it should be easy, given
the self-contained crypto subdir...
=20
> long term:
>=20
> *) user space library containing ciphers and cryptoapi
not so important, but nice to have
=20
> *) improve API design
yes...

> *) in-place encryption
that's actually auditing the code, to check whether all ciphers support
this mode... i.e. checking whether src =3D=3D dst yields something
non-corrupted...
=20
> *) swap space encryption
yeah, that's a personal favorite; I really like the openbsd paper,
although I would start with a somewhat simpler (read weaker)
key-management to get something at all working...

...any volunteers for a VM-swap implementation?

> ---------------------------

> I believe that it already has monolithic kernel support, but please
> correct me if i'm wrong.  I finally have gotten a chance to poke around
it always had monolithic support :-) what I mean is, easy support for
it... i.e. some semi-automatic way would be prefered...

> the sources(eek gnu indentation =3D=3D evil, we should be using 1TBS) and
> it's all very exciting stuff ;-)
well, indentation should be our least concern... but if it helps
development I don't have major problems with another indentation
style... what's 1TBS btw? :-)

regards,
--=20
Herbert Valerio Riedel       /    Phone: (EUROPE) +43-1-58801-18840
Email: hv...@hv...       /    Finger hv...@gn... for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F
4142