Date: Thu, 03 May 2001 16:53:20 +0000 From: Gunther Schadow <gunther@aurora.regenstrief.org> To: snap-users@kame.net, freebsd-security@freebsd.org, freebsd-small@freebsd.org Cc: Soren Kristensen <soren@soekris.com> Subject: HiFn hardware encryption? Message-ID: <3AF18D00.737F6121@aurora.regenstrief.org>
next in thread | raw e-mail | index | archive | help
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. gschadow@regenstrief.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 majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AF18D00.737F6121>