Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!uwm.edu!cs.utexas.edu!geraldo.cc.utexas.edu!sylvester.cc.utexas.edu!not-for-mail From: vax@sylvester.cc.utexas.edu (Vax) Newsgroups: comp.os.386bsd.development Subject: Re: Compressing file system ? Date: 12 Aug 1993 19:10:52 -0500 Organization: The University of Texas - Austin Lines: 21 Message-ID: <24em6c$84@sylvester.cc.utexas.edu> References: <23tr2j$3tt@europa.eng.gtefsd.com> <23tsn3$7e@Germany.EU.net> <1993Aug6.200839.9675@udel.edu> NNTP-Posting-Host: sylvester.cc.utexas.edu Since we are on the topic of new file systems, I was just wondering if anyone had considered an encrypting file system. It would, of course, be the same size as a normal file system, so size translation is not a problem. Presumably, you would provide a passkey at mount-time that is compared to a stored version on the partition somewhere. Then, assuming it is correct, it goes about decrypting the inode table and/or files with it. (It compares so that you don't get a bogus file system by decrypting with the wrong key). Oh, when I say it compares it, I mean by way of a one-way hash or something like Unixes password file. You obviously wouldn't want to store the key in plaintext form in the partition info (duh!) I feel that this would be an excellent security measure, especially for those people who cannot physically secure their workstation or media. Presumably you would make the dirs in the partition readable only by ppl with the proper access. You would probably have to consider the ramifications of known-plaintext attacks if the filesystem had invarying or at least predictable elements (i.e. magic numbers, etc..) or if an attacker had write access to something in the partition. -- Protect our endangered bandwidth - reply by email. NO BIG SIGS! VaX#n8 vax@ccwf.cc.utexas.edu - Don't blame me if the finger daemon is down