On Friday 30 July 2010 17:02:35 Cory Nelson wrote: > 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.
No, not practical given java is garbage collected, and not supported anyway afaik. Unless maybe some recent nio change? -------------- 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/20100730/751e08f8/attachment.pgp>
