Mr. Clift: There are definitely some countries that are willing and able to block the distribution of a Linux kernel so encapsulating encryption technologies within its core architecture (even the US has done this at times). It is however my personal understanding of the existing legislative climate (in the US at least) that a Linux kernel inclusive of an encryption API, and separate module loadable algorithms (not distributed with the kernel) is ripe in the instant moment, and may well not be an option in the future if legislation (under consideration currently by the US congress, and I am sure other legislative bodies in other political states) is enacted. Thus, the inclusion by Linus of at minimum an encryption API able to support encryption algorithms loaded via a module architecture is the most attractive adoption of encryption by the Linux kernel in order to not give impetus to political states to subvert and retard the distribution of Linux throughout the world. Having such an API inclusive to the kernel, general enough to allow it to implement encryption algorithms of a very broad spectrum would resolve an issue long hanging over the Linux kernel. At some point the maintainers with control over what goes in the kernel (Linus, Alan Cox, etc.) must accept the idea that if Linux is absent such technology its use and acceptance by users will be retarded absent the assistance of disruptive legislative action by a political state. So which is better? Prevent Linux from having an API within its source code, and allow it to be distributed worldwide absent disruptive actions by political states and cause those interested in Linux to choose not to use it based on that fact, or have a Linux which has strong encryption but cannot be freely distributed? Neither! So what do I propose? A very interesting hybrid! What ought to be done is for Linus (not Herbert, no offense Herbert) to create a crypto version of the kernel. This version of the kernel might be subject to restrictive licensing or importation / exportation limits, however would not impact the ability of Linus and friends to continue to distribute the non-crypto kernel, which would be the same as the crypto version absent the crypto code. Further discussion (legal and technological) would have to be employed to determine if this crypto kernel would be inclusive of the actual algorithms or not, but that we can save for a latter debate, as this would initially fix some problems with the acceptance of encryption technologies (i.e. an API) as being a standard within the Linux community. The virtual software constitution (i.e. the "GPL") espousing political, intellectual, and legal freedom for Linux can be preserved while still enabling the greater Linux community to experience both the current non-crypto and perhaps future crypto-kernel versions. Thus, only by having an officially disseminated crypto and non-crypto versions of the kernel can we assure ourselves that political states will not choose to retard the overall distribution of the Linux kernel to an extent able to totally prevent Linux from entering all those political states it currently has the freedom to enter in a non-crypto state. Very Respectfully, Stuart Blake Tener, IT3 (E-4), USNR-R, N3GWG Beverly Hills, California VTU 1904G (Volunteer Training Unit) stuart@bh90210.net west coast: (310)-358-0202 P.O. Box 16043, Beverly Hills, CA 90209-2043 east coast: (215)-338-6005 P.O. Box 45859, Philadelphia, PA 19149-5859 Telecopier: (419)-715-6073 fax to email gateway via www.efax.com (it's free!) JOIN THE US NAVY RESERVE, SERVE YOUR COUNTRY, AND BENEFIT FROM IT ALL. Wednesday, March 06, 2002 12:25 AM -----Original Message----- From: Justin [mailto:aa2@bigpond.net.au] Sent: Tuesday, March 05, 2002 10:19 PM To: stuart@bh90210.net; 'Jari Ruusu'; 'Newsmail' Cc: linux-crypto@nl.linux.org Subject: Re: journaling file systems Hi Stuart, On Wednesday 06 March 2002 16:37, IT3 Stuart Blake Tener, USNR-R wrote: > Mr. Clift: > > Yes, I most affermatively agree with that position. However, I > was of the impression that legal barriers (not just in the US, but other > countries as well) prevented such a scenario from being effective > without a realistic degradation in the ability to import / export the > Linus kernel to with such countries having such legal barriers with > regard to import / export controls > in place. I was aware that some countries would have a problem with the kernel code having the full cryptographic code in it. Does anyone know of a definitive list of countries where it truly wouldn't be acceptable these days? > Now if you are saying that instead of having the actual > cryptographic code in the kernel, but merely calls to advantage onesself > of whatever they had loaded into memory in the way of crytographic code > via a loadable module then this is indeed a superior methodology and I > would support its implementation most immediately, though I am > unfamiliar with the legal aspects of such a scenario or why Linus has > not contemplated such a scenario in the past. I wasn't suggesting merely having hooks. Although there are arguments for and against this, I think everyone most everyone agree's the best solution possible would be to have the cryptoAPi softteare completely implemented and available in the kernel. As has also been mentioned many times, this would not be acceptable in some countries. Given this wasn't a barrier, I wonder what would stop CryptoAPI from being included as part of the normal kernel? Regards and best wishes, Justin Clift > Very Respectfully, > > Stuart Blake Tener, IT3 (E-4), USNR-R, N3GWG > Beverly Hills, California > VTU 1904G (Volunteer Training Unit) > stuart@bh90210.net > west coast: (310)-358-0202 P.O. Box 16043, Beverly Hills, CA 90209-2043 > east coast: (215)-338-6005 P.O. Box 45859, Philadelphia, PA 19149-5859 - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
