From: anon@author.prg (aman) Newsgroups: alt.security.pgp,alt.security,sci.crypt Subject: Re: On-the-fly win95 HD encryption util? Date: 1 Jul 1998 18:59:01 -0500 Organization: Newscene Public Access Usenet News Service (http://www.newscene.com/) Message-ID: <359ac030.1234679@news3.newscene.com> References: <35888E52.1A39DA9A@pitt.edu> <6naju3$hic$1@nnrp1.dejanews.com> <3598FA52.1574936F@egg.chips.and.spam.com> <6ncr97$9ii$1@nnrp1.dejanews.com> <6ndchc$np5@senator-bedfellow.MIT.EDU> On 1 Jul 1998 13:11:08 GMT, fubob@mit.edu (Kevin E. Fu) wrote: >>> *More* algorithms? >>> >>> I never understood the need to have thousands of algorithms (and go >>> around >>> inventing more every day). Surely one good one is enough...(!) >> >>And if that one good algorithm is broken ?  Thats the trouble, we know what is >>a 'good algorithm' now, but in a years time we have discover new methods of >>cryptoanalysis. >> >>Having multiple algorithms also increases the security of the system; a would >>be attacker doesn't even know which algorithm is used to protect the data. >>Actually, the whole disk just looks like a large random file (DieHard thinks >>so anyway!). > >I am not entirely convinced by this reasoning.  Say you allow two >ciphers.  You are unable to use both ciphers simultaneously because of >time and memory constraints. Disk space would be the only problem...... The software can always use algorithms simultaneously for the four mounted disks it supports... Nothing is stored in the ciphered data about the algorithm used for the disk. It simply has to try them all, with all presently known digests/passwords and see if any of them work. Brute force style. So will an attacker too. Unless anything in the data byte sequences can give the (which cipher is it ) game away... > After some time, you discover cipher 1 >has a serious flaw.  You decide to switch to cipher 2.  But how do you >do this?  Some cryptographic file systems require you to copy the >decrypted contents of a file system to a temporary location before >re-encrypting with a new cipher or password.  Copy directly to a new disk, ciphered with the new algorithm/key/pass phrases, and *THEN* destroy the old one..... >Great.  Now your >cleartext bits wait to be stolen. Not as above. Rather than copy them to drive "C:" you copy them directly to another disk employing the new preferred algorithm, simultaneously mounted.... > My point is: it is not what cipher >you use, but how you use it.  You can DTRT, but you just have to do >it.  I'd be interested in hearing more of how you handle this kind of >problem efficiently. > Presently, there is no facility, to re-encrypt the contents of a partition/container file/ ciphered wav file. This is almost by design. Experimentation with other similar utilities, (which shall be nameless) revealed severe problems IMV. A press on the reset button in one case, and a click on a button on a dialog box, was enough to cause TOTAL loss of the container file. I may add a re-encryption facility, when I am convinced that I can devise a method which is reset proof, and fool proof. After all, it is very *VALUABLE* data we are talking about isn't it ? As such, the owner ought to at least have enough free space to copy the data to. No, you don't have to copy it to "clear" bits. You can create a new partition/container file/ wav host file, formatted with the new cipher, and copy your stuff to that, and then destroy the old scrambled data. In my view, this is the only safe and foolproof method of re ciphering the (valuable ? ) data. If you have a CD writer, and are using a container file, you can burn the host file, to a CD,  check its ok (it will mount as read only) destroy the original host file, and then create a new disk, with a new cipher algorithm Copy all the contents back from the CD, onto the new ciphered disk, and then smash the cd to smithereens, and scatter all the bits round the countryside..... But as far as physical storage is concerned, there isn't any clear bits....  (Make sure to clear the swap file however...) >A few cipher choices are nice, but what facilities do you have for >re-encryption?  See above. You might not like it, but neither did I when _another_ utility destroyed my container file, on the re-crypt option.......... >Wouldn't you prefer to concentrate on other aspects of >the file system such as more efficient random access with fewer space >requirements?  Faster incremental updates?  The ability to share?  As in a network ? Or granting different people their own access to your data ? Container files can be mounted at the other end of a network.... Remember, It's NOT a "file system"..... All file systems will work, if the image data is created suitably...   (By the Win32 app) Encryption is done at the sector level. Windows does not even know that the disk is different..... Different people can be granted access to your disks by creating a "SKF" file, with their passwords. You can only do this, when the disk is visible, and it creates a file (for them) which allows access to that disk (or presently visible disks), which is enciphered with their own password. They take the file away with them, and use it when they want to gain access to the disk(s). To revoke access, the owner must rebuild and copy the disks. He can use the same pass phrases. One can use the same pass phrases for all one's disks, and grant access to others, to only one, or a subset of them. You can even allow them to create their "SKF" files, (for all the presently visible disks) with their passwords, without you knowing their passwords if you close your eyes  etc...   (Ok you could have installed a key press  snoop utility....) >Or >ease of revocation or key change?  Most of the hard problems are above >the 'which cipher do you want' level. No they are not "hard" problems, when the OS (and electric power) continues to function, rather than fail, or glitch etc.... They are "hard" when they do fail. The simplest (and safest) solution is to create a new disk, with new keys (which will always be the case) and new passwords/phrases if that is needed, mount the new and the old, and simply copy across the files. Gosh, you can even create a 1 megabyte disk on a floppy, and copy the (small)  files to that.... Or on a Iomega  zip drive (100 meg) or a Jaz disk (1Gb), or another SCSI disk..... The program has been strictly tested on all these devices.... Basically, I wrote what I wanted for myself, and took on board the suggestions of *many* others too.... The Agent newsreader (and all it's relevant data files) that made this posting is running from/stored on an external SCSI HD partition of 650 MByte, encrypted  with the SQUARE algorithm..... The system's TEMP directory, is set up to another seperate (IDE) partition, encrypted with BLOWFISH... I can transfer files, from one to another (or to any other mounted disk) just like any other Windows disk drive.... Regards, Aman.