On 04/08/10 15:45, Gregory Maxwell wrote: > E.g. if you're concerned that telling the user that freenet uses disk > encryption will make them think they're immune to local attacks, > continue to encrypt the disk as much as freenet can? because a > collection of incomplete measures is still superior to no protection > at all? but don't mention it except in the more technical > documentation. >
We should at least ask whether the user wants freenet to encrypt stuff. Some people have full-disk encryption, in which case there's no point in freenet doing it as well. > It would be really nice if freenet could pin memory like all the other > crypto applications do. Not just to protect users who are concerned > about local attacks but because without it _every freenet user_ is > more at risk of a local attack because it's pretty likely that taking > a freenet user's computer will get you something useful. With Tor, on > the other hand, taking a node will do you no good? so if you have any > tor clue at all you won't even bother trying. Having your equipment > compromised stinks even if you did have it all encrypted. Herd > immunity has value here. > How is this so? If you don't go accessing compromising docs, taking your freenet node is useless (or theoretically supposed to be useless). The blocks are all encrypted and the keys are located elsewhere. > It's nice to advise the user to use truecrypt but sadly people all too > frequently underestimate their threat models. It would probably be > better for the fproxy front page to run 'advertisements' for trucrypt > (on windows) and dmcrypt (on Linux), continually reminding users that > they ought to be using these things regardless of what they currently > believe their threat model to be and to activate/offer to activate as > much encryption as it can. and mention steganography, as well as encryption. TBF disk encryption solutions don't have an equivalent to "erase master.keys". But that doesn't fully do what it sounds like it should, anyway. X
