Linux crypto?

Linux crypto?

[Myrddin Ambrosius]

I noticed that Motorola has published a set of tech
docs for their S1-range of crypto co-processors, which
look pretty comprehensive. (The 190 looks to be a very
nice chip, which -as best as I can tell- just plugs
straight onto a PCI bus.) Other co-pro manufacturers
(such as HIFN) seem to also have humungous tech
manuals for their crypto chips.

Is anyone working on drivers for these beasties?

Alongside that, I also noticed that many manufacturers
(again, Motorola and HIFN seem to top the list)
working on network accelerator chips - some h/w
L2/L3/L4 queueing/filtering, rudimentary packet
mangling, etc. Linux already has most of the
interesting stuff from the chips I've looked at, and
in most places is way more advanced in what it can do/
Given the ipfilter design, would there be any way to
use those chips as an additional networking layer?
(And, just as importantly, would there be any point?)

Secondly, I've taken a look at the "International
Kernel Patch" for Linux. I have finally found a
(fairly) mainstream kernel patch that is updated less
frequently than my own FOLK patch! Also, nobody seems
to use it. Packages that use crypto seem to steer
towards openssl, rsa-ref, mcrypt/mhash/gcrypt, gnutls,
and/or or private implementations. Even FreeS/WAN and
USAGI take no advantage of anything in the IKP.

Ignoring, for a second, the US export laws (which are
no longer an issue, anyway), is there some fundamental
reason why the IKP seems to be ignored? If there is,
then does anyone know of any re-design/re-write
effort?


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

Re: Linux crypto?

[Alan Cox]

> I noticed that Motorola has published a set of tech
> docs for their S1-range of crypto co-processors, which
> look pretty comprehensive. (The 190 looks to be a very
> nice chip, which -as best as I can tell- just plugs
> straight onto a PCI bus.) Other co-pro manufacturers
> (such as HIFN) seem to also have humungous tech
> manuals for their crypto chips.
> 
> Is anyone working on drivers for these beasties?

You might want to check on the apache and openssl lists. A lot of
crypto drivers are handled from userspace directly or with modules
that don't hit the base kernel.

> Given the ipfilter design, would there be any way to
> use those chips as an additional networking layer?
> (And, just as importantly, would there be any point?)

Some of that probably can be offloaded. You'd need code (preferably in
the user tools) that can compute if a given path through the ipchains
rules is expressable in the hardware and if so to enable it. In terms
of things like flow control and other magic try netdev@oss.sgi.com. Dave
and Jamal get very excited when they talk about NAPI but it just makes
my head hurt 8)

> Ignoring, for a second, the US export laws (which are
> no longer an issue, anyway), is there some fundamental
> reason why the IKP seems to be ignored? If there is,
> then does anyone know of any re-design/re-write
> effort?

What of it do you actually need in kernel space - encrypted file systems
certainly ought to be there but are not very well handled in Linux proper
right now - but anything else ?

Re: Linux crypto?

[Trond Myklebust]

>>>>> " " == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

     > What of it do you actually need in kernel space - encrypted
     > file systems certainly ought to be there but are not very well
     > handled in Linux proper right now - but anything else ?

Authentication...

At the Connectathon in February, we got as far as setting up a working
test machine for the RPCSEC_GSS kerberos V5 authentication on the NFS
and RPC clients. AFAIK, Andy is currently working on adding support
for SPKM auth. and data encryption.

I'm not sure exactly which ciphers we need for all this (Andy can
perhaps comment?) but we'd definitely want to see part of the crypto
patches go into the standard kernel at some point soon.

Cheers,
  Trond

Re: Linux crypto?

[Tobias Ringstrom]

On Wed, 22 May 2002, Alan Cox wrote:

> What of it do you actually need in kernel space - encrypted file systems
> certainly ought to be there but are not very well handled in Linux proper
> right now - but anything else ?

IPsec.

/Tobias

Re: Linux crypto?

[Alan Cox]

> On Wed, 22 May 2002, Alan Cox wrote:
> 
> > What of it do you actually need in kernel space - encrypted file systems
> > certainly ought to be there but are not very well handled in Linux proper
> > right now - but anything else ?
> 
> IPsec.

At the moment there doesn't appear to be an IPsec stack we can merge however

Re: Linux crypto?

[Thomas 'Dent' Mirlacher]

On Fri, 24 May 2002, Alan Cox wrote:

> > On Wed, 22 May 2002, Alan Cox wrote:
> > 
> > > What of it do you actually need in kernel space - encrypted file systems
> > > certainly ought to be there but are not very well handled in Linux proper
> > > right now - but anything else ?
> > 
> > IPsec.
> 
> At the moment there doesn't appear to be an IPsec stack we can merge however

what about freeswan - with some cleanups?

	tm

-- 
in some way i do, and in some way i don't.

Re: Linux crypto?

[David S. Miller]

   From: "Thomas 'Dent' Mirlacher" <dent@cosy.sbg.ac.at>
   Date: Fri, 24 May 2002 19:32:48 +0200 (MET DST)
   
   what about freeswan - with some cleanups?

They won't let me (or any other US citizen) make any edits to any of
the ipsec sources if it were to be added to the main tree.  That's
unacceptable because it means that effectively I cannot maintain the
networking.

Re: Linux crypto?

[Thomas 'Dent' Mirlacher]

On Fri, 24 May 2002, David S. Miller wrote:

>    From: "Thomas 'Dent' Mirlacher" <dent@cosy.sbg.ac.at>
>    Date: Fri, 24 May 2002 19:32:48 +0200 (MET DST)
>    
>    what about freeswan - with some cleanups?
> 
> They won't let me (or any other US citizen) make any edits to any of
> the ipsec sources if it were to be added to the main tree.  That's
> unacceptable because it means that effectively I cannot maintain the
> networking.

