Messages in this thread |  | | Date | Tue, 26 Nov 1996 09:23:42 -0600 (CST) | From | Jason Burrell <> | Subject | Re: your mail |
| |
On Mon, 25 Nov 1996, Nathan Bryant wrote:
> > > Todd T. Fries wrote: > > > > > Perhaps someone could browse to http://www.openbsd.org and see if their > > > suggestion of going through Canada are valid? > > For people who don't know, he's referring to a scheme where someone in the > U.S. would export cryptography software to someone in Canada, who would > then turn around and re-export the software to the rest of the world. > > This won't work; a U.S. resident who exports crypto to Canada with the > intention of having someone in Canada re-export the software WILL be > prosecutable in the U.S. Big Brother is watching! > > For any cryptography to be integrated into the mainline Linux kernel, the > cryptography will have to be implemented outside the U.S., and the kernel > will have to be maintained from outsided the U.S. Unless the cryptography > is usable only for authentication. Additionally, once crypto gets into the > mainline kernel, the kernel will not be re-exportable from the U.S.
Someone a while back created IDEA and DES patches to allow the loopback filesystem device to use encryption. It doesn't work in later kernels, though, and I haven't had time to fix it.
If we provide a very generic interface to the kernel, I figure we can implement this in modules. This would also (hopefully) get around the stupid "no-hooks" provision in ITAR, but I'm not a lawyer.
For filesystems, we could probably just create another filesystem. Make that compilable as a module, or directly into the kernel via a patch. Then if I want 100MB of my disk encrypted, I make a crypto-fs, and mount it.
|  |