Thanks for the questions Matthew, Matthew Toseland wrote: > Okay, so: > - You can keep it on disk, just encrypt it with an ephemeral key. (In > the long run).
Still thinking of that one. Present plan is RAMdisk-only, with the need to 'commit' it to Freenet. Please note that I'm looking to provide some shelter for users in mandatory encryption-key disclosure jurisdictions, such as the UK. The test scenario is: - police confiscate your PC - police go through all your files, and demand encryption keys for any files that appear to be encrypted - if you can't offer a technically plausible explanation for the files not being cleartext, you're looking at 2+ years' jail So any freenet application, IMHO, must offer strong protection against this. To address this need, I'm planning to add encryption, where if users install the optional python package 'SSLCrypto' (refer www.freenet.org.nz/python), they'll be able to encrypt their private keys and stash them as KSK@<my-favourite-song><my-favourite-torture-modality> or whatever. The aim is for freedisks to reside only within freenet, and temporarily within the user's RAM. In the above scenario, as long as the user keeps their shell history file clear (and their swapfile encrypted), there will be no evidence that they have ever created, written to or even accessed any particular freedisk. The user then can rest on the general Freenet PD defense. (/me can't wait for the first actual court test of a freenet PD defense) > - How are you handling conflicts? In most scenarios, only one user will hold the private key for a freedisk, and other users will hold only public keys. Given that the freedisk manifest holds the records for all files (ie, there are no separate 'subdirectory manifests', users with read access will only see changes when they do the next 'update'. It is totally at the owner's discretion when they 'add' then 'commit', and totally at users' discretion when they 'update'. ** Note - Freedisk manifests will be stored as USKs ** As for scenarios where 2 or more users possess private keys, that's where collisions may occur unless they can liase out of band, eg IRC/I2P. I am determined to avoid depending on KSK-thrashing schemes (eg Frost, old Freemail) for conflict prevention. (Bad experiences with Freemail, where several different KSK-thrash algos all failed to cope with freenet's 'performance' at the time). All of this implies a nasty assumption: users need to be aware that people mounting a freedisk may sometimes not be getting the latest version - same caveat as with freesites. Cheers David > > On Tue, May 30, 2006 at 12:34:54PM +1200, David McNab wrote: >> (this discussion has been moved into its own-thread to get it back on-topic) >> >> Matthew Toseland wrote: >>> How are you handling committing a directory? >> Hehe, I lost a bit of sleep thinking through that one :) >> >> What I've come up with is 4 'pseudo-files' that live in the toplevel >> directory of a freedisk: >> - .status - readonly, when read returns a status keyword, one of: >> - 'idle' - neither updating nor committing >> - 'committing' - dusk is syncing back into freenet >> - 'updating' - disk is syncing locally from freenet >> - 'failed\n<more details>' - something fatal happened >> - .publickey - read/write - write an SSK public key into this file to >> link the local freedisk with an in-freenet directory, so the >> directory can be mounted readonly >> - .privatekey - read/write - write an SSK private key into this file to >> link the local freedisk with an in-freenet directory, so the >> directory can be mounted read/write >> - .cmd - write-only - typically one-word commands will be written in, >> such as 'commit' or 'update' >> >> While committing or updating, the directory tree will be readonly, >> despite any permissions to the contrary. >> >> When a freedisk is 'update'd from freenet, only the nodes >> (file/directory records) will be fetched, not the data. When/if an >> individual file is opened in read, update or append mode, the file's >> data will be fetched as a CHK from freenet. If a file is opened in >> write-only mode (ie truncate), no freenet fetch will occur, since the >> file will become a new CHK with no reference to past content. >> >> When files are locally written, the changes will reside only in memory >> until the next commit. >> >> I'm working on a command-line utility called 'freedisk' which handles >> all the pseudo-files' I/O in a simple front-end, for example: >> >> freedisk -m /mnt/freenet new fred >> Create a new freedisk called 'fred', at /mnt/freenet/usr/fred, >> mounted readonly, with new random pub/priv keys >> >> freedisk -m /mnt/freenet add foo SSK at yadayadayada >> Import a freedisk and mount readonlly, at /mnt/freenet/usr/foo >> >> freedisk -m /mnt/freenet update foo >> Update freedisk 'foo' (at /mnt/freenet/usr/foo') from freenet >> >> freedisk -m /mnt/freenet add bar SSK at yadayada private >> Import a freedisk and mount read/write, at /mnt/freenet/usr/bar, >> using SSK private key SSK at yadayada >> >> freedisk -m /mnt/freenet commit bar >> Commit directory /mnt/freenet/usr/bar back into freenet >> >> If the environment variable 'FREEDISK_MOUNTPOINT' is set, then the >> '-m /mnt/freenet' option becomes unnecessary. >> >> Whenever a file's contents are fetched from freenet, it will be cached >> in memory, not on disk - this is for security reasons, since if a PC is >> uplifted by an attacker, a hard disk analysis won't identify anyone as >> having accessed a freedisk (as long as they have an encrypted swapfile, >> that is!) >> >> In the xml directory file discussed below, the 'hash' attribute will be >> hexadecimal SHA(1) of the file's contents. (Not base64, because of the >> plurality of base64 alphabets). >> >>>> To be honest, my gut feeling is that it's best for the 'freedisk' >>>> project if I implement my own manifest scheme. The idea would be: >>>> >>>> - a manifest key, inserted as a single 'text/xml' file into >>>> USK at blahblahblah/name/n, and of the form: >>>> >>>> <freedisk name="diskname" owner="nick"> >>>> <node path="/"/> >>>> <node path="/chinese_democracy.doc" >>>> hash="yadayada" >>>> size="nnn" >>>> mimetype="application/msword" >>>> uri="CHK at yadayadayada" >>>> /> >>>> ... >>>> </freedisk> >>>> >>>> - CHKs for each file node >> Cheers >> David >> >> _______________________________________________ >> Devl mailing list >> Devl at freenetproject.org >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -- Kind regards David