well the _big_ thing the freeswan people are afraid of, is exactly the
crypto laws in the us.

- here is a proposal which should be acceptable (at least i hope so :)

what about taking out the libdes stuff, and make it available from
elsewhere, and hook it into the kernel as a module?
the main kernel could come with a null crypto implementation - which
makes no sense to use, but it will allow to meintain the whole system
without having to worry about the crypto stuff per se (this shouldn't
change very much in any case)

	any comments?

		tm

-- 
in some way i do, and in some way i don't.

Re: Linux crypto?

[David S. Miller]

   From: "Thomas 'Dent' Mirlacher" <dent@cosy.sbg.ac.at>
   Date: Fri, 24 May 2002 19:42:45 +0200 (MET DST)
   
   what about taking out the libdes stuff, and make it available from
   elsewhere, and hook it into the kernel as a module?
   the main kernel could come with a null crypto implementation - which
   makes no sense to use, but it will allow to meintain the whole system
   without having to worry about the crypto stuff per se (this shouldn't
   change very much in any case)

The US laws cover even things that are meant to allow crypto.

Re: Linux crypto?

[Thomas 'Dent' Mirlacher]

On Fri, 24 May 2002, David S. Miller wrote:

>    From: "Thomas 'Dent' Mirlacher" <dent@cosy.sbg.ac.at>
>    Date: Fri, 24 May 2002 19:42:45 +0200 (MET DST)
>    
>    what about taking out the libdes stuff, and make it available from
>    elsewhere, and hook it into the kernel as a module?
>    the main kernel could come with a null crypto implementation - which
>    makes no sense to use, but it will allow to meintain the whole system
>    without having to worry about the crypto stuff per se (this shouldn't
>    change very much in any case)
> 
> The US laws cover even things that are meant to allow crypto.

well, but if you take that by the word, is means you cannot export _any_
hooks from the kernel (like the sycall table), because it would enable
someone to place some crytography in there (thinking of read and write
calls)

	tm
-- 
in some way i do, and in some way i don't.

Re: Linux crypto?

[Myrddin Ambrosius]

--- Thomas 'Dent' Mirlacher <dent@cosy.sbg.ac.at>
wrote:
> On Fri, 24 May 2002, David S. Miller wrote:
> well, but if you take that by the word, is means you
> cannot export _any_
> hooks from the kernel (like the sycall table),
> because it would enable
> someone to place some crytography in there (thinking
> of read and write
> calls)

Shhhhh! The RIAA might be listening! :)

Seriously, as I understand it, provided you register a
site on which the source is located with two different
House Of Spooks, then you're allowed to publish =ANY=
cryptographic material, without restriction, and
without further hastle.

(I've read through the tediously long, archaic,
English->Pig Latin documents on the EAR(?) website,
decribing in nausiating detail exactly what is and is
not permitted. However, I'd like it if someone else
who has seen the documents could correct me if I'm
wrong, as I think I fell asleep at several points.)


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

Re: Linux crypto?

[Henrique de Moraes Holschuh]

On Fri, 24 May 2002, Myrddin Ambrosius wrote:
> not permitted. However, I'd like it if someone else
> who has seen the documents could correct me if I'm
> wrong, as I think I fell asleep at several points.)

http://www.debian.org/legal/

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Linux crypto?

[Alan Cox]

> > They won't let me (or any other US citizen) make any edits to any of
> > the ipsec sources if it were to be added to the main tree.  That's
> > unacceptable because it means that effectively I cannot maintain the
> > networking.
> 
> well the _big_ thing the freeswan people are afraid of, is exactly the
> crypto laws in the us.

They refuse to have a US citizen working on it. Which is reasonable given
the historu of US law, but until the US finishes outlawing computers in 
a couple of years that is a problem.

Re: Linux crypto?

[Thomas 'Dent' Mirlacher]

On Fri, 24 May 2002, Alan Cox wrote:

> > > They won't let me (or any other US citizen) make any edits to any of
> > > the ipsec sources if it were to be added to the main tree.  That's
> > > unacceptable because it means that effectively I cannot maintain the
> > > networking.
> > 
> > well the _big_ thing the freeswan people are afraid of, is exactly the
> > crypto laws in the us.
> 
> They refuse to have a US citizen working on it. Which is reasonable given
> the historu of US law, but until the US finishes outlawing computers in 
> a couple of years that is a problem.

well probably everything which isn't plain english written with a pen
on white paper would be outlawed by then ;)
... but what about having all the crypto stuff in question beeing handled
by modules (developed outside the USSA) and having the networking-related
code in the kernel - could the hooks itself be a problem?

	tm
-- 
in some way i do, and in some way i don't.

Re: Linux crypto?

[Alan Cox]

> well probably everything which isn't plain english written with a pen
> on white paper would be outlawed by then ;)
> ... but what about having all the crypto stuff in question beeing handled
> by modules (developed outside the USSA) and having the networking-related
> code in the kernel - could the hooks itself be a problem?

The US types really want to make that possibility exist. FreeSWAN put a 
huge amount of effort into their project. They don't want to make it
possible for the US government to screw them around as well.

Re: Linux crypto?

[Sandy Harris]

Alan Cox wrote:
> 
> > well probably everything which isn't plain english written with a pen
> > on white paper would be outlawed by then ;)
> > ... but what about having all the crypto stuff in question beeing handled
> > by modules (developed outside the USSA) and having the networking-related
> > code in the kernel - could the hooks itself be a problem?

Any "crypto-shaped hole" -- any interface exclusively designed for crypto,
or anything like a ipsec_init() call in the networking code -- is covered.

