OpenBSD Cryptographic Framework -- version 2 - introductions/invitations

[Evgeniy Polyakov]

On Mon, May 01, 2006 at 03:44:18PM -0400, Michael Richardson (mcr at xelerance.com) wrote:
> Hi, most of you know me, but not all of you. 

Hello, developers.

> My name is Michael Richardson, I've worked on a number of IPsec
> implementations over the years, and most recently worked on FreeS/WAN,
> turning it into Xelerance's Openswan implementation.
> 
> One of the things that we always wanted to do was to get good, flexible
> integration with available hardware acceleration. Many of you on the To:
> and CC: have worked on this, and you know that it isn't easy. 
> 
> It's best when one can do this with the support and cooperation of a
> vendor: in this case Hifn. Specifically my company has been engaged to
> do 4 things:  {algorithm, packet} X {linux, freebsd}.
>
> Our code base is the OpenBSD Cryptographic Framework, as ported to
> FreeBSD by Sam and others, and then ported to Linux Openswan by David
> McCullough. 
> 
> The work on {algorithm} X { linux, freebsd } is mostly of the
> documentation, cleanup, and integration basis. We need to make the OCF
> framework useable by both KLIPS and NETKEY (aka "Linux 2.6 native").
> We have a plan for that, and we will be putting it on paper
> ("electrons"?) in the next weeks.

Are you going to push it into Linux mainline? That will be hard,
since there is upcoming work on asynchronous crypto api over
existing synchronous SW implementation, which is not compatible with any
existing designs.

> The work on packet acceleration is new work. This is work that we would
> like to call OCF 2.0. We think it should be a superset of the current
> OCF (which we'd like to call OCF 1.0).  We are aware that there has been
> other work on Linux.

According to your OLS abstract:
>1) does anyone care about packet processing and record support?

As far as I know there are only few of them, which have driver support
even from vendor (3com, patches to offload esp parts were quite heavy)

>2) do we care about devices which live on NIC cards, and can not be used
>generally?

Of course, if it allows to have more performance without decrease for
majority of users.

>3) are we enthusiastic, neutral or hostile towards having an API that
>can be used by hardware vendors to write closed source drivers for their
>hardware?

My personal opnion: NO API, which would allow to create closed source
drivers, this (and ignorance otherwise) is the only ability to push
vendors to open specs.

HIFN provides specs, Freescale likely does, VIA does, Intel does NOT,
3com does NOT... Well, just listen OpenBSD songs :)

> So, the next email will contain a formatted man page.

Btw, is it the same page as openbsd crypto man or updated one?
I have not received it.

-- 
	Evgeniy Polyakov