1993-06-12 - Re: CryptoStacker

Header Data

From: RYAN Alan Porter <ryan@rtfm.mlb.fl.us>
To: bbyer@BIX.com
Message Hash: f3dbdd88e47b228f9f50fefdfc3e98b043835ee7ba717366ae0d13fe3aa87d57
Message ID: <Pine.3.03.9306120237.A4623-b100000@rtfm>
Reply To: <9306112008.memo.59593@BIX.com>
UTC Datetime: 1993-06-12 06:35:50 UTC
Raw Date: Fri, 11 Jun 93 23:35:50 PDT

Raw message

From: RYAN Alan Porter <ryan@rtfm.mlb.fl.us>
Date: Fri, 11 Jun 93 23:35:50 PDT
To: bbyer@BIX.com
Subject: Re: CryptoStacker
In-Reply-To: <9306112008.memo.59593@BIX.com>
Message-ID: <Pine.3.03.9306120237.A4623-b100000@rtfm>
MIME-Version: 1.0
Content-Type: text/plain




On Fri, 11 Jun 1993 bbyer@BIX.com wrote:

> If the project is called CryptoStacker, why not use Stacker?
> Have the program go beneath Stacker (or another disk doubling system)
> and encrypt/decrypt the actual stacker file as Stacker reads it?  It
> would be a much simpler solution once you found out how te interface
> with Stacker.

Problems:

	1)  Defeats the purpose of free/cheap-ware.

	2)  Mixes abstraction levels and causes drivers to run 
	     redundantly (and thus, more slowly)

	3)  Would not be modular with further expandability

Solution:

	Take the meat of the suggestion (building upon an already working
system of sector remapping and data mangling) and build upon it.  Indeed,
what I am doing is finding working sources for drivers and network
redirectors and examining them to find one which will serve as a good
model to work from.  This will provide the benefits of working under
Stacker, as you suggested, and will also have the advantages of freeing
us from the list of disadvantages.

> Ben Byer <bbyer@bix.com>

-=Ryan=-
the Bit Wallah


	cat cypherpunk.flames > /dev/null









Thread