Hi,

again, at the risk of talking too much, a friend of ours who is a
hardware engineer (Soeren Kristensen, www.soekris.com) has built
a very cost-effective small low power consumption board with three
ethernet devices, well suited for SOHO routers or IPng "bump-in-the-
wire" boxes. Since this is an i486 class chip, the throughput with
encryption is somewhat limited (at about 2 Mbps with 256 bit blowfish.)

So, Soeren has planned for and is now putting together a plugin
with a HiFn hardware encryption chip. This should be very effective
without blowing up the price too much (may be his next releas of the
board will include that chip on-board ;-).

The question is, how will we be capitalizing on that hardware. For
one, HiFn has very good technical documentation freely available, that
will make driver-writing a breeze. Even I could do that. But the question
is, how best would hardware encryption fit into the overall framework
of FreeBSD and KAME? It would appear to me that there is not one
single point to fit it in. You don't want it to be restricted to the
ip_esp code, nor do you want it to be restricted to the kernel code
(as racoon would greatly benefit from the chip's DH and RSA capabilities.)

I could imagine throwing this behind the sys/crypto code. But that
doesn't make racoon benefit, since racoon relies on OpenSSL. Would
therefore need to put it both places, sys/crypto and as a userland
device and modify OpenSSL to use this new facility. I thought about
three device nodes:

crdi - crypto data in
crdo - crypto data out
crcio - crypto control i/o

I don't like ioctl's (can't be controlled through shell scripts) which
is why I would do the crcio device that can be controlled by sending
ASCII commands to it. But if this creates an outcry, we could use ioctls.
May be we could get by with a single device node: crio that handles
write(2) into the input queue, read(2) accessing the output queue and
ioctl(2) doing the controlling. But then, of course, we could also make
it a socket(2) domain ... may be the chip would also be a good candidate
for being queue managed by ALTQ. Those are just thoughts.

Are there other thoughts out there? Did someone attack this or plans
to attack this in the near or not so near future? I might be able to
allocate some dayjob time to this matter, but I have a certain learning
curve to climb ...

regards
-Gunther

-- 
Gunther Schadow, M.D., Ph.D.                    gschadowregenstrief.org
Medical Information Scientist      Regenstrief Institute for Health Care
Adjunct Assistent Professor        Indiana University School of Medicine
tel:1(317)630-7960                         http://aurora.regenstrief.org
To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]