A general-purpose interface is, theoretically at least, not covered. If
the crypto plugs in to a standard kernel module interface, or to
netfilter's interface for proxies and such, then the crypto code itself
may still be restricted, but the kernel side code shouldn't be.
 
> The US types really want to make that possibility exist.

Yes, and the US gov't can change the rules. In particular, they might
invent some interpretation that invalidates my second paragraph above
and try to enforce it.

> FreeSWAN put a huge amount of effort into their project. They don't 
> want to make it possible for the US government to screw them around
> as well.

This is a worthy and, given the history, quite likely a necessary goal.
Most FreeS/WAN work has been done in Canada -- with contributions from 
many places, but no code from the US -- for exactly that reason. See 
discussion at:
http://www.freeswan.org/freeswan_trees/freeswan-1.95/doc/politics.html#exlaw

On the other hand, getting strong crypto -- including IPsec -- into
the main kernel tree is also a thoroughly worthy goal.

On yet another hand, it seems obviously reasonable for kernel maintainers
not to accept code they cannot change.

Is there any way to meet both goals? Would a BOF on the topic at OLS
be useful?

Here are my suggestions as posted to a couple of other lists a week
or so ago. I don't imagine I have it right yet, but perhaps this
would do as a starting point:

Subject: [Design] Re: latest patches
Date: Tue, 21 May 2002 14:59:06 -0700
From: Sandy Harris <sandy@storm.ca>
To: linux-crypto@nl.linux.org
CC: design@lists.freeswan.org, tytso@mit.edu
Followup-To: linux-crypto@nl.linux.org
In-Reply-To: <Pine.LNX.4.44.0205211623020.6721-100000@boris.prodako.se>
<1021999182.2875.135.camel@janus.txd.hvrlab.org>

[added cc to FreeS/WAN list and random.c author, and set followup-to]

Herbert Valerio Riedel wrote:

> > 1. Crypto support (no algorithms).  This can go into the official kernel,
> >    at least once the API is stable. ...
> 
> > 2. Crypto modules.  Can probably not to inte the official kernel due to
> >    crypto export regulations.

That doesn't work, at least not for US export regs. Any "crypto-shaped
hole" -- any interface or plug-in support that is specifically for
cryptography -- is restricted in exactly the same way as the crypto
itself.

However, if you use a generic multi-purpose interface, such as the
Linux kernel modules interface or for IPsec, the interface that
netfilter provides, then that interface is not restricted.

Can the encrypted file system stuff use such an interface? Could
FreeS/WAN?

The good news about export regs is that, after two court losses
in the Bernstein case (http://www.eff.org/bernstein/) the US gov't
"liberalised" their regs so they now partially comply with the
Wassenaar agreement (http://www.fitug.de/news/wa/index.html).
That agreement says "public domain" code is exempt from its
restrictions, period. Until Bernstein, the US ignored that and
applied full restrictions. Now they only require notification
for export of"public domain" source code.

So under current regs, as long as kernel.org does some
paperwork (which I think they have) there's no legal problem
for crypto in the Linux kernel source. 

Of course, that does not cover US companies such as Redhat
who might want to ship compliled code. It should, since the
US has signed the Wassennaar agreement, but ...

Also, it does not change the FreeS/WAN project's policy of
carefully ensuring that their code is entirely developed
outside the US so that even if the US gov't change the rules
again, they cannot restrict FreeS/WAN.

> some people also suggested splitting the ciphers up into
> patented/non-patented, weak/strong, ...

Why on Earth would you want either patented or weak ciphers?

As I see it, you want only a very few ciphers, ideally only one.
Simplicity is a great virtue in security software.

Currently, I think the possible collection of crypto in the
kernel is:
        drivers/char/random.c
                #define for either MD5 or SHA-1
                MD4 for the TCP sequence # part
        ipsec
                both MD5 and SHA-1
                3DES
        JuanJo's patches for ipsec
                AES cipher
                some of SHA-256, -384, -512
        loop stuff
                multiple ciphers

As far as I know, these are independent/duplicated. Many kernels
will have two copies of MD5, one each in the random and ipsec
code. If you use AES in both an encrypted file system and in 
IPsec, you'll have two copies (versions?) of the AES code.

This is not a major problem, but it appears worth fixing. 
  
> > 3. Encrypted loop driver.
> >
> > What do you think?
> good point...
> 
> the crypto api itself almost kernel version independent, so it might
> well justify splitting it from the cryptoloop application, which is the
> biggest headache to keep in sync with the rest of the kernel...
> 
> that's one of the reasons why I started to split off the loop-modifying
> stuff into a patch of it's own (loop-jari/hvr patches)...
> 
> now I'll just have to figure out a way to accomplish the split without
> letting maintenance get unreasonable...

I'd like to see, in the main kernel tree, one good hash and one good
cipher. Then use them in all the above places. 

For AES in IPsec, the default (and the only required) algorithms are 
AES with 128-bit key and SHA-256. That makes them the obvious choices.

You might want somewhat more than that.

IPsec would probably want MD5, SHA-1 and 3DES for interoperability,
RFC compliance and backward compatibility. I'd suggest the standard
kernel not provide these. Keep them as part of FreeS/WAN so they
cannot become "contaminated" with US code during kernel maintenance.

I don't understand why random.c uses MD4; for all I know there are
good reasons to keep it.

There may be overhead issues. How fast is SHA-256 compared to MD5
and SHA-1? This mainly a concern for random.c.

If you are doing AES, then it is likely both easy and a good idea
to add Twofish and  Serpent. These were final round AES candidate
ciphers, so they've survived intensive analysis and there is code
for them with the same interface as AES. Both have completely
open licenses.

If you're doing SHA-256, it may make sense to do SHA-384 and -512
as well. I think they use much the same code.

Re: Linux crypto?

[Petro]

On Fri, May 24, 2002 at 07:55:38PM +0100, Alan Cox wrote:
> > well probably everything which isn't plain english written with a pen
> > on white paper would be outlawed by then ;)
> > ... but what about having all the crypto stuff in question beeing handled
> > by modules (developed outside the USSA) and having the networking-related
> > code in the kernel - could the hooks itself be a problem?
> The US types really want to make that possibility exist. FreeSWAN put a 
> huge amount of effort into their project. They don't want to make it
> possible for the US government to screw them around as well.
    
    They just have to understand that if we want to screw them around,
    we will, and International Law Be Damned. 

-- 
My last cigarette was roughly 36 days, 14 hours, 56 minutes ago.
YHBW

Re: Linux crypto?

[Myrddin Ambrosius]

--- Thomas 'Dent' Mirlacher <dent@cosy.sbg.ac.at>
wrote:
> well probably everything which isn't plain english
> written with a pen
> on white paper would be outlawed by then ;)

