From owner-freebsd-small Thu May 3 9:53:37 2001 Delivered-To: freebsd-small@freebsd.org Received: from rgmail.regenstrief.org (rgmail.regenstrief.org [134.68.31.197]) by hub.freebsd.org (Postfix) with ESMTP id EBA2D37B424; Thu, 3 May 2001 09:53:27 -0700 (PDT) (envelope-from gunther@aurora.regenstrief.org) Received: from aurora.regenstrief.org (rgnout.regenstrief.org [134.68.31.38]) by rgmail.regenstrief.org (8.11.0/8.8.7) with ESMTP id f43GwCX16999; Thu, 3 May 2001 11:58:12 -0500 Message-ID: <3AF18D00.737F6121@aurora.regenstrief.org> Date: Thu, 03 May 2001 16:53:20 +0000 From: Gunther Schadow Organization: Regenstrief Institute for Health Care X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: snap-users@kame.net, freebsd-security@freebsd.org, freebsd-small@freebsd.org Cc: Soren Kristensen Subject: HiFn hardware encryption? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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