1995-12-18 - Re: Secured RM ? (source)

Header Data

From: Ben Holiday <ncognito@gate.net>
To: cypherpunks@toad.com
Message Hash: 9ce30fe8a2fb6a3afe5d7a0e7f26065155f35ac3e337f6e1fb3504a364355a66
Message ID: <Pine.A32.3.91.951218004301.41900A-100000@hopi.gate.net>
Reply To: <199512171048.VAA23204@sweeney.cs.monash.edu.au>
UTC Datetime: 1995-12-18 09:12:40 UTC
Raw Date: Mon, 18 Dec 1995 17:12:40 +0800

Raw message

From: Ben Holiday <ncognito@gate.net>
Date: Mon, 18 Dec 1995 17:12:40 +0800
To: cypherpunks@toad.com
Subject: Re: Secured RM ? (source)
In-Reply-To: <199512171048.VAA23204@sweeney.cs.monash.edu.au>
Message-ID: <Pine.A32.3.91.951218004301.41900A-100000@hopi.gate.net>
MIME-Version: 1.0
Content-Type: text/plain




On Sun, 17 Dec 1995, Jiri Baum wrote:

> > In this particular case what im concerned about is a temporary  cleartext 
> > copy of a permanently encrypted document.  The cleartext only exists for 
> > about 1-4 seconds, and then is deleted, so backups arent really a 
> > problem..  
> 
> Is it then necessary to write it to disk?

Im pretty sure that its nessecary.. at least at this point.  Basically 
what im working on is a bit of front end that trys to make keeping things 
encrypted a bit less of a hassle.  It needs to be able to read multiple 
file types, and as such it does some odd things. It opens the file and 
figures out the magic for it, closes it, then jumps to the right routine 
for reading the particular thing.. the file is opened again, perhaps 
once, perhaps repeatedly, depnding on the nature of what is going on.. 
then when it finishes with the file the cleartext copy is removed.. the 
main idea pushing me here is that if you were to encrypt things on your 
harddrive for storage, you would most likely want access to them at some 
point, and if your like me, you'd want access to them on a regular basis. 
Prior to starting work on this project i would manually decode whichever 
file i needed, work with it, andd then delete it. This was a pain in the 
ass, and also somewhat less secure since im only human and could 
conceivabley forget to resecure the file after im done using it.  So 
looking at it from a relaxed standpoint.. the code as it stands now is at 
least as good as the previou method i was using, and is alot simpler. :) 
To be a bit more critical, neither method seems to be the BEST  method.. 

I hate saying this cause it feels like a cop out, but I keep coming back to 
the question of usability versus iron-clad security. At this point there 
is no noticible speed difference between using the program with encrypted 
versus decrypted files. Im pretty concerned about the overhead of getting 
too involved in a flawless implementation. I think at this point if i 
could produce a first release that would be "good enough" to pass (for 
example) a moderatly sophisticated once over by local law enforcement, i 
would be content.  Once thats available I have alot of other things tthat 
I'd like to see done better..  Incidentally, i'm planning to post the 
full details including an FTP site sometime in january or febuary.. at 
that point i expect to be torn to shreds by the cryptographic comunity.. 

:) 







Thread