On Wednesday 23 June 2010 13:28:10 Matthew Toseland wrote: > In git I have working support for a single encryption key for a whole > splitfile. This reduces the size of the metadata for a splitfile by a factor > of 2, and is part of the bundle of work I have been doing recently to try to > get all the metadata changes out of the way at once so as to limit the number > of changes, since every time I change how CHKs are calculated it > inconveniences all the uploaders. I have also been working on backwards > compatibility to make reinserts using old formats possible. > > Anyway, this means that changing the splitfile key to something random is > within easy reach (and it would make sense to do it now as it involves > putting the metadata changes already made but not tested into use). This > would significantly improve security but it would make reinserts a lot more > difficult. After a long discussion with p0s, I propose the following user > interface (on the upload form on the queue page): > > OPTION 1: Insert a canonical CCK. > (default if network seclevel = low) > > "This will always produce the same key for the same file. However, if the bad > guys can predict what files you are going to insert, they may be able to use > this to trace you a lot more easily." > > CCK = CHK but with no metadata, so CCK@<hash>/<filename> where filename is > ignored except to create the MIME type and the underlying CHK has a single > splitfile key but it is dependant on the file hash. So you get the same > <hash> part for any insert of the same file, regardless of filename. This > could be implemented quickly and would solve some long-standing grumbles: We > strip the filename and MIME type, we disallow any meta-strings, we disallow > redirects and e.g. NOT_ENOUGH_META_STRINGS in resulting errors (i.e. > translate them to something more appropriate, without the redirects). > > OPTION 2: Insert a random, safe SSK. > (default if network seclevel = maximum; no default if network seclevel = > normal or high) > > "This is much safer than a CCK but the key will be different each time. This > means if an SSK falls out and you reinsert as a random SSK, you will need to > tell people about the new SSK. It also uses more space on the network. > However, if you are the original source of sensitive data you should probably > use this option." > > OPTION 3: Try to reinsert a specific key: [ BOX TO PUT KEY IN ] > > "If you know the key that a file was inserted with, even if it is an SSK, we > can try to reinsert it exactly as it was originally. This is as dangerous as > inserting a CCK. The key must be retrievable from this node." > > We may provide a button to achieve something similar from a completed (or > perhaps partially completed) download on the downloads page. > > OPTION 4: Specify a key [ BOX TO PUT KEY IN ] > > "If you want to e.g. insert a KSK (e.g. k...@myfile, an insecure but > guessable keytype), or specify the SSK keypair, use this option. Anything > inserted under an SSK or KSK will be randomised." > Improved wording:
Insert a canonical key This will always produce the same key for the same file, so is convenient for filesharing. However, if the bad guys can predict what files you are going to insert, they may be able to use this to trace you a lot more easily. Insert a random, safe key This is much safer than the first option, but the key will be different every time you or somebody else inserts the key. Use this if you are the original source of some sensitive data. Insert a file that has been inserted before If you know the key that a file was inserted with, we can try to reinsert it exactly as it was originally. This is as dangerous as inserting a canonical key. The key must be at least partially retrievable. [ KEY BOX ] Specify a key (advanced mode only) If you know the exact key you want to insert to, please specify it here. If it is an SSK, USK or KSK, all the data under it will be encrypted randomly like with option 2. [ KEY BOX ]
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org http://freenetproject.org/cgi-bin/mailman/listinfo/devl
