On Fri, 2005-01-21 at 11:50 +0000, Toad wrote:
> Filling with 0's then deleting is not reliable on journaled
> filesystems.. the files should be encrypted in the first place. A while
> back somebody did some changes to make sure that keys don't show up if
> logLevel is less than debug (or minor?)..

Er.... Toad, you give me a negative answer only to
 my fourth point. Typical commit time for journaled
 filesystem is 5 to 15 seconds, so modification not
 writtend is just a possibility. This is not my
 concern.

Let me better explain my thoughts.

By design, Freenet must protect his users giving the
 greater anonimity possible and the greater plausible
 deniability possible.

AFAIK this philosophy must guide thru all
 implementation. Freenet must do his best to
 protect all his user (if this is an easy task)
 including user that doesn't know how use a cryptoloop
 or barely know how to install a windows program.
Naive, wrongdoer or stupid users must be protected
 too, as long as this is an easy task.

Delete all cleartext info as soon as they are no more
 necessary follow directly from this.
I understand that the nature of the Freenet code
 doesn't allow for an easy review if this happens
 always in the code.

BUT, I see really no reason why Fred must
 leave files filled of cleartext temporary info liying
 around, when Microsoft Word (R) itself lost this habit.

So OK, do not overwrite, just delete 
 temp & client-download files; at least the
 probability that a forensic analisys can
 recover it are greatly *reduced*.

I think a single code line somewhere in Fred
 can do this job. Ok this is not an
 interesting issue, but IMHO it close a big,
 trivial problem in current implementation
 and add a resilience that worth well implement it.

Or will be implemented only in 1.0 ?  ;)

Just my 2 eurocent.   Ciao.   Marco


> 
> On Fri, Jan 21, 2005 at 08:23:15AM +0100, Marco A. Calamari wrote:
> > On Wed, 2005-01-19 at 17:02 +0000, Toad wrote:
> > > On Wed, Jan 19, 2005 at 04:36:13PM +0000, Ben Golding wrote:
> > > > Doesn't storing decrypted data on disk break the "deniability" property
> > > > of Freenet, which is important for freedom of speech?
> > > 
> > > I'd have to check what the current behaviour is... I think we use
> > > temporary file buckets and don't encrypt them, in fproxy, at present...
> > > We should fix this, obviously.
> > 
> > Another check on next minor release IMHO useful would be
> >  delete all file stored in cleartext BOTH when shutting
> >  down the node and when starting it.
> > I mean all file in store/temp and the dir store/temp
> >  itself (to clean temo filenames)
> > Another useful addition would be an config option to
> >  clean all clearinfo places: client-download (both
> >  content and dir), that can be used by others if the node is an
> >  http gateway (has the fproxy port public), logfile
> >  that from time to time can contain keynames in weird
> >  messages or other internal information as stacktraces.
> > Doing this with a simple wiping algoritm (fill with
> >  zero before deletion) would be another good thing.
> > 
> > JM2C.   Marco
> > 
> > > > 
> > > > (after all, you can disable writing the cache to disk, even in IE!)
> > > > 
> > > > Ben Golding
> > > > 
> > > > ----- Original message -----
> > > > From: "Toad" <[EMAIL PROTECTED]>
> > > > To: support@freenetproject.org
> > > > Date: Wed, 19 Jan 2005 12:53:51 +0000
> > > > Subject: Re: [freenet-support] temp files from gateway
> > > > 
> > > > The encrypted files are stored in the store.
> > > > The decrypted files may be stored in the temp directory as well. Which
> > > > is often in the store, subdir temp.
> > > _______________________________________________
> > > Support mailing list
> > > Support@freenetproject.org
> > > http://news.gmane.org/gmane.network.freenet.support
> > > Unsubscribe at 
> > > http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
> > > Or mailto:[EMAIL PROTECTED]
> > -- 
> > 
> > "Oggi e' il domani di cui ci dovevamo preoccupare ieri."
> 
> 
> 
> > _______________________________________________
> > Support mailing list
> > Support@freenetproject.org
> > http://news.gmane.org/gmane.network.freenet.support
> > Unsubscribe at 
> > http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
> > Or mailto:[EMAIL PROTECTED]
> 
> _______________________________________________
> Support mailing list
> Support@freenetproject.org
> http://news.gmane.org/gmane.network.freenet.support
> Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
> Or mailto:[EMAIL PROTECTED]
-- 

"Oggi e' il domani di cui ci dovevamo preoccupare ieri."

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]

Reply via email to