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." SIDE-ISSUE: Wizard. Given the amount of text above, this should be moved to a separate page. SIDE-ISSUE: Big files in freesites. It will be necessary for jSite to insert big files in freesites once only, and then put a redirect in (maybe remembering a hash too so they can be reinserted if they change). Otherwise everything in a freesite will be inserted with random keys and thus use different keys each time. This will of course improve security significantly. SIDE-ISSUE: Single CHKs should have randomised encryption too if they are inserted as part of an SSK. But not if they are inserted as c...@.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org http://freenetproject.org/cgi-bin/mailman/listinfo/devl
