Julian Squires <tek@wiw.org> writes:
> On Thu, Jun 01, 2000 at 10:19:21PM -0500, David Marshall wrote:
> > Now sure, people can go plow through the source and do this
> > themselves, but the average person won't. While some of us might be
> > tempted to say that people who don't want to put forth the effort
> > shouldn't have the security, the more people who use such security,
> > the less conspicuous using it becomes. This is a good thing for those
> > of us who really want to secure things.
>
> I think that there are also aspects of the kernel whose security might
> be improved through the use of strong cryptographic primitives.
> (OpenBSD has been doing some innovative stuff here - it would be worth
> learning from their example, IMHO)
Definately.
> If the kernel doesn't have these cryptographic primitives without a
> patch, though, it means one must maintain a much larger amount of code
> in the international patch (and keep the weaker versions in the main
> distribution), which would be a tremendous pain.
And there's always a catch. :)
Someone mentioned that it was hypocritical (I'm paraphrasing) for
those of us in the United States to argue that crypto should go into
the kernel regardless of the laws in countries like China, because
stupid algorithm patents are enforced in the United States. There's
actually a huge difference: one is including an API, and the other is
including the actual algorithms. China, as far as I know, says that
you can't include the API. The United States says that you can't
include patented algorithms without permission, which is totally
different from adding an API.
In other words, putting in a crypto API with support for all sorts of
algorithms is one thing, and has its own technical issues. Putting in
support for specific algorithms can be made relatively simple: the
programmer literally just drops the code in, and writes init, release,
status, key generation and handling, encrypt, and decrypt functions.
How is block chaining done in the current kerneli setup?
> > Now enters the argument that weak security is far, far worse than no
> > security, because it lulls people into a false sense of security. True
> > enough. This begs the question about whether putting the crypto into
> > the kernel really *is* a good thing, because sooner or later we're
> > going to have hoards of people using it, thinking they're secure, and
> > doing boneheaded things which totally compromise their security
> > without realizing it. (Examples: putting the key for their encrypted
> > filesystem in a plaintext file on the disk, taping it to the monitor,
> > using obscenely short passphrases, etc.)
>
> True, but I personally believe that nothing is foolproof, and that the
> best we can do is provide the framework which allows for good security
> practice, coupled with good documentation.
I agree with you. I just brought the point up.
Phil Zimmerman tried to do what you describe when he released PGP. The
manual was in two parts. One part concerned operation of the program,
and the other part was a "Security for the Total Idiot" kind of thing.
> > Maybe the best deal is to have external patches which people can apply
> > if they want the feature. This is supposedly what we have now, but the
> > stuff needs to be kept current.
>
> That is something I was going to mention. One big point for putting it
> in the kernel is that it would greatly increase awareness about the
> crypto code, as currently all the responsibility seems to fall on the
> shoulders of a very small number of hard working people. This would
> seem to impair its development quite a bit.
Good point.
Is it possible to perhaps put in a crypto API like I mentioned above,
and let people drop in their own crypto algorithms with some patch?
Ideally the API would even handle the various block chaining schemes.
>From the looks of it, we already have something pretty close in
drivers/block/loop.c. In particular, look at the top of the file. Two
transfer functions are defined. One is a straight passthrough function
(i.e. no transformation/crypto at all). The other is a cheezy (and
horribly insecure, if anyone is actually clueless enough to use it)
XOR encryption scheme. I would assume that someone could write
transfer and other support functions for real crypto algorithms and
just drop them in without having to modify much of anything in the
kernel tree other than the Config.in file and the Makefile.
What I'm unclear on is how the block chaining is done, but I haven't
look at the code in depth.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:14 EST