On 05/09/14 19:43, localghost@eOC4Zm8KjRpMFhNBp6DmI8K4URaq8bQZH45y0dLHEnI wrote:> creamsoda@0vpcRHZV1ftyj4mJpZnuYaG8wpkNIvf3qa3b-LUcsZs wrote : >> >> TAILS is meant to be for short-lived sessions of minutes to hours right? That doesn't lend itself well to freenet which works better over a longer time. > > Ya, I kinda figured that.. just curious if anybody had done it. I was asking for a friend, as stated. I prefer to let Freenet run constantly, to help the network- and have not used TAILS, personally.. > This is exactly why "leave disk crypto to the operating system" isn't so obviously the right policy for Freenet.
The arguments for not doing disk crypto: - We're likely to get it wrong. - If they download video files etc there will probably be leaks. (But it IS possible to limit this) - Memorising a good password is hard, and the users who are willing to do so may be the same group as the users who will install a secure linux distro just to run Freenet, or at least do full disk encryption on Windows (presumably using BitLocker?) - If we do disk crypto we need to turn on swap encryption. This is trivial on recent Windows but arguably not a good idea. The arguments for doing disk crypto: - We want people to run Freenet long-term. They usually won't install a new OS just to run Freenet, and they can't run it long-term from a livecd. This is one of the reasons we support Windows! - People who are willing to remember a long password may not have the technical know-how to set up a secure system. - People who install Freenet casually and then discover something interesting may not want to reinstall at that point. - Tempfiles and other evidence of your past browsing should not be recoverable even if you *have* the password. Most full disk crypto setups don't have this property, but some do (e.g. /tmp on encrypted swap). - We can do some interesting things in the long run such as combining a password with a local nonce and data fetched from the network to decrypt local data, giving "hidden identities" e.g. for WoT/FMS. - In practice physical attacks are likely to be more common than network attacks, in most environments. A long term solution might be to have a separate node (which doesn't store anything private), possibly on dedicated hardware, and client (which stores your downloads and runs from a livecd or whatever, and uses tunnels through the node). But we need a decision in the short run. I used to think that disk crypto in Freenet made sense. I'm half convinced by the "good passwords are hard" thing. operhiem1 (Steve) is in favour of removing it, as is nextgens and most of the old guard (unix philosophy etc). I'm not convinced one way or the other. I will defer; I'll be away very soon; but it's worth discussing again maybe... Technically keeping passworded disk crypto isn't particularly difficult: - Review and merge the crypto pull request. We need this anyway. - Integrate with purge-db4o. (Fairly easy) - Use a proper iterated password function. - Think about changing the UI e.g. ask for a password when first start a download? But what about client-cache? Removing it will mean decrypting people's data and posting a useralert. It slightly speeds up the schedule for purge-db4o.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
