* Re: [Design] [PATCH] USAGI IPsec
2002-10-12 17:11 ` [Design] [PATCH] USAGI IPsec Sandy Harris
@ 2002-10-12 2:27 ` David S. Miller
2002-10-19 1:40 ` Zach Brown
0 siblings, 1 reply; 12+ messages in thread
From: David S. Miller @ 2002-10-12 2:27 UTC (permalink / raw)
To: sandy; +Cc: mk, linux-kernel, design, usagi
From: Sandy Harris <sandy@storm.ca>
Date: Sat, 12 Oct 2002 10:11:07 -0700
Please remove DES as it is insecure. For discussion, see:
http://www.freeswan.org/freeswan_trees/freeswan-1.98b/doc/politics.html#desnotsecure
It's fine for testing purposes, leave it in.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Design] [PATCH] USAGI IPsec
[not found] <m3k7kpjt7c.wl@karaba.org>
@ 2002-10-12 17:11 ` Sandy Harris
2002-10-12 2:27 ` David S. Miller
2002-10-21 14:46 ` Sandy Harris
1 sibling, 1 reply; 12+ messages in thread
From: Sandy Harris @ 2002-10-12 17:11 UTC (permalink / raw)
To: Mitsuru KANDA; +Cc: linux-kernel, design, usagi
Mitsuru KANDA wrote:
>Hello Linux kernel network maintainers,
>
>I'm a member of USAGI project.
>
>
[snip]
>2. Cipher/Digest Algorithms
>
> Supported algorithms:
> Ciphers: DES, 3DES and AES
> Digests: MD5 and SHA1
>
> We use CryptoAPI as cipher/digest algorithm.
> - CryptoAPI
> http://www.kerneli.org/
>
>
Please remove DES as it is insecure. For discussion, see:
http://www.freeswan.org/freeswan_trees/freeswan-1.98b/doc/politics.html#desnotsecure
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Design] [PATCH] USAGI IPsec
2002-10-12 2:27 ` David S. Miller
@ 2002-10-19 1:40 ` Zach Brown
0 siblings, 0 replies; 12+ messages in thread
From: Zach Brown @ 2002-10-19 1:40 UTC (permalink / raw)
To: David S. Miller; +Cc: sandy, mk, linux-kernel, design, usagi
> It's fine for testing purposes, leave it in.
absolutely. it could also be needed for interoperability, or many other
valid uses that might not depend on its sheer strength as a cipher.
"but you shouldn't be interoperating with things that are insecure!"
blah blah blah. that is not the kernel's decision to make. meaningful
security is defined by much more than context-free assertions. warn
against its naive use, avoid it being a default, but allow the clued to
use it easily when it makes sense.
- z
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Design] [PATCH] USAGI IPsec
2002-10-21 14:46 ` Sandy Harris
@ 2002-10-21 2:41 ` David S. Miller
2002-10-21 3:42 ` YOSHIFUJI Hideaki / 吉藤英明
2002-10-21 7:34 ` [CryptoAPI-devel] " Herbert Valerio Riedel
2002-10-21 4:22 ` Andre Hedrick
1 sibling, 2 replies; 12+ messages in thread
From: David S. Miller @ 2002-10-21 2:41 UTC (permalink / raw)
To: Sandy Harris
Cc: Mitsuru KANDA, linux-kernel, netdev, cryptoapi-devel, design, usagi
> Is this code being checked in to the mainline kernel? Or becoming part
> of the
> CryptoAPI patch set? Bravo, in either case.
We will be incorporating lots of ideas and small code pieces
from USAGI's work, but most of the core engine will be a new
implementation.
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.
It is intended that this work will be complete (it isn't done as I
type this) and pushed to Linus upon his return from vacation.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Design] [PATCH] USAGI IPsec
2002-10-21 2:41 ` David S. Miller
@ 2002-10-21 3:42 ` YOSHIFUJI Hideaki / 吉藤英明
2002-10-21 7:34 ` [CryptoAPI-devel] " Herbert Valerio Riedel
1 sibling, 0 replies; 12+ messages in thread
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2002-10-21 3:42 UTC (permalink / raw)
To: davem; +Cc: sandy, mk, linux-kernel, netdev, cryptoapi-devel, design, usagi
In article <1035168066.4817.1.camel@rth.ninka.net> (at 20 Oct 2002 19:41:06 -0700), "David S. Miller" <davem@rth.ninka.net> says:
> > Is this code being checked in to the mainline kernel? Or becoming part
> > of the
> > CryptoAPI patch set? Bravo, in either case.
>
> We will be incorporating lots of ideas and small code pieces
> from USAGI's work, but most of the core engine will be a new
> implementation.
:
> It is intended that this work will be complete (it isn't done as I
> type this) and pushed to Linus upon his return from vacation.
Well, we'd like to learn more about your ideas...
Source code is our friend.
If you don't mind, would you send "as-is" codes to us?
--
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Design] [PATCH] USAGI IPsec
2002-10-21 14:46 ` Sandy Harris
2002-10-21 2:41 ` David S. Miller
@ 2002-10-21 4:22 ` Andre Hedrick
1 sibling, 0 replies; 12+ messages in thread
From: Andre Hedrick @ 2002-10-21 4:22 UTC (permalink / raw)
To: Sandy Harris
Cc: Mitsuru KANDA, linux-kernel, netdev, cryptoapi-devel, design, usagi
It is all bolted togather and does not need to be piece from random parts.
Thus in simple reality, it is superior.
Maybe FreeS/WAN will get busy and compete or die.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Mon, 21 Oct 2002, Sandy Harris wrote:
> Mitsuru KANDA wrote:
>
> >Hello Linux kernel network maintainers,
> >
> >I'm a member of USAGI project.
> >
> >In IPv6 specifications, IPsec is mandatory.
> >
> >We implemented IPsec for Linux IP stack.
> >
> >At present, our implementation includes:
> > PF_KEY V2 interface,
> > Security Association Database and
> > Security Policy Database for whole IP versions,
> > IPsec for IPv6,(transport, tunnel mode),
> > IPsec for IPv4 (transport mode),
> >
> >Would you mind checking it ?
> >
> Is this code being checked in to the mainline kernel? Or becoming part
> of the
> CryptoAPI patch set? Bravo, in either case.
>
> How does that affect FreeS/WAN development?
>
> >
> >
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [CryptoAPI-devel] Re: [Design] [PATCH] USAGI IPsec
2002-10-21 2:41 ` David S. Miller
2002-10-21 3:42 ` YOSHIFUJI Hideaki / 吉藤英明
@ 2002-10-21 7:34 ` Herbert Valerio Riedel
2002-10-22 2:27 ` Sandy Harris
2002-10-22 5:02 ` Jari Ruusu
1 sibling, 2 replies; 12+ messages in thread
From: Herbert Valerio Riedel @ 2002-10-21 7:34 UTC (permalink / raw)
To: David S. Miller
Cc: Sandy Harris, Mitsuru KANDA, linux-kernel, netdev,
cryptoapi-devel, design, usagi
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...
...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 ;-)
regards,
--
Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840
Email: hvr@hvrlab.org / Finger hvr@gnu.org for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F
4142
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Design] [PATCH] USAGI IPsec
[not found] <m3k7kpjt7c.wl@karaba.org>
2002-10-12 17:11 ` [Design] [PATCH] USAGI IPsec Sandy Harris
@ 2002-10-21 14:46 ` Sandy Harris
2002-10-21 2:41 ` David S. Miller
2002-10-21 4:22 ` Andre Hedrick
1 sibling, 2 replies; 12+ messages in thread
From: Sandy Harris @ 2002-10-21 14:46 UTC (permalink / raw)
To: Mitsuru KANDA; +Cc: linux-kernel, netdev, cryptoapi-devel, design, usagi
Mitsuru KANDA wrote:
>Hello Linux kernel network maintainers,
>
>I'm a member of USAGI project.
>
>In IPv6 specifications, IPsec is mandatory.
>
>We implemented IPsec for Linux IP stack.
>
>At present, our implementation includes:
> PF_KEY V2 interface,
> Security Association Database and
> Security Policy Database for whole IP versions,
> IPsec for IPv6,(transport, tunnel mode),
> IPsec for IPv4 (transport mode),
>
>Would you mind checking it ?
>
Is this code being checked in to the mainline kernel? Or becoming part
of the
CryptoAPI patch set? Bravo, in either case.
How does that affect FreeS/WAN development?
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [CryptoAPI-devel] Re: [Design] [PATCH] USAGI IPsec
2002-10-21 7:34 ` [CryptoAPI-devel] " Herbert Valerio Riedel
@ 2002-10-22 2:27 ` Sandy Harris
2002-10-22 5:02 ` Jari Ruusu
1 sibling, 0 replies; 12+ messages in thread
From: Sandy Harris @ 2002-10-22 2:27 UTC (permalink / raw)
To: Herbert Valerio Riedel
Cc: David S. Miller, Mitsuru KANDA, linux-kernel, netdev,
cryptoapi-devel, design, usagi
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...
>
>...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 ;-)
>
>regards,
>
>
I think the long term goal should be to get good crypto, at least IPsec
and disk encryption,
into the mainline, standard Linux kernel. Also ipv6 support. Projects
like FreeS/WAN, USAGI
and cryptoapi seem necessary for getting the work done in the first
place, but eventually you
want to do away with patch sets and just have all the good stuff built
in to the kernel.
One payoff is integration. As I understand it, a current fully-patched
kernel has either MD-5
or SHA-1 in the /dev/random driver, both in FreeS/WAN, and possibly both
of those plus a
few other hashes in the CryptoAPI stuff. This is silly. The obvious fix
is for everyone to use
the CryptoAPI hashes and ciphers.
However, crypto is a special case. The US government (among others) has
a long history
of restricting it and, much as we would like to see good crypto in the
standard kernel,
there's a good case for being very careful to keep code out of their
clutches.
My suggestion would be that the standard kernel incorporate only one
good hash
and one good cipher, specifically AES and SHA-256 since (last I looked)
those
were en route to becoming requirements for IPsec. Let the FreeS/WAN and
CryptoAPI folk -- outside the US -- maintain the other ciphers and
hashes. That
way we have a fallback position if the US goes back to being viciously
restrictive.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [CryptoAPI-devel] Re: [Design] [PATCH] USAGI IPsec
2002-10-21 7:34 ` [CryptoAPI-devel] " Herbert Valerio Riedel
2002-10-22 2:27 ` Sandy Harris
@ 2002-10-22 5:02 ` Jari Ruusu
2002-10-24 14:50 ` Jean-Luc Cooke
1 sibling, 1 reply; 12+ messages in thread
From: Jari Ruusu @ 2002-10-22 5:02 UTC (permalink / raw)
To: Herbert Valerio Riedel
Cc: David S. Miller, Sandy Harris, Mitsuru KANDA, linux-kernel,
netdev, cryptoapi-devel, design, usagi
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 <jari.ruusu@pp.inet.fi>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [CryptoAPI-devel] Re: [Design] [PATCH] USAGI IPsec
2002-10-22 5:02 ` Jari Ruusu
@ 2002-10-24 14:50 ` Jean-Luc Cooke
2002-10-28 13:55 ` JuanJo Ciarlante
0 siblings, 1 reply; 12+ messages in thread
From: Jean-Luc Cooke @ 2002-10-24 14:50 UTC (permalink / raw)
To: Jari Ruusu
Cc: Herbert Valerio Riedel, David S. Miller, Sandy Harris,
Mitsuru KANDA, linux-kernel, netdev, cryptoapi-devel, design,
usagi
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [CryptoAPI-devel] Re: [Design] [PATCH] USAGI IPsec
2002-10-24 14:50 ` Jean-Luc Cooke
@ 2002-10-28 13:55 ` JuanJo Ciarlante
0 siblings, 0 replies; 12+ messages in thread
From: JuanJo Ciarlante @ 2002-10-28 13:55 UTC (permalink / raw)
To: Jean-Luc Cooke
Cc: Jari Ruusu, Herbert Valerio Riedel, David S. Miller,
Sandy Harris, Mitsuru KANDA, linux-kernel, netdev,
cryptoapi-devel, design, usagi
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 #
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2002-10-28 13:51 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <m3k7kpjt7c.wl@karaba.org>
2002-10-12 17:11 ` [Design] [PATCH] USAGI IPsec Sandy Harris
2002-10-12 2:27 ` David S. Miller
2002-10-19 1:40 ` Zach Brown
2002-10-21 14:46 ` Sandy Harris
2002-10-21 2:41 ` David S. Miller
2002-10-21 3:42 ` YOSHIFUJI Hideaki / 吉藤英明
2002-10-21 7:34 ` [CryptoAPI-devel] " Herbert Valerio Riedel
2002-10-22 2:27 ` Sandy Harris
2002-10-22 5:02 ` Jari Ruusu
2002-10-24 14:50 ` Jean-Luc Cooke
2002-10-28 13:55 ` JuanJo Ciarlante
2002-10-21 4:22 ` Andre Hedrick
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).