Secure FileSystem 9
Interfacing with mountsfs
In order to facilitate the use of SFS with other software such as graphical front-ends, mountsfs has the ability to be run in batch mode in which it will accept abbreviated forms of the usual commands and output more complex results to data files instead of to the screen. External software can then parse the mountsfs output and report the results back to the user. This is how WinSFS performs the task of scanning for SFS volumes, since using direct disk access to do this under Windows is virtually impossible.
Controlling mountsfs in Batch Mode
You can enable the use of batch mode by giving mountsfs the keyword `batch=<filename>' as the first command option. This tells mountsfs to output its results to the file specified in the command instead of to the screen. In batch mode, mountsfs will recognise the additional command `password=' to allow you to specify the password needed to access a volume. For ease of use, you may want to take advantage of the partial-commandname-matching capability of the SFS software to shorten the batch-mode command, so that for example to mount the volume "Test" with a quick-unmount hotkey of Ctrl-Alt-Z, an auto-unmount timeout of 10 minutes, and a password of "secret data" the command would be:
mountsfs b=result.dat v=Test h=Ctrl-Alt-Z t=10 "p=secret data"which is equivalent to the usual
mountsfs volume=test hotkey=ctrl-Alt-Z timeout=10and will result in mountsfs writing the output status of the mount to the file RESULT.DAT.
mountsfs Output in Batch Mode
During normal operation mountsfs may print several lines of information to the screen giving details on the status of the operation being performed and details on currently mounted and unmounted SFS volumes. When you run mountsfs in batch mode, this information is written to a data file with the name and location you have specified using the `batch=' option. For example if you have used:
mountsfs batch=c:\tmp\result.datthen the output will be writting to the file RESULT.DAT in the TMP directory of the C: drive.
The mountsfs output is written to the file as a series of data packets with the same general layout as the ones given in the section "SFS Disk Volume Layout" above. Each packet consists of a packet type identifier followed by the length of the data in the packet, and then by the packet data itself.
The data file is laid out as follows:
Offset Size Type Description
0 4 BYTE[ 4 ] 'SFS1' application identification string
4 4 BYTE[ 4 ] 'INFO' file type identification string
8 2 WORD Information packet 1 ID
10 2 WORD Information packet 1 data length
12 ?? ???? Information packet 1 data
n 2 WORD Information packet 2 ID
n+2 2 WORD Information packet 2 data length
n+4 ?? ???? Information packet 2 data
..........
m 2 WORD Information packet n ID
m+2 2 WORD Information packet n data length
m+4 ?? ???? Information packet n dataThe result records have data packet types with values starting at 1000 to distinguish them from disk volume packets contained within them. These records are for internal use by mountsfs and mountsfs-related programs only and will never be found as part of any other SFS information such as an SFS volume header:
Name Value Information type
SFS_PACKET_INT_RESULT 1000 Result of mountsfs command
SFS_PACKET_INT_INFO 1001 Disk volume informationIf the mountsfs command does not produce information on an encrypted volume, the outupt will consist of a single SFS_PACKET_INT_RESULT result packet. If the command does produce information on an encrypted volume or volumes, the output will consist of one or more SFS_PACKET_INT_INFO information packets followed by a single SFS_PACKET_INT_RESULT result packet. The result packet will always be the last packet in the file.
Packet 1000 - Result of mountsfs Command Packet
The result of mountsfs command packet contains the completion status of the command which has just been executed. The packet layout is as follows:
Offset Size Type Description
0 2 WORD Command result packet ID = 1000
2 2 WORD Command result packet data length
4 2 WORD Command result status (see below)
6 2 WORD Command result message character set
8 2 WORD Command result message length
10 ?? BYTE[] Command result messageIf the command result status is 0 indicating no error occurred, the command result message will have a length of 0 bytes. If the command result status is nonzero indicating that an error occurred, more details on the error will be given in the result message, with the result status being an error code for the type of error which was encountered, or -1 for a nonspecific error type. The use of error codes allows the calling program to define its own error messages rather than using the ones returned by mountsfs. Currently no error codes are defined.
The command result character set is as specified in the section "SFS Disk Volume Layout" above.
The result message is stored as an octet string immediately following the character set and length values. This string should in general not exceed 256 octets.
Packet 1001 - Disk Volume Information Packet
This packet type contains a superset of the disk volume information packets given in the section "SFS Disk Volume Layout" above and provides extra information on the disk layout which is needed to access and mount the volume. The packet layout is as follows:
Offset Size Type Description
0 2 WORD Disk volume information packet ID = 1001
2 2 WORD Disk volume information packet data length
4 2 WORD Physical drive the SFS volume is stored on
6 4 LONG Sector or disk block offset of logical volume
from start of physical volume, or 0 if logical
volume corresponds to physical volume
10 4 LONG Size of the volume in kilobytes
12 2 WORD Removable-media flag (0 = fixed, 1 = removable)
14 ?? BYTE[] SFS volume header recordThe encoding of the physical drive value is as specified in the section "Interfacing with SFS" above.
The SFS volume header record is as specified in the section "SFS Disk Volume Layout" above. The volume header record is encapsulated by the disk volume information packet.
Sample Output File
When used to obtain information on one or more SFS disk volumes, mountsfs will output a series of disk volume header records encapsulated within a disk volume information packet as explained above, and terminate the file with a command result packet. A sample output file produced from a scan of two volumes might be as follows:
'SFS1' application identification string
'INFO' file type identification string
SFS_PACKET_INT_INFO disk volume information packet
Disk volume information
SFS_PACKET_VOLUMEINFO volume information packet
Volume information
SFS_PACKET_ENCRINFO encryption information packet
Encryption information
SFS_PACKET_DISK_BPB filesystem information packet
Filesystem information
SFS_PACKET_INT_INFO disk volume information packet
Disk volume information
SFS_PACKET_VOLUMEINFO volume information packet
Volume information
SFS_PACKET_ENCRINFO encryption information packet
Encryption information
SFS_PACKET_DISK_BPB filesystem information packet
Filesystem information
SFS_PACKET_FASTACCESS direct disk access information packet
Direct disk access
SFS_PACKET_UNMOUNT volume unmount information packet
Volume unmount information
SFS_PACKET_INT_RESULT mountsfs command result packet
Command result information
In order to use this facility, a controlling program should invoke mountsfs in batch mode with the `i' information command. mountsfs will run and write its output to the output file. The controlling program can then read the data from the file, delete the file, and handle the information as appropriate.
Selected Source Code
This section contains a walkthrough of selected portions of the source code (mainly the encryption-related parts) to allow the verification of its correctness and to help people wishing to write SFS-compatible software.
[!!!! Not in this release to save space and because I haven't had time to add it yet, should be in a later version !!!!]
Future Work
The following ideas may be incorporated into future versions of SFS if requested by users. In addition reasonable requests for other improvements may also find their way into SFS.
- Improve error recovery for the encryption process. This is somewhat difficult, and will probably involve keeping a copy of status information and the track currently being encrypted on a local volume to allow a restart in the case of a power failure. There are problems inherent in this as it involves storing sensitive data in a disk file, and will slow down the processing considerably due to the need to write each track to two physically separate disk volumes instead of one continuous one. A partial solution is to keep the status information (simply an index of the disk section currently being encrypted) in the volume header while mksfs is running and provide some sort of restart option if power is lost, although what happens if power dies halfway through writing a track is uncertain.
- A plug-in card which contains a BIOS extension which hooks int 13h and encrypts and entire physical disk (not just one disk volume), from the master boot record at the start to the very last sector at the end. This means all disk I/O must be done via int 13h and won't work on all systems. Cost for the card is estimated to be about $80-$100 for the basic version an up to $200 for the full hardware version whose throughput it significantly higher than the basic version.
Recommended Reading
In recent years a large number of books and articles on crytography have appeared. Many of these are beyond the level of anyone with a casual interest in the subject, but a good overview is given by Dorothy Dennings (now somewhat dated) "Cryptography and Data Security", published by Addison-Wesley in 1982 (ISBN 0-201-10150-5). Bruce Schneier's much more recent "Applied Cryptography", published by John Wiley and Sons in 1993 (ISBN 0-471-59756-2), is probably the best single text on cryptography currently available, and is recommended reading for anyone wanting more information on the principles behind SFS. This book also contains a large list of references to more information on all manner of encryption algorithms, protocols, and technology. Voydock and Kent's tutorial "Security Mechanisms in High-Level Network Procotols", published in the ACM Computing Surveys Vol.15, No.2 (June 1983) provides a good overview of design considerations for encryption systems.
The algorithms and techniques used in SFS are laid down in the following national and international standards:
ANSI X3.106, "American National Standard for Information Systems - Data
Encryption Algorithm - Modes of Operation"
ANSI X9.30 Part 2, "The Secure Hash Algorithm (SHA)"
Australian Standard AS 2805.5.2, "Electronic Funds Transfer - Requirements
for Interface", Part 5.2, "Ciphers - Modes of operation for an n-bit block
cipher algorithm"
ISO 10116:1991, "Information technology - Modes of operation for an n-bit
block cipher algorithm"[1]
ISO 10126-2:1991, "Banking - Procedures for message encipherment (wholesale)
- DEA Algorithm"[1]
NBS FIPS pub. 81, "DES Modes of Operation", 1980[2]
NIST FIPS pub. 180, "Secure Hash Standard", 1993[2]
Information on the weaknesses of some cryptosystems are published in a variety of places. The largest publicly available sources of information are the cryptography conference proceedings which are part of the Springer-Verlag "Lecture Notes in Computer Science" series. Eli Biham and Adi Shamir's "Differential Cryptanalysis of the Data Encryption Standard", also published by Springer-Verlag (ISBN 0-387-97930-1), gives information on the resistance to attack of a number of block ciphers.
Charles Pfleegers book "Security in Computing", published by Prentice Hall in 1989 (ISBN 0-137-98943-1) provides a thorough overview of computer security techniques, including coverage of more obscure areas such as ethical issues.
Three online references which contain links to a large number of other URL's containing computer security and cryptography related information are:
http://retriever.cs.umbc.edu/~mohan/Work/crypt.html
http://www.tansu.com.au/Info/security.html, and
http://www.tezcat.com/web/security/security_top_level.html
These references include links to security and cryptography-related web and gopher servers, FTP sites, newsgroups, mailing lists, bulleting boards, frequently-asked question (FAQ) lists and incident bulletins, conferences, seminars, workshops, and miscellaneous other sources. Another interesting online reference, but with less security-related information than the previous three, is:
http://www.misty.com/laughweb/lweb.html
Information on upcoming meetings and conferences on cryptography and computer security can be found at:
http://www.itd.nrl.navy.mil:80/ITD/5540/ieee/cipher/
A good technical coverage of smart cards can be found in "Smart Card 2000: The Future of IC Cards", published by North-Holland in 1988 (ISBN 0-444-70545-7). The physical and interface characteristics of smart cards are covered in the following international standard:
ISO 7816:1991, "Identification cards - Integrated circuit card with contacts"[1]
Threshold schemes, being a practical application of mathematical theory, are therefore mostly ignored by maths texts. Rudolf Lidl and Harald Niederreiter's "Introduction to Finite Fields and their Applications", published by Cambridge University Press in 1986 (ISBN 0-521-30706-6) provides a good overview of the issues involved with the threshold scheme used by SFS, including a mention of the application of finite fields to cryptography.
Finally, James Bamford's "The Puzzle Palace", published by Houghton-Mifflin in 1982, is a good source of information on the operation of the NSA, albeit slightly dated (it predates the widespread availability of encryption for personal computers, for example).
This list only scratches the surface of the full range of cryptographic and security literature available - a very detailed bibliography can be found in the "Applied Cryptography" book.
Footnote [1]: These publications are available for a horribly high price from ISO-affiliated national standards bodies in most countries. A catalogue of all ISO standards (including draft standards) along with ordering information, can be found at: http://www.iso.ch/welcome.html
Footnote [2]: These publications are available from the National Technical Information Service, Springfield, Virginia 22161. NTIS will take telephone orders on +1 (703) 487-4650 (8:30 AM to 5:30 PM Eastern Time), fax +1 (703) 321-8547. For assistance, call +1 (703) 487-4679.
Staying Current with SFS Developments
As SFS is a continully evolving product, you can use the SFS Web page or mailing list and to stay up to date on the latest SFS developments. The preferred method of obtaining updates on the current status of SFS is through the Web page, which is available as:
http://www.cs.auckland.ac.nz/~pgut01/sfs.html
Alternatively, you can join the SFS mailing list, which has a very low volume and is used mainly to discuss of SFS issues and development work. The list is administered through the mail address `majordomo@mbsks.franken.de'. To join the list, send mail to this address with any subject line and the message body `subscribe sfs-crypt'. You should receive a reply:
You have been added to the SFS mailing list. To submit something to the list, send it to sfs-crypt@mbsks.franken.de. To unsubscribe from the list, send a message with the message body "unsubscribe sfs-crypt" to majordomo@mbsks.franken.de.
To leave the mailing list, send mail to the list administration address with any subject line and the message body `unsubscribe sfs-crypt'. You should receive a reply:
You have been removed from the SFS mailing list. To resubscribe to the list, send a message with the message body "subscribe sfs-crypt" to majordomo@mbsks.franken.de.
For information on the list, send mail to the list administration address with any subject line and the message body `info sfs-crypt'. You should receive a reply containing information on the mailing list and how to use it.
Using SFS
In general SFS is free for personal (private) use. However if you find SFS of use then in order to allow continued development of and enhancements to SFS, in particular the creation of more user-friendly versions of mksfs and mountsfs, of versions for other systems, of a low-cost plug-in card containing whole-disk encryption firmware, and the replacement of the drive I fried testing SFS, a donation of $25 would be appreciated. Alternatively, the donation can be used to cover the legal costs of those people involved in the current US government investigation of the PGP encryption program.
Use of SFS in a commercial, government, or institutional environment or for business purposes is allowed for free for 30 days to allow it to be evaluated. After this period it should be registered for further use. The registration fee covers use of SFS on any one machine at any one time (so you could, for example, use SFS on a machine at work and keep a copy on your notebook PC for use while travelling).
If you decide to send a donation or registration, please specify whether you'd like it to be used for further SFS development work or if it is to go into the PGP legal fund. Cheques or money orders can be sent to:
Peter Gutmann
24 Durness Pl.
Orewa
Auckland
New Zealand
New Zealand banks are very flexible with cheques so sending a personal cheque in your local currency is fine, there's no need to bother with complex currency conversions or bank cheques.
I can also be contacted through email at (among others) the following addresses:
pgut01@cs.auckland.ac.nz
p.gutmann@cs.auckland.ac.nz
peterg@kcbbs.gen.nz
with the first address being the preferred one. Finally, the fastest way to contact me is by phone on +64 9 426-5097 between about 11am and 1am except Mondays and Fridays (remembering that NZ local time is GMT+13, so we're usually about 18-20 hours ahead of the US and about 12 hours ahead of Europe).
Testimony from one of our satisfied customers:
"I hear this crash and I find a rock, wrapped in paper, next to my living room window. I open up the note and it says `You want it in writing? You got it. Next time, use a *real* encryption program. SFS. We know where you live'".
So why aren't *you* using SFS?
Here's what reviewers have been saying about SFS:
"Version 1.2 has several of the advanced features recommended in version 1.1, but not all of the ones I'd like to see in version 1.3. So, it's pretty good except when it's not. Three stars.
You probably won't use half the features anyway. I'm a little ticked off that it clashes with my most exotic memory-resident programs, but otherwise the software runs just fine on my Turbo Rambuster 586. It will probably run like molasses on your 386SX.
It's great value at $25, and I recommend you register it, although that's easy for me to say because reviewers get freebies".
Availability
The latest shareware version of SFS should always be available from the following locations:
FTP sites:
Finland: garbo.uwasa.fi (193.166.120.5)
/pc/crypt
Australia: archie.au (139.130.4.6)
/micros/pc/garbo/pc/crypt
Germany: ftp.germany.eu.net (192.76.144.75)
/pub/comp/msdos/mirror.garbo/pc/crypt
Italy: cnuce_arch.cnr.it (131.114.1.10)
/pub/msdos/garbo.uwasa.fi/pc/crypt
South Africa (Johannesburg):
ftp.mpd.co.za (196.4.76.53)
/pub/garbo/pc/crypt
South Africa (Natal):
owl.und.ac.za (146.230.128.40)
/mirrors/garbo/pc/crypt
Taiwan: nctuccca.edu.tw (140.111.1.10)
/PC/garbo/pc/crypt
USA (St. Louis, MO):
wuarchive.wustl.edu (128.252.135.4)
/systems/msdos/garbo.uwasa.fi/pc/crypt
USA (Walnut Creek, CA):
ftp.cdrom.com (192.153.46.2)
/pub/garbo/pc/crypt
A site which makes SFS available only to US users is:
csn.org
/mpj/I_will_not_export/crypto_???????/secdrv
where the exact value of ??????? is given in /mpj/README.MPJ. This means of access is used to comply with US export restrictions. Please don't use this site unless you're in the US.
BBS's:
The Ferret Bulletin Board System, Arkansas +1 (501) 791-0124 (Log on as "PGP USER" with "PGP" as the password).
The Colorado Catacombs BBS, Colorado +1 (303) 938-9654.
Beta releases of the next version of SFS are available from ftp://ftp.informatik.uni-hamburg.de/pub/virus/crypt/disk/. Beta versions will be indicated by incrementing the least significant digit of the version number from zero, so that if the last release was 1.20 then later betas will be 1.21, 1.22, and so on. Betas of the next version generally don't appear until at least a month or two after the release of the current version. Details on the availability of the latest SFS beta can be found on the SFS Web page as described in the section "Staying Current with SFS Developments" above.
Revision levels
This section details the various improvements and changes made to each new version of SFS, beginning with the first public beta release.
0.90 First public beta
0.97 Second public beta
Added explict support for DRDOS large partitions (which differ from MSDOS large partitions).
Added more internal consistency checks in mksfs, mountsfs, chsfs.
Performed a major rewrite of SFS library internals to improve usability.
Used XMS buffering or a more conservative write strategy to fix occasional copy-on-write buffering problem in newer versions of DOS.
Added support for multiple mounted SFS volumes.
Added WinSFS 0.8, a prototype Windows front-end for SFS.
Added batch mode operation to mountsfs for WinSFS support.
Fixed a problem with a race condition when a hotkey or timed unmount occurs during disk access to an encrypted volume.
Improved the overwriting of the SFS driver data on unmount.
Added better self-checking in the SFS driver during operation.
1.00 General public release
Fixed some problems in the technical section of the docs.
Added the Quick-start section to the docs.
Precomputed the encryption key in SFS.SYS and made assorted other small changes. This makes the driver run approximately 1.7 times faster, and gives a decrease of about 1K in the overall memory usage.
Added even better data overwriting based on an analysis of disk data encoding schemes.
Added a quick introduction to encryption issues section to the docs.
mksfs now asks for a new disk when encrypting floppies, like the DOS format program.
1.10 Maintenance release
Added faster direct disk access for IDE drives.
Fixed an incompatibility with the DOS 6 scandisk.
Added a timeout to the automount password entry routine to allow booting of unattended machines without them waiting forever for a password to be entered.
Changed the error handling code in the driver to still load it if an error occurs during a volume mount, instead of exiting back to DOS.
Added a disk read test when volumes are mounted as an extra check.
Fixed a bug in mountsfs where it wouldn't mount or get info on an SFS volume created on a partition which was not the first partition on the second physical hard disk in the system.
Fixed a problem with /PROMPT strings containing spaces.
Changed the way the drives are scanned in order to speed mountsfs disk mounts.
Added the `hotkey=none' option to disable hotkey unmounts.
Added the option to transparently wipe the original unencrypted data from the disk during the mksfs encryption process.
Added independant unmount timers for each volume instead of using one global timer for all volumes.
chsfs now wipes the original volume header when the `newpass' command is used.
Added the ability to specify default timeout values for each volume.
Added the handling of more escape codes and case conversion for /PROMPT strings.
Added stealth features to the password-handling code to bypass trojan horses.
Fixed a problem with the bizarre reverse-logic check used by the DoubleDisk driver (it indirectly affects SFS).
Fixed several incompatibility problems with DRDOS.
Fixed a problem where a volume decrypted with chsfs and re-encrypted with mksfs couldn't be accessed any more.
Added the ability to access SCSI devices controlled through ASPI and CAM drivers.
Added the ability to mount volumes as fixed, non-removable volumes.
Changed all `automount' references in the documentation to simply `mount'.
Changed the driver to make the use of `/' optional.
Added the ability to detect if it has already been loaded to SFS driver.
1.20 Key Escrow/Smart Card/WinSFS release
Changed the order of disk scanning even further to make mounting floppies slightly faster.
Fixed a bug in chsfs which gave a divide error when changing the password on a volume in a floppy drive.
Changed the disk scanning code again to skip network drives for faster scanning.
Fixed a bug in the SFS driver write-protect error handler for floppies.
Updated the disk overwriting code based on new information obtained from drive manufacturers.
Added the ability to handle timed and hotkey unmounts under Windows to the SFS driver.
Fixed a problem when encrypting some drives over 2GB with unusual drive characteristic remapping.
Fixed a problem with handling of some i18n-ized volume names.
Finally found out how to force DOS to recognize a floppy disk change for mksfs, the occasional int 25h problems reported by mksfs when the `-c' option is used are now fixed.
Added a threshold-scheme-based key escrow system for key safeguarding purposes.
Fixed a problem where SFS's internal cacheing wouldn't be activated if no SFS volumes were present, speeding up the mksfs initial disk scan in this case.
Fixed the problem where a drive acessible via the BIOS and a SCSI driver would be displayed twice, once for BIOS access, once for SCSI access.
Broke the documentation files up into smaller sections to make them more manageable.
Added a pager to the program help screens.
Extended the help screens to provide more information.
Fixed a misfeature in which performing an unmount of the last mounted volume would disable the KEYB.COM keyboard driver.
Added smart card support to allow volumes to be mounted and controlled via smart cards.
Added proper internationalization of volume name character sets.
Rewrote the documentation to use the second person active voice instead of the third person passive voice, and made miscellaneous changes and improvements throughout.
Eliminted the unnecessary mksfs `-o' option.
Changed the `mksfs -c' code to perform more rigorous tests for SCSI and EIDE drives.
Added the ability to specify the drive letter a volume is to be mounted as to mountsfs.
Fixed a problem where chsfs wouldn't ask for a confirmation of the new password when performing a `newpass' command.
Changed the access mode settings to use more intuitive names instead of numeric values.
Changed the command-parsing to accept substrings of commands as well as the full command names.
Fixed a bug which would cause DRDOS to give divide errors if it tried to acess a newly-unmounted volume.
Added a few new features to the anti-keyboard-sniffer code.
Fixed an incompatibility with NCache.
Fixed a race condition in the hotkey unmount handler which occasionally messed up the status of the shift keys.
Credits
Thanks to the readers of comp.os.msdos.programmer and comp.os.linux.development and in particular Jouni Kosonen, for their valuable advice with low-level DOS disk handling and organization, and the users of the Enigma BBS, in particular Arne Rohde, for helping test-run several early versions of the low-level disk handling code on various drive configurations and for providing useful advice on the vagaries of the PC's disk handling. Thanks also to Steven Altchuler for performing all sorts of dangerous tests on SFS volumes and for his heroic efforts in finding the obscure mountsfs bug, and to Vadim Vlasov for help with various thorny problems with low-level disk and device driver programming.
Matthias Bruestle (the greatest chemist of all time and space) provided valuable feedback on assorted problems in mksfs and mountsfs, and risked his disk drives testing the SFS driver and other SFS software. At the behest of the author he also risked imprisonment for Datenvergewaltigung by letting mksfs near his Linux partition.
Colin Plumb made noises about various problems with CFB-mode encryption, corrected me when I tried to explain the need for encrypted IV's in email at 3am, and provided much useful feedback on SFS's operation in general, including the very elegant solution to the CFB-mode encryption problem and help with the disk overwriting method.
Vesselin Bontchev sent in long lists of suggested improvements to SFS, and provided an ongoing commentary on features and ideas for the software (it seems half the functionality provided by SFS is due to his suggestions). Ralf Brown's interrupt list provided help with the haze of obscure interrupts used by mksfs in its quest for random information.
Thanks to John Huttley for the loan of a SCSI controller, Peter Shields for the loan of a SCSI cable, Stuart Woolford for the loan of a SCSI drive which didn't work, and John Huttley for the loan of a SCSI drive which did, in order to get the SCSI interface code for SFS going.
Peter Conrad typset the entire set of SFS docs into LaTeX format. Lynn Prentice helped answer all sorts of annoying questions about Windoze programming for WinSFS. Matthias Bruestle (that chap again) did the German translation and Edoardo Comar did the Italian translation of the WinSFS text strings.
The Beerdigungsinstitut Utzmann (erstes Erlanger Beerdigungsunternehmen) helped clean up the casualties from the SFS beta-testing. Finally, Tony, Geezer, Bill, Ozzy, Ron, and Grandos helped me stay awake during many long nights of debugging low-level disk access code and encryption routines.
Various other people have at various times offered help and suggestions on getting SFS going. My thanks go to them also.
Warranty
1. Customer Obligations
1.1. Customer assumes full responsibility that this program meets the specifications, capacity, capabilities, and other requirements of said customer, and agrees not to bother the author if the program does not perform as expected, or performs other than expected, or does not perform at all.
1.2. Customer assumes full responsibility for any deaths or injuries that may result from the normal or abnormal operation of this program. In the event of casualties exceeding 1000 persons or property damage in excess of $10 million, customer agrees that he or she has stolen the program and we didn't even know he or she had it.
1.3. Customer agrees not to say bad things about the program or the author to anyone claiming to be from "60 Minutes".
2. Very Limited Warranty and Conditions of Sale
2.1. For a period of 90 minutes, commencing from the time you first thought about getting this program, we warrant that this program may or may not be free of any manufacturing defects. It will be replaced during the warranty period upon payment of an amount equal to the original purchase price plus $10.00 for handling. This warranty is void if the program has been examined or run by the user, or if the manual has been read.
2.2. This program is sold on an AS WAS basis. The author makes no warranty that it is, in fact, what we say it is in our propaganda, or that it will perform any useful function. We have no obligation whatsoever other than to provide you with this fine disclaimer.
2.3. Some countries do not allow limitations as to how long an implied warranty lasts, so we refuse to imply anything.
2.4. There is an extremely small but nonzero chance that, through a process known as "tunnelling", this program may spontaneously disappear from its present location and reappear at any random place in the universe, including your neighbours computer system. The author will not be responsible for any damages or inconvenience that may result.
3. Limitation of Liability
3.1. We have no liability or responsibility to the customer, the customers agents, our creditors, your creditors, or anyone else.