Should be easy to test:

if [ cat /usa/laws | grep ban | grep written | grep -q
english ]; then
  echo "Ok, time to panic"
fi

Output:

"You're too late. That's a $1000 fine, for using
dictionary words."

> ... but what about having all the crypto stuff in
> question beeing handled
> by modules (developed outside the USSA) and having
> the networking-related
> code in the kernel - could the hooks itself be a
> problem?

Hmmmm. This would be an interesting idea. In theory, I
don't see why this couldn't be done via an extension
of the existing network hooks.

IIRC, there are hooks for adding new networking
protocols, so it shouldn't be too difficult to extend
this mechanism.

What you'd need is the ability to layer one transport
mechanism over another, as well as add them in
parallel. That way, you're not adding hooks to be used
-for- IPSec, merely hooks that IPSec could exploit.

This could also be used to simplify the tunneling
code. A tunnel would become an n-deep stack of
transport mechanisms, each piping into the next.
Instead of having to write a new tunneling system for
every possible combination, you'd simply write your
transport mechanism to support a "generic" input and
"generic" output channel. Any protocol could then be
tunelled through any other protocol, including a
protocol which is already being used to tunnel.

For IPSec, this translates to the transport mode
becoming: network protocol -> IPSec

And, for tunneling mode, you'd want something like:
network protocol -> IPSec -> network protocol

By allowing protocol stacks, and by having a generic
interface, it would be easy to throw the output over a
non-IP connection.

At present, if you want to use IPSec over ATM, you'd
need two tunnels. One for IPSec over IP, and one for
IP over ATM. Each would need to be independently
maintained, and you'd end up with a fascinating
routing table, trying to get packets from one virtual
device to another virtual device, through a virtual
network space, without the router daemon deciding that
what you REALLY want is some clam chowder.

With the layering concept, you're simply wrapping one
protocol in another, as many deep as you like, to
produce a single, composite device, with the precice
characteristics you want. For the IPSec over ATM,
you've no tunnels, just the two wrappers (IP->IPSec,
and IPSec->ATM), to produce a composite IP->IPSec->ATM
virtual device.

This is gettig WAAY too off-topic, at this point, but
I could picture the protocols themselves being built
up, LEGO-style, out of sub-components, both in
parallel and as wrappers. The "standard" protocols
would then be simply one way to wire the networking
code, but there'd be a virtually infinite number of
combinations you could do.

(Most of those combinations would be meaningless, but
could prove highly entertaining!)


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

Re: Linux crypto?

[Thomas 'Dent' Mirlacher]

--snip/snip

> > ... but what about having all the crypto stuff in
> > question beeing handled
> > by modules (developed outside the USSA) and having
> > the networking-related
> > code in the kernel - could the hooks itself be a
> > problem?
> 
> Hmmmm. This would be an interesting idea. In theory, I
> don't see why this couldn't be done via an extension
> of the existing network hooks.
> 
> IIRC, there are hooks for adding new networking
> protocols, so it shouldn't be too difficult to extend
> this mechanism.
> 
> What you'd need is the ability to layer one transport
> mechanism over another, as well as add them in
> parallel. That way, you're not adding hooks to be used
> -for- IPSec, merely hooks that IPSec could exploit.

right - i was on the way looking into some "pluggable"
system for the datalink layer in any case - and stumbled
across other implementations: FreeBSDs netgraph, and
also SysV streams. (i don't think netgraph works on
layers >= network ... but that's another story)

> This could also be used to simplify the tunneling
> code. A tunnel would become an n-deep stack of
> transport mechanisms, each piping into the next.

well, you need also some hooks to hook into some arbitrary
points in this "chain". - for setting up the tunnel, ...
but yes, should be doable.

> Instead of having to write a new tunneling system for
> every possible combination, you'd simply write your
> transport mechanism to support a "generic" input and
> "generic" output channel. Any protocol could then be
> tunelled through any other protocol, including a
> protocol which is already being used to tunnel.

right: for the datalink layer it your be decaps and
encaps (or X_type_trans and hard_header right now)
- looks a little bit different on higher layers.

> For IPSec, this translates to the transport mode
> becoming: network protocol -> IPSec
> 
> And, for tunneling mode, you'd want something like:
> network protocol -> IPSec -> network protocol

seems to be ok (guess you just don't count DLL)

> By allowing protocol stacks, and by having a generic
> interface, it would be easy to throw the output over a
> non-IP connection.

since you should be able (at least in theory) to have
deep nested stacks of protocols - including really ugly
combinations

> At present, if you want to use IPSec over ATM, you'd
> need two tunnels. One for IPSec over IP, and one for
> IP over ATM. Each would need to be independently
> maintained, and you'd end up with a fascinating
> routing table, trying to get packets from one virtual
> device to another virtual device, through a virtual
> network space, without the router daemon deciding that
> what you REALLY want is some clam chowder.

problem is: clam chowder is really tasty - but you cannot
get it everywhere :)

> With the layering concept, you're simply wrapping one
> protocol in another, as many deep as you like, to
> produce a single, composite device, with the precice
> characteristics you want. For the IPSec over ATM,
> you've no tunnels, just the two wrappers (IP->IPSec,
> and IPSec->ATM), to produce a composite IP->IPSec->ATM
> virtual device.

