On Friday 30 July 2010 15:29:54 Matthew Toseland wrote: > Freenet encrypts temp files with a random key, which for non-persistent temp > files is kept in RAM, and for persistent temp files is kept in the client > layer database, which is itself encrypted. > > The encryption of the client layer database is less than perfect. We can fix > this fairly easily, but we will need to re-encrypt node.db4o, and we will > probably want to have a new key for each file (there will be multiple files > as soon as I implement auto-backup of node.db4o). > > If the user sets a high physical seclevel (with a strong password), the > default option for downloads is to download to encrypted temporary space. For > HTML, this is probably safe - the browser will not cache the data and will > hopefully keep it in disk. But for anything that needs to be opened in an > external player, and possibly for media files in general, this doesn't help > much. > > Worse, none of this matters if swap is enabled and not encrypted. > > So we have two options really: > > 1. Offer to turn on encrypted swap in the installer. Keep encrypting > everything. Warn users about saving files out, and media files, and work > towards playing media files in an embedded (e.g. java) player that doesn't > use plaintext temp files. > 2. Give up on encrypting anything on disk, and offer to install TrueCrypt if > it isn't already installed. > > IMHO it is important that Freenet works out of the box, and works reasonably > securely. Arguably it should be possible to install without administrative > rights. But swap files are an unavoidable problem - anything involving keys > in RAM is breakable as long as that ram gets stored to disk. > > https://bugs.freenetproject.org/view.php?id=4262 > https://bugs.freenetproject.org/view.php?id=4258 > To summarize the thread, a lot of people are opposed to any support for physical security in Freenet. On the grounds that people "should" use Truecrypt. I disagree, I believe this is an overly geeky viewpoint, because IMHO casual users, computer illiterate users and users who are just in a hurry should be protected as well as we can protect them, as long as it doesn't cost us a lot of work. If they start off by not being grossly paranoid and then they find something that could get them into trouble, it's a good thing if we provided basic protection. And most of this code is there already. It was added after discussions with the Iran folks who identified physical security as the top issue practically. Clearly the most important consequence of this was the datastore changes, but the datastore changes required the client-cache, and IMHO the client-cache requires basic support for physical security. The Iranians can of course turn off the client cache, although this opens up network attacks; IMHO most users will want it. And the existing code works, at least for basic browsing - we tell the browser not to cache the pages, it won't. Some system level security features are necessary regardless of encryption - opening the browser in incognito mode, filtering HTML, etc.
Unfortunately there is the issue of the swap file, which is somewhat hit and miss, and in any case can be tackled with a single command without having to make drastic changes to your system by installing Truecrypt; and frankly the swap issue is unique because very few privacy programs are written in Java, which has the critical vulnerability that it cannot lock pages. This is what I am going to do - not immediately, but soon, and before 0.8.0: - Port the GF(2^128) code from the kernel. - Implement XTS using that code. - Upgrade the current node.db4o.crypt encryption to a new version using XTS. - Keep the rest of the physical security precautions intact. - In the wizard, recommend to the user that they encrypt their swapfile, if they set the physical security level above LOW. If they are using Windows Vista / Windows 7, show the exact command needed to do so, but don't attempt to run it. In any case provide a link to Truecrypt. Shorten the text on the choice page itself to compensate. Explain that if they save stuff they're on their own. - (Once we have filters for stuff other than HTML) Implement a one-time-only warning, if seclevel is not LOW, when we open a non-HTML file explaining that it may be cached externally and they really really should install Truecrypt. - Implement checkpointing infrastructure for node.db4o. Once a checkpoint has been written, we cannot reuse any freed buckets until the next checkpoint, this ensures that the checkpoint remains valid until that point. Use this to implement auto-backups of db4o. This is IMHO a critical usability feature. - BONUS: Improve disk I/O significantly by either turning off syncing in normal transactions and writing backups regularly, or caching as much as possible in memory and writing periodically / when we need to. IMHO the latter should give more performance, but the two are really basically equivalent. - Consider setting defrag database on startup to true by default, at least if the user chooses a physical seclevel above LOW. Most of the above is either easy or essential regardless of crypto. https://bugs.freenetproject.org/view.php?id=4185 https://bugs.freenetproject.org/view.php?id=4258 https://bugs.freenetproject.org/view.php?id=4243 https://bugs.freenetproject.org/view.php?id=4244 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20101106/42d3f7f3/attachment.pgp>
