From owner-linux-crypto@nl.linux.org Tue Sep 26 15:37:36 2000
Received: by humbolt.nl.linux.org id <S92214AbQIZNg7>;
	Tue, 26 Sep 2000 15:36:59 +0200
Received: from mail.nsc.at ([195.58.178.54]:63240 "EHLO mail.nsc.at")
	by humbolt.nl.linux.org with ESMTP id <S92354AbQIZNfj>;
	Tue, 26 Sep 2000 15:35:39 +0200
Received: from pdc.nsc.at (unknown [192.168.168.2])
	by mail.nsc.at (Postfix) with ESMTP id 182B4DBA
	for <linux-crypto@mail.nl.linux.org>; Tue, 26 Sep 2000 15:36:16 +0200 (CEST)
Received: by pdc.nsc.at with Internet Mail Service (5.5.2650.21)
	id <TVBMTZZL>; Tue, 26 Sep 2000 15:34:13 +0200
Message-ID: <61767C2F5423D41190030000B4A8AA070926A7@pdc.nsc.at>
From:   Otto Klingesberger <ok@nsc.at>
To:     "'linux-crypto@mail.nl.linux.org'" <linux-crypto@nl.linux.org>
Subject: 
Date:   Tue, 26 Sep 2000 15:34:13 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

auth 44ed1ec1 subscribe linux-crypto ok@nsc.at


Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Tue Sep 26 18:44:52 2000
Received: by humbolt.nl.linux.org id <S92269AbQIZQo1>;
	Tue, 26 Sep 2000 18:44:27 +0200
Received: from [204.244.205.25] ([204.244.205.25]:30768 "HELO post.gateone.com")
	by humbolt.nl.linux.org with SMTP id <S92346AbQIZQn4>;
	Tue, 26 Sep 2000 18:43:56 +0200
Received: (qmail 22229 invoked from network); 26 Sep 2000 16:40:26 -0000
Received: from mystery.wizard.ca (HELO mistress) (204.244.205.8)
  by mail.wizard.ca with SMTP; 26 Sep 2000 16:40:26 -0000
From:   Michael Peddemors <michael@wizard.ca>
Organization: Wizard Internet Services
To:     linux-crypto@nl.linux.org
Subject: New Mail list
Date:   Tue, 26 Sep 2000 09:51:50 -0700
X-Mailer: KMail [version 1.1.62]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <00092609515002.23167@mistress>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

Great topic for a new list..  Might as well start it off with a little wasted 
bandwidth.

This list is very important for us for several reasons.
Specifically, because we have a VPN Firewall on a 1.44 floppy, based on the 
FreeS/WAN ipsec, and using an encrypted initrd.gz

We want to see the FreeS/WAN code in the main kernel stream.

(I know, this list is supposed to be for CIPE too, but when we first looked 
at it, we had compilation problems, and no support from the listed 
maintainers, and in hindsight, the FreeS/WAN now seems to have been the 
better choice overall for us, so we are specific to FreeS/WAN)

We are a security consulting company, so this is also something we should 
keep up with in general.

We might have something to add occasionally..



-- 
--------------------------------------------------------
Michael Peddemors - Senior Consultant
Unix Administration - WebSite Hosting
Network Services - Programming
Wizard Internet Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com
--------------------------------------------------------
(604) 589-0037 Beautiful British Columbia, Canada
--------------------------------------------------------

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Tue Sep 26 19:13:12 2000
Received: by humbolt.nl.linux.org id <S92214AbQIZRM6>;
	Tue, 26 Sep 2000 19:12:58 +0200
Received: from terra.geo.uu.nl ([131.211.29.16]:26330 "EHLO terra.geo.uu.nl")
	by humbolt.nl.linux.org with ESMTP id <S92269AbQIZRMa>;
	Tue, 26 Sep 2000 19:12:30 +0200
Received: from mail.storm.ca (storm.ca [209.87.239.69])
	by terra.geo.uu.nl (8.9.3/8.9.3/TvZ) with ESMTP id TAA07516
	for <linux-crypto@nl.linux.org>; Tue, 26 Sep 2000 19:12:29 +0200 (MET DST)
Received: from storm.ca (ppp072.ottawa.storm.ca [209.87.255.72])
	by mail.storm.ca (8.9.3+Sun/8.9.3) with ESMTP id NAA09676
	for <linux-crypto@nl.linux.org>; Tue, 26 Sep 2000 13:11:57 -0400 (EDT)
Message-ID: <39D0D912.90AF1772@storm.ca>
Date:   Tue, 26 Sep 2000 13:12:50 -0400
From:   Sandy Harris <sandy@storm.ca>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en,fr
MIME-Version: 1.0
To:     linux-crypto@nl.linux.org
Subject: resources
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

The FreeS/WAN IPSEC for Linux project has all its documentation online.

Main URL:        http://www.freeswan.org/
Documentation:   http://www.freeswan.org/doc.html

Three files under http://www.freeswan.org/freeswan_trees/freeswan-1.5/doc/
have links that might be of interest:

	links.ipsec.html
	links.crypto.html
	links.linux.html

It is all under GPL, so if anyone wants any of that as a starting point for
a resource page for this list, help yourselves. If anyone knows of resources
that should be listed above and aren't, let me know. I'll happily add them. 

There's also a list of mailing lists:

http://www.freeswan.org/freeswan_trees/freeswan-1.5/doc/mail.html

I'll be adding this one shortly. Anyone know of others not listed?

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Tue Sep 26 21:09:39 2000
Received: by humbolt.nl.linux.org id <S92353AbQIZTJO>;
	Tue, 26 Sep 2000 21:09:14 +0200
