On Fri, Jul 30, 2010 at 7:29 AM, Matthew Toseland <toad at amphibian.dyndns.org> 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.
3. Distribute a secured Linux VirtualBox image that uses full-disk encryption. > 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. I know that at least Windows lets you lock pages in RAM. Maybe Java has a launch option that does this? Even better would be to use large pages, which are more efficient (lowers overhead and TLB cache misses) and are also locked in RAM. -- Cory Nelson http://int64.org
