Resolving the crypto duplicity...

[Poul-Henning Kamp]

I'm just using Rijndael/AES for illustration, the same issues apply
to various other algorithms.

Right now we have identical (apart from some trivial details) of the
AES algorithms in the kernel:

[1]	src/sys/crypto/rijndael/*
	[ipsec, random and geom_bde options]

[2]	arc/sys/opencrypto/rijndael.?
	[crypto]

As far as I can see, the src/crypto stuff which is slightly better
organized, originally arrived with KAME, and the sys/opencrypto
stuff of came in with sam@'s HW-crypto support work.

The HW-crypto support code only needs a software implementation as
a fall-back if hardware does not offer it.

I would like to propose that we try to eliminate the private copies
of crypto functions in sys/opencrypto and instead focus on the
copies in src/crypto as our "generic" implementations.

Are there any technical or political reasons why we should not do this ?


Next problem is that there currently is no way to detect if opencrypto
is present in the kernel or not, or for that matter if we have the
rijndael code in there or not.  This makes life for GBDE as a KLD
sort of interesting.

Were are we going with our kernel modularization ?

Do we want to use multi-level module dependencies ?

	"gbde depends on opencrypto _or_ rijndael"
	"opencrypto depends on rijndael and [...]"
	"random depends on rijndael"

If not, how else do we want to manage this "creepy maze of dependencies,
all tangled" ?

For reference:
	a rijndael implementation is about 14kB in .o files

	GBDE is about 15kB in .o files

	Opencrypto framework is about 25kB in .o files
	Sw-crypto engines an additional 40kB (incl rijndael)

One obvious and tempting solution is to make opencrypt non-optional
since that solves all the dependency issues.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.