Received: from doggy.lineone.net ([194.75.152.224]:29353 "EHLO
        scooby.lineone.net") by humbolt.nl.linux.org with ESMTP
	id <S92355AbQIZTIn>; Tue, 26 Sep 2000 21:08:43 +0200
Received: from simon.widearea.org (root@host213-1-45-75.host.btclick.com [213.1.45.75])
	by scooby.lineone.net (8.9.3/8.9.3) with ESMTP id UAA27173
	for <linux-crypto@humbolt.nl.linux.org>; Tue, 26 Sep 2000 20:08:36 +0100 (BST)
Received: from localhost (net-ste@localhost)
	by simon.widearea.org (8.9.3/8.9.3) with ESMTP id UAA06277
	for <linux-crypto@mail.nl.linux.org>; Tue, 26 Sep 2000 20:08:29 +0100
Date:   Tue, 26 Sep 2000 20:08:29 +0100 (BST)
From:   Stephen Bowyer <net-ste@widearea.org>
To:     linux-crypto@nl.linux.org
Message-ID: <Pine.LNX.4.20.0009262008040.6205-100000@simon.widearea.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

auth abc0b239 subscribe linux-crypto net-ste@widearea.org


Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Wed Sep 27 12:18:56 2000
Received: by humbolt.nl.linux.org id <S92264AbQI0KSa>;
	Wed, 27 Sep 2000 12:18:30 +0200
Received: from linux.sisa.be ([194.88.100.134]:17162 "HELO socrates.sisa.be")
	by humbolt.nl.linux.org with SMTP id <S92221AbQI0KSD>;
	Wed, 27 Sep 2000 12:18:03 +0200
Received: (qmail 13705 invoked by uid 612); 27 Sep 2000 10:18:09 -0000
Date:   Wed, 27 Sep 2000 12:18:09 +0200
From:   Peter van Hove <peter.van.hove@mind.be>
To:     linux-crypto <linux-crypto@nl.linux.org>
Subject: Hardware crypto
Message-ID: <20000927121809.A13379@mind.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

Reply-To: 
Hello all,

i was wndering if there already is support for crypto cards in the kernel and if so
can they be used to accelerate IPsec encryption.

Peter Van Hove
Unix & Opensource consultant
Mind NV
http://mind.be

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Wed Sep 27 13:06:51 2000
Received: by humbolt.nl.linux.org id <S92278AbQI0LGU>;
	Wed, 27 Sep 2000 13:06:20 +0200
Received: from midten.fast.no ([213.188.8.11]:58127 "EHLO midten.fast.no")
	by humbolt.nl.linux.org with ESMTP id <S92266AbQI0LFh>;
	Wed, 27 Sep 2000 13:05:37 +0200
Received: (from astor@localhost)
	by midten.fast.no (8.9.3/8.9.3) id NAA65965;
	Wed, 27 Sep 2000 13:04:56 +0200 (CEST)
Date:   Wed, 27 Sep 2000 13:04:56 +0200
From:   Alexander S A Kjeldaas <Alexander.Kjeldaas@fast.no>
To:     Peter van Hove <peter.van.hove@mind.be>
Cc:     linux-crypto <linux-crypto@nl.linux.org>
Subject: Re: Hardware crypto
Message-ID: <20000927130456.B62395@midten.fast.no>
References: <20000927121809.A13379@mind.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4i
In-Reply-To: <20000927121809.A13379@mind.be>; from Peter van Hove on Wed, Sep 27, 2000 at 12:18:09PM +0200
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

On Wed, Sep 27, 2000 at 12:18:09PM +0200, Peter van Hove wrote:
> Hello all,
> 
> i was wndering if there already is support for crypto cards in the
> kernel and if so can they be used to accelerate IPsec encryption.

There is a product from Redcreek with linux drivers. I have not tried
it.

http://www.redcreek.com/products/ipsec_card.html

astor

-- 
Alexander Kjeldaas                Mail:  astor@fast.no
finger astor@master.kernel.org for OpenPGP key.

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Wed Sep 27 15:43:45 2000
Received: by humbolt.nl.linux.org id <S92378AbQI0NnP>;
	Wed, 27 Sep 2000 15:43:15 +0200
Received: from mail2.uni-bielefeld.de ([129.70.4.90]:57678 "EHLO
        mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP
	id <S92373AbQI0Nme>; Wed, 27 Sep 2000 15:42:34 +0200
Received: from Mutz.com (ppp36-88.hrz.uni-bielefeld.de [129.70.36.88])
 by mail.uni-bielefeld.de
 (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6)
 with ESMTP id <0G1J00F73SQDKG@mail.uni-bielefeld.de> for
 linux-crypto@nl.linux.org; Wed, 27 Sep 2000 15:42:13 +0200 (MET DST)
Date:   Wed, 27 Sep 2000 13:38:31 +0000
From:   Marc Mutz <Marc@Mutz.com>
Subject: Re: Hardware crypto
To:     Peter van Hove <peter.van.hove@mind.be>
Cc:     linux-crypto <linux-crypto@nl.linux.org>
Message-id: <39D1F857.D049BDC7@Mutz.com>
Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics
MIME-version: 1.0
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <20000927121809.A13379@mind.be>
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

Peter van Hove wrote:
> 
<snip>
> i was wndering if there already is support for crypto cards in the kernel and if so
> can they be used to accelerate IPsec encryption.
> 

Lee Cremeans <leec@gtgi.com> is working on a driver for a crypto card
for Linux. He posted an unrelated question on lkml, but has not said
anything more about it. If it is there, I'll try and make this work for
the cryptoapi (kerneli patch). But so far, both frees/wan and (this is a
guess) the nist implementation of ipsec for linux do not use the crypto
api. The redcreek thing might be the better way for now.

Marc

-- 
Marc Mutz <Marc@Mutz.com>        http://marc.mutz.com/Encryption-HOWTO/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's:   0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)


Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Wed Sep 27 16:29:21 2000
Received: by humbolt.nl.linux.org id <S92243AbQI0O2Q>;
	Wed, 27 Sep 2000 16:28:16 +0200
Received: from cpu2747.adsl.bellglobal.com ([207.236.55.216]:38651 "EHLO
        grendel.conscoop.ottawa.on.ca") by humbolt.nl.linux.org with ESMTP
	id <S92274AbQI0O1l>; Wed, 27 Sep 2000 16:27:41 +0200
Received: (from rgb@localhost)
	by grendel.conscoop.ottawa.on.ca (8.9.0/8.9.0) id KAA06188;
	Wed, 27 Sep 2000 10:25:23 -0400
Date:   Wed, 27 Sep 2000 10:25:22 -0400
From:   Richard Guy Briggs <rgb@conscoop.ottawa.on.ca>
To:     Marc Mutz <Marc@Mutz.com>
Cc:     Peter van Hove <peter.van.hove@mind.be>,
        linux-crypto <linux-crypto@nl.linux.org>
Subject: Re: Hardware crypto
Message-ID: <20000927102522.Q28566@grendel.conscoop.ottawa.on.ca>
References: <20000927121809.A13379@mind.be> <39D1F857.D049BDC7@Mutz.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <39D1F857.D049BDC7@Mutz.com>; from Marc@Mutz.com on Wed, Sep 27, 2000 at 01:38:31PM +0000
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, Sep 27, 2000 at 01:38:31PM +0000, Marc Mutz wrote:
> Peter van Hove wrote:
> > 
> <snip>
> > i was wndering if there already is support for crypto cards in the
> > kernel and if so can they be used to accelerate IPsec encryption.
> > 
> 
> Lee Cremeans <leec@gtgi.com> is working on a driver for a crypto card
> for Linux. He posted an unrelated question on lkml, but has not said
> anything more about it. If it is there, I'll try and make this work for
> the cryptoapi (kerneli patch). But so far, both frees/wan and (this is a
> guess) the nist implementation of ipsec for linux do not use the crypto
> api. The redcreek thing might be the better way for now.

We (FreeS/WAN) are not directly working on hardware crypto support,
but are certainly willing to morally support its development and
include well-formed unencumbered code to do so.  Bart Trojanovsky
(sp?) of Chrysalis-ITS here in Ottawa is working on linux drivers for
their hardware crypto accellerator and on integrating them into
FreeS/WAN.  We were hoping that libgcrypt from the GnuPG project could
be used for this, having options to compile it as a userspace or
kernelspace lib.  I doubt we would need and strongly hope we would not
need gmp in the kernel portions since libgcrypt would abstract all
this away so we don't care what is doing encryption/decryption.  It
would also be not only SMP-safe, but able to take advantage of
parallelism by queueing jobs.

I really need to take a serious look at the kerneli patch and see what
we can do to co-operate...

> Marc Mutz <Marc@Mutz.com>        http://marc.mutz.com/Encryption-HOWTO/

	slainte mhath, RGB
- -- 
Richard Guy Briggs -- PGP key available            Auto-Free Ottawa! Canada
<www.conscoop.ottawa.on.ca/rgb/>                       <www.flora.org/afo/>
Prevent Internet Wiretapping!        --        FreeS/WAN:<www.freeswan.org>
Thanks for voting Green! -- <green.ca>      Marillion:<www.marillion.co.uk>

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBOdIDT9+sBuIhFagtAQGz6AP+OasY+eeu3F2FveHIA37Lvrk5v3SHyCry
diHiSUBZLc6bIA6v7cZ4PHC2hXXY5UhsP4VI/UWIWM7biNGXm2qDi0NSXog3/SfZ
X6u7RrxsB0KFAqpUI4iRw0ZmnXGZK+3LMeQ/5E7BlfWeoVPdTkbDFVLViH+WSSCT
vlsG3zpwqJo=
=4PcW
-----END PGP SIGNATURE-----

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Wed Sep 27 17:53:07 2000
Received: by humbolt.nl.linux.org id <S92373AbQI0Pwo>;
	Wed, 27 Sep 2000 17:52:44 +0200
Received: from midten.fast.no ([213.188.8.11]:61967 "EHLO midten.fast.no")
	by humbolt.nl.linux.org with ESMTP id <S92274AbQI0PwO>;
	Wed, 27 Sep 2000 17:52:14 +0200
Received: (from astor@localhost)
	by midten.fast.no (8.9.3/8.9.3) id RAA77849;
	Wed, 27 Sep 2000 17:52:04 +0200 (CEST)
Date:   Wed, 27 Sep 2000 17:52:04 +0200
From:   Alexander S A Kjeldaas <Alexander.Kjeldaas@fast.no>
To:     Marc Mutz <Marc@Mutz.com>
Cc:     Peter van Hove <peter.van.hove@mind.be>,
        linux-crypto <linux-crypto@nl.linux.org>
Subject: Re: Hardware crypto
Message-ID: <20000927175204.A75897@midten.fast.no>
References: <20000927121809.A13379@mind.be> <39D1F857.D049BDC7@Mutz.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4i
In-Reply-To: <39D1F857.D049BDC7@Mutz.com>; from Marc Mutz on Wed, Sep 27, 2000 at 01:38:31PM +0000
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

On Wed, Sep 27, 2000 at 01:38:31PM +0000, Marc Mutz wrote:
> Peter van Hove wrote:
> > 
> <snip>
> > i was wndering if there already is support for crypto cards in the kernel and if so
> > can they be used to accelerate IPsec encryption.
> > 
> 
> Lee Cremeans <leec@gtgi.com> is working on a driver for a crypto card
> for Linux. He posted an unrelated question on lkml, but has not said
> anything more about it. If it is there, I'll try and make this work for
> the cryptoapi (kerneli patch). But so far, both frees/wan and (this is a
> guess) the nist implementation of ipsec for linux do not use the crypto
> api. The redcreek thing might be the better way for now.
> 

I think there are some interesting issues to be solved when we want to
get hardware crypto cards running under Linux.  For one, we want to
have a queue of processing requests for the device instead of having a
synchronous interface like most crypto libraries offer.  We also
probably want to use the CPU if the queue starts to have too many
entries, or load-balance between several cards, so we need a
"crypto-provider" concept.  Also, for programmable crypto-cards we
might want to consider the cost of switching ciphers on the card when
choosing which requests should be done by which cards/CPU.  This will
be interesting to look at when the first drivers emerge.

astor

-- 
Alexander Kjeldaas                Mail:  astor@fast.no
finger astor@master.kernel.org for OpenPGP key.

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Wed Sep 27 18:09:38 2000
Received: by humbolt.nl.linux.org id <S92385AbQI0QJQ>;
	Wed, 27 Sep 2000 18:09:16 +0200
Received: from [216.168.105.33] ([216.168.105.33]:52218 "HELO
        mail.fibrespeed.net") by humbolt.nl.linux.org with SMTP
	id <S92382AbQI0QIe>; Wed, 27 Sep 2000 18:08:34 +0200
Received: (qmail 10953 invoked from network); 27 Sep 2000 16:08:29 -0000
Received: from unknown (508@216.168.105.34)
  by 216.168.105.35 with QMQP; 27 Sep 2000 16:08:29 -0000
Received: from mb.circus.fibrespeed.net (HELO scanner) (192.168.10.12)
  by gw.fibrespeed.net with SMTP; 27 Sep 2000 12:08:28 -0000
Message-ID: <000701c0289d$75d14780$0c0aa8c0@hosted.fibrespeed.net>
From:   "Michael T. Babcock" <mbabcock@fibrespeed.net>
To:     "Alexander S A Kjeldaas" <Alexander.Kjeldaas@fast.no>,
        "Marc Mutz" <Marc@Mutz.com>
Cc:     "Peter van Hove" <peter.van.hove@mind.be>,
        "linux-crypto" <linux-crypto@nl.linux.org>
References: <20000927121809.A13379@mind.be> <39D1F857.D049BDC7@Mutz.com> <20000927175204.A75897@midten.fast.no>
Subject: Re: Hardware crypto
Date:   Wed, 27 Sep 2000 12:10:30 -0400
Organization: FibreSpeed
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

> On Wed, Sep 27, 2000 at 01:38:31PM +0000, Marc Mutz wrote:
> I think there are some interesting issues to be solved when we want to
> get hardware crypto cards running under Linux.  For one, we want to
> have a queue of processing requests for the device instead of having a
> synchronous interface like most crypto libraries offer.  We also
> probably want to use the CPU if the queue starts to have too many
> entries, or load-balance between several cards, so we need a
> "crypto-provider" concept.  Also, for programmable crypto-cards we
> might want to consider the cost of switching ciphers on the card when
> choosing which requests should be done by which cards/CPU.  This will
> be interesting to look at when the first drivers emerge.

A queuing concept is definately needed if this is to be done right the first
time (so to speak).  The configuration of this interface, however, would be
the interesting challenge here.  How to present to the user (the sysadmin,
most likely) the options for dealing with crypto on a per-system, perhaps
per-app basis.  Prioritising certain applications over others, perhaps,
would end up being an issue as well.

For example:
OpenSSL uses the "crypto accel api" for web serving.
FreeS/WAN uses it for VPN traffic.
GPG uses it to encrypt E-mails or generate signatures.

I would probably set the FreeS/WAN requests to have a slightly lower
priority than the OpenSSL requests because we host E-commerce sites ... and
the GPG traffic would be lowest, but I wouldn't want it to get swamped out
of the picture if the crypto card were at full use.  Having it send a
suitable? number of requests to the software crypto system would be
necessary as well.

It becomes quite interestingly complex ;-).



Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Wed Sep 27 18:15:28 2000
Received: by humbolt.nl.linux.org id <S92382AbQI0QOx>;
	Wed, 27 Sep 2000 18:14:53 +0200
Received: from hplms26.hpl.hp.com ([15.255.168.31]:34564 "EHLO
        hplms26.hpl.hp.com") by humbolt.nl.linux.org with ESMTP
	id <S92274AbQI0QO1>; Wed, 27 Sep 2000 18:14:27 +0200
Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33])
	by hplms26.hpl.hp.com (8.9.3 (PHNE_18979)/HPL-PA Relay) with ESMTP id JAA05112
	for <linux-crypto@nl.linux.org>; Wed, 27 Sep 2000 09:14:19 -0700 (PDT)
Received: from ndunbar.hpl.hp.com (ndunbar.hpl.hp.com [15.144.30.170])
	by hplms2.hpl.hp.com (8.10.2/8.10.2 HPL-PA Hub) with ESMTP id e8RGEH328209
	for <linux-crypto@nl.linux.org>; Wed, 27 Sep 2000 09:14:18 -0700 (PDT)
Received: from hplb.hpl.hp.com (dunbar-n-1.hpl.hp.com [15.144.26.129])
	by ndunbar.hpl.hp.com (Postfix) with ESMTP id 2BDB92AA5
	for <linux-crypto@nl.linux.org>; Wed, 27 Sep 2000 17:14:17 +0100 (BST)
Message-ID: <39D21D58.CB3FD30A@hplb.hpl.hp.com>
Date:   Wed, 27 Sep 2000 17:16:24 +0100
From:   Neil Dunbar <nd@hplb.hpl.hp.com>
Reply-To: nd@hplb.hpl.hp.com
Organization: Hewlett-Packard Company - ISE
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.18pre9aa1 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-crypto <linux-crypto@nl.linux.org>
Subject: Re: Hardware crypto
References: <20000927121809.A13379@mind.be> <39D1F857.D049BDC7@Mutz.com> <20000927175204.A75897@midten.fast.no>
Content-Type: multipart/mixed;
 boundary="------------D507108F2F5FE7124248CD07"
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

This is a multi-part message in MIME format.
--------------D507108F2F5FE7124248CD07
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alexander S A Kjeldaas wrote:
> 
> I think there are some interesting issues to be solved when we want to
> get hardware crypto cards running under Linux.  For one, we want to
> have a queue of processing requests for the device instead of having a
> synchronous interface like most crypto libraries offer.  We also
> probably want to use the CPU if the queue starts to have too many
> entries, or load-balance between several cards, so we need a
> "crypto-provider" concept.

So you need an abstraction interface. If we're talking
kernel here (ie for IPsec/filesystem crypto/stego), then
all we should need is an abstraction over symmetric key
operations - IKE is done in userspace, after all. I suppose
that it would be possible to leave the slot open for
message digests as well, although I haven't seen a card
which accelerates MD5/SHA-1, or HMAC over them.

The only plea that I would make is to not make it too
fancy - otherwise we end up with CDSA and other such
monsters.

Neil
--------------D507108F2F5FE7124248CD07
Content-Type: text/x-vcard; charset=us-ascii;
 name="nd.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Neil Dunbar
Content-Disposition: attachment;
 filename="nd.vcf"

begin:vcard 
n:Dunbar;Neil
tel;fax:+44 (0) 117 312 9901
tel;home:+44 (0) 1454 856684
tel;work:+44 (0) 117 312 9471
x-mozilla-html:FALSE
org:Hewlett Packard Company;ISE
version:2.1
email;internet:neil_dunbar@hp.com
title:IT Consultant
adr;quoted-printable:;;Filton Road=0D=0AStoke Gifford;Bristol;England;BS34 6QZ;United Kingdom
x-mozilla-cpt:;-24320
fn:Neil Dunbar
end:vcard

--------------D507108F2F5FE7124248CD07--


Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Wed Sep 27 18:19:46 2000
Received: by humbolt.nl.linux.org id <S92387AbQI0QSy>;
	Wed, 27 Sep 2000 18:18:54 +0200
Received: from terra.geo.uu.nl ([131.211.29.16]:50669 "EHLO terra.geo.uu.nl")
	by humbolt.nl.linux.org with ESMTP id <S92274AbQI0QS1>;
	Wed, 27 Sep 2000 18:18:27 +0200
Received: from mail.storm.ca (storm.ca [209.87.239.69])
	by terra.geo.uu.nl (8.9.3/8.9.3/TvZ) with ESMTP id SAA27181
	for <linux-crypto@nl.linux.org>; Wed, 27 Sep 2000 18:18:26 +0200 (MET DST)
Received: from storm.ca (ppp072.ottawa.storm.ca [209.87.255.72])
	by mail.storm.ca (8.9.3+Sun/8.9.3) with ESMTP id MAA03137
	for <linux-crypto@nl.linux.org>; Wed, 27 Sep 2000 12:17:52 -0400 (EDT)
Message-ID: <39D21DE7.F1EC38D6@storm.ca>
Date:   Wed, 27 Sep 2000 12:18:47 -0400
From:   Sandy Harris <sandy@storm.ca>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en,fr
MIME-Version: 1.0
To:     linux-crypto <linux-crypto@nl.linux.org>
Subject: Re: Hardware crypto
References: <20000927121809.A13379@mind.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

Peter van Hove wrote:

> i was wndering if there already is support for crypto cards in the kernel and if so
> can they be used to accelerate IPsec encryption.

This question has come up a number of times on FreeS/WAN's linux-ipsec@clinet.fi
list, including being asked by several hardware vendors. So far the answer has
been that FreeS/WAN wasn't designed for that, but the kernel parts are in the
process of re-design for other reasons and we'll try to provide a clean interface
to hardware in the new design. It is not one of the top considerations, though.

Meanwhile, someone at chip/board vendor Chrysalis (www.chrysalis-its.com)
is working on kernel patches to support their stuff, with the co-operation of the
FreeS/WAN kernel hacker. The intention is to define an interface generic enough
that other hardware could use it as well.

For details, search that list's archive:

http://www.sandelman.ottawa.on.ca/linux-ipsec/

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Wed Sep 27 18:21:16 2000
Received: by humbolt.nl.linux.org id <S92391AbQI0QUm>;
	Wed, 27 Sep 2000 18:20:42 +0200
Received: from cpu2747.adsl.bellglobal.com ([207.236.55.216]:4852 "EHLO
        grendel.conscoop.ottawa.on.ca") by humbolt.nl.linux.org with ESMTP
	id <S92389AbQI0QTp>; Wed, 27 Sep 2000 18:19:45 +0200
Received: (from rgb@localhost)
	by grendel.conscoop.ottawa.on.ca (8.9.0/8.9.0) id MAA07340;
	Wed, 27 Sep 2000 12:17:20 -0400
Date:   Wed, 27 Sep 2000 12:17:17 -0400
From:   Richard Guy Briggs <rgb@conscoop.ottawa.on.ca>
To:     Alexander S A Kjeldaas <Alexander.Kjeldaas@fast.no>
Cc:     Marc Mutz <Marc@Mutz.com>, Peter van Hove <peter.van.hove@mind.be>,
        linux-crypto <linux-crypto@nl.linux.org>
Subject: Re: Hardware crypto
Message-ID: <20000927121717.Z28566@grendel.conscoop.ottawa.on.ca>
References: <20000927121809.A13379@mind.be> <39D1F857.D049BDC7@Mutz.com> <20000927175204.A75897@midten.fast.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20000927175204.A75897@midten.fast.no>; from Alexander.Kjeldaas@fast.no on Wed, Sep 27, 2000 at 05:52:04PM +0200
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, Sep 27, 2000 at 05:52:04PM +0200, Alexander S A Kjeldaas wrote:
> On Wed, Sep 27, 2000 at 01:38:31PM +0000, Marc Mutz wrote:
> > Peter van Hove wrote:
> > > 
> > <snip>
> > > i was wndering if there already is support for crypto cards in the kernel and if so
> > > can they be used to accelerate IPsec encryption.
> > > 
> > 
> > Lee Cremeans <leec@gtgi.com> is working on a driver for a crypto card
> > for Linux. He posted an unrelated question on lkml, but has not said
> > anything more about it. If it is there, I'll try and make this work for
> > the cryptoapi (kerneli patch). But so far, both frees/wan and (this is a
> > guess) the nist implementation of ipsec for linux do not use the crypto
> > api. The redcreek thing might be the better way for now.
> 
> I think there are some interesting issues to be solved when we want to
> get hardware crypto cards running under Linux.  For one, we want to
> have a queue of processing requests for the device instead of having a
> synchronous interface like most crypto libraries offer.  We also
> probably want to use the CPU if the queue starts to have too many
> entries, or load-balance between several cards, so we need a
> "crypto-provider" concept.  Also, for programmable crypto-cards we
> might want to consider the cost of switching ciphers on the card when
> choosing which requests should be done by which cards/CPU.  This will
> be interesting to look at when the first drivers emerge.

I completely agree that it should be queue-based.  SMP is the other
obvious reason for a queue.

Alan Cox has publicly stated that he thinks this is the right way to
do things, but at the moment, asynchrony and queues for this type of
processing will be a big challenge to accomplish this in the present
Linux kernels.  This is something that needs to get Linus' ear when
planning for 2.5.

> astor
> 
> -- 
> Alexander Kjeldaas                Mail:  astor@fast.no
> finger astor@master.kernel.org for OpenPGP key.
> 
> Linux-crypto:  cryptography in and on the Linux system
> Archive:       http://mail.nl.linux.org/linux-crypto/

	slainte mhath, RGB
- -- 
Richard Guy Briggs -- PGP key available            Auto-Free Ottawa! Canada
<www.conscoop.ottawa.on.ca/rgb/>                       <www.flora.org/afo/>
Prevent Internet Wiretapping!        --        FreeS/WAN:<www.freeswan.org>
Thanks for voting Green! -- <green.ca>      Marillion:<www.marillion.co.uk>

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBOdIdh9+sBuIhFagtAQEmnAP/R3edd683P1+XsiHEZOMJ2kRDwDdsQE9J
HvD6pD1KbdG80Lcy0vogGJezXKGJY74wd1RB5Uq0iGsBRTofOamqN1tMOpqR6FZ1
2UM1Gk6AtIr42MyGp9wnL/q0DPmMwLEv1T+Mzn/8C6Tliqx3L5Fw/uJA4g5Dm2o9
Z56K4bY+2jw=
=Jfbh
-----END PGP SIGNATURE-----

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Wed Sep 27 18:22:46 2000
Received: by humbolt.nl.linux.org id <S92390AbQI0QWW>;
	Wed, 27 Sep 2000 18:22:22 +0200
Received: from [216.168.105.33] ([216.168.105.33]:41979 "HELO
        mail.fibrespeed.net") by humbolt.nl.linux.org with SMTP
	id <S92389AbQI0QWO>; Wed, 27 Sep 2000 18:22:14 +0200
Received: (qmail 11441 invoked from network); 27 Sep 2000 16:22:12 -0000
Received: from unknown (508@216.168.105.34)
  by 216.168.105.35 with QMQP; 27 Sep 2000 16:22:12 -0000
Received: from mb.circus.fibrespeed.net (HELO scanner) (192.168.10.12)
  by gw.fibrespeed.net with SMTP; 27 Sep 2000 12:22:12 -0000
Message-ID: <002601c0289f$60e36400$0c0aa8c0@hosted.fibrespeed.net>
From:   "Michael T. Babcock" <mbabcock@fibrespeed.net>
To:     <nd@hplb.hpl.hp.com>, "linux-crypto" <linux-crypto@nl.linux.org>
References: <20000927121809.A13379@mind.be> <39D1F857.D049BDC7@Mutz.com> <20000927175204.A75897@midten.fast.no> <39D21D58.CB3FD30A@hplb.hpl.hp.com>
Subject: Re: Hardware crypto
Date:   Wed, 27 Sep 2000 12:24:15 -0400
Organization: FibreSpeed
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

> Alexander S A Kjeldaas wrote:
>
> So you need an abstraction interface. If we're talking
> kernel here (ie for IPsec/filesystem crypto/stego), then
> all we should need is an abstraction over symmetric key
> operations - IKE is done in userspace, after all. I suppose
> that it would be possible to leave the slot open for
> message digests as well, although I haven't seen a card
> which accelerates MD5/SHA-1, or HMAC over them.

I would be tempted to do (some of) what another company did (what's their
name ... Microsoft?) when they implemented an acceleration layer for video /
sound, etc.  That is, add hooks for things that aren't necessarily
accelerated everywhere, but might be, and then report back to the caller
whether those things are or are not accelerated (like a CPU-ID).

Session = CryptoAccel_Init();
if (CryptoAccel_Available(CRYPTA_SHA1))
    /* send data to be accelerated */
else
    /* do it yourself, or let the un-accelerated library do it */

> The only plea that I would make is to not make it too
> fancy - otherwise we end up with CDSA and other such
> monsters.

True enough ...

--
Michael T. Babcock


Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Wed Sep 27 18:44:10 2000
Received: by humbolt.nl.linux.org id <S92398AbQI0Qne>;
	Wed, 27 Sep 2000 18:43:34 +0200
Received: from hplms26.hpl.hp.com ([15.255.168.31]:43014 "EHLO
        hplms26.hpl.hp.com") by humbolt.nl.linux.org with ESMTP
	id <S92395AbQI0QnK>; Wed, 27 Sep 2000 18:43:10 +0200
Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33])
	by hplms26.hpl.hp.com (8.9.3 (PHNE_18979)/HPL-PA Relay) with ESMTP id JAA06921
	for <linux-crypto@nl.linux.org>; Wed, 27 Sep 2000 09:43:08 -0700 (PDT)
Received: from ndunbar.hpl.hp.com (ndunbar.hpl.hp.com [15.144.30.170])
	by hplms2.hpl.hp.com (8.10.2/8.10.2 HPL-PA Hub) with ESMTP id e8RGh6302361
	for <linux-crypto@nl.linux.org>; Wed, 27 Sep 2000 09:43:07 -0700 (PDT)
Received: from hplb.hpl.hp.com (dunbar-n-1.hpl.hp.com [15.144.26.129])
	by ndunbar.hpl.hp.com (Postfix) with ESMTP id E6F022AA5
	for <linux-crypto@nl.linux.org>; Wed, 27 Sep 2000 17:43:05 +0100 (BST)
Message-ID: <39D22419.61F907E7@hplb.hpl.hp.com>
Date:   Wed, 27 Sep 2000 17:45:13 +0100
From:   Neil Dunbar <nd@hplb.hpl.hp.com>
Reply-To: nd@hplb.hpl.hp.com
Organization: Hewlett-Packard Company - ISE
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.18pre9aa1 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-crypto <linux-crypto@nl.linux.org>
Subject: Re: Hardware crypto
References: <20000927121809.A13379@mind.be> <39D1F857.D049BDC7@Mutz.com> <20000927175204.A75897@midten.fast.no> <39D21D58.CB3FD30A@hplb.hpl.hp.com> <002601c0289f$60e36400$0c0aa8c0@hosted.fibrespeed.net>
Content-Type: multipart/mixed;
 boundary="------------FE25ED7DCB08AB7F210CA3B5"
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

This is a multi-part message in MIME format.
--------------FE25ED7DCB08AB7F210CA3B5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Michael T. Babcock" wrote:
> 
> > Alexander S A Kjeldaas wrote:
> >
> > So you need an abstraction interface.

Oh, don't go attributing my random wibbling to
poor Alexander!

> I would be tempted to do (some of) what another company did (what's their
> name ... Microsoft?) when they implemented an acceleration layer for video /
> sound, etc.

Perhaps. Or perhaps the implementation of DRI/DRM in
the current kernel (ie for 3D acceleration) would
be a starting point.

If I yank the tdfx.o module from the active list,
OpenGL works on my machine - just goes slowly, so
this sort of thing has been thought of and implemented
already.

Neil
--------------FE25ED7DCB08AB7F210CA3B5
Content-Type: text/x-vcard; charset=us-ascii;
 name="nd.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Neil Dunbar
Content-Disposition: attachment;
 filename="nd.vcf"

begin:vcard 
n:Dunbar;Neil
tel;fax:+44 (0) 117 312 9901
tel;home:+44 (0) 1454 856684
tel;work:+44 (0) 117 312 9471
x-mozilla-html:FALSE
org:Hewlett Packard Company;ISE
version:2.1
email;internet:neil_dunbar@hp.com
title:IT Consultant
adr;quoted-printable:;;Filton Road=0D=0AStoke Gifford;Bristol;England;BS34 6QZ;United Kingdom
x-mozilla-cpt:;-24320
fn:Neil Dunbar
end:vcard

--------------FE25ED7DCB08AB7F210CA3B5--


Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Wed Sep 27 19:22:13 2000
Received: by humbolt.nl.linux.org id <S92400AbQI0RVh>;
	Wed, 27 Sep 2000 19:21:37 +0200
Received: from mail2.uni-bielefeld.de ([129.70.4.90]:10390 "EHLO
        mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP
	id <S92274AbQI0RVM>; Wed, 27 Sep 2000 19:21:12 +0200
Received: from Mutz.com (ppp36-58.hrz.uni-bielefeld.de [129.70.36.58])
 by mail.uni-bielefeld.de
 (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6)
 with ESMTP id <0G1K00MNA2V2DE@mail.uni-bielefeld.de> for
 linux-crypto@nl.linux.org; Wed, 27 Sep 2000 19:21:07 +0200 (MET DST)
Date:   Wed, 27 Sep 2000 17:20:14 +0000
From:   Marc Mutz <Marc@Mutz.com>
Subject: [KERNELI-PATCH] Twofish for the cipherapi.
To:     linux-crypto@nl.linux.org
Message-id: <39D22C4E.6EFB79AA@Mutz.com>
Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics
MIME-version: 1.0
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586)
Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_rHZDUOqZ5JW4Vo0adR7tmA)"
X-Accept-Language: en
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

This is a multi-part message in MIME format.

--Boundary_(ID_rHZDUOqZ5JW4Vo0adR7tmA)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi Alex!

As you know, I've ported the Twofish implementation of GnuPG
(http://www.gnupg.org) to the cipherapi of the kerneli patch
(http://www.kerneli.org/). You need to patch include/linux/crypto.h and
util-linux to use a cipher id you like. I don't want to mess around with
the loop_fish2.c driver. If you find this implementation worth of being
able to replace the other twofish, then it can take its number. 192 bits
mode is not working for this twofish.c, but not hard to obtain.

This patch assumes my changes to loop_gen.c, so no need to patch that
file. Please consider applying:

It works for me:

prompt$ ./speed | grep fish
Registered twofish (9)
Registered twofish-cbc (65545)
Registered blowfish (4)
Registered blowfish-cbc (65540)
Testing cipher blowfish, number 4..seems to work
encrypt blowfish        =    97908 usec/MB; 10.214 MB/s; 81.709 Mb/s
decrypt blowfish        =    78719 usec/MB; 12.703 MB/s; 101.627 Mb/s
encrypt blowfish-cbc    =    67178 usec/MB; 14.886 MB/s; 119.087 Mb/s
decrypt blowfish-cbc    =    87712 usec/MB; 11.401 MB/s; 91.208 Mb/s
Testing cipher twofish, number 9..seems to work
encrypt twofish         =   137124 usec/MB;  7.293 MB/s; 58.341 Mb/s
decrypt twofish         =   127834 usec/MB;  7.823 MB/s; 62.581 Mb/s
encrypt twofish-cbc     =   111974 usec/MB;  8.931 MB/s; 71.445 Mb/s
decrypt twofish-cbc     =   114556 usec/MB;  8.729 MB/s; 69.835 Mb/s

prompt$ ./aes-test twofish ecb_tbl_sans_192.txt | grep -v OK
prompt$

aes-test is a small bash script I wrote on top of testcip. It should go
into crypto/testing. ecb_tbl.txt is contained for each of the fifteen
AES candiadates in their respective known-answer test tables, available
from the NIST-AES homepage www.nist.gov/aes.

-- 
Marc Mutz <Marc@Mutz.com>        http://marc.mutz.com/Encryption-HOWTO/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's:   0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)

--Boundary_(ID_rHZDUOqZ5JW4Vo0adR7tmA)
Content-type: application/octet-stream; name=twofish+aes_test.patch.bz2
Content-disposition: attachment; filename=twofish+aes_test.patch.bz2
Content-transfer-encoding: base64

QlpoODFBWSZTWax5fTEAXz3fgHwwff//////3v+/////YFlPK+p8uK5yDlKsACwAHI1bJSlX
bUQIIolDkqqaDczvA2wAAAAAAAAWA9A1i3Fr501rvgfQAN98R9tbWrnYl26Mc7sumYpjGqtr
No2ttlV3YdswLRZqgzFjImRigrcPtXjwpW0hhIslsTfX3t924fKNIxhLTbrHJSLgPQJ9gMqU
MgFaZAr6qJVA0NMQAdABqj6NKqiigRAPXZvXpRyDKjoFNUYJQQAQjIgmI1Mgmym0ZUeptTDS
aBtQ0BoyA0BqYAQFJJpUfqI000MQAAA0BpiaYJgJiANMRBBkSoKNDQAAAADTQAAAAABCkhEy
mQJAek9TaQ9TTR6gZGgZBoBoG1AGgAVFJNIknmJPNTIMU3qJlN6ZEwINNGpp5R5J6jNQeo8i
DQKkhAgQAQ0ACaATKeU2CmjJ6aCTJkaaNGmnqRmnf4/T7fD3eP0+32e72ev2fLjVEEESNK6V
vSul9NMa6sgCfKLEjozrpCKUlKFKdTFxgqqSUIoKklB2VD2+v1W5B7P1z0ZfvaDWJFRUGFSo
qAjgoU/J9/7P0nt+2S/AWOG/a/337nq8B/06R79Kc8HkVIVUoKN1SLKapZoo50db/huPHsTc
olO5qDekpUlKSlJq1dDYZvt2XjrQpoJsqp1/0Lriypzc/3v/P/vyd0/yZm4s2WNzD/ldLKZM
MvlUsxZTou9zQ7lLqUo52nRWs/ue3U9jjN14uM7AjfvgKHzJVDroqP56vX6eW4PIIfKPfOZ0
E6kRHoOw5C6N1UpBpVskSyiTVarOG/P/dvfSp5fl9PDzM3lfm1NzN+0Zz6lHPDzH95yif9UG
MkjHMwH0+j9ww7wHKuuZuQH6HtlCHoKjBA1Oz3te1y5QoF5QDFIEiIp2Czwxtch5Cn0H7ykh
oHxKjbNAwetKfZ6gQ8hQe18N6zgdSnfSzOPNUnc4FpR6ZLEcFIKoHFRjwjhXiv+/fd/rUSKo
aqCnu+c+bkIUFNA+vTyVteDm6fx/Nrvj2E8F2uj4dnK3VEhH32qtiQi6mIkI+3HUoiTllSPG
VUoUkJxhgMJAbQ0irqFaEThXUCj4AxwggIgJG1ijirkWE7TIwpDqum5fdvVt7v5/pzezN4hu
fmyaO6w5sHC1JocvVvmxnybxPL9eyzs5H8j6ZtnEqq75OfNJ+QpR6RgwKUeTAWf3NhOY2TXD
0fAmE+hx+XSZp1ug/iqqqqqqqqqqqqqqqqqqqq0GzzGDlBf1rurIoDvN7pwdyz9vc4uKlKUp
TrXfrsLEucCngXkXNCihRRRjuqgVSUpFUkVQ6Ccxm9Lvfo/J9zzPa0aNGjRo0atXY6lzc3Nz
c3NzcyZMmTJk3NGpJZQ/UqHGUP71R8XMT4jh23Dkds+QopUiddvKeQ1dO3vH6HXmg0H0PK+U
cHa9FPXJf8R+ahJfnU1tVdmrD5xWjCOySdDfHIcY9IzMxpOSyCkFoaBClShShaFGlClGhEpV
pQoCgKBKpBKBBoAKBpKBBoFpChSkKRaUaQCgAoaVSlAKSIQaESkSqUCgSihUoAKAaWkGgRpV
paQCkAoEaApClKQSlKQoAoEpFqhSkKEVpGhRiVpBpRpFiFaRaQpWihGkKEApSkUpEKRaUSgG
gRoESgaEKAWlQoQKEKpaUoQGhEpBKEpVCoWkj8ScTi0H3ntNJt12CpVVU+54XwZPtdJmjmf0
f6OBwZE9su4rqUnzWYF3eUl3EUNVJuOXi8uiTBSdDvnxe+3KrsnJ1rJ8m46C7+GJd1KMJRzs
4u59HYUs2ehsatE9yza6yhSZnuNssibzUs6mib3idb2ukcU1Q+YeiyeodQ7R3CwuKGEnzjOy
dB0JZOZ3j/AajNxaGj+sZDD9D6D4ijyFlHt/pOUjvZjypmaGH839zztXyv5OL6n1vvfzeN6X
tet0ulSlFHSWUGFIZuoYZFKLEs+5/L1+j6/k99Pd+b7udgbh8Q9QuPJLPSp7H13dTD/0+gcw
8TDZ8zZZ85gs9K5g+lh61TztVmSj6VlKWWWUozXe1R+ZrK7eCYU6nsWTq/n9QuM3ApouYH44
ZFMrOCs0eUdfkB7AYU5EiR0BiwwbjEd176ZqydA8SSRlqLa0GW0pYSQtw8hj+AUOgodhU1NS
ZysMcg0yUYkm9yU+SdG/J3Zt0b8Ny9kspSFTRZwUbqdTPI3Rtr/RlY0ZPavDVksopKUooU61
NWmFljZZjc8rI535diff8B4h5lSYVVUpU7iYMFJVJSVGPDRg4KUpmo73JdH0v1FLFllmaZhg
FOZSbbb3ewreOJ1XUbTJVb6skDwtAt6WJdoIXHGBOgd5SMv3PaptItOmrGqfNZ0NOd9W/7zn
+90ycHu8aXLpTS29dxLnM9Bh3fV+MTTJOx+bvtOxg2bU3MOxP32tPorWmjR3nmeZIkgoqFqk
hfhX2vukyR4dE+00POIMIiESRuQpcNNJGEj9LygiYuH9AqP/6Fy7jTiH0uGRTBlXJyUs3smo
j66Gpk0aNXt5e67Lw/bfcqZNiYHff4KfJ9kUS21SpqEDdQ9P4MmIlEO0+cK/Dx2NPNDfnlDy
HKGSJbJyO4/GWO+431B5B+cFg/g9bceV5D0EKTZzVv8nSzcrOXPfoydtN50OpKsQJVMePw9X
nApfOvsImh4ApDtIIfZ0GDY45iqdmYPobdKHs7gO49RAnmoDtZjy7Y3qRAVmrRTi2da7NosY
eJs9bEzdO5r0tr3SyiXbseDlDVkmxZD3CMClCpYyBzTJcYjywTjrkaizG9kq2TT6VnrdTqS7
yrG5/A2cHq1rvXZeW4sv3/Z+Kqqqr1fGesd3m7fczbd+2eTwWs9XNGcu0mHNlvQYoeRVkgin
rkSPjBWNj57OWMCWPEWR08S05i7hhhqVMO9MMmSnF6m5dWsjtC3nD8ws5ja/aOUPMP0hP4EG
LmSaWOTcg8ztGJo1sGiXZrK9bZaLtlLHifKC7uUaqTxL5NyO9q0U064c79/Lc20z0e7x+9pw
NUWPB+rc5Kno6nTt5WhmqlJs5G3nO+napehhR1GFM/39xM0uWGgYv6jeLJ9nt5VLKNwIKOCq
V3VsdWOs5nYCkzb8QxoeiJyYngYupUbQdB8RRxKkJMIrlhRGkSl/WWHQcPE9wpV68rIwr5jg
4+72GzFaolT6OYes8hRRiBg7T10g6xD+I7yJuClBTBUVdk5j1PlnNHofX5kYxXl2+I/dJgcY
FRLnMWApRrgool+hBBGbq8iVaNsfq7C6cc/Rf08zDqMMnQ5MkwedxWMKTmTBk8T1Op3PWapv
dHMhgpCjKWQsUo6m7jhfJTx2XQzKQopDuWNW5U2b2GvabnOzYaJvcHBDZSFKQpSlIU2tNLVZ
C7feUpdC7sWbz72jPm2eRbc4HBTJIYNT3Ch80aVYqimzHrF7iesKFZTWsGPNUR3adtFYzoes
7JzUxV0UnyImimhQgRgYnEiULzQUUUUoUDNTiVDBwLMmoYTWMhxWjfL1JmrVZLNWa6UmjcyY
0m5murcwvNbGC1CBdimSgVJOUGLCmQUajAxWbmBIESxGI5GinyHpaVCZTSA+qaD5cz9pMZEO
4USnI7zxTmaBZS4pNl8DsLI5NtiZAcNcOEFbK5OtdhhwKwswzPM6Sxp6mZvU51lvOo0PdYwe
xY4smNsOemV1yjJvtTE4kBzUYhMxTpBDxAyHeVyWDxvSZGJpMuc2gffe+xslFOtd7XSybmbf
mpjBRvKXXX6KcHa7TtQpKa4N5R4kyJw9azrGoozRcU4vLu7+o3NIwq5sVPV47v6qPXzW9Rn7
f+fGvL+b2re7fpfvr1Ox/b0nKlKqTMelzOzESePxeyY+GlgSZ2WlWKobbd+mWaC2ipPql9t0
DvdrcvCZjs8k3/kmomWtpOMs1in+Y5LHUssWUT0uwo4vi44785If9ZQqSok8UqfaKRwcFKe1
Yf7MHudB+D4mbVVaGBsNg0FKVhT/KlUZFKXWSxMixo/F2HmwmyCkQ+ahPcUn8zoGAjTUdqav
jMMiPr2V/W3KdjXgjwsLPJ/Y/c/N+Ccj52H5dv024fT4PxajrfGpZzsHC8rcYdg9hmc43SVS
pUUqlTntxRSlKU1bFLLrrqUzZHSaHUZH+K5sdJkOL/Fo3lKKO5xXXWaqUZ5evcDpkiOOHARN
Bj1fvCm4HUD9II9/gL0jw/0/OtXLzdDVdyZHzM3wbLqWfuUzUyeRZs2ZNjZozbLqWbKZqZNl
nUfzYUbNy7N/W8zNuaNGjRo0Zrrs2GbJkyZMmTcZvuasljmssyGgoXHqG8chsPM+1Smr0qec
wpRzjM9J3+d0yyfEu9q72NjXWf3pxOoSPcKVVCV71GBKokwYQOMQQwxQBFRBMohqEMNGA+aQ
NECKfpQFVgSUiKSSffJZIjsLSWk9pYtIPPdgyizpuXusWWVImQntqDP0+Z7GCHOfzT2T9/oS
vreDkfP1M01mfh7Gq/fo3FsNbCrKONqX9lHW/z6GXcxyz0CLjKottYvK0utLturScik7qt86
QN6rTla0iuxlBvULuQ7m68nn+Sk7o5k+LOtlxR2Scb95fE08Qcbo2wnN5SQr57HIrMwK09Eb
TretdvFZSdFqrhyVNQ3DtOpn+l+YFh2783R3n21j0pXSrQNPKIzVWdbi5RzLfCGQu75zIut3
JfOaPrbouW9DtaTVxElqqyulQZ5rU978/rj6Bj5+sE+gn+98p7j8j4PsPgdx4lOt2ujryy4+
Psy7me3jHTZq7JdtRsz7pHe8sNquiZlqGl9YwFteylbVW9EKYxqoVz3a13KYrUN+ajjvYzB8
VRFd5Tac1x1dM580gQzPN6Vx594HrlLUah3J64BmDves6fVjTKWnUurR1XIzlqFqIZFIPB5z
gXrZxUK/O3ntoNGcd1rvRyVJpAEzXBDs+tGNAW0bVokKRMWbG0MdbVMfcDN7uRziHIYGqKc6
p5Cmz9HF2WYfh9Ea4zlfHHL6C1JnrsFnmg/JXu+Hi1wLXN+6fjyM0p3J84iaGPY5CZ9sVtmq
2rueON8P1iLou8skKNUUuVb2DbKWI7qUs5wAuAO2Z2NhhsLWXksNqbctWF7QytTC4EisBckY
hh3qBWAsraE5qrfTmG1Nqos9WeZ7rGVAvPJqecDGGvixjAjWAHPdybYBjSLFhpqwXdmu2kFn
NLlEiODMaqarcgBJ10/aMngbAFoozrOWgbnfs4BPyy0J0FTK6lp8CpZlaLQrXiunA03Rduq8
flBwB3Odw2FLA8Sb0aeAGQabUd7ODzDlveBKY37XjnnhO62iNgFOSMsBHsJTZNYCtd8GU3lY
LvGvabCTQ7IIdcAc1wHLdQU1xs7VEXq830KhJZaOIO+91sOM1gdIngcVhTyzmWeuR6ot4hlp
BcENb1pdcixzeaZS0wle4G7vQjQAk7ody+sgy7GzdYVARdfpjh4CXfXLitL6Kxx97i+Q9EKy
uXhHYdg3rZpadGbyOgyMslY1u8m+mwA1ZKXe8jBDXI2pyE7l1VdInXyWcFDpzAl8zI0fSZ+E
uBEWiu2eCLqjviUIKAR5HE/9HsZ4I2hwA5plR8Zl575I+Dudk5W8h/j/DeDsZuc0+sBVwEGu
rCmSjG3ntZnUAg29dmt4GxS6b4dG+xCb7xtrembMwoHUM8Id7vTtob5NsBqlTmhsWvo9IV0s
AbnjuLN16H7OTAJkvw5Wqr2jLzp1I9b54UBS7QfwE8IJQioTFFGayDwDQant73Xjfg03EL2j
BwANFgKM7HRA2IIPRxncgd6nJHawBA3xlyQZ57WdlJ7gbM98uJ3ujZJu7D80HSNwWo3uhwgY
xquiRJJWrsQBWUMEuSvgcM/C8gA9a+GR4UPQEv182pjj2hgMGwD4oAbtBxI6OhyLkrAB6jJf
Jm5HB6Jzn5jTsitV4EfPi4znO67I1BIYmYDlqs+zvoymiGoGpatIyRG41r5DdsOR2Bvzc2DA
Htjqcf0GDSs222d3kekW91JTyt6GSmNpzTaAOucxudNchNSxN3OeuW+JG1tZ0NII7V50oTAa
d7Pd5obIuvSCXMoeJ2sOLFh17FdPohAJ6KNeDkntF1vfZbp7JRwtxscl9ju6kuUdHxxtm1Hc
WQdGLoGgXebKinJd33WYwLGe5M02Oq3QoOBmW1mT3FZkJFgCe9i5Yc52xKuwnaStY1tqVja8
TdqssOza0Xc76Q1PFhMDncYMlctG/FHjaMC9vxE5Ge8IEt7oxYad0NNNrCTz2nOhac3XnfId
p+C+31jzlDyYIxB+7Be4AI3gNrPV0AJ8a6EAxQkB53XCRaEpNuBoppR5sjjDMohGIumADDm+
2eAc5nN3yRzZceJwJ7Hd/OdtZFqS+HDINtn8gzR4EFozrPjnyWhwfsCeV4zYc0ypzW3oonAg
cvur0ADgZ4EFhwsXKbwG7BxpKVAQRJ5MNZJIYDgloenHb53p4BYemu31teKVnd4GdCowOjm7
To5t911lYH29s9dG5Yt6dhFA+Ad5yDAF0ygxAgGTtT3xGNuIdljaOroIF9mu1dlgG+oLOp4m
WA6k7LmQOOHSiXLzgUOL2L7GrlUSlzA3oNTlpt6wLDMbCmGE0LKnZq0wQm3M8ApQwCQC8vkw
JHJNstlkzz1DFYHouSm767TrF8Lad2hsVIlX9odDoHaCgoKCj5mzvYLrLFJdo+owaPEZrlKK
P3rFFFKKMJYsZHzmZkyKTwLly7gU4LlH2PM/L3+vHrp/q9j6U6jynF8gps6Slzfjsn2uwwyf
tcHwfW3u8nvPeWRP04c7bg71lzpPGjcUoonMdZ0E4mRYNTe2Oo5lMYh/JqfaeQZut9h9ZyYc
7sOhzGrvfemrzo6fqMizvR18WS0Up3OIVtBXSCukqhW8FbwV8YVzhTmCjiFPDsrnC7zhzOZ1
7ns62rN9xY611HM7WzDJPWZow4ngnzV46ta50T7D4H6SfbUlSXjzVN6JMlu1h8HM+NmcBZLF
KUspR8cTX2pm6C+STsxf46elXSk+ZJ3Rlgbu3vZNsKNmSzzvX3re87dGzodKy9HLsbXYU+rD
2X4yjRR3vXtz+wycVyyNg5kwsH6DmbHccipzKGpM2sTCYaGnQf6yJuZcfju7ncfkeT8aSXpJ
4JNzy99Uqqpqu+ee1g3EzU4FmlwMM3VOTDnP2z7AhrRJ9T0CqwPnMFKVJSlRaVMSvybRP2HF
+fI2tVqqqqqrbbbbpMjfwTWvPROy67+x4zw+e0qWfheT+Z1PPSqXP+kSzPFjQBxwUkAyJ/L+
X5fmv71aHz/fQv+KXZNZQJr8PhlY6VT9RRvMaABfqdkCVN/Dup3sp7ksCFtAUcsdKt7E8dqZ
sCxtdiOIDZMAXMDJBmNB4B36HjNQB2SDWfismzeB2+6LwX3S0tjYA1SI75mIApjGiFJ5u0qF
mlTMnzGIMqqcgNgRPtDcMiI/xpPKk6EnqPHBY3IsczBxai+DuqHYzCiryFTq8BXVpB2EN5Re
IF5oV3dxXZnOif1D4Prd6BJ2zkAKxuYFYEtdfcHLLQtVpQXvrjvheGIM8vsEiehQvoGTbBxi
7j0gXZlEKoUJpArv5mEkAK7CJZnAjgL5sPHh9BO8LSfb3riY6LMXGAuQww5OcBjHx/BVuNqC
QMtn5JBIa6oHkTNKvRwsfLjJsQPg5CBGgxIk/DE6xq0uYXTcEhI0wxZUg0BSUCAVNYyXJImY
7MdHXydmSL0DxNWs7+2dYUaI7Ib4GJbCzIoI8xIplc/hAbIY0g+IpZKB1yYTuInroMePjyHI
YYe9k9WOhq3GUaCA4MZOTohTKId3K3PuWvz8GeeVa+KST84Luoh2VSiKqFRRSNCUoUUhQKUi
0ixC0C0FKNA0jSgVQjQUCRUrQ1QjQBVUJTSsEAlRIDMIUBSpSiFKpSpELQ1StIUFIDS0qU0D
QFNUBVKrQtJSJNUlsi0KoqoFpVIqwtFJSNJRSLEhUS0AtBSUAVQAUKjSLSRKtDTEhVIlTCFU
jEtNARAoUKFKJQ0g0jEpVINUlAFCBQDS0C0q000DSEQlPplHJUIgKKWCVKQpFpSqEaSmkcil
yFaaQIkKpChBoCkiVpoQpQKUGKlaAmEaopAKoKDJVyQKVWgKCCAKWlmRooQKGlWhGKkRpKpK
BKFKoEaBpKGgpEdE8zx/3LlhzDsHvyb5P5WaHSUZOh2KU8xgdQJBaN14depxHs5cp861WVee
XmSOyr2rJ2sRO64JOd/LNq1gDYYdC3SlPKWDcH7mhuz+qBJywkdWsA/Csc5rOALShENzWR00
zowcXErrnGx3euo8KQtyzuBzFVOlaxkRhdbwEut6al5EfQH2A5gwQcPJWuycIdnfnqyWC/V0
crHpxHosXeNIyWrc+JLc4Ii4OhUOq5WBNojNFWyaRxHrqsB54kti8WBQ6zccc0YVtFsVP9CY
ia0mMWeRbTCwHFIZB8IhjC9tsh/UPcO+OsT9+lDP0G5HQip3NkqG5j7H1XP0X9gTqxjD/ND/
kMYfI1G1ND0EkrzssbieSiGqkw3YGN1VhzlC7SfWO4UohtLLFoA0tgeMAgQD+p059Oh/hwbZ
9CB3LHnMroe7mQBIB8KGkddNtV8Pwd20OfBzcPPR6ihApxdQu8BinJYzuXeikr1BYMI1bnKk
S4aHmFwckXOu54xSdtzc2bJfwdD4cSIHpqrTk/RZWTJuDVFZsZDxSQUhSWh7Kwil8EHAlLG6
D2QfKjZQ6WB8KOipsr84t8AFrDOULGHmm61UkEfG85E1gx80OO/CGGsMCpZjc9WDd+DYSqPv
kk50nnklNX60nPxeJzCieYpJoeY2KKMnSOcZXKzGrVZiUpPPYXUZYO5QsDgqfhXuLdNuKx07
qKvdPvfecu63dY7u/As6yhfui7wDdc4pbfIzvfOkKPXLrgQUd2ZX3MgtXnA0D6iCqjOtZfve
J9AFPFFuD7A73QG5F5rXinseyjK177wDs5O4dDHZFAve9gdzap56nwgK0pGcYzLa8uYcCh6Q
3DUyImgiSPTx4Jvu1ReFYFUEj0tBotDd+HrGq03OHdTdmTjI1H6Oytg5uoccNSECXq7FDmXw
GUAwQ+g4ZXI4XQWIEu6vo2AFR9R5IjRkan2UV49+48Gdgxnjnu6OKycih4qJopeSFlrAGiUb
mo1oQckbRNR52KpHRdxus5aWmS/HhTF8/V6fL+BI4MkLxYXBRRTrrXC5FxpsaL1osTJOioXU
ksBKMMROTixXmZIE6TyZsnHF6pfoySMtHfuxCcWpnshzXsOMCvQtQyXNbyQ3tIRx5CIpR+Fd
2ksMjix5VzOCDwCETc7ePkw/p9BTNlngEmcYQZkxqdNvsudC7qwVsNQ/O0Bcs8BD197H0lzs
c9YN7cDmmmoE4WuVkIFWKt1M2K8v4BigBaVAgXNlDJpUcjQn8MoY0BIpoFrAwzGQ4cIKF6DB
80h0ceMMQEGxE6goDJU3KO10RT+WPoDccHdJMPHJ7T+1cZOPaOw5xli5bmYUpZsFPE2nx2dO
uWaPWT3xpCXZ17hY5j0tCjuadbw3mxPMj10Ov7AZ4h+CC4UbLY84hubt1lLMbhL5m0DT3dOj
b5l3TfIvsDXV5GXjZYVZwOF3qzzE0aT2VLSjFBtNJSS8NeY8a50SUR7uQrBB9EJbgcw8fsDB
iKIjS0I+PVJrXQVK5+XdHAA07/SgKNBYbmJyizM02uuDNIUOD4B+UFP2oJoWDhUOi81rERMm
2Se822WnZCjUHs41PQOThBUN17SDRGaNicqxsDYcGZWALIaJ8m6oiEjGtun0OCZlQo/F3LA4
WBuBAUlOi0kCdB8N+IeXOFMKWMlBciaTZbUsjp8o1qYA+oxRiBpjYodVgfXb7O6slnuVm9CB
18VzvdwnwpILRzj4HkEIwPOrBOZIXI2uB8G3ahtDpkX1NoHwjVDp0VcU8A6hA8PJDUAwOmPA
sqfAhuqOJ6qmRwHHEGZViBHwUt1Sb6WRmbHoVbkfSADuYHBgDR1yTILRXSebpa21uLc4+w84
U3UDpDbk+k2UrgXnuSRGVIq3JZSg3OSQhIxQrMeNVlzDoiIp6hEmaFIgGgAyaQcDDGgbBYHB
QhCU98bq+OLS5QXed6PLRZwCguQicITlkWFn40yY4hm21RXPotD9mObZMr5gAWhsYZztBGI3
vVbNjh+7hjocoPs8ycMmthBgJgM1dvnhQ4jOa7C+BKyU1T6qHBpelIj2Bl6O+AODGhg9ZyAx
FYnkfTEkAs6aAOghY2HgdWM9cv0gIh5SsTQWVN3CMTbdrB4bBFja0nV8WlP9KVX8fsd7kEhC
suIGPbB6pavLXAwhU3GDmtivTwbkCGeFQTaD6ChNg92w2WM35BjX03VidEzMcIRQREopRw4g
XIwdlhKUkVd0N8Dt5DePoABj6DGTfNzZzEdDYpjeduVMNd4C30N94EtLOgZ3FRtVGqqRpoUS
xSGHGBgIXFP4x/eBGEcaH2UUpZCiolvV03VEdZO3OIrbDJMe0WpVkKqWg0lTholDj2asr4eE
Kd4I4IrCAzU1OWMOxN21Um099oD5pDXSBkAoiiqqOLLBqI4x3YUO7TpWRtbnogIIEoeSbR4G
OA3CsKdR40OeuUPywaOB8RTUQ3GTQBRwHXHQOA8NeWZbrar76cVnp0q+/2IQN6oFE4BTa7MR
CCFECdUjb+/PuDmjJsJEmDyWZclgz7nm7t3fA5jfLp05yu1WYFMM8Sl+B0rOl1ra0eO4WVVG
yXbAFt6TBwCfyP3OBOBPUg825GvIyafR/ZERkRBER9fREex2Y8a5SZRIwdq9iYHIFl5qyplG
blVuyMYrCM+ZuRDclS0KyCfiQHiR2l6PoVo4BoW5QZjk6nwbdUmU+vyL6dhWLoafDdIY4WJ6
b9T5lnGjT7Ki5yJC5ofcAxmNlE5s20yjkOarfnmRk32Kw0QENQFEfd0KIF6ER4Hboc3wJp3A
WMD0kXU1ECDdoKZgKtMqGZqOhVeAwhVuy0NAAW+PsX0WPsU7CoT6SHM4Uvgext4GiwhfTnZZ
f4CHVQQiPpRwZ4dxwNgAVycGxgnYcpqSmWxbkGYGMqOEB4gAsIPi/HU+uxwIZYJPAwcnkgLQ
TlWGUw7O6oMke7TPRhdqTNkpwU5fKGhjgWhxSADKoIIbaxpEISIFrRmNufeGMRoV2JDO0zbl
X6GXNVaczTi4rCOCd6q2XHAUmCdobgwagdps0qNo8na+deIayaUzbg2pLglm3C4FXtqmextu
thtqCwDc0mABOYPo2VgOuBUCHvNBJ6UB2Qd7sAcHXCjjEFwMkMuMjDhe8V6YgBfHgcEfAE5n
cv5T0aCl53WBE4F8DzrYDVptqWSveBvflyGPxH3y9BDQxh+/gMGW4NsjdXmlQl3Joe20KgtR
10pNzjdI+yti96rHe2SVMqUMHXE70m7M1yYPWzUNh3OcsPNQgZ2iriDdGTw8rK7A0IacwpDQ
M+WJhmPYVOcY/gYNCfIX3jGPcRODkcUzM/DwpZFjZDKhCwMVcc7tVxSuPA3cWXgXDo+nkxCw
FUiU1wUQbYHwAPRjskjm0jDpLiyamUQa4Gg/hHZZDOQkNzTkSpeR2vO4IBGJm8DBFxsdT1Sy
JxKwaqTwFfQlgYMdkSdWb8Y1WKQS0ye7z6OFGMobNGBPQPNqdMsNHFNZHVgcjuw2bWQFDeGr
3Bc3lqUeRclxxdDraBIXYtqwmsjQ4nXzBMzOeGJyG9LsEGax27WicifAoZBjCGTbQCJqArAc
k4FFKAY020bBnaehGa5hL6P6xf1HaRoybYDHWsqr/F4JT5NcFkN9WrKw/O7t9DYAK05bT1zG
e3mRIjnWwF3nPElM9UUYykNqJzjmdwJ4S9HexKoEOTzVRsV3hfBfODpNOI5IRjhDO2RCLu8M
+flgKcbqSUOYu46MoaDKD75iGBh7Y0YHXfL+dm4e1wMzuZxL894kZMBjQkO/y7TF7qUxkLma
b+eVHRMqM+5S4yMG/S3R0aEoK9GNdPAvEjLQovJQbbQ+B0yxn9AxHZ0YGyOCjohZyhcGd2MV
WMuyMRJ2erAkMveOe18XGcrMyQbNMCSHfUDdZJIiQzMUkOTwRHZBsMjAtXg1ctIt3d3Pi0YQ
Md8gvE+Hc9GZVbbrepAbXhBK6J7tdBDY4uSU0bSboDgGMlGF0tyCCSkJTNM+TxzajGcqMeAx
Z+aFw2LlJXGHNJAeEdnkiiENO56pxZbxYeTdKRSCSjRFxlcTyDc1TwCjjipJyYDCkloo6z0S
MV1jFdYK0Gp3Go5qWByoHgA0Z4AWIEUQ7TqIKhzBTSVOd76UfbE40005Qrx9vDmtRP4OBq5F
H3Wy7ovc2Iz7z4Ds9R6JFWeAKwMuIwJPWvYEXE7Bczp9spmWBQjcXOFwO1iN6C6yWBAznI32
yyaHFwESYorkaKhJ2XZoLKDK1tcya5pBB7mNNUMo2tK3E2FAlwmirNkSknsdWRdI2UJnlg2c
DwjvyX7K3ZprgmQhU6AB82oHoK4HreSXYOvDZq7o0q7F72A9I6JZVz0fRWSCZl82IzxQ2YzK
EEp3Hnvtm80Id6CEaignXbAMgubDJDGTzqjV2HoMW2iGF1xLsOjl0zRhoSHa0QP8AAy4Akhp
zgUdRyMtpWrp4vkPRwYZDOl6hQtYTNl1OpF14yDHZgpY7aI5m6WJ6xJ2EALaVGAPTAGNRbM3
bPE6Gm70Ss5Hg05REBpcjhVI091WjLc9JmNsBiiE9OwgZNBxbCWuzcEvXbMhg+BBC8wcBvjn
5iLzMaoy1R0pjFE9KkhjKxs4UlFVcmXhBNVwuFKYheEyLEpwySpocHU3ImnKYOB3RBwOOW2s
68m32wReTxHpOD8RswcS35pXSpY5r7eFHtvd9agBd79yZyHvJse64O51O7UTGAuvdvmnHTdR
GtHx40RQKLa7rmO870pYlHG6j8HTi2zWdq/BvlDo5HKXgkhnhveWfovN54K+m5APaDaV3MTw
O0yQyA2MkDk6z2t227bBwwixe82MbBiuFA6NgpLNDjvyap+WNVocUEnFHg9HBaFnmRLsE+rG
axyFA7ssGGQbogYNMsGX3VOhxt5BQq7LxDxDaKmUXY2hRioJ0MLoEAHKiBnSA29s3T3eZU3C
a1g8CRsgLlcsA5TsavyV3M0nnq3gGOrjRHBiMzLot4KLdCzkPmRgChAHNIXMHLuBYEbshdXM
xdarbwRA6vw7hpkxXV8nZ47vhO/IKmHdAb+x2OuureM3eFtqzbASiFj3I6DHtlnZOarwiqFh
/B3GATunNqEIKaLsj4WkWHdz79AAHBj4Yz0VmXyJVfNBc18BWLUjPwgP1D47CZwllaSIPCeN
Bj8h+ZT7gse9PzG4TDs7OzquXN169ElVNn7EI/ucFjoKf2vnNGGEiWUn2FH6faqz7FjC58ip
+9TQWaLgd6h97v4ZDClKUp5VhRYnapcKcsGXkXdRzuwuzWaLLjU/2HlKSVJFUH4KSfEojDtj
xMiN3NGjIimGEwpSsGAYRz/Jf1+tj7v8GIvCHk/6w9IcrHxCnJKUva8vBP0JR+CDzueg8SJK
6z/QxRR+A9U0vCe8CIoC4+B8BRT5UD6Ps+v6/stL4V+j4q95YfD/H3X0wTpnD61x8z7IIQ2m
kQ+ccE02zfe8CTcnwC6rqEHN5lBux15rqlgVbTqlwHIc1mB1G7u851pXdd6GY0VcDRBMVyNE
C0AOZLGR0+DN7bvSSIWbYh7fg/AAyQSe/zBEWeOCfL7oHDcpfJTIPAAMDkXXVh3wR7axF6ak
WCmeNynOEB8+KEoW7KwWLVSJuZ+Yrsj0gDqVQyeb5Hlihw5SWx4AIceeqIHIPgte1VuysaSW
RiphSrHoxvXPmg7QUHBbCyxlRXkxZeIXBsXwMHyH4K+SalPxQz2Y3foHjyci4V/D0HDY47oa
ExG8zcJcDQrNyNhMp9JkGiASI84YlSnwObbmyUKxmlVPBhKiyogJgz4mP8xIsgzEctMCSODU
bR5UnsPWLE0ng+D76MWjqUAQSeRrIz1W83IxCP/gCGjobrrNpjxut5tvekBYOzjDvwAqJhzx
9QaiGhUB6RyYIfJLf2Hy9TLFj8CxzdWAzbPqq2ChiU34eDNiHAMiAIn+pqfwA/UMgZI2AP2C
dDU5mpzIECBAgc2hurrxKspWpKVY3fiF78Osxr8d3vVhTeYgr3u3hhaXuPwfmSTb842oD5Gd
uc/im571hzAdHGiPN9R5NQYPdZyGRAs1gdx3Vc3cx1IKY4edwkxvjbgicAdzK9ysyI4RoeAp
j8QHLJMQ9ruRZvhzKIPqBa4GA1s2KyQOGQsY7GRu9qZZak5nDGDcgfbEQ10e68wfgiPnOPc8
ZbTQGe/XciF4PC/QvlvKxpTo+OVzmRE2V6OxbFd3Euby5L5y45MbOLmRUW5CtilSSzhydmME
a5Sut0xiD0LWoJC4+CziiKwgyhZGc7Ytu5n2TycOqZCrhyCkNgzlCtvDOoOzpyZEUImA5AnP
icHeWNhBIibQ6l04OAwMkIyRgg9JMaLnisGdLLngIA4XR72T5xnyy6Fmc8CwkcaUQu8MAq8j
Ao6TBqVKEh3IEnkGphZkkVJIleXV5FHN0JIuRwZGuXYb8CpIEvRUZqQF+ygwGGgo43QjzBn2
0NY0TNef85/2mqNuIHyHU/4UNDADCm/HLduNeRXo82qsnh1l0q3JbRdGAWAvWhVkOucGaSzi
hejWR2xKzw5lmJHYc2MuAPu7NVpomdk71dAla1uCBxpS7u6yN7zo8ipvbXCB71vkrx273asJ
UhjnXk971fE0M5iaStacuqGKMMw2Fa5A0WMW0UG5ARxGRwYDHZA0KcTMdpJCxhbswPKGqn06
ErzMeFHDG8JDmDIBAzpwKOCRIpfkKSIZzeJ5L40QHOgg2vkenlGoRNAsyeN0YkqIZC7RAT8h
hS2WwcO5nnY+ABckMXZgCvN3lgnzBuGMi94qZA0eCL79apcg1YEbWHKxymI8I5I6pcDdWk2H
vf2bVYlUhrauckDseDwP3Am7MycCV29awHUILG0CosCUi68oMytnYif2gIbgKAkKwAfsIVxU
whYg4Twx6nHTvW205g1Lk+dUkKVrXtLNCwx0XiLBgZWaxz3ZZTlq1twy0v5WpSlKUpSlKUUU
tti2VHUXh0fg67H3GT8fbR9QamZ2O363GC2RmS/ikhgsYONObvyUgoZ3a85pktGtyVLxdmsb
h+HxYTqKVU3hHcIZmi2eilYzOB0SlYyn3Z1tX29vAh0v9JBJub2xH8SuD+It6HazHoAUKdTv
FFO4PQBADvjDw5eidlrCnjZiPlVgPzoj73/VZbQWaAvLzR1CuAEHXYZsr6wjI4WuJBwO9SX3
bsvY3mxpgwsYJMA0WH3OR0r7tFHGADKjuWs8wAiq0UkHc75oQMjr96hRx+NgZDwDQ9wNaJJO
xsauR+dkn0YwPFjGypA2uSlnMm0MmANmIHk+MRkPgTJdWHdbsqlLPYz1Q2QTFx4GX0Dti7uL
U0/EwOu+3Ec9JVsXFqoZKQwjb0ZpxgmKeeKAsMfgw8HhHypEaHxh/87PZBpARngcP1W5IuJD
rDSwq7vS8XFo6MQwT4y7cXV/K9ptGLgx7lXwklVVLnoY5BsLCrnm5QgbG8c0K4auJhGlJuRZ
BAE8pLHcjYuM8mRaamb4ihBTkyZzFWjNIisq7LTng4ALzNrGAKwl8nMq4bv6Orgh5xZoqMpD
5ZDifbS+VwmNWGci16N5wH8PpEaMZkkawKpki4llay0jyVY1WMGSSnMw0ikZaDxytYz+PyAG
4HaQMU8gh2nVuMbzFVAyu5EI77c5zfqSIECvagfKBzE5ngHs/awAaAaAd4DAOhUztvz5+ijZ
nKX5hs6/gYNYj6/N+6XlejKrD0taEZlZj2VTjawKGir8oaxMkhsL4mhqc5rg2bVt+4RBroXv
c63l3F8G15mksKsVPd4y+oWNVqt6p5GFrFM/Wkau9bm3HKy+2xX1xAwRc4yoAZ1IzaJVmAp2
KUwugQPCBw12SSOsLwubHrgHFhJ2F0YGZ8anm9GpRVxobFrV425HO2Bg+EZFmy0JxYTK4vdS
IbUb5Q6mz8DVcE0i+cBtSPqAFZrgjsgIUpdEr5BBvhfGIt+PGBqbRxPFDXHnn4CyoaVN/gLS
gWXCDhD6NG59TIXMOCDvaA50YwpAGzKHaN6q97jrgGrXBp+QSRCFw1gdamyw2NovRou2x9Jx
/8nPae+7CLSD5cZ1hjmRk83dic+zpqB4fVl0fZBsupl3mbmBf2nA4+gdWtJHdnsQA3X0Bvmc
iZsAPiED0wBYxPKnzWppeOQVHJH5fc4eBZgeLHOhASbY8knPETd+wSiyKomMS+7MrG7PDPOJ
oQJzvpJdgpfwAOYHAe7tDx+/8v0TI+cfNcjjOFN0+RwrQntNTEk8/a9b/oh6jgUU7vB2117P
R3K871nQ77eXp8rYkrxWkfUw6rQ0iKzugtaBwckVaewBQyCEou30Rx+fvu47jILPD0GHLTk8
NNITaQ+SwNm0WXbGX1su4CDvduuUnfT3AAZJHDRL4KAD5LpdyrcG+yUjWvz1BAiAY06jA4Di
3I5YLktJc3cBGxgE24HA25mxl63WAb0j4Yi9lD1bYQsa5PNXoSvAbNfSADAnMIMZKSOzDu92
PcEsLoY2TF8LHSMj2Z5Fx0cFZYp5FoZBjMT48P87sEsFovBbomYy8DogeHKkWDEvpM96HffF
+wUDdnBiOyKPJYsP3fBQiq6hi0Q+GMMQEF5xsLLEIAOItFOgwZ3POUEF0gP7fviy0nu3BtkM
NpIM8DpYUhDI46p3DojAM3OrHGcZsvnncwCYHbXPg+MijTm0kTNwB18Y9MAosMsYeB1PnJpM
WcRJgdXQ2R36vL2h+NXehIvRMA0slm3fhPN8UDw4kUgtmgGZAtFhCHJPg111Q3Tg+vVoaExg
Tug9a52vppNpSGhOxJl5mouklHxQUWeT2qVvWSmZJaI97KHuowqWro9vybcYPbTyWLrnEbBs
dyJhJMPM5GUcKP8ujKXRqDcSKOqyxQk+fn9otbd0ZF7337JkFHZ0yQk/4N4OVFPpOY7NZ+ij
hUNmhY+o5WSfqKnzSjvip+ufxk6XSJudJP/1jvgoYLHgNjDNSlKUpVVVVVVVVnSnKzGY4+dO
+NL1ImXig0P6J6FiXOgMj9VSZCMszg5ImTub/P5+/x+bQzOwqq06rGwodJ0ksmgq1JNteYvX
zmwHdML3wWopetRfDF4lpEdxzpJyKdzM7TQTs4x6uZ56W+pkXYopxlzodTuMuTnI0PWcSk9C
WkfZRDnKPsqRm4u05E6yKMFEULhEwZzYqdtWo4qbpCnBTonDpesnM7qqwVhVesnlKh9D7Uk/
gPRsbGzM5JuSvwHwEREEdmn4eh/Q6HQIgg0cGauhG5hjgal1HBsaM1NVlllKUspZSyllliyl
lMx/Gcokk4jD9H8GOJ/KPufg4Jci667+ZvY/Kv2zgmFB1H/Y/ifxPyf7P9XU53J0PEu7n5nM
/cTE501Kfo6X71n755na728UdTyOt4Ox/Jho8rZs8qzsWXWdkvjGIosXLrqUpS66lKUdS67J
5XU6n8GzR1sKZMm9J/uokjsk3yUsH/P10XcMtExfS1vM7TnvWqlKrCqYVhhWGGGFYVWGzOac
x3X2Bguh5GbnFw0pCZFBd+r99WvEiV+yUarn3DBc5h4MiYSuU1o+gzO+mhifM92kmXfiXNHg
JojSDDIyb0+l/U/8JcSyv7BKIUUUlgs+n5UmrR/mMzpb8KfXJRGzbwVuNsnedRaqivieDZ7E
rZnAxJi+T2TF8XR2xvfo4JJ/k6mKpkqSjmc68sfs3NKjyuxZVu5dzfeXkelSi48rsexkNejc
s5at+OBfPsdeaoouj+Bxb9FO5W5vy366EJX7HWyUup2LnbvyP8GjP+yoZNl2yeyLtxdHiGbt
NtwO/DzgXO3uXuHZ6GHiJ0cyYk8sck6+XpwbmYeyEupO0shjwJ4zsOUJrshLesZZGq5SrMZ0
svFWxBzuzDY3cqPjWvo6aK2UYrCz2pY9qKKRSUUguGSSjaVC703T/qpLk51NyFZd5ZSCp4JH
QS30SNKiMLxVLMonWvll/BdJP8KSOEmnFynOybSeI0WhZboQwI0DLkzNZgwd0MGq7SJKRyje
P/hr3c7fa0o0XWtI0eWQwv02UZ4Z7oazxzaXHbZumTnyk+UVDp3NFDgiyi2j9Gb5k4xDEOUH
iS6S6JKGJfuBJ1hdgSGZKbN8hq1KUopSUoeJJMqMOhMjGGaXGEyTEorJ700h8RSlKUoodyM2
E+1MJvMbZ27KUunBSypdSrKdTxMRdqUWNLSLKZLJLRRUKIjzzqDUcjuMUTRJFKxAbBgZM8GB
yNhO0HAgh6DBBBDBtBmop13WbNEmRfa6TQzvDmkmoy6GqZuCmb1SWpuf8QTOPLkbP4Y/lZ5j
nnNwMzVBVJP+8nO8N+Tn+ppaVHZIwdCifxrimSUZLLLLHsiTZob4qU5aX0WPepXdKi9XpLVy
WXxLVu6ORo9jWLMtdVzORqtMhVPpUTconrpiZWWRLrLSXxri1l2jJinNpboc0w2+IzR7Htb9
dw3Je3YzuLIdREG8dhCyomVlmqlmWlw+ZiWY4tqZuXMrMJqgSSYMOus9ZsWYnJEmqAuf1ugQ
ywmilQUTk3ON26VN6hbeUocXJddRSkqR0dHBS4OOKSpXSAxEFslallB0NFJApZbKWjnKu01d
gzyUGqi1lN5k3OZhWRiSlA1skiRMspIV/qobFDxweDkjkFBMn4xRGLkROQGSGJB0U1Njg1Go
EAcYpyKxiWkDExqioIUN2QyRL5PEmGyL7RaCqkS7OTgTpx4+RiImofdbKZv5Cva5x5fNOLJr
d63opifi7k7XY3qc6dyXrt739aYUzZGjDs2SMTvNT5zQQod4NsvJkZRJolESxMRCenMuzHda
+LHXMZN6TO+UlOpr1IqaRejVZIv75s/ouc0GFkKWIGc6kZgYi4vrqzsAwwEakNWey7NQpLJl
aGrExP8VR5Gac19Hnew1ZUcFG7jcu0q8sr2OyY5qLbKNX3MlM2Kduj1FMYrO65Z1LtXqYM9W
S19j0RhqlzDI3t/TdOmUw4OY7Y7lJdTniOLjXnphQpnXWWdEiy5Px93NnVVWHBwSKXPOiiN0
Se9JTT0maoilCqb1CR1p3Sh5VnY0eu2rAwsD9usSnQQKYdQZEUtIYnNZpMTcmRYqQlKUPRqg
fuSmmaZSD3KT4PlW65KnF025amUvEi0ZKeVUk3qIYSihgLQ3lFjPzrvKp/U0kswPDWboihdU
nTBnM1XMLs4yx+jbqQKATMnvNV7j0mpA8yDipCCMKI5ljFMLLFjCXqS9ixgwbFKFEmShV2S4
WUqRQll8PxWS0XSeJVIMTzGKRABEKwQNAwQiUkQMTBCBQlKbm6YvYk0SBwhBm8UcEm2FmiGG
HBTzmeI5Oypmw790lm5UkcBwZt5qMnhg1ccubB4LWeBKLlPpXJddNAp69SxJkZwmSo6pM5sr
wXcKn7LRdzrRhVFPXhOZXWvI9WJ73cxSTzEnRLYZT2vI5555yibomzzPWL/Kw9lMl4WerKF+
B8OhvdDg7lSeI36uZjsKaMG1O26mWupQ+D0L1SRVM6qkjw+s6MOfCZPJJ8251STCclEKhHFQ
2Uvf7UsZvfTDxpPDyuplhakv8uGLlnRZkuoxNRRd2cU+U+xxnllc54s7yinnMlk8yUwoyFI6
ZFcJBwqQnS8A+JSLyNXMs+TkLm9uSyUlKlKqqqD02eW/a9bSRDLYjWOGDc0cadfzsMlFdUuA
pWpS1FXke9ueznSOUTjMWu5tFSbMmnVenKk5pmzgwTTgWUnrQUiwU/2PiLqT48ZfLYyeN625
haW87DfyFjZA0Uo1C5Z/uf3CxxMnwU5HnnKVHtaDfUnWVIu8yxDcyWfcss4JosUUUUoUcm6h
z3iy66dKl4vHc8JyjnVFp5CrOtUtLLl5dS24yHSoYyYHCaJUMmRm3PDLRPSTTSQ3XScFmzXW
W8azyL2SqppFqlKbzfq4q2P127kyk1J8WpZKfi2XbSZmvlsyf6yMnQ/OpVSdKpD1u5zOEbid
WW9xU1UsjpknPEYN8Vxzvkut24nGqYu7V2WWG7GdhqDZU+THBPaHp8O+xFnUzRLHI1d6NDJp
n4XtSmEubBZyws1YVPMspdDRsOByuDBxU6CE+8QDt5OThNQa0sZ3eVrFKqnRpo0R7MsGjLu6
2I4GU74+Zaau1oTaF0azVSRyeNkayKXsszyrrsvVcjyZL6DDrYZpkc6rRmpZVFDa0i5sJDDG
WBMUEKpsRIQUCZCj4CQYq4OUyxWdlv86kj33fr/oPXekbPGJsUfRysLlGbgq7nCnAuyODZfF
KVIqlChm0ul5VOTWL4pmstEWexKUUOsmIoQxtDhI5KmDIET8Oxh6MDcQpJsswzUXWK7MQixV
CqoYbLPYpS1u2ZTJwZtpM9DNLEKVJIzLLTCpEMRKG+2dgm6ffI17YczlfTj6Scx4niLI3bGC
pFly2+60hhSxeS5VGZgZDhmFGg0sYGxgJpNCELslKVHz6wXYkZRXxrr/b467nS7r+e9LqWwt
bfb1NjckcsJPqzo3wK+9AUG6cONFutFUuVFrhkthhJO9P9fN+rVlImkh+x7ZHs+gVCuDsiSc
SD8GNf3v1wedrJ2h2M2hn9SJcMmIzc87VL/OVI/WlRPBH5p4XBGZKI58jTygXg6m/AFBjzTb
q6mUmkTBJkqE1+ln0t60Nl2yWcnBPpxuf2vCeJixSklXWWvOtdF6F1JToR3SY+CxPFOnEl40
kjcbX1izRySXPE6MNG7MooPeMnq6EPfJE6PHxwwg0KaI7UOyX7ntd+u4t8C0GfFzVMonV+HQ
N2+onBdu+Izq1LSvcyCzNTC7uaNGJhksTOMG8pSlzoWQxmPkUsZZbk8E0hpM3CRMo1fRwjEl
1WUpXgTVGSmTfM0eOL2nKNmZJulOD4PyGJDGzTNik5DVQW2WFqSGjndCVFJkkXZNtZe1RP6x
VAiPcIPARpGAoDMw0QRGxo3eCJljqZjERHeGAwwxCDDCqehrB0xmBgQeIsdjHCanYwTAkIUl
qWVcpeSg7F3YSUx7tUZZz5GbUYpoyO5/kk1TEoym9ZaQoZ1VKrDC6+FLUWoS3BSyzfXGNmem
jIrw0u6lKdKlKWS6jaQqpQ2aLN3xjtXZskZUqSzwaYToyWssVO5zSeTV66HOzi7SloMyTXpJ
Sbylakc7zhq5MMklicFIpwiLHQofapLN05OKWI411jDC6or8HOi2HTUyXswnEHqlSD8Oebmi
qnxOGekYnrCxElKA5gXqpEHPN5A5CT0cYWAspTJrL2Lulgu5lbmR9amFaarRnHG1VIKBcESO
GHcETyohEUARIiiDI0sA/BQwRHJCfIWIiCmbDpcyZAkRME+JFgqqZBik4j6FTSBQZguUg4L1
FGJDIDDDCsLv76MLqJZUtUnUVSnDhw34PyN1FJS0qUtKlLSybqcQU3qnyrCeSFJHXUpubLpH
ZGlWXxiSzhWTqy3BwHIfAYPUKVh4Y2Q5ujOqR2EKciSN9N0CgoSkpCpG4KYKkbG6ks34WR0K
EdqiL5LNA2WSJd7RiJ3EQEREcSJ3d7HqRoiIwueNVizOGF9BdGkW+pGVsMDgvFhnUMj1zDgl
MZWhP73NovsqKedSzC3wpbTWylr2PJdjyKy8Zohpn5lnSuzUXWOGGp4uRGUCQkftjFRRQpY4
fFikhSwpUYKEL0gpYYmKJQUC5BIg5FjgXIPOAw0sA9po3MjZlvZM41VqppmlJULmRZjcLXyp
hTXKluLLdUtkW2wmSgwiuBeTlB3pvGqd6yJuXbKWtRkTVku4SbM7l11xaLKdhReWyasqxwYR
nh5FM0jEdDK0M1QyNyNNtikpR8Udtc35RqhnSQw7Q9YiljQgrj33DqQhrqWCm5HHcJ24aeRt
y5F3BrvlD4yAjFmN9SxellRYupQvF0tSdMjZno0S44CY/GPZA/2drwR1hpXCTIHAhIwZOxIq
NHCk5N5N44G3i3JujaDIf1MQcy9vGqdEZt7ocnSxZYmXFVSRxU4v0UpSwu7Vqd9JZJpqiTzz
zspxTifIayksSpt63w3961I4FdZnMYGK34jJS9OSNPW6EXSaIvEyfWstvQ1LPlJokcw7nOjt
KKYWK96qdDc2i+IPTJl6V5ZJW5Tu2nlUhvUTDR+L3u4xSxapRaRUUoU6ahvqGynYyT8Sl360
6ZHS8OXTuea54qTp9L4s0tgeO0N7WcqVaWzYVZ2tDZGM8mmSuC2aFH0KfIVzOVnwU5UYbWT9
1Ga7VI+VW/NeEmxMpDwqUVCqRVE5sJSlKFqRyXdU6E/NTJ0qRY0SyG2dqjCKUyR4zBgsskzC
yUIedT0iqgBsDuWIKqHofw+EZ7K6O8niWkk30hVKpE2dE7XostgwizUWBgNzeD2yd3nyMwNZ
oMiMPNwaLURMWVJS9jLLBeFFMRkvkpdhZYtP72qzZTRnowwXUvLpeKF0ktSUKSkdKWSxvjNI
PS0yB5G8PMaTc3qYmpqTLOsSWTdSWSedT8dU47lzJpGFT29/D9+by5+fNOA/+LuSKcKEhWPL
6Yg=

--Boundary_(ID_rHZDUOqZ5JW4Vo0adR7tmA)--

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Wed Sep 27 20:11:51 2000
Received: by humbolt.nl.linux.org id <S92395AbQI0SLX>;
	Wed, 27 Sep 2000 20:11:23 +0200
Received: from mail2.uni-bielefeld.de ([129.70.4.90]:13217 "EHLO
        mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP
	id <S92274AbQI0SK4>; Wed, 27 Sep 2000 20:10:56 +0200
Received: from Mutz.com (ppp36-21.hrz.uni-bielefeld.de [129.70.36.21])
 by mail.uni-bielefeld.de
 (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6)
 with ESMTP id <0G1K000IU565L8@mail.uni-bielefeld.de> for
 linux-crypto@nl.linux.org; Wed, 27 Sep 2000 20:10:55 +0200 (MET DST)
Date:   Wed, 27 Sep 2000 18:08:27 +0000
From:   Marc Mutz <Marc@Mutz.com>
Subject: Re: Hardware crypto
To:     "Michael T. Babcock" <mbabcock@fibrespeed.net>
Cc:     nd@hplb.hpl.hp.com, linux-crypto <linux-crypto@nl.linux.org>
Message-id: <39D2379B.7E46BE39@Mutz.com>
Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics
MIME-version: 1.0
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <20000927121809.A13379@mind.be> <39D1F857.D049BDC7@Mutz.com>
 <20000927175204.A75897@midten.fast.no> <39D21D58.CB3FD30A@hplb.hpl.hp.com>
 <002601c0289f$60e36400$0c0aa8c0@hosted.fibrespeed.net>
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

"Michael T. Babcock" wrote:
> 
<snip>
> Session = CryptoAccel_Init();
> if (CryptoAccel_Available(CRYPTA_SHA1))
>     /* send data to be accelerated */
> else
>     /* do it yourself, or let the un-accelerated library do it */
<snip>

What we have so far is the following (w/o error checking):

userspace scans /proc/cipher/* for a cipher-id, kernel spaces can search
a table.
with this ID you do: (look at driver/block/loop_gen.c in a kernel
patched with the kerneli patch)

struct cipher_implementation *ci;
struct cipher_context *cx;

ci = find_cipher_by_id(cipherid);

/* in case the cipher is implemented in a loadable module: */
ci->lock()

cx = (struct cipher_context *) kmalloc(
	sizeof(struct cipher_context),GFP_KERNEL);

cx->ci=ci;
cx->keyinfo = kmalloc(ci->key_schedule_size, GFP_KERNEL);
ci->set_key(cx,key,keysize);

/* save away cx and later: */
cx->iv = ... /* for modes requiring an IV */
cx->ci->encrypt(cx,plaintext,ciphertext,length);
/* or */
cx->ci->decrypt(cx,ciphertext,plaintext,length);
/* or for re-keying */
cx->ci->setkey(cx,newkey,newkeylength);

/* if you don't need it anymoe */
kfree(cx->keyinfo);
kfree(cx);
ci->unlock();

It would be easy to hide knowledge of ci->key_schedule_size from the
user of this api and make the second kmalloc call inside ci->setkey.
Also, we could add constructors and destructors (ci->init and ci->exit,
e.g.). For now, they would be no-ops, but they might be necessary for hw
crypto.

I think that with some minor additions and changes this api (which, btw,
does exist similarly for hash functions) would be capable of carrying
even hw crypto. The backend has to be changed, of course, but the user
interface would be stable.

And something we are working on, too, is to benchmark cipher
implementations on boot/module load and publish the results via /proc,
so kernelspace users of this api can choose a suiting implementation by
having a userspace deamon look at the encryption speed vs. key agility
figures.

And the best: It's there! Get it at
ftp.*.kernel.org/pub/linux/kernel/crypto/.

Marc

-- 
Marc Mutz <Marc@Mutz.com>        http://marc.mutz.com/Encryption-HOWTO/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's:   0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)


Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Wed Sep 27 22:38:14 2000
Received: by humbolt.nl.linux.org id <S92399AbQI0Uhs>;
	Wed, 27 Sep 2000 22:37:48 +0200
Received: from [200.248.43.134] ([200.248.43.134]:39175 "EHLO
        mail.sul-e.com.br") by humbolt.nl.linux.org with ESMTP
	id <S92403AbQI0UhV>; Wed, 27 Sep 2000 22:37:21 +0200
Received: from baraico ([192.9.200.151])
	by mail.sul-e.com.br (8.9.3/8.9.3) with SMTP id UAA21911
	for <linux-crypto@nl.linux.org>; Wed, 27 Sep 2000 20:24:46 GMT
Message-ID: <01b101c028c2$b9de6460$97c809c0@sule.com.br>
From:   "Maicon Triches" <maicon@sul-e.com.br>
To:     <linux-crypto@nl.linux.org>
Subject: lista
Date:   Wed, 27 Sep 2000 17:37:09 -0300
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_01AE_01C028A9.901D5780"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

This is a multi-part message in MIME format.

------=_NextPart_000_01AE_01C028A9.901D5780
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Pedido de inscri=E7=E3o na lista...

Maicon L. Triches
maicon@sul-e.com.br
Sule Eletrodom=E9sticos
Inform=E1rtica - Suporte=20

------=_NextPart_000_01AE_01C028A9.901D5780
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Pedido de inscri=E7=E3o na =
lista...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><BR>Maicon L. Triches<BR><A=20
href=3D"mailto:maicon@sul-e.com.br">maicon@sul-e.com.br</A><BR>Sule=20
Eletrodom=E9sticos<BR>Inform=E1rtica - Suporte =
</FONT></DIV></BODY></HTML>

------=_NextPart_000_01AE_01C028A9.901D5780--


Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Wed Sep 27 22:49:25 2000
Received: by humbolt.nl.linux.org id <S92409AbQI0Ust>;
	Wed, 27 Sep 2000 22:48:49 +0200
Received: from eik.ii.uib.no ([129.177.16.3]:39589 "EHLO ii.uib.no")
	by humbolt.nl.linux.org with ESMTP id <S92412AbQI0Us1> convert rfc822-to-8bit;
	Wed, 27 Sep 2000 22:48:27 +0200
Received: from apal.ii.uib.no [129.177.16.7] 
	by ii.uib.no with esmtp (Exim 3.03)
	id 13eO85-0006hO-00 ; Wed, 27 Sep 2000 22:48:37 +0200
Received: (from gisle@localhost)
	by apal.ii.uib.no (8.8.8+Sun/8.8.7) id WAA13815;
	Wed, 27 Sep 2000 22:48:25 +0200 (MET DST)
Date:   Wed, 27 Sep 2000 22:48:25 +0200 (MET DST)
From:   Gisle S{lensminde <gisle@ii.uib.no>
To:     Marc Mutz <Marc@Mutz.com>
cc:     linux-crypto@nl.linux.org
Subject: Re: [KERNELI-PATCH] Twofish for the cipherapi.
In-Reply-To: <39D22C4E.6EFB79AA@Mutz.com>
Message-ID: <Pine.SOL.4.21.0009272245310.13728-100000@apal.ii.uib.no>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

On Wed, 27 Sep 2000, Marc Mutz wrote:

> Hi Alex!
> 
> As you know, I've ported the Twofish implementation of GnuPG
> (http://www.gnupg.org) to the cipherapi of the kerneli patch
> (http://www.kerneli.org/). You need to patch include/linux/crypto.h and
> util-linux to use a cipher id you like. I don't want to mess around with
> the loop_fish2.c driver. If you find this implementation worth of being
> able to replace the other twofish, then it can take its number. 192 bits
> mode is not working for this twofish.c, but not hard to obtain.
> 
> This patch assumes my changes to loop_gen.c, so no need to patch that
> file. Please consider applying:

The patch seems not to be complete. It does at least miss the definitions
in linux/include/linux/crypto.h. Since I'm too lazy to scan the code to
find the exact size of the key schedule, I would prefere an updated
patch. 


--
Gisle Sælensminde ( gisle@ii.uib.no )   

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly
overhead. (from RFC 1925)


Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Wed Sep 27 23:10:42 2000
Received: by humbolt.nl.linux.org id <S92415AbQI0VKT>;
	Wed, 27 Sep 2000 23:10:19 +0200
Received: from midten.fast.no ([213.188.8.11]:37645 "EHLO midten.fast.no")
	by humbolt.nl.linux.org with ESMTP id <S92414AbQI0VJu>;
	Wed, 27 Sep 2000 23:09:50 +0200
Received: (from astor@localhost)
	by midten.fast.no (8.9.3/8.9.3) id XAA88581;
	Wed, 27 Sep 2000 23:08:31 +0200 (CEST)
Date:   Wed, 27 Sep 2000 23:08:30 +0200
From:   Alexander S A Kjeldaas <Alexander.Kjeldaas@fast.no>
To:     Neil Dunbar <nd@hplb.hpl.hp.com>
Cc:     linux-crypto <linux-crypto@nl.linux.org>
Subject: Re: Hardware crypto
Message-ID: <20000927230830.A87315@midten.fast.no>
References: <20000927121809.A13379@mind.be> <39D1F857.D049BDC7@Mutz.com> <20000927175204.A75897@midten.fast.no> <39D21D58.CB3FD30A@hplb.hpl.hp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4i
In-Reply-To: <39D21D58.CB3FD30A@hplb.hpl.hp.com>; from Neil Dunbar on Wed, Sep 27, 2000 at 05:16:24PM +0100
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

On Wed, Sep 27, 2000 at 05:16:24PM +0100, Neil Dunbar wrote:
> Alexander S A Kjeldaas wrote:
> > 
> > I think there are some interesting issues to be solved when we want to
> > get hardware crypto cards running under Linux.  For one, we want to
> > have a queue of processing requests for the device instead of having a
> > synchronous interface like most crypto libraries offer.  We also
> > probably want to use the CPU if the queue starts to have too many
> > entries, or load-balance between several cards, so we need a
> > "crypto-provider" concept.
> 
> So you need an abstraction interface. If we're talking
> kernel here (ie for IPsec/filesystem crypto/stego), then
> all we should need is an abstraction over symmetric key
> operations - IKE is done in userspace, after all. I suppose
> that it would be possible to leave the slot open for
> message digests as well, although I haven't seen a card
> which accelerates MD5/SHA-1, or HMAC over them.
> 

The API in the kerneli patch only deals with ciphers and digests.  I
really haven't thought about adding public-key stuff as I can't think
of any applications for it.  The only additional interface one might
want is for random numbers, and that already esists.  The goal of the
kerneli project has simply been to provide high-performance
ciphers/digests for the kernel that other crypto-projects can build
upon.  

> The only plea that I would make is to not make it too
> fancy - otherwise we end up with CDSA and other such
> monsters.

I agree.  However there is a case for having a more higher-level
interface than the typical vanilla crypto-API you see in OpenSSL.  It
is possible to do IDEA+SHA1 _at the same time_ on a normal Pentium II
processor in roughly the same time it takes to do just one of them.
This is how you do it: You run the IDEA algorithm using the MMX
instruction set, and the SHA1 using plain C code, and then merge the
two.  The reason you can do this "for free" on a modern CPU is that
the issue-width is pretty high combined with the fact that most crypto
algorithms don't lend themselves to parallel implementations.  So when
executing a cipher, most CPUs have lots of extra memory bandwidth and
instruction-issue bandwidth left unused.  Making use of this requires
some complexity in how ciphers/digest algorithms are implemented, but
I plan on trying out this idea in the future.  However since this has
never been done in a crypto API AFAIK, it might require a slightly
higher-level API.  Something along a "transform" that is both a cipher
and a digest at the same time.  You should tell the API to "encrypt
this datastream while calculating SHA1 and doing IP checksumming". 

Until the kerneli patch has a screaming implementation of the above,
I'll let the idea rest, but you have been warned :-).

Similarly, in some situations where you want to calculate 3des_cbc of
lots of streams at the same time, you might want to be able to switch
over to vector processing of lots of packets.  Using AltiVec (Power
PC) or SSE (Intel) vector instructions you can theoretically have a
bitslice implementation of 3des_cbc that can handle 128 streams in
parallel.  This could be interesting for some IPsec gateways where you
can sacrifice some latency for throughput.

So keep the API simple unless the numbers tell you otherwise.

astor

-- 
Alexander Kjeldaas                Mail:  astor@fast.no
finger astor@master.kernel.org for OpenPGP key.

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Wed Sep 27 23:26:33 2000
Received: by humbolt.nl.linux.org id <S92414AbQI0V0K>;
	Wed, 27 Sep 2000 23:26:10 +0200
Received: from midten.fast.no ([213.188.8.11]:15886 "EHLO midten.fast.no")
	by humbolt.nl.linux.org with ESMTP id <S92412AbQI0VZl>;
	Wed, 27 Sep 2000 23:25:41 +0200
Received: (from astor@localhost)
	by midten.fast.no (8.9.3/8.9.3) id XAA89196;
	Wed, 27 Sep 2000 23:25:33 +0200 (CEST)
Date:   Wed, 27 Sep 2000 23:25:32 +0200
From:   Alexander S A Kjeldaas <Alexander.Kjeldaas@fast.no>
To:     Richard Guy Briggs <rgb@conscoop.ottawa.on.ca>
Cc:     Alexander S A Kjeldaas <Alexander.Kjeldaas@fast.no>,
        Marc Mutz <Marc@Mutz.com>,
        Peter van Hove <peter.van.hove@mind.be>,
        linux-crypto <linux-crypto@nl.linux.org>
Subject: Re: Hardware crypto
Message-ID: <20000927232532.B87315@midten.fast.no>
References: <20000927121809.A13379@mind.be> <39D1F857.D049BDC7@Mutz.com> <20000927175204.A75897@midten.fast.no> <20000927121717.Z28566@grendel.conscoop.ottawa.on.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4i
In-Reply-To: <20000927121717.Z28566@grendel.conscoop.ottawa.on.ca>; from Richard Guy Briggs on Wed, Sep 27, 2000 at 12:17:17PM -0400
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

On Wed, Sep 27, 2000 at 12:17:17PM -0400, Richard Guy Briggs wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> On Wed, Sep 27, 2000 at 05:52:04PM +0200, Alexander S A Kjeldaas wrote:
> > 
> > I think there are some interesting issues to be solved when we want to
> > get hardware crypto cards running under Linux.  For one, we want to
> > have a queue of processing requests for the device instead of having a
> > synchronous interface like most crypto libraries offer.  We also
> > probably want to use the CPU if the queue starts to have too many
> > entries, or load-balance between several cards, so we need a
> > "crypto-provider" concept.  Also, for programmable crypto-cards we
> > might want to consider the cost of switching ciphers on the card when
> > choosing which requests should be done by which cards/CPU.  This will
> > be interesting to look at when the first drivers emerge.
> 
> I completely agree that it should be queue-based.  SMP is the other
> obvious reason for a queue.
> 
> Alan Cox has publicly stated that he thinks this is the right way to
> do things, but at the moment, asynchrony and queues for this type of
> processing will be a big challenge to accomplish this in the present
> Linux kernels.  

Could you expand on some of the issues?  Are the problems related to
where you are allowed to sleep in the tcp/ip stack?  The part of
creating the async crypto API seems doable.

astor

-- 
Alexander Kjeldaas                Mail:  astor@fast.no
finger astor@master.kernel.org for OpenPGP key.

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Wed Sep 27 23:33:27 2000
Received: by humbolt.nl.linux.org id <S92418AbQI0Vcw>;
	Wed, 27 Sep 2000 23:32:52 +0200
Received: from midten.fast.no ([213.188.8.11]:32526 "EHLO midten.fast.no")
	by humbolt.nl.linux.org with ESMTP id <S92412AbQI0VcZ>;
	Wed, 27 Sep 2000 23:32:25 +0200
Received: (from astor@localhost)
	by midten.fast.no (8.9.3/8.9.3) id XAA89405;
	Wed, 27 Sep 2000 23:32:13 +0200 (CEST)
Date:   Wed, 27 Sep 2000 23:32:13 +0200
From:   Alexander S A Kjeldaas <Alexander.Kjeldaas@fast.no>
To:     "Michael T. Babcock" <mbabcock@fibrespeed.net>
Cc:     Alexander S A Kjeldaas <Alexander.Kjeldaas@fast.no>,
        Marc Mutz <Marc@Mutz.com>,
        Peter van Hove <peter.van.hove@mind.be>,
        linux-crypto <linux-crypto@nl.linux.org>
Subject: Re: Hardware crypto
Message-ID: <20000927233213.C87315@midten.fast.no>
References: <20000927121809.A13379@mind.be> <39D1F857.D049BDC7@Mutz.com> <20000927175204.A75897@midten.fast.no> <000701c0289d$75d14780$0c0aa8c0@hosted.fibrespeed.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4i
In-Reply-To: <000701c0289d$75d14780$0c0aa8c0@hosted.fibrespeed.net>; from Michael T. Babcock on Wed, Sep 27, 2000 at 12:10:30PM -0400
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

On Wed, Sep 27, 2000 at 12:10:30PM -0400, Michael T. Babcock wrote:
> 
> A queuing concept is definately needed if this is to be done right the first
> time (so to speak).  The configuration of this interface, however, would be
> the interesting challenge here.  How to present to the user (the sysadmin,
> most likely) the options for dealing with crypto on a per-system, perhaps
> per-app basis.  Prioritising certain applications over others, perhaps,
> would end up being an issue as well.
> 
> For example:
> OpenSSL uses the "crypto accel api" for web serving.
> FreeS/WAN uses it for VPN traffic.

ok

> GPG uses it to encrypt E-mails or generate signatures.

This is a stretch!  Unless there is a painfully obvious win of
involving the kernel in GPGs activities I it should be left to do its
stuff in userland.

> 
> I would probably set the FreeS/WAN requests to have a slightly lower
> priority than the OpenSSL requests because we host E-commerce sites ... and
> the GPG traffic would be lowest, but I wouldn't want it to get swamped out
> of the picture if the crypto card were at full use.  Having it send a
> suitable? number of requests to the software crypto system would be
> necessary as well.
>

Hopefully this could be (indirectly) handled by other parts of the
kernel, namely the QoS modules or the traffic shaper.

> 
> It becomes quite interestingly complex ;-).
> 

It certainly _can_ be made complex.

astor

-- 
Alexander Kjeldaas                Mail:  astor@fast.no
finger astor@master.kernel.org for OpenPGP key.

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Wed Sep 27 23:34:42 2000
Received: by humbolt.nl.linux.org id <S92412AbQI0VdA>;
	Wed, 27 Sep 2000 23:33:00 +0200
Received: from mail2.uni-bielefeld.de ([129.70.4.90]:31685 "EHLO
        mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP
	id <S92416AbQI0Vcd>; Wed, 27 Sep 2000 23:32:33 +0200
Received: from Mutz.com (ppp36-120.hrz.uni-bielefeld.de [129.70.36.120])
 by mail.uni-bielefeld.de
 (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6)
 with ESMTP id <0G1K0079ZEI5G4@mail.uni-bielefeld.de> for
 linux-crypto@nl.linux.org; Wed, 27 Sep 2000 23:32:31 +0200 (MET DST)
Date:   Wed, 27 Sep 2000 21:22:24 +0000
From:   Marc Mutz <Marc@Mutz.com>
Subject: Twofish users:attention! (was: Re: [KERNELI-PATCH] Twofish for the
 cipherapi.)
To:     Gisle S{lensminde <gisle@ii.uib.no>
Cc:     linux-crypto@nl.linux.org
Message-id: <39D26510.C8FD40B3@Mutz.com>
Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics
MIME-version: 1.0
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586)
Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_GAwNkn9yMdrLr8fegjd2Dg)"
X-Accept-Language: en
References: <Pine.SOL.4.21.0009272245310.13728-100000@apal.ii.uib.no>
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

This is a multi-part message in MIME format.

--Boundary_(ID_GAwNkn9yMdrLr8fegjd2Dg)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Gisle S{lensminde wrote:
> 
> On Wed, 27 Sep 2000, Marc Mutz wrote:
> 
> > Hi Alex!
> >
> > As you know, I've ported the Twofish implementation of GnuPG
> > (http://www.gnupg.org) to the cipherapi of the kerneli patch
> > (http://www.kerneli.org/). You need to patch include/linux/crypto.h and
> > util-linux to use a cipher id you like. I don't want to mess around with
> > the loop_fish2.c driver. If you find this implementation worth of being
> > able to replace the other twofish, then it can take its number. 192 bits
> > mode is not working for this twofish.c, but not hard to obtain.
> >
> > This patch assumes my changes to loop_gen.c, so no need to patch that
> > file. Please consider applying:
> 
> The patch seems not to be complete. It does at least miss the definitions
> in linux/include/linux/crypto.h. Since I'm too lazy to scan the code to
> find the exact size of the key schedule, I would prefere an updated
> patch.
> 
<snip>

You're right, of course. The sent patch was relative to stuff I sent to
Alex earlier, before this ml was established. The included patch adds
the necessary definitions to include/linux/cryto.h and contains the
changes I made to drivers/block/loop_gen.c.

The driver has been assigned id 9 temporarily. It will not stay there.
Alex should choose number for it when he decides what will become of the
loop_2fish.c driver. Patching lomount.c involves only changing the
static list of ciphers and to add LO_CRYPT_TWOFISH to the 128 bit case
in lomount.c:set_loop()'s switch statement.

As you see, I don't want people to deploy this on a large basis, because
the ID is not assigned yet and there will be _questions_ if it changes
:-)

Hi out there! Anyone using Twofish from patch-int-2.2.17.3 or earlier?
Please contact me! It may well vanish in the future and the cipherapi
implementation might not be compatible then.

Marc

-- 
Marc Mutz <Marc@Mutz.com>        http://marc.mutz.com/Encryption-HOWTO/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's:   0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)

--Boundary_(ID_GAwNkn9yMdrLr8fegjd2Dg)
Content-type: text/plain; name=twofish-related.patch; charset=us-ascii
Content-disposition: inline; filename=twofish-related.patch
Content-transfer-encoding: 7BIT

--- i5/drivers/block/loop_gen.c	Mon Sep 25 16:50:54 2000
+++ i5-raidA0-raid1rb15.B2-ext0.0.3a//drivers/block/loop_gen.c	Mon Sep 25 17:48:47 2000
@@ -56,6 +56,7 @@
 static int loop_gen_init2(struct loop_device *lo, struct loop_info *info)
 {
 	int cipher,err = -EINVAL;
+	int mode = CIPHER_CBC;
 	struct cipher_implementation *ci;
 	struct cipher_context *cx;
 
@@ -64,19 +65,7 @@
 	case LO_CRYPT_XOR:      cipher = CIPHER_XOR; break;
 	case LO_CRYPT_DES:      cipher = CIPHER_cbc_DES; break;
 	case LO_CRYPT_FISH2:    cipher = CIPHER_cbc_FISH2; break;
-	case LO_CRYPT_BLOW:     cipher = CIPHER_cbc_BLOWFISH; break;
-	case LO_CRYPT_CAST128:  cipher = CIPHER_cbc_CAST128; break;
-	case LO_CRYPT_IDEA:     cipher = CIPHER_cbc_IDEA; break;
-	case LO_CRYPT_SERPENT:  cipher = CIPHER_cbc_SERPENT; break;
-	case LO_CRYPT_MARS:     cipher = CIPHER_cbc_MARS; break;
-	case LO_CRYPT_SKIPJACK: cipher = CIPHER_cbc_SKIPJACK; break;
-	case LO_CRYPT_RC5:      cipher = CIPHER_cbc_RC5; break;
-	case LO_CRYPT_RC6:      cipher = CIPHER_cbc_RC6; break;
-	case LO_CRYPT_DES_EDE3: cipher = CIPHER_cbc_DES_EDE3; break;
-	case LO_CRYPT_E2:       cipher = CIPHER_cbc_E2; break;
-	case LO_CRYPT_CAST256:  cipher = CIPHER_cbc_CAST256; break;
-	case LO_CRYPT_DFC:      cipher = CIPHER_cbc_DFC; break;
-	default: goto out;
+	default:                cipher = info->lo_encrypt_type | mode; break;
 	}
 
 	ci = find_cipher_by_id(cipher);
@@ -85,7 +74,7 @@
 
 	if (ci->trans.t_id != cipher) {
 		printk("find_cipher_by_id gave me the wrong cipher!\n");
-		goto out_ci;
+		goto out;
 	}
 
 	ci->lock();
--- i5/include/linux/crypto.h	Mon Sep 25 16:50:54 2000
+++ i5-raidA0-raid1rb15.B2-ext0.0.3a//include/linux/crypto.h	Mon Sep 25 17:39:33 2000
@@ -20,6 +20,7 @@
 #define CIPHER_IDEA     6
 #define CIPHER_SERPENT  7
 #define CIPHER_MARS     8
+#define CIPHER_TWOFISH  9
 
 #define CIPHER_SKIPJACK 10
 #define CIPHER_RC6      11
@@ -39,6 +40,8 @@
 #define CIPHER_cbc_IDEA     (CIPHER_IDEA     | CIPHER_CBC)
 #define CIPHER_cbc_SERPENT  (CIPHER_SERPENT  | CIPHER_CBC)
 #define CIPHER_cbc_MARS     (CIPHER_MARS     | CIPHER_CBC)
+#define CIPHER_cbc_TWOFISH  (CIPHER_TWOFISH  | CIPHER_CBC)
+
 #define CIPHER_cbc_SKIPJACK (CIPHER_SKIPJACK | CIPHER_CBC)
 #define CIPHER_cbc_RC5      (CIPHER_RC5      | CIPHER_CBC)
 #define CIPHER_cbc_RC6      (CIPHER_RC6      | CIPHER_CBC)
@@ -257,6 +260,16 @@
 			    const u8 *in, u8 *out, int size);
 extern int blowfish_decrypt(struct cipher_context *cx,
                             const u8 *in, u8 *out, int size);
+
+extern int init_twofish(void);
+#define TWOFISH_KEY_SCHEDULE_SIZE ((4*256+8+32)*sizeof(u32))
+extern int twofish_set_key(struct cipher_context *cx,
+                            unsigned char *key, int key_len);
+extern int twofish_encrypt(struct cipher_context *cx,
+			    const u8 *in, u8 *out, int size);
+extern int twofish_decrypt(struct cipher_context *cx,
+                            const u8 *in, u8 *out, int size);
+
 extern int init_idea(void);
 #define IDEA_KEY_SCHEDULE_SIZE (104*2)
 extern int idea_set_key(struct cipher_context *cx, unsigned char *key, 

--Boundary_(ID_GAwNkn9yMdrLr8fegjd2Dg)--

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Wed Sep 27 23:35:29 2000
Received: by humbolt.nl.linux.org id <S92416AbQI0VdS>;
	Wed, 27 Sep 2000 23:33:18 +0200
Received: from mail2.uni-bielefeld.de ([129.70.4.90]:32197 "EHLO
        mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP
	id <S92417AbQI0Vce>; Wed, 27 Sep 2000 23:32:34 +0200
Received: from Mutz.com (ppp36-120.hrz.uni-bielefeld.de [129.70.36.120])
 by mail.uni-bielefeld.de
 (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6)
 with ESMTP id <0G1K007AVEI8GN@mail.uni-bielefeld.de> for
 linux-crypto@nl.linux.org; Wed, 27 Sep 2000 23:32:33 +0200 (MET DST)
Date:   Wed, 27 Sep 2000 21:28:50 +0000
From:   Marc Mutz <Marc@Mutz.com>
Subject: Re: lista
To:     Maicon Triches <maicon@sul-e.com.br>
Cc:     linux-crypto@nl.linux.org
Message-id: <39D26692.6CD2A8E0@Mutz.com>
Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics
MIME-version: 1.0
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <01b101c028c2$b9de6460$97c809c0@sule.com.br>
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

Maicon Triches wrote:
> 
>    Part 1.1    Type: Plain Text (text/plain)
>            Encoding: quoted-printable

Please don't send MIME multipart messages when not attaching something.
I use netscape messenger and it only shows an attachment with your
message. I will skip such messages in the future. Sorry.

Yes, iknow that it is possibly netscapes fault, but sending multipart
messages when plain test would suffice is abuse of MIME. IMO. YMMV.

Marc

-- 
Marc Mutz <Marc@Mutz.com>        http://marc.mutz.com/Encryption-HOWTO/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's:   0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)


Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Thu Sep 28 00:04:08 2000
Received: by humbolt.nl.linux.org id <S92417AbQI0WDc>;
	Thu, 28 Sep 2000 00:03:32 +0200
Received: from mail2.uni-bielefeld.de ([129.70.4.90]:14027 "EHLO
        mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP
	id <S92421AbQI0WDC>; Thu, 28 Sep 2000 00:03:02 +0200
Received: from Mutz.com (ppp36-282.hrz.uni-bielefeld.de [129.70.37.26])
 by mail.uni-bielefeld.de
 (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6)
 with ESMTP id <0G1K007L0FWZG4@mail.uni-bielefeld.de> for
 linux-crypto@nl.linux.org; Thu, 28 Sep 2000 00:03:00 +0200 (MET DST)
Date:   Wed, 27 Sep 2000 22:02:44 +0000
From:   Marc Mutz <Marc@Mutz.com>
Subject: [KERNLI PATCH] Configure.help update against 2.2.17.5
To:     linux-crypto@nl.linux.org
Message-id: <39D26E84.4F10C595@Mutz.com>
Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics
MIME-version: 1.0
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586)
Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_h9P8TqFQYboApUreehaw4w)"
X-Accept-Language: en
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

This is a multi-part message in MIME format.

--Boundary_(ID_h9P8TqFQYboApUreehaw4w)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi Alex!

I've incorporated your suggestions. Have a look.

Marc

-- 
Marc Mutz <Marc@Mutz.com>        http://marc.mutz.com/Encryption-HOWTO/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's:   0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)

--Boundary_(ID_h9P8TqFQYboApUreehaw4w)
Content-type: text/plain; name=Configure.help-2.2.17.5.patch; charset=us-ascii
Content-disposition: inline; filename=Configure.help-2.2.17.5.patch
Content-transfer-encoding: 7BIT

--- i5/Documentation/Configure.help	Mon Sep 25 16:50:54 2000
+++ i5-raidA0-raid1rb15.B2-ext0.0.3a/Documentation/Configure.help	Wed Sep 27 23:58:05 2000
@@ -287,22 +287,35 @@
 
 Crypto ciphers
 CONFIG_CIPHERS
-  A cipher is a parameter-dependant function E_K that takes a
-  fixed-length block M (usually 64 or 128 bits) and maps it onto
-  another (usually equal-sized) block E_K(M) in such a way that,
-  without knowledge of the "key" K, it is hard to compute
-
-  1. M,      if E_K(M) is given,
-
-  2. E_K(M), if M is given.
-
-  However, there always exists the inverse function D_K of E_K such
-  that D_K(E_K(M))=M for any M. M is called the 'plaintext' and E_K(M)
-  the 'ciphertext'. The ideal cipher is one where it is impossible to
-  compute M, if you have E_K(M), but not K. In this case, the easiest
-  way to break the cipher is to use 'brute-force', i.e. try all K in
-  turn until you hit the right one. With most ciphers in this library,
-  K is a 128-bit number. Here, brute-force attacks are infeasible.
+  Ciphers basically help us scramble data so that other people don't
+  get access to it. Useful applications for this include hiding hard
+  drive contents or network traffic from unauthorized eyes. Compare a
+  file encrypted with a cipher with very good safe: The document is in
+  it, you can carry the document with you (if the safe is not too
+  heavy), but others can steal it, too. However, they will not be able
+  to read the document if the safe is any good.
+
+  Mathematically speaking, a cipher is a parameter-dependant function
+  E(K, ) that takes a fixed-length block M (usually 64 or 128 bits)
+  and maps it onto another (usually equal-sized) block C=E(K,M) in such
+  a way that, without knowledge of the "key" K, it is hard to compute
+
+  1. M, if C and the function E are given,
+
+  2. C, if M is given and the function E is known.
+
+  M is called the 'plaintext' and C the 'ciphertext'. The above
+  properties are commonly described as "All the security of the cipher
+  lies in its key". However, there always exists the inverse function
+  D(K, ) of E(K, ) such that D(K,E(K,M))=M for any M.  The ideal
+  cipher is one where it is impossible to compute M if you have C, but
+  not K. In this case, the easiest way to break the cipher is to use
+  'brute-force', i.e. try all K in turn until you hit the right
+  one. With most ciphers in this library, K is a 128-bit number. Here,
+  brute-force attacks are infeasible since they require testing all
+  2^128 possible keys K, which would take far too long on any
+  conceivable computer (some big multiple of the age of the universe
+  for example).
 
   Unfortunately, the ideal cipher has not been found yet, so most
   ciphers in this library, or certain 'reduced-round' versions

--Boundary_(ID_h9P8TqFQYboApUreehaw4w)--

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Thu Sep 28 00:06:55 2000
Received: by humbolt.nl.linux.org id <S92419AbQI0WGZ>;
	Thu, 28 Sep 2000 00:06:25 +0200
Received: from terra.geo.uu.nl ([131.211.29.16]:34558 "EHLO terra.geo.uu.nl")
	by humbolt.nl.linux.org with ESMTP id <S92421AbQI0WFs>;
	Thu, 28 Sep 2000 00:05:48 +0200
Received: from james.kalifornia.com (root@james.kalifornia.com [208.179.0.2])
	by terra.geo.uu.nl (8.9.3/8.9.3/TvZ) with ESMTP id AAA20965
	for <linux-crypto@nl.linux.org>; Thu, 28 Sep 2000 00:05:43 +0200 (MET DST)
Received: from Huntington-Beach.Blue-Labs.org (mail@Huntington-Beach.Blue-Labs.org [208.179.0.198])
	by james.kalifornia.com (8.11.0/8.11.0) with ESMTP id e8RM5bV07206;
	Wed, 27 Sep 2000 15:05:38 -0700
Received: from kalifornia.com (david@localhost [127.0.0.1])
	by Huntington-Beach.Blue-Labs.org (8.9.3/8.9.0) with ESMTP id PAA01874;
	Wed, 27 Sep 2000 15:05:33 -0700
Message-ID: <39D26F2C.BEC708A6@kalifornia.com>
Date:   Wed, 27 Sep 2000 15:05:33 -0700
From:   David Ford <david@kalifornia.com>
Reply-To: david+validemail@kalifornia.com
Organization: Talon Technology, Intl.
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test8 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Marc Mutz <Marc@mutz.com>
CC:     Maicon Triches <maicon@sul-e.com.br>, linux-crypto@nl.linux.org
Subject: Re: lista
References: <01b101c028c2$b9de6460$97c809c0@sule.com.br> <39D26692.6CD2A8E0@Mutz.com>
Content-Type: multipart/mixed;
 boundary="------------8E7928FF09E395C5A92DB6DA"
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

This is a multi-part message in MIME format.
--------------8E7928FF09E395C5A92DB6DA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Netscape sent it multipart because he chose both text and html for the
message.  The message was sent as both text and html.  This allows for the
reader to choose plain or 'enriched' viewing.  This is having it both
ways.  People who gripe about enriched content can read the plain text.
People who want the markup can view it as well.

It's a configuration choice issue.  What you viewed was his entire
message, regardless of whether your reader displayed it in text or html.
I also use NS messenger as one of my preferred readers and I'm able to
view his message perfectly.

-d

Marc Mutz wrote:

> >    Part 1.1    Type: Plain Text (text/plain)
> >            Encoding: quoted-printable
>
> Please don't send MIME multipart messages when not attaching something.
> I use netscape messenger and it only shows an attachment with your
> message. I will skip such messages in the future. Sorry.
>
> Yes, iknow that it is possibly netscapes fault, but sending multipart
> messages when plain test would suffice is abuse of MIME. IMO. YMMV.

--
      "There is a natural aristocracy among men. The grounds of this are
      virtue and talents", Thomas Jefferson [1742-1826], 3rd US President



--------------8E7928FF09E395C5A92DB6DA
Content-Type: text/x-vcard; charset=us-ascii;
 name="david.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Ford
Content-Disposition: attachment;
 filename="david.vcf"

begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:<img src="http://www.kalifornia.com/images/paradise.jpg">
adr:;;;;;;
version:2.1
email;internet:david@kalifornia.com
title:Blue Labs Developer
x-mozilla-cpt:;28256
fn:David Ford
end:vcard

--------------8E7928FF09E395C5A92DB6DA--


Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Thu Sep 28 00:48:37 2000
Received: by humbolt.nl.linux.org id <S92424AbQI0WsM>;
	Thu, 28 Sep 2000 00:48:12 +0200
Received: from cpu2747.adsl.bellglobal.com ([207.236.55.216]:12788 "EHLO
        grendel.conscoop.ottawa.on.ca") by humbolt.nl.linux.org with ESMTP
	id <S92422AbQI0Wry>; Thu, 28 Sep 2000 00:47:54 +0200
Received: (from rgb@localhost)
	by grendel.conscoop.ottawa.on.ca (8.9.0/8.9.0) id SAA10746;
	Wed, 27 Sep 2000 18:45:28 -0400
Date:   Wed, 27 Sep 2000 18:45:28 -0400
From:   Richard Guy Briggs <rgb@conscoop.ottawa.on.ca>
To:     Alexander S A Kjeldaas <Alexander.Kjeldaas@fast.no>
Cc:     "Michael T. Babcock" <mbabcock@fibrespeed.net>,
        Marc Mutz <Marc@Mutz.com>,
        Peter van Hove <peter.van.hove@mind.be>,
        linux-crypto <linux-crypto@nl.linux.org>
Subject: Re: Hardware crypto
Message-ID: <20000927184528.I28566@grendel.conscoop.ottawa.on.ca>
References: <20000927121809.A13379@mind.be> <39D1F857.D049BDC7@Mutz.com> <20000927175204.A75897@midten.fast.no> <000701c0289d$75d14780$0c0aa8c0@hosted.fibrespeed.net> <20000927233213.C87315@midten.fast.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20000927233213.C87315@midten.fast.no>; from Alexander.Kjeldaas@fast.no on Wed, Sep 27, 2000 at 11:32:13PM +0200
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, Sep 27, 2000 at 11:32:13PM +0200, Alexander S A Kjeldaas wrote:
> On Wed, Sep 27, 2000 at 12:10:30PM -0400, Michael T. Babcock wrote:
> > 
> > A queuing concept is definately needed if this is to be done right the first
> > time (so to speak).  The configuration of this interface, however, would be
> > the interesting challenge here.  How to present to the user (the sysadmin,
> > most likely) the options for dealing with crypto on a per-system, perhaps
> > per-app basis.  Prioritising certain applications over others, perhaps,
> > would end up being an issue as well.
> > 
> > For example:
> > OpenSSL uses the "crypto accel api" for web serving.
> > FreeS/WAN uses it for VPN traffic.
> 
> ok
> 
> > GPG uses it to encrypt E-mails or generate signatures.
> 
> This is a stretch!  Unless there is a painfully obvious win of
> involving the kernel in GPGs activities I it should be left to do its
> stuff in userland.

I agree that it is better off in a shared object library for
userspace.  Having said that, how do we get the shared object library
to share the one or more hardware crypto accellerators with such a
facility provided to kernel consumers?

> > I would probably set the FreeS/WAN requests to have a slightly lower
> > priority than the OpenSSL requests because we host E-commerce sites ... and
> > the GPG traffic would be lowest, but I wouldn't want it to get swamped out
> > of the picture if the crypto card were at full use.  Having it send a
> > suitable? number of requests to the software crypto system would be
> > necessary as well.
> 
> Hopefully this could be (indirectly) handled by other parts of the
> kernel, namely the QoS modules or the traffic shaper.

Hopefully.

> > It becomes quite interestingly complex ;-).
> 
> It certainly _can_ be made complex.

Let's not make it complex.  Complexity is the enemy of good security.

> astor
> 
> -- 
> Alexander Kjeldaas                Mail:  astor@fast.no
> finger astor@master.kernel.org for OpenPGP key.
> 
> Linux-crypto:  cryptography in and on the Linux system
> Archive:       http://mail.nl.linux.org/linux-crypto/

	slainte mhath, RGB
- -- 
Richard Guy Briggs -- PGP key available            Auto-Free Ottawa! Canada
<www.conscoop.ottawa.on.ca/rgb/>                       <www.flora.org/afo/>
Prevent Internet Wiretapping!        --        FreeS/WAN:<www.freeswan.org>
Thanks for voting Green! -- <green.ca>      Marillion:<www.marillion.co.uk>

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBOdJ4ht+sBuIhFagtAQHYiQP9F297j/EI9GZMP5LwNL620VPwFR8NmYai
Z+1XGQzi5kvbXqU/K19K02F6Rh5r3DHqPdA/FWrSkueqitWMVEfGkYs/vPeBR/Zz
VCvB5w8LV6EKEaMgbgPQv+VNRQD2ikwIFOzoapb6sHsbNirAP0SmGhULR487AWGH
SDtb4rZekS0=
=YxDH
-----END PGP SIGNATURE-----

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Thu Sep 28 00:56:57 2000
Received: by humbolt.nl.linux.org id <S92300AbQI0W4X>;
	Thu, 28 Sep 2000 00:56:23 +0200
Received: from cpu2747.adsl.bellglobal.com ([207.236.55.216]:51188 "EHLO
        grendel.conscoop.ottawa.on.ca") by humbolt.nl.linux.org with ESMTP
	id <S92421AbQI0Wzz>; Thu, 28 Sep 2000 00:55:55 +0200
Received: (from rgb@localhost)
	by grendel.conscoop.ottawa.on.ca (8.9.0/8.9.0) id SAA10825;
	Wed, 27 Sep 2000 18:53:01 -0400
Date:   Wed, 27 Sep 2000 18:53:01 -0400
From:   Richard Guy Briggs <rgb@conscoop.ottawa.on.ca>
To:     david+validemail@kalifornia.com
Cc:     Marc Mutz <Marc@mutz.com>, Maicon Triches <maicon@sul-e.com.br>,
        linux-crypto@nl.linux.org
Subject: Re: lista
Message-ID: <20000927185301.K28566@grendel.conscoop.ottawa.on.ca>
References: <01b101c028c2$b9de6460$97c809c0@sule.com.br> <39D26692.6CD2A8E0@Mutz.com> <39D26F2C.BEC708A6@kalifornia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <39D26F2C.BEC708A6@kalifornia.com>; from david@kalifornia.com on Wed, Sep 27, 2000 at 03:05:33PM -0700
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, Sep 27, 2000 at 03:05:33PM -0700, David Ford wrote:
> Netscape sent it multipart because he chose both text and html for the
> message.  The message was sent as both text and html.  This allows for the
> reader to choose plain or 'enriched' viewing.  This is having it both
> ways.  People who gripe about enriched content can read the plain text.
> People who want the markup can view it as well.

It also uses a lot more bandwidth.  It is unnecessary.  Please kill it.

> -d

	slainte mhath, RGB
- -- 
Richard Guy Briggs -- PGP key available            Auto-Free Ottawa! Canada
<www.conscoop.ottawa.on.ca/rgb/>                       <www.flora.org/afo/>
Prevent Internet Wiretapping!        --        FreeS/WAN:<www.freeswan.org>
Thanks for voting Green! -- <green.ca>      Marillion:<www.marillion.co.uk>

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBOdJ6St+sBuIhFagtAQHw9AQAr934PrJfsOxrPCh7Jw7yoEF+VmFAOvzA
oJY0VBaLZpPQiBatjD6C9ctg0xT0XGF0F6AL+uqcaIvzKn10fWHZ3pLiLOZ4nCO7
+mPWd6SLdNCNBM+KQ2fBFsCudc3gqO0K22zvhQxVxpG6flix14V/DyblUF/W6QXQ
kLGeCHEXb7A=
=DWdA
-----END PGP SIGNATURE-----

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Thu Sep 28 03:18:48 2000
Received: by humbolt.nl.linux.org id <S92301AbQI1BSW>;
	Thu, 28 Sep 2000 03:18:22 +0200
Received: from cpu2747.adsl.bellglobal.com ([207.236.55.216]:48624 "EHLO
        grendel.conscoop.ottawa.on.ca") by humbolt.nl.linux.org with ESMTP
	id <S92297AbQI1BRq>; Thu, 28 Sep 2000 03:17:46 +0200
Received: (from rgb@localhost)
	by grendel.conscoop.ottawa.on.ca (8.9.0/8.9.0) id VAA12100;
	Wed, 27 Sep 2000 21:15:21 -0400
Date:   Wed, 27 Sep 2000 21:15:21 -0400
From:   Richard Guy Briggs <rgb@conscoop.ottawa.on.ca>
To:     Alexander S A Kjeldaas <Alexander.Kjeldaas@fast.no>
Cc:     Richard Guy Briggs <rgb@conscoop.ottawa.on.ca>,
        Marc Mutz <Marc@Mutz.com>,
        Peter van Hove <peter.van.hove@mind.be>,
        linux-crypto <linux-crypto@nl.linux.org>
Subject: Re: Hardware crypto
Message-ID: <20000927211521.Q28566@grendel.conscoop.ottawa.on.ca>
References: <20000927121809.A13379@mind.be> <39D1F857.D049BDC7@Mutz.com> <20000927175204.A75897@midten.fast.no> <20000927121717.Z28566@grendel.conscoop.ottawa.on.ca> <20000927232532.B87315@midten.fast.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20000927232532.B87315@midten.fast.no>; from Alexander.Kjeldaas@fast.no on Wed, Sep 27, 2000 at 11:25:32PM +0200
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, Sep 27, 2000 at 11:25:32PM +0200, Alexander S A Kjeldaas wrote:
> On Wed, Sep 27, 2000 at 12:17:17PM -0400, Richard Guy Briggs wrote:
> > On Wed, Sep 27, 2000 at 05:52:04PM +0200, Alexander S A Kjeldaas wrote:
> > > I think there are some interesting issues to be solved when we want to
> > > get hardware crypto cards running under Linux.  For one, we want to
> > > have a queue of processing requests for the device instead of having a
> > > synchronous interface like most crypto libraries offer.  We also
> > > probably want to use the CPU if the queue starts to have too many
> > > entries, or load-balance between several cards, so we need a
> > > "crypto-provider" concept.  Also, for programmable crypto-cards we
> > > might want to consider the cost of switching ciphers on the card when
> > > choosing which requests should be done by which cards/CPU.  This will
> > > be interesting to look at when the first drivers emerge.
> > 
> > I completely agree that it should be queue-based.  SMP is the other
> > obvious reason for a queue.
> > 
> > Alan Cox has publicly stated that he thinks this is the right way to
> > do things, but at the moment, asynchrony and queues for this type of
> > processing will be a big challenge to accomplish this in the present
> > Linux kernels.  
> 
> Could you expand on some of the issues?  Are the problems related to
> where you are allowed to sleep in the tcp/ip stack?  The part of
> creating the async crypto API seems doable.

I don't know, I would have to check back with Alan on this one...

> astor
> 
> -- 
> Alexander Kjeldaas                Mail:  astor@fast.no
> finger astor@master.kernel.org for OpenPGP key.
> 
> Linux-crypto:  cryptography in and on the Linux system
> Archive:       http://mail.nl.linux.org/linux-crypto/

	slainte mhath, RGB
- -- 
Richard Guy Briggs -- PGP key available            Auto-Free Ottawa! Canada
<www.conscoop.ottawa.on.ca/rgb/>                       <www.flora.org/afo/>
Prevent Internet Wiretapping!        --        FreeS/WAN:<www.freeswan.org>
Thanks for voting Green! -- <green.ca>      Marillion:<www.marillion.co.uk>

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBOdKbp9+sBuIhFagtAQH+NQP/e4Kt2jpy4kEu0gTlUhryCbgtZ7srcZdY
awY4kbGSV+qUYtm8+zP3txLZq2VgFdwxyjEUC0QU4quTaJhITdoBDc3A3ECoQqJU
9KP+lI8RIhM0N8be+qvcH6nCreHHy8xiTEkF8+Cd7lSRk4+GuRM/AQqW8xUBwG3e
Mnw/8jB9MRA=
=JFUs
-----END PGP SIGNATURE-----

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Thu Sep 28 10:42:24 2000
Received: by humbolt.nl.linux.org id <S92183AbQI1Ils>;
	Thu, 28 Sep 2000 10:41:48 +0200
Received: from midten.fast.no ([213.188.8.11]:18960 "EHLO midten.fast.no")
	by humbolt.nl.linux.org with ESMTP id <S92164AbQI1IlM>;
	Thu, 28 Sep 2000 10:41:12 +0200
Received: (from astor@localhost)
	by midten.fast.no (8.9.3/8.9.3) id KAA08233
	for linux-crypto@nl.linux.org; Thu, 28 Sep 2000 10:41:10 +0200 (CEST)
Date:   Thu, 28 Sep 2000 10:41:10 +0200
From:   Alexander S A Kjeldaas <Alexander.Kjeldaas@fast.no>
To:     linux-crypto@nl.linux.org
Subject: 2.2.17.6
Message-ID: <20000928104109.B75897@midten.fast.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.95.4i
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

ChangeLog:

	* International kernel patch 2.2.17.6 released.

	* Twofish implementation added. Patch from Marc Mutz
	<marc@mutz.com>.

	* loop_gen.c cleanups + plugged memory leak by Marc Mutz
	<marc@mutz.com>.

	* Configure.help updates. Patch from Marc Mutz <marc@mutz.com>

	* New script crypto/testing/aes-test from Marc Mutz tests ciphers
	based on the known-answer test values in NIST format.

	* crypto/testing/speed.c used weak DES-keys for speed-testing. 
	Fixed by patch from Gisle Sælensminde <gisle@ii.uib.no>.


astor

-- 
Alexander Kjeldaas                Mail:  astor@fast.no
finger astor@master.kernel.org for OpenPGP key.

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Thu Sep 28 17:57:23 2000
Received: by humbolt.nl.linux.org id <S92224AbQI1P4s>;
	Thu, 28 Sep 2000 17:56:48 +0200
Received: from eik.ii.uib.no ([129.177.16.3]:3765 "EHLO ii.uib.no")
	by humbolt.nl.linux.org with ESMTP id <S92211AbQI1P4S> convert rfc822-to-8bit;
	Thu, 28 Sep 2000 17:56:18 +0200
Received: from lomvi.ii.uib.no [129.177.17.40] 
	by ii.uib.no with esmtp (Exim 3.03)
	id 13eg2v-0006u0-00 
	for <linux-crypto@nl.linux.org>; Thu, 28 Sep 2000 17:56:29 +0200
Received: (from gisle@localhost)
	by lomvi.ii.uib.no (8.9.3+Sun/8.9.3) id RAA02484;
	Thu, 28 Sep 2000 17:56:14 +0200 (MEST)
Date:   Thu, 28 Sep 2000 17:56:13 +0200 (MEST)
From:   Gisle S{lensminde <gisle@ii.uib.no>
To:     linux-crypto@nl.linux.org
Subject: Assembly implementation for the linux kryptoapi.
In-Reply-To: <39D22C4E.6EFB79AA@Mutz.com>
Message-ID: <Pine.SOL.4.21.0009272258170.13990-100000@apal.ii.uib.no>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list


I'm looking a bit on the posibility to make assembly versions of
some of the cipers (3DES, the AES candidates), but before I do 
a major effort on this area, do anyone know about implementations
that is GPL-compatible, or written by people that is willing to 
realese the code as such. 

As a note, I copied the assembly implementation of blowfish from cipe into
the crypto API. To my surprise, the it showed not to be any faster than
the existion C implementation. I also tried some tricks to get it faster,
but it did not help. I have not tried the IDEA implementation.




--
Gisle Sælensminde ( gisle@ii.uib.no )   

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly
overhead. (from RFC 1925)




Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Thu Sep 28 18:29:04 2000
Received: by humbolt.nl.linux.org id <S92225AbQI1Q2j>;
	Thu, 28 Sep 2000 18:28:39 +0200
Received: from mail2.uni-bielefeld.de ([129.70.4.90]:15092 "EHLO
        mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP
	id <S92211AbQI1Q2M>; Thu, 28 Sep 2000 18:28:12 +0200
Received: from Mutz.com (ppp36-194.hrz.uni-bielefeld.de [129.70.36.194])
 by mail.uni-bielefeld.de
 (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6)
 with ESMTP id <0G1L00L4WV2XFL@mail.uni-bielefeld.de> for
 linux-crypto@nl.linux.org; Thu, 28 Sep 2000 18:28:10 +0200 (MET DST)
Date:   Thu, 28 Sep 2000 13:03:05 +0000
From:   Marc Mutz <Marc@Mutz.com>
Subject: Re: lista
To:     david+validemail@kalifornia.com
Cc:     Maicon Triches <maicon@sul-e.com.br>, linux-crypto@nl.linux.org
Message-id: <39D34189.B337F4FB@Mutz.com>
Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics
MIME-version: 1.0
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <01b101c028c2$b9de6460$97c809c0@sule.com.br>
 <39D26692.6CD2A8E0@Mutz.com> <39D26F2C.BEC708A6@kalifornia.com>
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

David Ford wrote:
> 
> Netscape sent it multipart because he chose both text and html for the
> message.  The message was sent as both text and html.  This allows for the
> reader to choose plain or 'enriched' viewing.  This is having it both
> ways.  People who gripe about enriched content can read the plain text.
> People who want the markup can view it as well.
> 
Have you had a look at the message? Did it include rich text formatting
and if it does, did it need to? No. It was a plain, simple message. The
vast majority of them are. And netscape contains a configuration option
to only send html mails when there actually _is_ rich content.

> It's a configuration choice issue.  What you viewed was his entire
> message, regardless of whether your reader displayed it in text or html.
> I also use NS messenger as one of my preferred readers and I'm able to
> view his message perfectly.
<snip>

Can you show me where this option is?

Marc

-- 
Marc Mutz <Marc@Mutz.com>        http://marc.mutz.com/Encryption-HOWTO/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's:   0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)



Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Fri Sep 29 00:02:53 2000
Received: by humbolt.nl.linux.org id <S92299AbQI1WCD>;
	Fri, 29 Sep 2000 00:02:03 +0200
Received: from mail2.uni-bielefeld.de ([129.70.4.90]:25167 "EHLO
        mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP
	id <S92293AbQI1WBS>; Fri, 29 Sep 2000 00:01:18 +0200
Received: from Mutz.com (ppp36-241.hrz.uni-bielefeld.de [129.70.36.241])
 by mail.uni-bielefeld.de
 (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6)
 with ESMTP id <0G1M006AJAI2KU@mail.uni-bielefeld.de> for
 linux-crypto@nl.linux.org; Fri, 29 Sep 2000 00:01:15 +0200 (MET DST)
Date:   Thu, 28 Sep 2000 22:01:03 +0000
From:   Marc Mutz <Marc@Mutz.com>
Subject: [Encryption-HOWTO] v0.2.1 released
To:     linux-crypto@nl.linux.org
Message-id: <39D3BF9F.B7C784BE@Mutz.com>
Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics
MIME-version: 1.0
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

ChangeLog:

Small updates all over the place (IKP 2.2.17.6 now on kernel.org,
	CIPE4Win, linux-crypto ml, remount loop bug, --passfd for
	losetup and mount, FreeS/WAN 1.5, OpenSSH instead of SSH); 
Small additions all over the place (VTUN, PPTP, Cipe+Masquerading
	miniHOWTO, Credits);
Debian issues when compiling util-linux; 
A new question for Q&A: journaling filesystems (no "A" yet); 

Release Notes:
This version is a maintainance release only. It updates a bunch of small
things, nothing big, and adds another bunch. I have tried to incorporate
as many suggestions as possible without changing the document too much.
In the light of the massive publicity the Encrytion HOWTO has attracted
for the last two days, I wanted to update the discussion to the most
recent stuff. See ChangeLog for more.

Enjoy!

Marc

-- 
Marc Mutz <Marc@Mutz.com>        http://marc.mutz.com/Encryption-HOWTO/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's:   0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Fri Sep 29 18:09:25 2000
Received: by humbolt.nl.linux.org id <S92204AbQI2QIw>;
	Fri, 29 Sep 2000 18:08:52 +0200
Received: from mail2.uni-bielefeld.de ([129.70.4.90]:36197 "EHLO
        mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP
	id <S92199AbQI2QIO>; Fri, 29 Sep 2000 18:08:14 +0200
Received: from Mutz.com (ppp36-147.hrz.uni-bielefeld.de [129.70.36.147])
 by mail.uni-bielefeld.de
 (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6)
 with ESMTP id <0G1N00JO2OTKBR@mail.uni-bielefeld.de> for
 linux-crypto@nl.linux.org; Fri, 29 Sep 2000 18:08:10 +0200 (MET DST)
Date:   Fri, 29 Sep 2000 15:13:27 +0000
From:   Marc Mutz <Marc@Mutz.com>
Subject: [experimantal patch] show allowed keylengths in /proc/cipher/*
To:     linux-crypto@nl.linux.org
Message-id: <39D4B197.CE21F30C@Mutz.com>
Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics
MIME-version: 1.0
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586)
Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_3Z9VYK/E648oxv7CZlYkMQ)"
X-Accept-Language: en
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

This is a multi-part message in MIME format.

--Boundary_(ID_3Z9VYK/E648oxv7CZlYkMQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi out there!

This little patch allows /proc/cipher/* to show a bitmask of allowed
keysizes. Simple as it may ssem, it breaks the current jungle of
#define's quite thoroughly. Ciphers that want to take advantage of this
patch and actually _provide_ more than one keylength per cipher
implementation (and most ciphers could), will not be able to use the
DEFINE_CIPHER construct any more.

So what now? I'd like to remove the DEFINE_CIPHER construct althogether.
It makes defining "dumb" ciphers easy, but it obfuscates the definition
of a cipher for unexperienced (w.r.t. cipherapi) coders and interested
eyes that read the source, since the meaning of the numbers and strings
appearing in DEFINE_CIPHER is not obvious. Even when you have read over
a few cipher sources you catch yourself going back to
include/linux/crypto.h to look up what each entry means.

On the opposite, having the struct cipher_implementation populated
without the help of macros goes a long way towards transparency, because
the field identifiers show up alongside their values. Or not?

Now my inexprience with C comes up again: Is there a C construct that
shows the field identifiers even in static const definitions? Like in
perl:

%an_associative_array = {
	field1 -> value1,
	field2 -> value2,
	 :          :
}

Is there a C reference online somewhere to install locally, e.g. in
html?

Marc

-- 
Marc Mutz <Marc@Mutz.com>        http://marc.mutz.com/Encryption-HOWTO/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's:   0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)

--Boundary_(ID_3Z9VYK/E648oxv7CZlYkMQ)
Content-type: text/plain; name=proc_shows_keysizes.patch; charset=us-ascii
Content-disposition: inline; filename=proc_shows_keysizes.patch
Content-transfer-encoding: 7BIT

--- i6/crypto/cryptoapi.c	Thu Sep 28 16:29:13 2000
+++ i6-raidA0-raid1rb15.B2-ext0.0.3a/crypto/cryptoapi.c	Fri Sep 29 16:11:52 2000
@@ -218,10 +218,11 @@
 	len = sprintf(page, "cipher_id:         %d\n"
 		      "cipher_name:       %s\n"
 		      "blocksize:         %d\n"
+		      "keysize_mask:      0x%08x\n"
 		      "ivsize:            %d\n"
 		      "key_schedule_size: %d\n",
 		      ci->trans.t_id, ci->trans.t_name, 
-		      ci->blocksize,
+		      ci->blocksize, ci->key_size_mask,
 		      ci->ivsize, ci->key_schedule_size);
 	*eof=1;
 
--- i6/include/linux/crypto.h	Thu Sep 28 16:29:14 2000
+++ i6-raidA0-raid1rb15.B2-ext0.0.3a/include/linux/crypto.h	Fri Sep 29 16:19:48 2000
@@ -51,6 +51,23 @@
 #define CIPHER_cbc_DFC      (CIPHER_DFC      | CIPHER_CBC)
 #define CIPHER_cbc_RIJNDAEL (CIPHER_RIJNDAEL | CIPHER_CBC)
 
+
+#define CIPHER_KEYSIZE_ANY  0xFFFFFFFF
+#define CIPHER_KEYSIZE_NONE 0x00000000
+
+#define CIPHER_KEYSIZE_40   0x00000010
+#define CIPHER_KEYSIZE_56   0x00000040
+#define CIPHER_KEYSIZE_64   0x00000080
+#define CIPHER_KEYSIZE_80   0x00000200
+#define CIPHER_KEYSIZE_96   0x00000800
+#define CIPHER_KEYSIZE_112  0x00002000
+#define CIPHER_KEYSIZE_128  0x00008000
+#define CIPHER_KEYSIZE_160  0x00080000
+#define CIPHER_KEYSIZE_168  0x00100000
+#define CIPHER_KEYSIZE_192  0x00800000
+#define CIPHER_KEYSIZE_256  0x80000000
+
+
 #define DIGEST_NONE        0
 #define DIGEST_SUM         1
 #define DIGEST_CRC_CCITT16 2
@@ -94,7 +113,7 @@
	int blocksize;         /* in bytes */
	int ivsize;            /* in bytes */
	int key_schedule_size; /* in bytes */
+	u32 key_length_list;   /* bit 0 set = 8 bit, ... , bit 31 set = 256 bit */
	int (*encrypt)(struct cipher_context *cx, 
		       const u8 *in, u8 *out, int size);
	int (*decrypt)(struct cipher_context *cx,
@@ -110,7 +130,7 @@
 
 extern struct list_head ciphers;
 
-#define MAX_KEY_SIZE 8
+#define MAX_KEY_SIZE 8               /* 256 bit */
 #define MAX_IV_SIZE  MAX_KEY_SIZE
 
 struct cipher_context {
@@ -331,6 +351,7 @@
 	blocksize,							   \
 	ivsize,								   \
 	uppername##_KEY_SCHEDULE_SIZE,					   \
+        0x0,                                                               \
 	name##_##mode##encrypt,						   \
 	name##_##mode##decrypt,						   \
 	name##_set_key,							   \

--Boundary_(ID_3Z9VYK/E648oxv7CZlYkMQ)--

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Fri Sep 29 22:12:28 2000
Received: by humbolt.nl.linux.org id <S92299AbQI2ULV>;
	Fri, 29 Sep 2000 22:11:21 +0200
Received: from eik.ii.uib.no ([129.177.16.3]:36005 "EHLO ii.uib.no")
	by humbolt.nl.linux.org with ESMTP id <S92303AbQI2UKp> convert rfc822-to-8bit;
	Fri, 29 Sep 2000 22:10:45 +0200
Received: from apal.ii.uib.no [129.177.16.7] 
	by ii.uib.no with esmtp (Exim 3.03)
	id 13f6Uk-0003Vl-00 
	for <linux-crypto@nl.linux.org>; Fri, 29 Sep 2000 22:10:58 +0200
Received: (from gisle@localhost)
	by apal.ii.uib.no (8.8.8+Sun/8.8.7) id WAA02527;
	Fri, 29 Sep 2000 22:10:43 +0200 (MET DST)
Date:   Fri, 29 Sep 2000 22:10:43 +0200 (MET DST)
From:   Gisle S{lensminde <gisle@ii.uib.no>
To:     linux-crypto@nl.linux.org
Subject: AES will be announced monday.
Message-ID: <Pine.SOL.4.21.0009292208420.2470-100000@apal.ii.uib.no>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list


See: http://csrc.nist.gov/encryption/aes/

TIME:  11:00 a.m. Eastern Daylight Time.

etc.

--
Gisle Sælensminde ( gisle@ii.uib.no )   

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly
overhead. (from RFC 1925)


Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Fri Sep 29 23:53:43 2000
Received: by humbolt.nl.linux.org id <S92306AbQI2VxH>;
	Fri, 29 Sep 2000 23:53:07 +0200
Received: from mail2.uni-bielefeld.de ([129.70.4.90]:9109 "EHLO
        mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP
	id <S92235AbQI2Vwl>; Fri, 29 Sep 2000 23:52:41 +0200
Received: from Mutz.com (ppp36-130.hrz.uni-bielefeld.de [129.70.36.130])
 by mail.uni-bielefeld.de
 (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6)
 with ESMTP id <0G1O004GB4RIQK@mail.uni-bielefeld.de> for
 linux-crypto@nl.linux.org; Fri, 29 Sep 2000 23:52:31 +0200 (MET DST)
Date:   Fri, 29 Sep 2000 21:52:01 +0000
From:   Marc Mutz <Marc@Mutz.com>
Subject: Re: AES will be announced monday.
To:     Gisle S{lensminde <gisle@ii.uib.no>
Cc:     linux-crypto@nl.linux.org
Message-id: <39D50F01.7419EB7D@Mutz.com>
Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics
MIME-version: 1.0
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <Pine.SOL.4.21.0009292208420.2470-100000@apal.ii.uib.no>
Sender: owner-linux-crypto@nl.linux.org
Precedence: bulk
Return-Path: <owner-linux-crypto@nl.linux.org>
X-Orcpt: rfc822;linux-crypto-list

Gisle S{lensminde wrote:
> 
> See: http://csrc.nist.gov/encryption/aes/
> 
> TIME:  11:00 a.m. Eastern Daylight Time.
> 
<snip>

Anyone wants to bet? I'd say one of Twofish, Serpent, Rijndael. To be
precise, I'd say Serpent. Because it is fastest in HW and the most
secure. Software performance was never really high on NISTs list (see
DES). Twofish, while equally secure as Serpent is very complicated and
Rijndael can only be elected if the number of rounds is increased, which
implies a relative performance loss w.r.t. the other two.

RC6, though fast and simple, is patented and I don't like that so I
don't want that. MARS is inefficient everywhere and hasn't got a single
outstanding advantage over the others.

Sssssssserpent.

Marc

-- 
Marc Mutz <Marc@Mutz.com>        http://marc.mutz.com/Encryption-HOWTO/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's:   0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)


Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

From owner-linux-crypto@nl.linux.org Sat Sep 30 00:18:31 2000
Received: by humbolt.nl.linux.org id <S92320AbQI2WSC>;
	Sat, 30 Sep 2000 00:18:02 +0200
Received: from [207.159.118.1] ([207.159.118.1]:9284 "EHLO ead42.ead.dsa.com")
	by humbolt.nl.linux.org with ESMTP id <S92319AbQI2WRZ>;
	Sat, 30 Sep 2000 00:17:25 +0200
Received: (from uucp@localhost)
	by ead42.ead.dsa.com (8.8.7/