yup.

> This is gettig WAAY too off-topic, at this point, but
> I could picture the protocols themselves being built
> up, LEGO-style, out of sub-components, both in
> parallel and as wrappers. The "standard" protocols
> would then be simply one way to wire the networking
> code, but there'd be a virtually infinite number of
> combinations you could do.

sure. - one thing which could get a little bit hairy are
the combinations where:
	you have to setup the connection at some layer(s)
		connection orientated
	you'd like to have different addressed at different
		layers.
but i guess you could use a userland tool for that.

there is a streams implementation for linux out there (LiS),
which could be capable of providing the above functionality
- but i'm not aware of the performance impact.

		tm

-- 
in some way i do, and in some way i don't.

Re: Linux crypto?

[Herman Oosthuysen]

Hmm, here is a brief policy statement on crypto in Canada.  I know that this
in not the US, but Canadian and US policies follow each other closely in
military matters, due to various mutual defence agreements.  From this, it
is clear that most legal issues regarding the use/development of crypto has
been dropped in North America.  This makes sense, since it is far easier to
gather intelligence by other means than by decrypting computer data.

Instead of worrying about US law, you should now worry about
French/Chinese/Russian law instead...

---

SUMMARY OF CANADA'S CRYPTOGRAPHY POLICY

BACKGROUNDER

The Government is implementing a cryptography policy that:

encourages the growth of electronic commerce;
allows Canadian producers to export their products globally within the
framework of international arrangements; and
contains measures to maintain the capability of law enforcement agencies to
ensure public safety.
Support for Electronic Commerce

Canadians are free to develop, import and use whatever cryptography products
they wish.

The Government will not implement mandatory key recovery requirements or
licensing regimes.

The Government encourages industry to establish responsible practices, such
as key recovery techniques for stored data.

The Government will act as a model user of cryptography through the
practices of the Government of Canada Public Key Infrastructure (GOC PKI).

The Government encourages and supports industry-led accreditation of private
sector certification authorities.

Export / International Agreements

Canada will continue to implement cryptography export controls in keeping
with the framework of the international Wassenaar Arrangement.

Canada will take into consideration the export practices of other countries
and the availability of comparable products when rendering export permit
decisions.

The export permit application process will be made more transparent and
procedures will be streamlined to ensure the least regulatory intervention
necessary.

Public Safety

The Government proposes amendments to the Criminal Code and other statutes
as necessary to:

criminalize the wrongful disclosure of keys;
deter the use of encryption in the commission of a crime;
deter the use of cryptography to conceal evidence;
apply existing interception, search and seizure and assistance procedures to
cryptographic situations and circumstances.

---

Cheers,
--
Herman Oosthuysen
Herman@WirelessNetworksInc.com
Suite 300, #3016, 5th Ave NE,
Calgary, Alberta, T2A 6K4, Canada
Phone: (403) 569-5687, Fax: (403) 235-3965
----- Original Message -----
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Thomas 'Dent' Mirlacher <dent@cosy.sbg.ac.at>
Cc: David S. Miller <davem@redhat.com>; <alan@lxorguk.ukuu.org.uk>;
<tori@ringstrom.mine.nu>; <imipak@yahoo.com>; <linux-kernel@vger.kernel.org>
Sent: Friday, May 24, 2002 12:41 PM
Subject: Re: Linux crypto?


> > > They won't let me (or any other US citizen) make any edits to any of
> > > the ipsec sources if it were to be added to the main tree.  That's
> > > unacceptable because it means that effectively I cannot maintain the
> > > networking.
> >
> > well the _big_ thing the freeswan people are afraid of, is exactly the
> > crypto laws in the us.
>
> They refuse to have a US citizen working on it. Which is reasonable given
> the historu of US law, but until the US finishes outlawing computers in
> a couple of years that is a problem.
>
> -
> 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/

Re: Linux crypto?

[Xavier Bestel]

Le ven 24/05/2002 à 19:21, David S. Miller a écrit :
>    From: "Thomas 'Dent' Mirlacher" <dent@cosy.sbg.ac.at>
>    Date: Fri, 24 May 2002 19:32:48 +0200 (MET DST)
>    
>    what about freeswan - with some cleanups?
> 
> They won't let me (or any other US citizen) make any edits to any of
> the ipsec sources if it were to be added to the main tree.  That's
> unacceptable because it means that effectively I cannot maintain the
> networking.

Why ? You can make all edits you like, they just won't be folded back to
their tree. You can retrieve all their fixes, just if you have an
important change to do in their core, do it as free speech on their
public mailing list, do not provide a patch.

Re: Linux crypto?

[David S. Miller]

   From: Xavier Bestel <xavier.bestel@free.fr>
   Date: 24 May 2002 23:49:29 +0200
   
   Why ? You can make all edits you like, they just won't be folded back to
   their tree. You can retrieve all their fixes, just if you have an
   important change to do in their core, do it as free speech on their
   public mailing list, do not provide a patch.
   
I can't edit their code because effectively I could contaminate
their sources.

Say I make some global networking API change, and this required
a significant edit to ipsec to make it comply with the new
structure layout or whatever.

And let's assume there is only one clear way to implement the
change, no other way to do the change would make any sense at all.

So the IPSEC people would have to effectively avoid integrating my
change, ie. it is a big onus on them to make their version of the API
update different enough from my edits so that nobody can claim they
just applied my change.

