Herbert Valerio Riedel wrote:
> On Mon, 2002-10-21 at 04:41, David S. Miller wrote:
> > A completely new CryptoAPI subsystem has been implemented so that
> > full lists of page vectors can be passed into the ciphers, which is
> > necessary for a clean IPSEC implementation.
>
> oh... nice to learn about your plans (so late) at all ;-)
>
> well, it would be cool if you'd cooperate (or at least share
> information) with us (the official cryptoapi project ;-), as we're open
> for the design requirements of the next generation cryptoapi...
Official cryptoapi? Define official.
> ...otherwise this may render the kerneli.org/cryptoapi effort completely
> useless :-/ ...of course, if it's your long term goal to take the
> cryptoapi development away from kerneli.org, I'd like to know too ;-)
kerneli.org/cryptoapi _is_ useless joke for many needs. Fortunately other
people are able to see the limitations/sillyness of kerneli.org/cryptoapi:
1) You are trying to replace link/insmod time overhead with runtime
overhead + unnecessary bloat.
2) No direct link access to low level cipher functions or higher level
functions.
3) No clean way to replace cipher code with processor type optimized
assembler implementations.
Regards,
Jari Ruusu <[email protected]>
On Tue, Oct 22, 2002 at 08:02:00AM +0300, Jari Ruusu wrote:
> kerneli.org/cryptoapi _is_ useless joke for many needs. Fortunately other
> people are able to see the limitations/sillyness of kerneli.org/cryptoapi:
>
> 1) You are trying to replace link/insmod time overhead with runtime
> overhead + unnecessary bloat.
> 2) No direct link access to low level cipher functions or higher level
> functions.
> 3) No clean way to replace cipher code with processor type optimized
> assembler implementations.
Jari has a few points here. But the "killer" functionalities are all there
IMHO. Low-level assembler implementations are over-rated, again IMHO. The
performance difference between C and ASM is at most 50%. 1ms vs 1.5 ms.
Even if you've got a large payload on the rare occation (>5MB) block ciphers
are quite fast for 95% of applications
JLC
--
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6
C: 613.263.2983
On Thu, Oct 24, 2002 at 10:50:26AM -0400, Jean-Luc Cooke wrote:
> On Tue, Oct 22, 2002 at 08:02:00AM +0300, Jari Ruusu wrote:
> > kerneli.org/cryptoapi _is_ useless joke for many needs. Fortunately other
> > people are able to see the limitations/sillyness of kerneli.org/cryptoapi:
> >
> > 1) You are trying to replace link/insmod time overhead with runtime
> > overhead + unnecessary bloat.
> > 2) No direct link access to low level cipher functions or higher level
> > functions.
> > 3) No clean way to replace cipher code with processor type optimized
> > assembler implementations.
>
> Jari has a few points here. But the "killer" functionalities are all there
> IMHO. Low-level assembler implementations are over-rated, again IMHO. The
> performance difference between C and ASM is at most 50%. 1ms vs 1.5 ms.
> Even if you've got a large payload on the rare occation (>5MB) block ciphers
> are quite fast for 95% of applications
According to my tests, AES ASM has given me _2x_ speed boost over C; this
fact has re-written freeswan CPU/bandwidth empirical formula to peak at
CPU [MHz] ~= BW [Mbit/s] * 10 (instead of 25)
This boost has allowed my old Cyrix-6x86 120MHz to be my 802.11b gateway =)
--Juanjo freeswan algo: AES (+others), SHA2, MODP2048-4096
selectable algorithms support for Phase1 and 2.
http://www.irrigacion.gov.ar/juanjo/ipsec/
# Juan Jose Ciarlante (JuanJo PGP) jjo ;at; mendoza.gov.ar #
# Key fingerprint = 76 60 A5 76 FD D2 53 E3 50 C7 90 20 22 8C F1 2D #