And the fact that there would be two edits makes no sense.  If a
change has to occur twice in two different ways this makes merging a
disaster.

So someone quips "just let them edit and just merge from IPSEC" and
I say I refuse to let something just sit in the tree that I cannot
edit when I want to make sweeping changes across the tree.  That is
unacceptable.

Re: Linux crypto?

[Jakob Østergaard]

On Fri, May 24, 2002 at 02:43:05PM -0700, David S. Miller wrote:
>    From: Xavier Bestel <xavier.bestel@free.fr>
>    Date: 24 May 2002 23:49:29 +0200
>    
>    Why ? You can make all edits you like, they just won't be folded back to
>    their tree. You can retrieve all their fixes, just if you have an
>    important change to do in their core, do it as free speech on their
>    public mailing list, do not provide a patch.
>    
> I can't edit their code because effectively I could contaminate
> their sources.

Could there be issued a general license for export of the Linux kernel from the
U.S. ?

It seems that even though the politics/politicians may not be entirely up to
par with reality, that there is also some understanding of the need to share
and cooperate in development of a secure operating system kernel.  Most
notably, the NSA Secure Linux Project.  While this doesn't include crypto, it
includes a number of other technologies which are (like crypto) necessary for a
secure environment, but (like crypto) not any magic secret technology that it
would make sense to restrict exports on.

Could someone from "inside" give an oppinion on this ?

As far as I know, it should be possible to get a general license for the export
of the Linux kernel (by some definition thereof).  It works like this in my
country too, and probably many others.

If this could be done with the U.S. perhaps other countries with export/import
controls would be more willing to negotiatiate similar deals.  "First we take
Manhattan, then we take Berlin"  ;)

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

Drivers, Hardware, and their relationship to Bagels.

[Myrddin Ambrosius]

[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]

Hi all,

With the discussion on kernel crypto a while back,
there was one very important recurring element that I
would like someone to clarify for me.

The issue is this. My understanding is that -all-
hardware access should be through the kernel, partly
so that similar hardware can have a similar API, but
also so that kernel security code (eg: capabilities)
applies to ALL hardware and ALL lower-level
operations.

However, there were a number of mentions of userland
hardware drivers, which did NOT operate through the
kernel. (This was in reference to why it wouldn't be
necessary to have a kernel-level driver for the
Motorola M190 crypto chip.)

If you can blithely ignore restrictions placed by the
kernel on some piece of hardware, and access it
directly, then surely this would apply to any
hardware. Including disk drives, RAM, etc.

I could be wrong (and I hope, very much, that I am),
but if my understanding is correct, then that's a hole
you could drive a truck through, and have room to
spare.

This isn't intended as a critisism of anyone, or of
any decisions made regarding the way the kernel
operates. (I know my phrasing leaves a lot to be
desired. Sometimes I think my best chance of a long
life would be to take a vow of silence and become a
monk.)

I'd really appreciate it if someone could clarify this
for me, especially the security aspect of non-kernel
drivers.


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

[-- Attachment #2: ks.txt --]
[-- Type: text/plain, Size: 489 bytes --]

(Tune of "Running Free", by Iron Maiden)

Kernel bug, core runs wild,
Space/time twists and gets compiled.
Wormholes open and bring to me,
Linux Kernel Version 3!

I'm running 3, yeah, I'm running 3!
I'm running 3, yeah, I'm running 3!

Got support for Tbyte RAM,
The newest arch is leg of lamb.
Max cpus, one thousand now,
Neg latency gives quite a pow.

Men in Black zap my brains,
Melt the hard-disk, and what remains.
There's nothing left for you to see
That my machine was running 3!

Re: Drivers, Hardware, and their relationship to Bagels.

[Zwane Mwaikambo]

On Tue, 18 Jun 2002, Myrddin Ambrosius wrote:

> If you can blithely ignore restrictions placed by the
> kernel on some piece of hardware, and access it
> directly, then surely this would apply to any
> hardware. Including disk drives, RAM, etc.

iopl(2), chmod(1) and friends, hardware frobbing isn't a free for all. 
Then again if you're root...

Regards,
	Zwane Mwaikambo

-- 
http://function.linuxpower.ca
		

Re: Drivers, Hardware, and their relationship to Bagels.

[Richard B. Johnson]

On Tue, 18 Jun 2002, Myrddin Ambrosius wrote:

> Hi all,
> 
> With the discussion on kernel crypto a while back,
> there was one very important recurring element that I
> would like someone to clarify for me.
> 
> The issue is this. My understanding is that -all-
> hardware access should be through the kernel, partly
> so that similar hardware can have a similar API, but
> also so that kernel security code (eg: capabilities)
> applies to ALL hardware and ALL lower-level
> operations.
> 
> However, there were a number of mentions of userland
> hardware drivers, which did NOT operate through the
> kernel. (This was in reference to why it wouldn't be
> necessary to have a kernel-level driver for the
> Motorola M190 crypto chip.)
> 
> If you can blithely ignore restrictions placed by the
> kernel on some piece of hardware, and access it
> directly, then surely this would apply to any
> hardware. Including disk drives, RAM, etc.
> 
> I could be wrong (and I hope, very much, that I am),
> but if my understanding is correct, then that's a hole
> you could drive a truck through, and have room to
> spare.
> 
> This isn't intended as a critisism of anyone, or of
> any decisions made regarding the way the kernel
> operates. (I know my phrasing leaves a lot to be
> desired. Sometimes I think my best chance of a long
> life would be to take a vow of silence and become a
> monk.)
> 
> I'd really appreciate it if someone could clarify this
> for me, especially the security aspect of non-kernel
> drivers.


No hole you can drive through. A process with a UID of 0 and
a GID of 0 can do anything it wants. It can execute iopl(3)
and set an I/O permission level that allows it to directly access
hardware I/O ports, etc. It can also turn off interrupts. Basically,
it can do anything, since such a process can also memory-map anything.

Users are not supposed to execute as 'root'. Also, only certain
priviliged tasks execute as root. Ignore that this account
"seems-to-be" root@chaos.analogic.com. This is an anti-spam trick.
The real root on this machine is called "system". Names mean nothing
to Unix, it's the UID/GID that counts.

You can make a priviliged task by setting the UID/GID to zero in
the first few lines of 'C' code of main(). This will fail unless
the resulting executable has its SUID bit set (chmod 4755 filename).
Further, this file has to execute in a root-owned directory. Once
these conditions are satisfied, the program can do anything it wants.

main()
{
   setuid(0);
   setgid(0);
   iopl(3);
   mmap(everything);
   destroy_the_world();
}


Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: Drivers, Hardware, and their relationship to Bagels.

[Myrddin Ambrosius]

--- "Richard B. Johnson" <root@chaos.analogic.com>
wrote:
> No hole you can drive through. A process with a UID
> of 0 and
> a GID of 0 can do anything it wants. It can execute
> iopl(3)
> and set an I/O permission level that allows it to
> directly access
> hardware I/O ports, etc. It can also turn off
> interrupts. Basically,
> it can do anything, since such a process can also
> memory-map anything.

But since it is the kernel that permits that (by
definition, since somebody has to check the UID & GID!
:) then the kernel can also restrict that.

The system admin account (UID/GID 0) could just as
easily access a virtual memory map, virtual I/O ports,
etc, with the kernel then handling how that maps onto
the physical world, and even IF it does.

> Users are not supposed to execute as 'root'. Also,
> only certain
> priviliged tasks execute as root. Ignore that this

The problem with priviliged tasks is that (in general)
they run with absolute privilige. Sure, some of these
priviliges can be turned off, but if /dev/mem is
reachable, then they can be turned back on again,
precicely for the reasons you give.

I guess that my understanding for having kernels the
size and complexity of Linux, as opposed to, say,
CP/M, is that the kernel can reduce the need for
userspace apps to have dangerous powers.


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Re: Drivers, Hardware, and their relationship to Bagels.

[Richard B. Johnson]

On Tue, 18 Jun 2002, Myrddin Ambrosius wrote:


> 
> I guess that my understanding for having kernels the
> size and complexity of Linux, as opposed to, say,
> CP/M, is that the kernel can reduce the need for
> userspace apps to have dangerous powers.

Users need to have 'dangerous' things done, like reading and
writing to hard-disks, etc. To keep things organized, like
writing and reading files they control, there is some code
called the kernel, that performs these 'dangerous' things on
behalf of the callers. Since the callers can't modify the kernel
to make it do "bad" things like writing outside "files",  everything
works out just fine. The exact same things can usually be done by
"user-mode" programs. You just need to keep them from being hacked and
everything works out just fine, just like in the kernel.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: Drivers, Hardware, and their relationship to Bagels.

[Stevie O]

At 11:35 AM 6/18/2002 -0700, Myrddin Ambrosius wrote:
>The problem with priviliged tasks is that (in general)
>they run with absolute privilige. Sure, some of these
>priviliges can be turned off, but if /dev/mem is
>reachable, then they can be turned back on again,
>precicely for the reasons you give.

What about the bagels? I like bagels! ;)

I agree that this is a problem.  A very, very good example of this is 'binding to a reserved port (<1024)'. A number of programs that should never need to run as root, do, some for the sole purpose of binding to a "reserved port":
        * Webservers in a relatively simple configuration (ex: my Apache install)
        * BIND (which doesn't even drop root. A security nightmare.)
        * identd

There are kernel patches that can help solve this problem. One, found at ftp://ftp.v-lo.krakow.pl/pub/linux/patches/, creates 'magic' GIDs that give special limited privileges like binding to a reserved port (above list) or creating a raw socket (ping, traceroute).

If I recall the Capabilities FAQ correctly, I think there's something relating to PAM that might let you give partial capabilities to certain users who login (like CAP_SYS_TIME to your normal desktop login, so you can set the clock without using 'su'). It would be nice to be able to (relatively easily) create certain uids/gids (or names) that get special privileges automatically... then certain apps (like ping, traceroute) could be setuid something-less-powerful-than-root.  I think that'd be an interesting project to work on when I'm bored... anybody on this list think it's worthy of discussion (or not worthy -- arguing is fun, it makes for more active threads!) ?

Just remember -- we need root/uid0/whatever, because in the end, the computers are here to serve US, to do OUR bidding. And using root is what I like to term an 'executive override' -- it cuts through all the protections and guards that the kernel has, and makes the computer do what we say. That's why we don't protect root from itself.


--
Stevie-O

Real programmers use COPY CON PROGRAM.EXE

Re: Drivers, Hardware, and their relationship to Bagels.

[Xavier Bestel]

Le mar 18/06/2002 à 17:06, Myrddin Ambrosius a écrit :
> The issue is this. My understanding is that -all-
> hardware access should be through the kernel, partly
> so that similar hardware can have a similar API, but
> also so that kernel security code (eg: capabilities)
> applies to ALL hardware and ALL lower-level
> operations.

You want to forbid XFree86's DRI ?

	Xav

Re: Drivers, Hardware, and their relationship to Bagels.

[Myrddin Ambrosius]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 4009 bytes --]


--- Xavier Bestel <xavier.bestel@free.fr> wrote:
> Le mar 18/06/2002 à 17:06, Myrddin Ambrosius a écrit
> :
> > The issue is this. My understanding is that -all-
> > hardware access should be through the kernel,
> partly
> > so that similar hardware can have a similar API,
> but
> > also so that kernel security code (eg:
> capabilities)
> > applies to ALL hardware and ALL lower-level
> > operations.
> 
> You want to forbid XFree86's DRI ?

No, the kernel's DRM provides a nice kernel layer for
XFree's DRI, which covers all the security issues.
Well, provided the DRM code gets enough drivers.

Personally, I'd like to see more fine-control of
graphics hardware end up in the kernel, partly to
avoid some of the nastier security risks (such as
having to run X servers as root! bleagh!) but also
because the kernel has to have a whole lot of control
anyway.

The sheer number of possible displays you can put into
any given one of the fantastically large number of
virtual consoles makes for an interesting challange.
(On older kernels, changing to and from virtual
terminal when running an svgalib app could do some
VERY interesting things to your display.)

When you start looking at running X under multiple
resolutions on the same machine, or even running
multiple X servers (which I -think- is now possible),
things don't get any better.

If the kernel's various graphics components (DRM,
framebuffers, etc) handled the low-level stuff, you
don't get multiple pieces of software each trying to
drive the screen at a different rate. You could even
have two pieces of software access the same virtual
terminal at different resolutions, because the kernel
would eliminate the "conflict".

I understand that, prior to framebuffers going in,
there were a number of (cough!) lengthy discussions on
the safety and stability of high-level code in the
kernel. I honestly believe that this is the flip-side
of that same debate. Whether it is safe and stable to
have low-level code in userland.

I honestly believe that too much low-level code or
access in userland is just as destabilizing (and
potentially far more dangerous) than high-level code
in the kernel.

Someone else mentioned all the wonderful stuff root
can do. Root's a cool toy, but in the end, root is
still a product of the kernel's imagination. There is
no physical chunk of machinary in a computer that can
be called "root". Unless your spider-plant has grown.

Therefore, to argue that root can do anything is not
entirely true. (In fact, Linux' Capabilities
demonstrates this, nicely. It is possible to set the
capabilities such that nothing root can do can
re-enable any capabilities removed.)

It would be too soon to "retire" root, because I don't
think anyone's entirely happy with the alternatives
that exist. (If they were, Linux would have lost root
before version 1.0! I can remember patches almost the
size of the kernel!) Maybe, someday, someone'll figure
out a rootless system that is generally acceptable.

On the other hand, if the small handful of actual
instructions (not apps, not even functions, just the
instructions) that -need- super-user privs were all
encapsulated inside kernel system calls, then you
don't risk running a root-kit-o-matic every time you
boot X, or some other server that currently needs root
privs.

One reason for NOT doing this is that it takes time to
switch between contexts. Deliberately adding a whole
bunch of switches would seem to be remarkably stupid.
Doubly so, when you're adding switches to maybe run
half a dozen lines. For stuff that's used heavily,
there's probably less time penalty in typing the code
in by hand into the server, and running as root, than
all the constant switching.

I don't have to like it, but I can't find any solid
argument against this. Good solutions are efficient,
and efficient != slower than a snail on salt.


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Re: Linux crypto?

[James Yonan]

> On Fri, 24 May 2002, Alan Cox wrote:

> > > On Wed, 22 May 2002, Alan Cox wrote:
> > > 
> > > > What of it do you actually need in kernel space - encrypted file 
systems
> > > > certainly ought to be there but are not very well handled in Linux 
proper
> > > > right now - but anything else ?
> > > 
> > > IPsec.
> > 
> > At the moment there doesn't appear to be an IPsec stack we can merge 
however

> what about freeswan - with some cleanups?

I'd like to propose that network crypto can be handled well in user-space.

There are quite a few user-space options now for secure tunneling of IP or 
ethernet.  I am personally a developer on the OpenVPN project, but there 
are quite a few others including VTun, cipe, and tinc.  I know that 
OpenVPN and VTun take advantage of the Universal TUN/TAP driver which has 
been in the official kernel since 2.4.6 or so, which lets user-space 
programs control a virtual point-to-point IP link or virtual ethernet 
adapter.  While not explicitly a crypto-enabler, the TUN/TAP driver nicely 
imposes a modularization on secure tunneling daemons -- the bulk of the 
code including crypto lives in user-space and the kernel component is 
reduced to a small virtual network driver that talks to user-space rather 
than hardware -- and which hopefully is sufficiently generic that it 
doesn't fall into the class of crypto-enabling infrastructure with respect 
to export-control regulations.  Running in userspace confers a number of 
other benefits such as:

1. the daemon is easily portable beyond Linux to any platform that 
supports a tun driver (such as OpenBSD, FreeBSD, Mac OS X, and Solaris).  
IPSec implementations tend to be OS-specific,

2. the daemon can use portable user-space libraries such as OpenSSL to 
handle the crypto, taking advantage of the SSL/TLS protocol and the X509 
PKI,

3. the daemon can tunnel over UDP (IPSec uses IP protocols 50 and 51 which 
are often blocked by broadband ISPs),

4. the daemon can tunnel through NAT gateways (IPSec doesn't like NAT), 
and

5. the daemon can transparently tunnel or bridge non-IP protocols or any 
protocol which can be represented as an ethernet frame.

The downside of course is that a user-space implementation will be slower.  
It's also difficult to achieve IPSec compliance, because user-space 
tunneling daemons want to use an application-level protocol over UDP -- 
user-space is not the right place to implement a protocol stack.

But the upside is that the secure tunneling daemons are available now, 
the better ones are robust, secure, and portable, they don't require 
embedding any crypto or crypto hooks in the kernel, and they work
with most out-of-the-box 2.4 distributions without needing any external
kernel modules.


James Yonan
OpenVPN Developer
http://openvpn.sourceforge.net/