[freenet-dev] Future of disk encryption in Freenet?

[Matthew Toseland]

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, 

Re: [freenet-dev] Future of disk encryption in Freenet?

[Matthew Toseland]

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 

[freenet-dev] Future of disk encryption in Freenet?

[Romain Dalmaso]

On Fri, Aug 6, 2010 at 12:46 PM, Ximin Luo  wrote:
> 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.
>

Some systems do. With dm-crypt and cryptsetup (on Linux kernels), you
can encrypt a disk or anything else using a keyfile. Securely deleting
(using for example shred) the keyfile makes useless all the data on
the disk, whether you know the passphrase or not. The same thing must
be possible with TrueCrypt.

> X
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Future of disk encryption in Freenet?

[Ximin Luo]

On 06/08/10 13:00, Romain Dalmaso wrote:
> Some systems do. With dm-crypt and cryptsetup (on Linux kernels), you
> can encrypt a disk or anything else using a keyfile. Securely deleting
> (using for example shred) the keyfile makes useless all the data on
> the disk, whether you know the passphrase or not. The same thing must
> be possible with TrueCrypt.
> 

i meant, it would be nice if they had something simpler, like `cryptsetup
luksDestroy `, that erases the LUKS master key, instead of messing
around with shred or dd or whatever works for your filesystem.

X

[freenet-dev] Future of disk encryption in Freenet?

[Ximin Luo]

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

Re: [freenet-dev] Future of disk encryption in Freenet?

[Ximin Luo]

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
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Future of disk encryption in Freenet?

[Romain Dalmaso]

On Fri, Aug 6, 2010 at 12:46 PM, Ximin Luo infini...@gmx.com wrote:
 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.


Some systems do. With dm-crypt and cryptsetup (on Linux kernels), you
can encrypt a disk or anything else using a keyfile. Securely deleting
(using for example shred) the keyfile makes useless all the data on
the disk, whether you know the passphrase or not. The same thing must
be possible with TrueCrypt.

 X
 ___
 Devl mailing list
 Devl@freenetproject.org
 http://freenetproject.org/cgi-bin/mailman/listinfo/devl
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Future of disk encryption in Freenet?

[Ximin Luo]

On 06/08/10 13:00, Romain Dalmaso wrote:
 Some systems do. With dm-crypt and cryptsetup (on Linux kernels), you
 can encrypt a disk or anything else using a keyfile. Securely deleting
 (using for example shred) the keyfile makes useless all the data on
 the disk, whether you know the passphrase or not. The same thing must
 be possible with TrueCrypt.
 

i meant, it would be nice if they had something simpler, like `cryptsetup
luksDestroy volume`, that erases the LUKS master key, instead of messing
around with shred or dd or whatever works for your filesystem.

X
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Future of disk encryption in Freenet?

[Gregory Maxwell]

On Wed, Aug 4, 2010 at 4:24 AM, artur  wrote:
> Extra security is not a bad thing. And in the case of storing encrypted temp
> files I agree with Matthew as well, but like I said in my other E-Mail,
> freenet will never be able to protect the user from local attacks.
>
> And I think it is worse to keep the user in the false pretence that he is
> secure, because freenet stores it temp file sencrypted, than telling him:
> ?Hey, freenet helps you to publish and get information anonymously, but from
> the point it reaches your system (Browser, Adobe Reader, Image / Video
> viewer,..) it is out of the scope of freenet. So if you want to be protected
> when your system is sized, install a full disk encryption like TrueCrypt.?
[snip]

If you're concerned that telling a user about all the helpful but
incomplete mechanisms that freenet uses to protect them might give
them a false sense of security then simply don't tell them.

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.

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.


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.

[freenet-dev] Future of disk encryption in Freenet?

[artur]

On 02.08.2010 20:03, Ian Clarke wrote:
> On Mon, Aug 2, 2010 at 11:20 AM, Arne Babenhauserheide  
> wrote:
>> On Sunday 01 August 2010 12:14:51 Ximin Luo wrote:
>>> So yes we should just
>> drop "physical security". To do it properly we'll
>>> have to  fuck with parts
>> of people's machines we really shouldn't be
>>> fucking with; and if they are
>> that paranoid (I am) they should just
>>> encrypt their entire disks, which
>> will cover non-freenet stuff too.
>>
>> For me that would take away one of the
>> main strengths of freenet: People need only install one program and have
>> anonymous and mostly secure communication right away.
>>
>> Why throw away one
>> of the strength freenet already has?
>>
>> Freenet can only attain the goal of
>> spreading uncensorable information, if it is really easy to use. Else it can
>> only reach the geek part of the population.
>
> I agree.  The unix philosophy of "one tool for one task" is all very
> well for the typical unix user who is comfortable stringing multiple
> tools together, but that isn't our target audience.
>
> Installing and running Freenet shouldn't require that a user install a
> bunch of other tools and do a load of configuration, because the
> reality is that most people won't bother.
>
> If we can encrypt on-disk data with relative ease, and Matthew tells
> me we can, then we should.

Extra security is not a bad thing. And in the case of storing encrypted 
temp files I agree with Matthew as well, but like I said in my other 
E-Mail, freenet will never be able to protect the user from local attacks.

And I think it is worse to keep the user in the false pretence that he 
is secure, because freenet stores it temp file sencrypted, than telling 
him: ?Hey, freenet helps you to publish and get information anonymously, 
but from the point it reaches your system (Browser, Adobe Reader, Image 
/ Video viewer,..) it is out of the scope of freenet. So if you want to 
be protected when your system is sized, install a full disk encryption 
like TrueCrypt.?

Otherwise the user will need a very big handbook, where he can look up 
what configurations he has to do in his Browser, which actions are save 
to do, what he should not do,..  And this is far more complicated for 
the user than just installing a disk encryption software.

So if freenet can help to strengthen local security, with little 
performance drawbars and not to much effort in the part of development, 
go for it. But I think the focus should be placed on other parts of freeent.

Re: [freenet-dev] Future of disk encryption in Freenet?

[artur]

On 02.08.2010 20:03, Ian Clarke wrote:

On Mon, Aug 2, 2010 at 11:20 AM, Arne Babenhauserheidearne_...@web.de  wrote:

On Sunday 01 August 2010 12:14:51 Ximin Luo wrote:

So yes we should just

drop physical security. To do it properly we'll

have to  fuck with parts

of people's machines we really shouldn't be

fucking with; and if they are

that paranoid (I am) they should just

encrypt their entire disks, which

will cover non-freenet stuff too.

For me that would take away one of the
main strengths of freenet: People need only install one program and have
anonymous and mostly secure communication right away.

Why throw away one
of the strength freenet already has?

Freenet can only attain the goal of
spreading uncensorable information, if it is really easy to use. Else it can
only reach the geek part of the population.


I agree.  The unix philosophy of one tool for one task is all very
well for the typical unix user who is comfortable stringing multiple
tools together, but that isn't our target audience.

Installing and running Freenet shouldn't require that a user install a
bunch of other tools and do a load of configuration, because the
reality is that most people won't bother.

If we can encrypt on-disk data with relative ease, and Matthew tells
me we can, then we should.


Extra security is not a bad thing. And in the case of storing encrypted 
temp files I agree with Matthew as well, but like I said in my other 
E-Mail, freenet will never be able to protect the user from local attacks.


And I think it is worse to keep the user in the false pretence that he 
is secure, because freenet stores it temp file sencrypted, than telling 
him: “Hey, freenet helps you to publish and get information anonymously, 
but from the point it reaches your system (Browser, Adobe Reader, Image 
/ Video viewer,..) it is out of the scope of freenet. So if you want to 
be protected when your system is sized, install a full disk encryption 
like TrueCrypt.”


Otherwise the user will need a very big handbook, where he can look up 
what configurations he has to do in his Browser, which actions are save 
to do, what he should not do,..  And this is far more complicated for 
the user than just installing a disk encryption software.


So if freenet can help to strengthen local security, with little 
performance drawbars and not to much effort in the part of development, 
go for it. But I think the focus should be placed on other parts of freeent.


___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Future of disk encryption in Freenet?

[Gregory Maxwell]

On Wed, Aug 4, 2010 at 4:24 AM, artur ar...@gmx.net wrote:
 Extra security is not a bad thing. And in the case of storing encrypted temp
 files I agree with Matthew as well, but like I said in my other E-Mail,
 freenet will never be able to protect the user from local attacks.

 And I think it is worse to keep the user in the false pretence that he is
 secure, because freenet stores it temp file sencrypted, than telling him:
 “Hey, freenet helps you to publish and get information anonymously, but from
 the point it reaches your system (Browser, Adobe Reader, Image / Video
 viewer,..) it is out of the scope of freenet. So if you want to be protected
 when your system is sized, install a full disk encryption like TrueCrypt.”
[snip]

If you're concerned that telling a user about all the helpful but
incomplete mechanisms that freenet uses to protect them might give
them a false sense of security then simply don't tell them.

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.

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.


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.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Future of disk encryption in Freenet?

[Ximin Luo]

On 02/08/10 19:33, Matthew Toseland wrote:
>> All the work on physical security - encryption of node.db4o in particular -
>> resulted directly from my discussions with the Nedanet people. In such
>> places as Iran, by far the most likely attack is seizing people's computers
>> and looking at what they have been downloading.

Why, oh why, are they not just recommending full-disk encryption? Why make
Freenet do all this complicated case-by-case patching stuff, when a single
full-disk encryption will be enough?

>> If Tor doesn't use locked pages I'd be very surprised. Even if it doesn't,
>> GPG does.

I understand you're not suggesting to implement swap encryption yourself. The
point of bringing it up is that it's an intrusive step *that's also not enough*
to provide physical security. It changes system performance, and is only one
small fraction of what's needed to achieve the supposed aim.


On 02/08/10 19:33, Matthew Toseland wrote:
>> - alternatively, use the browser in "private mode",
> 
> When we install Freenet we open a browser for the user. When they click the
> rabbit after we have installed, again we open a browser for the user. We
> have control over what browser is opened and with what settings. We do not
> have to merely advise them to use incognito/private mode, we can open it for
> them.
> 
>> don't save any files to disk,
> 
> We can warn the user, depending on the seclevel, with a dismissable warning
> when they try to download a file direct to disk, and/or when they set a
> higher physical seclevel.
> 
>> encrypt your swap,
> 
> On recent Windows, this is one very short command. We can offer to execute
> that command.
> 
>> and delete any state that fred (and plugins) leave behind.
> 
> This is freenet's responsibility simply because we are the program doing the
> deleting a lot of the time: On uninstall, when rewriting on-disk files, etc
> etc.
>> 
>> There are programs that do this already. If you want to make these "easier
>> to use", go develop for those projects, or start your own project that
>> does all of this in one easy program (or more likely, OS distribution).
> 
> I have demonstrated above that most of these are things that we either must
> implement, should implement if they are relatively easy, or should
> recommend.
> 

I wasn't trying to make an exhaustive list; even if you are right about each of
the individual things, they are not ENOUGH to provide proper physical security.

For example, a lot of the plugins will have to be modified to store data inside
node.db4o, usage advice will need to be given to users (eg. have your mail
client not cache stuff, etc). Every single plugin author will need to think
about such things, and design plugin-specific advice and security mechanisms to
take care of those things.

The FAR simpler option is to go for full-disk encryption, *if the user feels
they need it*.

> Another interesting point is that even if you have full disk encryption,
> provided swap is encrypted, it is actually slightly *more* secure for
> Freenet to encrypt its temporary files

This is a non-point, you don't want the disk encryption to be breakable
*anyway*. If the enemy has a knife in your heart you're already dead, it
doesn't matter if you're also wearing a helmet.

>> 
>> But freenet should not be this program, because:
>> 
>> - it greatly increases the complexity we have to deal with, and we are
>> short on developer time already.
> 
> Not true in general.
> 

(see above about plugins)

> Even if we tell people to install Truecrypt, many users won't do so until
> they find some interesting material. By which time it might be too late.

We'll just have to make it clear how important it is. To be quite fair, people
are not stupid, if they are in serious danger they will follow the advice.

If someone is stupid enough to not use full-disk encryption in a hostile
environment, they are also stupid enough to bypass the security mechanism
*you're* suggesting.

> If we want to compromise users, practically speaking we can, unless they are
> *very* dedicated. However, in practice it works because if we did distribute
> compromised builds, eventually somebody would reverse engineer them and
> figure out what was going on.

Not if everyone has this "oh let the freenet devs look after all our security
needs for us" attitude.

> So lets disable ALL local security features and require everyon who wants to
> speak freely to have a PhD in computer security...
> 
> For example we could marginally simplify the code by not using incognito
> mode when launching a browser, not sending no-cache headers to the browser,
> not encrypting the client cache and client layer database, and not filtering
> HTML.

My point was to *simplify* the security mechanism, by recommending full-disk
encryption instead of implementing a complicated hard-to-maintain mish-mash
that only 90% works. You don't need a PhD to run TrueCrypt/cryptsetup, but you
may well need a PhD to maintain all the random 

[freenet-dev] Future of disk encryption in Freenet?

[Ximin Luo]

On 02/08/10 19:03, Ian Clarke wrote:
> Installing and running Freenet shouldn't require that a user install a
> bunch of other tools and do a load of configuration, because the
> reality is that most people won't bother.
> 

Nobody is suggesting freenet be forcibly dependant on installing TrueCrypt. It
should just be the recommended advice given to anyone security-minded enough.

> If we can encrypt on-disk data with relative ease, and Matthew tells
> me we can, then we should.
> 

This by itself is pointless. All it will achieve is the newbie thinking "ooo!
enCRYPTion! that MUST mean i'm safe!!1!one".

For example, Freemail offers a local mail service, which a mail client can pick
up and cache. And the other 5-6 things Matthew mentioned in the email dated
2010-07-31 18:47.

Realistically, if anyone believes there's a significant chance their machine
will be seized, they should use full-disk encryption. If their environment is
hostile enough, they *will* follow this advice.

Or are you considering a scenario where the population is mostly apathetic to
censored material, but people might access it out of curiosity if there was
less chance of being caught? In this case the whole "hand-holding" thing would
be useful, but still very complex to implement effectively.

X

[freenet-dev] Future of disk encryption in Freenet?

[Matthew Toseland]

On Monday 02 August 2010 18:49:24 Ximin Luo wrote:
> On 02/08/10 17:20, Arne Babenhauserheide wrote:
> > On Sunday 01 August 2010 12:14:51 Ximin Luo wrote:
> >> So yes we should just drop "physical security". To do it properly we'll 
> >> have to  fuck with parts of people's machines we really shouldn't be 
> >> fucking with; and if they are that paranoid (I am) they should just 
> >> encrypt their entire disks, which will cover non-freenet stuff too.
> > 
> > For me that would take away one of the main strengths of freenet: People
> > need only install one program and have anonymous and mostly secure
> > communication right away.
> 
> AISB, "the freenet service" (ie. the theoretical design) tries to provide an
> anonymous/DDoS-resistant insert/request service, it doesn't try to protect you
> after you actually *get* that data. If you run freenet, but never access
> anything through FProxy, disk encryption is (for the most part) irrelevant.
> 
> Encrypted node.db4o is for when your computer gets seized, and you've accessed
> (ie. obtained the keys for, and decrypted) incriminating data. But there are
> many other things that may incriminate you, which we can't possibly predict.
> 
> This is a general issue that applies to any access of incriminating data, not
> just freenet. Therefore, it's better to some give general advice:

It is not an intractable problem, nor is it is not unique to Freenet.
> 
> - full-disk encryption is best

This is good advice and we can tell the user in the post-install wizard if they 
select a higher physical seclevel. We can e.g. provide a link to TrueCrypt's 
website.

> - alternatively, use the browser in "private mode", 

When we install Freenet we open a browser for the user. When they click the 
rabbit after we have installed, again we open a browser for the user. We have 
control over what browser is opened and with what settings. We do not have to 
merely advise them to use incognito/private mode, we can open it for them.

> don't save any files to 
> disk, 

We can warn the user, depending on the seclevel, with a dismissable warning 
when they try to download a file direct to disk, and/or when they set a higher 
physical seclevel.

> encrypt your swap, 

On recent Windows, this is one very short command. We can offer to execute that 
command.

> and delete any state that fred (and plugins) leave behind.  

This is freenet's responsibility simply because we are the program doing the 
deleting a lot of the time: On uninstall, when rewriting on-disk files, etc etc.
> 
> There are programs that do this already. If you want to make these "easier to
> use", go develop for those projects, or start your own project that does all 
> of
> this in one easy program (or more likely, OS distribution).

I have demonstrated above that most of these are things that we either must 
implement, should implement if they are relatively easy, or should recommend.

Another interesting point is that even if you have full disk encryption, 
provided swap is encrypted, it is actually slightly *more* secure for Freenet 
to encrypt its temporary files than to rely solely on full disk encryption. The 
reason for this is that each such temporary file has a single key which is kept 
only in RAM - or in node.db4o if it is a persistent temp file. Once the 
download is finished the key is wiped: For non-persistent requests, there is no 
way to get it back, even if the enemy compromises the full disk encryption, 
provided that they can't pick it up from RAM - e.g. if there has been enough 
memory churn (e.g. a full gc), or if the computer has been rebooted.
> 
> But freenet should not be this program, because:
> 
> - it greatly increases the complexity we have to deal with, and we are short 
> on
> developer time already.

Not true in general.

> - a separate project would benefit other services that depend on this, such 
> as Tor.

Not true.
> 
> > Why throw away one of the strength freenet already has?
> 
> It's NOT a strength that freenet already has. It gives a false sense of
> security (take eg. the claims you're making right now!).

Even if we tell people to install Truecrypt, many users won't do so until they 
find some interesting material. By which time it might be too late.
> 
> > Freenet can only attain the goal of spreading uncensorable information, if
> > it is really easy to use. Else it can only reach the geek part of the
> > population.
> 
> Security is more than installing one program. If you use freenet to get some
> incriminating documents then spray paint it all over the front of your house,
> of course you're going to get fucked. Or what if your computer gets seized
> while freenet is running, and everything is in RAM? Encrypting swap is similar
> - it's completely outside of what freenet does.

I have never proposed that Freenet *IMPLEMENTS* swap encryption. We cannot 
write a VXD in Java! I have simply suggested that we offer to enable the 
built-in functionality via changing a 

[freenet-dev] Future of disk encryption in Freenet?

[Matthew Toseland]

On Sunday 01 August 2010 11:14:51 Ximin Luo wrote:
> I agree with this view too. We just don't have enough developer time to worry 
> about this *and* progress with more productive features. Even Tor, which has 
> many times more resources than us, don't worry about swap/etc/whatever.

Tor is written in C. So is GPG. GPG locks pages in memory to ensure keys are 
not leaked to disk. As have C programs doing encryption since a very long time 
ago. THIS IS NOT POSSIBLE IN JAVA. This is a clear technical defficiency that 
should have a technical solution. The only way we can avoid such leaks is to 
recommend people either encrypt or turn off swap, or to offer to do it for 
them. Since on recent Windows versions we can do this, it would be a good idea 
to offer the possibility in the installer, or offer instructions on how to do 
it if/when the user chooses a higher security level in the first time wizard.

Secondly, turning on swap encryption on recent windows is *very* easy. If it 
works. It's a single command. I propose that, *if* the user sets physical 
security above LOW, we have the system tray applet (which will connect via FCP 
to pick up notifications) pop up a dialog box offering to encrypt the swap 
file. It should check whether it is already encrypted first.
> 
> The theoretical scope of freenet design is to have secure and anonymous 
> storage 
> and transfer. (Everything unknown to you) is encrypted so that you can have 
> plausible deniability if your machine gets seized and examined. There is no 
> difference between running a node, and never using it to actually obtain 
> stuff 
> for yourself - you're still providing "the freenet service" to others.

We have a great many mechanisms that theoretically are out of scope but 
practically make a useful difference for users, especially for non-technical 
users, to avoid unnecessary risk and exposure. For example:
- We tell browsers not to cache pages. (This should largely prevent sensitive 
freesites from ever hitting disk, ignoring swap issues)
- We try to open an incognito mode browser if possible. (The user should clear 
his browser history or use a separate browser)
- We filter HTML. (The user should set up a VM which only has access to Fproxy!)
- We encrypt node.db4o, if the user wants a higher physical seclevel. (This is 
already implemented, the issue at the moment is that we need to upgrade the 
encryption before implementing auto-backups)
> 
> However, once you access data in a readable form, you've decrypted it. This 
> is 
> just like accessing anything on any other service (looking at web pages, 
> reading email, etc). Your computer is going to cache it, leaving traces of 
> what 
> you've done.

This is another well established technical problem with a set of well 
established technical solutions. Sensitive sites set no-cache headers, so does 
Freenet. Apart from the swap hole, this is largely a solved problem, at least 
in principle.
> 
> In this scenario, it's up to the individual what level of security they want. 
> It can only be up to the individual - only they know what they've accessed, 
> and 
> can get in trouble for. Security that you don't need is just a waste of time 
> and resources. 

Which is why we ask them. Right now, and will continue to do so.

> Also, if we spend this much time on an issue out of our scope  
> we're effectively DDoSing our own development time.

It's hardly a DDoS.
> 
> So yes we should just drop "physical security". To do it properly we'll have 
> to 
> fuck with parts of people's machines we really shouldn't be fucking with; and 
> if they are that paranoid (I am) they should just encrypt their entire disks, 
> which will cover non-freenet stuff too.

I strongly disagree. We do not have to do any low-level anything. We can make 
Freenet relatively secure out of the box without a huge effort, and without 
unreasonable layer violations. This significantly improves the 
security:usability combination for new users (security and usability are 
inseparable).

All the work on physical security - encryption of node.db4o in particular - 
resulted directly from my discussions with the Nedanet people. In such places 
as Iran, by far the most likely attack is seizing people's computers and 
looking at what they have been downloading. (Freenet isn't actually suitable 
for Iran in general due to poor broadband but that's a discussion for another 
day...). Obviously the most critical issue was the The Register attack i.e. 
caching stuff in the datastore that really shouldn't be cached in the 
datastore. I fixed this by not caching locally requested content in the 
datastore, but this resulted in more requests for such content going to the 
network, which could conceivably be a risk on the network level; so I created 
the client-cache. The client-cache only caches stuff requested locally, and 
there is no mechanism to ensure that stuff you no longer request is instantly 
removed from the client-cache. This is 

[freenet-dev] Future of disk encryption in Freenet?

[Ximin Luo]

On 02/08/10 17:20, Arne Babenhauserheide wrote:
> On Sunday 01 August 2010 12:14:51 Ximin Luo wrote:
>> So yes we should just drop "physical security". To do it properly we'll 
>> have to  fuck with parts of people's machines we really shouldn't be 
>> fucking with; and if they are that paranoid (I am) they should just 
>> encrypt their entire disks, which will cover non-freenet stuff too.
> 
> For me that would take away one of the main strengths of freenet: People
> need only install one program and have anonymous and mostly secure
> communication right away.
> 

AISB, "the freenet service" (ie. the theoretical design) tries to provide an
anonymous/DDoS-resistant insert/request service, it doesn't try to protect you
after you actually *get* that data. If you run freenet, but never access
anything through FProxy, disk encryption is (for the most part) irrelevant.

Encrypted node.db4o is for when your computer gets seized, and you've accessed
(ie. obtained the keys for, and decrypted) incriminating data. But there are
many other things that may incriminate you, which we can't possibly predict.

This is a general issue that applies to any access of incriminating data, not
just freenet. Therefore, it's better to some give general advice:

- full-disk encryption is best
- alternatively, use the browser in "private mode", don't save any files to
disk, encrypt your swap, and delete any state that fred (and plugins) leave 
behind.

There are programs that do this already. If you want to make these "easier to
use", go develop for those projects, or start your own project that does all of
this in one easy program (or more likely, OS distribution).

But freenet should not be this program, because:

- it greatly increases the complexity we have to deal with, and we are short on
developer time already.
- a separate project would benefit other services that depend on this, such as 
Tor.

> Why throw away one of the strength freenet already has?
> 

It's NOT a strength that freenet already has. It gives a false sense of
security (take eg. the claims you're making right now!).

> Freenet can only attain the goal of spreading uncensorable information, if
> it is really easy to use. Else it can only reach the geek part of the
> population.
> 

Security is more than installing one program. If you use freenet to get some
incriminating documents then spray paint it all over the front of your house,
of course you're going to get fucked. Or what if your computer gets seized
while freenet is running, and everything is in RAM? Encrypting swap is similar
- it's completely outside of what freenet does.

Relying on freenet developers to provide total security, is extremely naive.
Centralising security into the hands of a few - sound familiar? What's the
difference between trusting *us*, and trusting the government?

"Spreading uncensorable information" is a nice goal, but it can only work if
everyone participates. You're (as in, one is) not being helpful, if all you do
is sit on your ass and let us encrypt your swap file without understanding wtf
you're letting us do to *YOUR COMPUTER*, believing that this absolves you from
watching your own back.

"When the freedom they wished for most was freedom from responsibility, then
Athens ceased to be free and was never free again. "

X

[freenet-dev] Future of disk encryption in Freenet?

[Arne Babenhauserheide]

On Sunday 01 August 2010 12:14:51 Ximin Luo wrote:
> So yes we should just
drop "physical security". To do it properly we'll
> have to  fuck with parts
of people's machines we really shouldn't be
> fucking with; and if they are
that paranoid (I am) they should just
> encrypt their entire disks, which
will cover non-freenet stuff too.

For me that would take away one of the
main strengths of freenet: People need only install one program and have
anonymous and mostly secure communication right away. 

Why throw away one
of the strength freenet already has? 

Freenet can only attain the goal of
spreading uncensorable information, if it is really easy to use. Else it can
only reach the geek part of the population. 

Best wishes, 
Arne

[freenet-dev] Future of disk encryption in Freenet?

[Gregory Maxwell]

On Mon, Aug 2, 2010 at 3:22 PM, Ximin Luo  wrote:
[snip]
> This is a non-point, you don't want the disk encryption to be breakable
> *anyway*. If the enemy has a knife in your heart you're already dead, it
> doesn't matter if you're also wearing a helmet.

Ah! So this is why no one anywhere ever wares a helmet without also
wearing body armor.

As always, freenet-dev is an educational adventure!

[freenet-dev] Future of disk encryption in Freenet?

[Ian Clarke]

On Mon, Aug 2, 2010 at 11:20 AM, Arne Babenhauserheide  
wrote:
> On Sunday 01 August 2010 12:14:51 Ximin Luo wrote:
>> So yes we should just
> drop "physical security". To do it properly we'll
>> have to ?fuck with parts
> of people's machines we really shouldn't be
>> fucking with; and if they are
> that paranoid (I am) they should just
>> encrypt their entire disks, which
> will cover non-freenet stuff too.
>
> For me that would take away one of the
> main strengths of freenet: People need only install one program and have
> anonymous and mostly secure communication right away.
>
> Why throw away one
> of the strength freenet already has?
>
> Freenet can only attain the goal of
> spreading uncensorable information, if it is really easy to use. Else it can
> only reach the geek part of the population.

I agree.  The unix philosophy of "one tool for one task" is all very
well for the typical unix user who is comfortable stringing multiple
tools together, but that isn't our target audience.

Installing and running Freenet shouldn't require that a user install a
bunch of other tools and do a load of configuration, because the
reality is that most people won't bother.

If we can encrypt on-disk data with relative ease, and Matthew tells
me we can, then we should.

Ian.

-- 
Ian Clarke
CEO, SenseArray
Email: ian at sensearray.com
Ph: +1 512 422 3588

[freenet-dev] Future of disk encryption in Freenet?

[Ian Clarke]

On Fri, Jul 30, 2010 at 9:29 AM, Matthew Toseland
 wrote:
> 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.

I think we should make some effort to achieve physical security, but
it isn't a primary goal - there are just too many ways that someone
can be compromised if the attacker has physical access to the machine,
and addressing all of them is WAY beyond the scope of this project.
Its not like we don't already have a huge task, without taking on
additional problems.

We should do something things to help with physical security, but I
think worrying about swap is taking it too far - if the user is that
concerned about it then they should address it outside the context of
Freenet (and we can provide advice to this end).

Ian.

-- 
Ian Clarke
CEO, SenseArray
Email: ian at sensearray.com
Ph: +1 512 422 3588

Re: [freenet-dev] Future of disk encryption in Freenet?

[Arne Babenhauserheide]

On Sunday 01 August 2010 12:14:51 Ximin Luo wrote:
 So yes we should just
drop physical security. To do it properly we'll
 have to  fuck with parts
of people's machines we really shouldn't be
 fucking with; and if they are
that paranoid (I am) they should just
 encrypt their entire disks, which
will cover non-freenet stuff too.

For me that would take away one of the
main strengths of freenet: People need only install one program and have
anonymous and mostly secure communication right away. 

Why throw away one
of the strength freenet already has? 

Freenet can only attain the goal of
spreading uncensorable information, if it is really easy to use. Else it can
only reach the geek part of the population. 

Best wishes, 
Arne
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Future of disk encryption in Freenet?

[Ian Clarke]

On Fri, Jul 30, 2010 at 9:29 AM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
 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.

I think we should make some effort to achieve physical security, but
it isn't a primary goal - there are just too many ways that someone
can be compromised if the attacker has physical access to the machine,
and addressing all of them is WAY beyond the scope of this project.
Its not like we don't already have a huge task, without taking on
additional problems.

We should do something things to help with physical security, but I
think worrying about swap is taking it too far - if the user is that
concerned about it then they should address it outside the context of
Freenet (and we can provide advice to this end).

Ian.

-- 
Ian Clarke
CEO, SenseArray
Email: i...@sensearray.com
Ph: +1 512 422 3588
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Future of disk encryption in Freenet?

[Ximin Luo]

On 02/08/10 17:20, Arne Babenhauserheide wrote:
 On Sunday 01 August 2010 12:14:51 Ximin Luo wrote:
 So yes we should just drop physical security. To do it properly we'll 
 have to  fuck with parts of people's machines we really shouldn't be 
 fucking with; and if they are that paranoid (I am) they should just 
 encrypt their entire disks, which will cover non-freenet stuff too.
 
 For me that would take away one of the main strengths of freenet: People
 need only install one program and have anonymous and mostly secure
 communication right away.
 

AISB, the freenet service (ie. the theoretical design) tries to provide an
anonymous/DDoS-resistant insert/request service, it doesn't try to protect you
after you actually *get* that data. If you run freenet, but never access
anything through FProxy, disk encryption is (for the most part) irrelevant.

Encrypted node.db4o is for when your computer gets seized, and you've accessed
(ie. obtained the keys for, and decrypted) incriminating data. But there are
many other things that may incriminate you, which we can't possibly predict.

This is a general issue that applies to any access of incriminating data, not
just freenet. Therefore, it's better to some give general advice:

- full-disk encryption is best
- alternatively, use the browser in private mode, don't save any files to
disk, encrypt your swap, and delete any state that fred (and plugins) leave 
behind.

There are programs that do this already. If you want to make these easier to
use, go develop for those projects, or start your own project that does all of
this in one easy program (or more likely, OS distribution).

But freenet should not be this program, because:

- it greatly increases the complexity we have to deal with, and we are short on
developer time already.
- a separate project would benefit other services that depend on this, such as 
Tor.

 Why throw away one of the strength freenet already has?
 

It's NOT a strength that freenet already has. It gives a false sense of
security (take eg. the claims you're making right now!).

 Freenet can only attain the goal of spreading uncensorable information, if
 it is really easy to use. Else it can only reach the geek part of the
 population.
 

Security is more than installing one program. If you use freenet to get some
incriminating documents then spray paint it all over the front of your house,
of course you're going to get fucked. Or what if your computer gets seized
while freenet is running, and everything is in RAM? Encrypting swap is similar
- it's completely outside of what freenet does.

Relying on freenet developers to provide total security, is extremely naive.
Centralising security into the hands of a few - sound familiar? What's the
difference between trusting *us*, and trusting the government?

Spreading uncensorable information is a nice goal, but it can only work if
everyone participates. You're (as in, one is) not being helpful, if all you do
is sit on your ass and let us encrypt your swap file without understanding wtf
you're letting us do to *YOUR COMPUTER*, believing that this absolves you from
watching your own back.

When the freedom they wished for most was freedom from responsibility, then
Athens ceased to be free and was never free again. 

X
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Future of disk encryption in Freenet?

[Matthew Toseland]

On Sunday 01 August 2010 11:14:51 Ximin Luo wrote:
 I agree with this view too. We just don't have enough developer time to worry 
 about this *and* progress with more productive features. Even Tor, which has 
 many times more resources than us, don't worry about swap/etc/whatever.

Tor is written in C. So is GPG. GPG locks pages in memory to ensure keys are 
not leaked to disk. As have C programs doing encryption since a very long time 
ago. THIS IS NOT POSSIBLE IN JAVA. This is a clear technical defficiency that 
should have a technical solution. The only way we can avoid such leaks is to 
recommend people either encrypt or turn off swap, or to offer to do it for 
them. Since on recent Windows versions we can do this, it would be a good idea 
to offer the possibility in the installer, or offer instructions on how to do 
it if/when the user chooses a higher security level in the first time wizard.

Secondly, turning on swap encryption on recent windows is *very* easy. If it 
works. It's a single command. I propose that, *if* the user sets physical 
security above LOW, we have the system tray applet (which will connect via FCP 
to pick up notifications) pop up a dialog box offering to encrypt the swap 
file. It should check whether it is already encrypted first.
 
 The theoretical scope of freenet design is to have secure and anonymous 
 storage 
 and transfer. (Everything unknown to you) is encrypted so that you can have 
 plausible deniability if your machine gets seized and examined. There is no 
 difference between running a node, and never using it to actually obtain 
 stuff 
 for yourself - you're still providing the freenet service to others.

We have a great many mechanisms that theoretically are out of scope but 
practically make a useful difference for users, especially for non-technical 
users, to avoid unnecessary risk and exposure. For example:
- We tell browsers not to cache pages. (This should largely prevent sensitive 
freesites from ever hitting disk, ignoring swap issues)
- We try to open an incognito mode browser if possible. (The user should clear 
his browser history or use a separate browser)
- We filter HTML. (The user should set up a VM which only has access to Fproxy!)
- We encrypt node.db4o, if the user wants a higher physical seclevel. (This is 
already implemented, the issue at the moment is that we need to upgrade the 
encryption before implementing auto-backups)
 
 However, once you access data in a readable form, you've decrypted it. This 
 is 
 just like accessing anything on any other service (looking at web pages, 
 reading email, etc). Your computer is going to cache it, leaving traces of 
 what 
 you've done.

This is another well established technical problem with a set of well 
established technical solutions. Sensitive sites set no-cache headers, so does 
Freenet. Apart from the swap hole, this is largely a solved problem, at least 
in principle.
 
 In this scenario, it's up to the individual what level of security they want. 
 It can only be up to the individual - only they know what they've accessed, 
 and 
 can get in trouble for. Security that you don't need is just a waste of time 
 and resources. 

Which is why we ask them. Right now, and will continue to do so.

 Also, if we spend this much time on an issue out of our scope  
 we're effectively DDoSing our own development time.

It's hardly a DDoS.
 
 So yes we should just drop physical security. To do it properly we'll have 
 to 
 fuck with parts of people's machines we really shouldn't be fucking with; and 
 if they are that paranoid (I am) they should just encrypt their entire disks, 
 which will cover non-freenet stuff too.

I strongly disagree. We do not have to do any low-level anything. We can make 
Freenet relatively secure out of the box without a huge effort, and without 
unreasonable layer violations. This significantly improves the 
security:usability combination for new users (security and usability are 
inseparable).

All the work on physical security - encryption of node.db4o in particular - 
resulted directly from my discussions with the Nedanet people. In such places 
as Iran, by far the most likely attack is seizing people's computers and 
looking at what they have been downloading. (Freenet isn't actually suitable 
for Iran in general due to poor broadband but that's a discussion for another 
day...). Obviously the most critical issue was the The Register attack i.e. 
caching stuff in the datastore that really shouldn't be cached in the 
datastore. I fixed this by not caching locally requested content in the 
datastore, but this resulted in more requests for such content going to the 
network, which could conceivably be a risk on the network level; so I created 
the client-cache. The client-cache only caches stuff requested locally, and 
there is no mechanism to ensure that stuff you no longer request is instantly 
removed from the client-cache. This is also true of the downloads database: 

Re: [freenet-dev] Future of disk encryption in Freenet?

[Matthew Toseland]

On Monday 02 August 2010 18:49:24 Ximin Luo wrote:
 On 02/08/10 17:20, Arne Babenhauserheide wrote:
  On Sunday 01 August 2010 12:14:51 Ximin Luo wrote:
  So yes we should just drop physical security. To do it properly we'll 
  have to  fuck with parts of people's machines we really shouldn't be 
  fucking with; and if they are that paranoid (I am) they should just 
  encrypt their entire disks, which will cover non-freenet stuff too.
  
  For me that would take away one of the main strengths of freenet: People
  need only install one program and have anonymous and mostly secure
  communication right away.
 
 AISB, the freenet service (ie. the theoretical design) tries to provide an
 anonymous/DDoS-resistant insert/request service, it doesn't try to protect you
 after you actually *get* that data. If you run freenet, but never access
 anything through FProxy, disk encryption is (for the most part) irrelevant.
 
 Encrypted node.db4o is for when your computer gets seized, and you've accessed
 (ie. obtained the keys for, and decrypted) incriminating data. But there are
 many other things that may incriminate you, which we can't possibly predict.
 
 This is a general issue that applies to any access of incriminating data, not
 just freenet. Therefore, it's better to some give general advice:

It is not an intractable problem, nor is it is not unique to Freenet.
 
 - full-disk encryption is best

This is good advice and we can tell the user in the post-install wizard if they 
select a higher physical seclevel. We can e.g. provide a link to TrueCrypt's 
website.

 - alternatively, use the browser in private mode, 

When we install Freenet we open a browser for the user. When they click the 
rabbit after we have installed, again we open a browser for the user. We have 
control over what browser is opened and with what settings. We do not have to 
merely advise them to use incognito/private mode, we can open it for them.

 don't save any files to 
 disk, 

We can warn the user, depending on the seclevel, with a dismissable warning 
when they try to download a file direct to disk, and/or when they set a higher 
physical seclevel.

 encrypt your swap, 

On recent Windows, this is one very short command. We can offer to execute that 
command.

 and delete any state that fred (and plugins) leave behind.  

This is freenet's responsibility simply because we are the program doing the 
deleting a lot of the time: On uninstall, when rewriting on-disk files, etc etc.
 
 There are programs that do this already. If you want to make these easier to
 use, go develop for those projects, or start your own project that does all 
 of
 this in one easy program (or more likely, OS distribution).

I have demonstrated above that most of these are things that we either must 
implement, should implement if they are relatively easy, or should recommend.

Another interesting point is that even if you have full disk encryption, 
provided swap is encrypted, it is actually slightly *more* secure for Freenet 
to encrypt its temporary files than to rely solely on full disk encryption. The 
reason for this is that each such temporary file has a single key which is kept 
only in RAM - or in node.db4o if it is a persistent temp file. Once the 
download is finished the key is wiped: For non-persistent requests, there is no 
way to get it back, even if the enemy compromises the full disk encryption, 
provided that they can't pick it up from RAM - e.g. if there has been enough 
memory churn (e.g. a full gc), or if the computer has been rebooted.
 
 But freenet should not be this program, because:
 
 - it greatly increases the complexity we have to deal with, and we are short 
 on
 developer time already.

Not true in general.

 - a separate project would benefit other services that depend on this, such 
 as Tor.

Not true.
 
  Why throw away one of the strength freenet already has?
 
 It's NOT a strength that freenet already has. It gives a false sense of
 security (take eg. the claims you're making right now!).

Even if we tell people to install Truecrypt, many users won't do so until they 
find some interesting material. By which time it might be too late.
 
  Freenet can only attain the goal of spreading uncensorable information, if
  it is really easy to use. Else it can only reach the geek part of the
  population.
 
 Security is more than installing one program. If you use freenet to get some
 incriminating documents then spray paint it all over the front of your house,
 of course you're going to get fucked. Or what if your computer gets seized
 while freenet is running, and everything is in RAM? Encrypting swap is similar
 - it's completely outside of what freenet does.

I have never proposed that Freenet *IMPLEMENTS* swap encryption. We cannot 
write a VXD in Java! I have simply suggested that we offer to enable the 
built-in functionality via changing a windows config setting.
 
 Relying on freenet developers to provide total security, is 

Re: [freenet-dev] Future of disk encryption in Freenet?

[Ximin Luo]

On 02/08/10 19:33, Matthew Toseland wrote:
 All the work on physical security - encryption of node.db4o in particular -
 resulted directly from my discussions with the Nedanet people. In such
 places as Iran, by far the most likely attack is seizing people's computers
 and looking at what they have been downloading.

Why, oh why, are they not just recommending full-disk encryption? Why make
Freenet do all this complicated case-by-case patching stuff, when a single
full-disk encryption will be enough?

 If Tor doesn't use locked pages I'd be very surprised. Even if it doesn't,
 GPG does.

I understand you're not suggesting to implement swap encryption yourself. The
point of bringing it up is that it's an intrusive step *that's also not enough*
to provide physical security. It changes system performance, and is only one
small fraction of what's needed to achieve the supposed aim.


On 02/08/10 19:33, Matthew Toseland wrote:
 - alternatively, use the browser in private mode,
 
 When we install Freenet we open a browser for the user. When they click the
 rabbit after we have installed, again we open a browser for the user. We
 have control over what browser is opened and with what settings. We do not
 have to merely advise them to use incognito/private mode, we can open it for
 them.
 
 don't save any files to disk,
 
 We can warn the user, depending on the seclevel, with a dismissable warning
 when they try to download a file direct to disk, and/or when they set a
 higher physical seclevel.
 
 encrypt your swap,
 
 On recent Windows, this is one very short command. We can offer to execute
 that command.
 
 and delete any state that fred (and plugins) leave behind.
 
 This is freenet's responsibility simply because we are the program doing the
 deleting a lot of the time: On uninstall, when rewriting on-disk files, etc
 etc.
 
 There are programs that do this already. If you want to make these easier
 to use, go develop for those projects, or start your own project that
 does all of this in one easy program (or more likely, OS distribution).
 
 I have demonstrated above that most of these are things that we either must
 implement, should implement if they are relatively easy, or should
 recommend.
 

I wasn't trying to make an exhaustive list; even if you are right about each of
the individual things, they are not ENOUGH to provide proper physical security.

For example, a lot of the plugins will have to be modified to store data inside
node.db4o, usage advice will need to be given to users (eg. have your mail
client not cache stuff, etc). Every single plugin author will need to think
about such things, and design plugin-specific advice and security mechanisms to
take care of those things.

The FAR simpler option is to go for full-disk encryption, *if the user feels
they need it*.

 Another interesting point is that even if you have full disk encryption,
 provided swap is encrypted, it is actually slightly *more* secure for
 Freenet to encrypt its temporary files

This is a non-point, you don't want the disk encryption to be breakable
*anyway*. If the enemy has a knife in your heart you're already dead, it
doesn't matter if you're also wearing a helmet.

 
 But freenet should not be this program, because:
 
 - it greatly increases the complexity we have to deal with, and we are
 short on developer time already.
 
 Not true in general.
 

(see above about plugins)

 Even if we tell people to install Truecrypt, many users won't do so until
 they find some interesting material. By which time it might be too late.

We'll just have to make it clear how important it is. To be quite fair, people
are not stupid, if they are in serious danger they will follow the advice.

If someone is stupid enough to not use full-disk encryption in a hostile
environment, they are also stupid enough to bypass the security mechanism
*you're* suggesting.

 If we want to compromise users, practically speaking we can, unless they are
 *very* dedicated. However, in practice it works because if we did distribute
 compromised builds, eventually somebody would reverse engineer them and
 figure out what was going on.

Not if everyone has this oh let the freenet devs look after all our security
needs for us attitude.

 So lets disable ALL local security features and require everyon who wants to
 speak freely to have a PhD in computer security...
 
 For example we could marginally simplify the code by not using incognito
 mode when launching a browser, not sending no-cache headers to the browser,
 not encrypting the client cache and client layer database, and not filtering
 HTML.

My point was to *simplify* the security mechanism, by recommending full-disk
encryption instead of implementing a complicated hard-to-maintain mish-mash
that only 90% works. You don't need a PhD to run TrueCrypt/cryptsetup, but you
may well need a PhD to maintain all the random security patchwork hacks that
people have added to the source code over several years.

If 

Re: [freenet-dev] Future of disk encryption in Freenet?

[Gregory Maxwell]

On Mon, Aug 2, 2010 at 3:22 PM, Ximin Luo infini...@gmx.com wrote:
[snip]
 This is a non-point, you don't want the disk encryption to be breakable
 *anyway*. If the enemy has a knife in your heart you're already dead, it
 doesn't matter if you're also wearing a helmet.

Ah! So this is why no one anywhere ever wares a helmet without also
wearing body armor.

As always, freenet-dev is an educational adventure!
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Future of disk encryption in Freenet?

[artur]

On 30.07.2010 16:29, 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
>

Hi,

I think freenet should focus on what it can do.

Freenet can protect the User from attacks outside the System, freenet 
will never be able to protect the user from attacks when the system 
itself is compromised.
And this should be stated clear to the user.
Everything else will keep the user in false safety.

If the user wants to be save from information leeks within his system, 
he has to install a system wide encryption software which includes swap 
space (like truecrypt), evary other solution will never be secure.
If Freenet tells the user that all files are only stored encrypted on 
disk (by freenet), many will be kept in a sense of false safety. The 
user will not know  what he is allowed to do and what will break his 
security. There are just too many ways (temp files, swap ...) to leak 
information?s.  Freenet will never be able to implement solutions for 
all usecases, so the responsibility will be by the user. And this is far 
more complicated for the user (knowing how it works so he can decide 
what is save to do and what not) than installing another software to 
strengthen his security.

If freenet states clear, what it can protect the user from and what not 
and help him to find solutions for other attacks (telling him to use 
truecrypt) will help the most in the end.

[freenet-dev] Future of disk encryption in Freenet?

[Ximin Luo]

I agree with this view too. We just don't have enough developer time to worry 
about this *and* progress with more productive features. Even Tor, which has 
many times more resources than us, don't worry about swap/etc/whatever.

The theoretical scope of freenet design is to have secure and anonymous storage 
and transfer. (Everything unknown to you) is encrypted so that you can have 
plausible deniability if your machine gets seized and examined. There is no 
difference between running a node, and never using it to actually obtain stuff 
for yourself - you're still providing "the freenet service" to others.

However, once you access data in a readable form, you've decrypted it. This is 
just like accessing anything on any other service (looking at web pages, 
reading email, etc). Your computer is going to cache it, leaving traces of what 
you've done.

In this scenario, it's up to the individual what level of security they want. 
It can only be up to the individual - only they know what they've accessed, and 
can get in trouble for. Security that you don't need is just a waste of time 
and resources. Also, if we spend this much time on an issue out of our scope 
we're effectively DDoSing our own development time.

So yes we should just drop "physical security". To do it properly we'll have to 
fuck with parts of people's machines we really shouldn't be fucking with; and 
if they are that paranoid (I am) they should just encrypt their entire disks, 
which will cover non-freenet stuff too.

Obviously, we should try to make it clear (like Tor[1]) what Freenet DOES and 
DOES NOT do. "the freenet service" only tries to provide an 
anonymous/DDoS-resistant insert/request service, it doesn't try to protect you 
after you actually *get* that data.

X

[1] http://www.torproject.org/download.html.en#Warning

On 01/08/10 00:30, Steve Oliver wrote:
> That's a good point, stop worrying about the physical side of things because
> it is a bit pointless. Perhaps just recommend that the user install
> Truecrypt and refer them to the Truecrypt site, give them a strong warning
> that if their drive is not encrypted, Freenet can't actually protect them
> from physical attacks.
>
>
> On Jul 31, 2010, at 9:52 AM, xor wrote:
>
>> On Friday 30 July 2010 04:29:54 pm Matthew Toseland wrote:
>>>
>>> 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.
>>
>> Offering to reconfigure swap to be encrypted is out of scope. And not
>> possible on Windows
>>
>>> 2. Give up on encrypting anything on disk, and offer to install
>>> TrueCrypt if it isn't already installed.
>>
>> Offering TrueCrypt is out of scope
>>
>> I see a third option:
>>
>> 3. Realize that most users have a real LOAD of stuff on their hard disks
>> which could get them screwed. Get rid of physical security. Encrypting the
>> Freenet stuff does not help because they will use browsers which cache
>> dangerous stuff and do downloads of dangerous stuff etc. The really
>> paranoid ones will use TrueCrypt anyway. And encryption makes stuff slow.
>>
>> I mean it IS nice that we have a physical security level but I wouldn't
>> have offered that feature from the beginning on.
>>
>> If you want to be safe when your computer gets seized you absolutely have
>> to do full disk encryption, something will ALWAYS leak out otherwise.

Re: [freenet-dev] Future of disk encryption in Freenet?

[Ximin Luo]

I agree with this view too. We just don't have enough developer time to worry 
about this *and* progress with more productive features. Even Tor, which has 
many times more resources than us, don't worry about swap/etc/whatever.


The theoretical scope of freenet design is to have secure and anonymous storage 
and transfer. (Everything unknown to you) is encrypted so that you can have 
plausible deniability if your machine gets seized and examined. There is no 
difference between running a node, and never using it to actually obtain stuff 
for yourself - you're still providing the freenet service to others.


However, once you access data in a readable form, you've decrypted it. This is 
just like accessing anything on any other service (looking at web pages, 
reading email, etc). Your computer is going to cache it, leaving traces of what 
you've done.


In this scenario, it's up to the individual what level of security they want. 
It can only be up to the individual - only they know what they've accessed, and 
can get in trouble for. Security that you don't need is just a waste of time 
and resources. Also, if we spend this much time on an issue out of our scope 
we're effectively DDoSing our own development time.


So yes we should just drop physical security. To do it properly we'll have to 
fuck with parts of people's machines we really shouldn't be fucking with; and 
if they are that paranoid (I am) they should just encrypt their entire disks, 
which will cover non-freenet stuff too.


Obviously, we should try to make it clear (like Tor[1]) what Freenet DOES and 
DOES NOT do. the freenet service only tries to provide an 
anonymous/DDoS-resistant insert/request service, it doesn't try to protect you 
after you actually *get* that data.


X

[1] http://www.torproject.org/download.html.en#Warning

On 01/08/10 00:30, Steve Oliver wrote:

That's a good point, stop worrying about the physical side of things because
it is a bit pointless. Perhaps just recommend that the user install
Truecrypt and refer them to the Truecrypt site, give them a strong warning
that if their drive is not encrypted, Freenet can't actually protect them
from physical attacks.


On Jul 31, 2010, at 9:52 AM, xor wrote:


On Friday 30 July 2010 04:29:54 pm Matthew Toseland wrote:


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.


Offering to reconfigure swap to be encrypted is out of scope. And not
possible on Windows


2. Give up on encrypting anything on disk, and offer to install
TrueCrypt if it isn't already installed.


Offering TrueCrypt is out of scope

I see a third option:

3. Realize that most users have a real LOAD of stuff on their hard disks
which could get them screwed. Get rid of physical security. Encrypting the
Freenet stuff does not help because they will use browsers which cache
dangerous stuff and do downloads of dangerous stuff etc. The really
paranoid ones will use TrueCrypt anyway. And encryption makes stuff slow.

I mean it IS nice that we have a physical security level but I wouldn't
have offered that feature from the beginning on.

If you want to be safe when your computer gets seized you absolutely have
to do full disk encryption, something will ALWAYS leak out otherwise.

___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Future of disk encryption in Freenet?

[artur]

On 30.07.2010 16:29, 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



Hi,

I think freenet should focus on what it can do.

Freenet can protect the User from attacks outside the System, freenet 
will never be able to protect the user from attacks when the system 
itself is compromised.

And this should be stated clear to the user.
Everything else will keep the user in false safety.

If the user wants to be save from information leeks within his system, 
he has to install a system wide encryption software which includes swap 
space (like truecrypt), evary other solution will never be secure.
If Freenet tells the user that all files are only stored encrypted on 
disk (by freenet), many will be kept in a sense of false safety. The 
user will not know  what he is allowed to do and what will break his 
security. There are just too many ways (temp files, swap ...) to leak 
information’s.  Freenet will never be able to implement solutions for 
all usecases, so the responsibility will be by the user. And this is far 
more complicated for the user (knowing how it works so he can decide 
what is save to do and what not) than installing another software to 
strengthen his security.


If freenet states clear, what it can protect the user from and what not 
and help him to find solutions for other attacks (telling him to use 
truecrypt) will help the most in the end.


___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Future of disk encryption in Freenet?

[Steve Oliver]

That's a good point, stop worrying about the physical side of things because it 
is a bit pointless. Perhaps just recommend that the user install Truecrypt and 
refer them to the Truecrypt site, give them a strong warning that if their 
drive is not encrypted, Freenet can't actually protect them from physical 
attacks.


On Jul 31, 2010, at 9:52 AM, xor wrote:

> On Friday 30 July 2010 04:29:54 pm Matthew Toseland wrote:
>> 
>> 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. 
> 
> Offering to reconfigure swap to be encrypted is out of scope. And not 
> possible 
> on Windows
> 
>> 2. Give up on encrypting anything on disk, and
>> offer to install TrueCrypt if it isn't already installed.
> 
> Offering TrueCrypt is out of scope
> 
> I see a third option:
> 
> 3. Realize that most users have a real LOAD of stuff on their hard disks 
> which 
> could get them screwed. Get rid of physical security. Encrypting the Freenet 
> stuff does not help because they will use browsers which cache dangerous 
> stuff 
> and do downloads of dangerous stuff etc. The really paranoid ones will use 
> TrueCrypt anyway. And encryption makes stuff slow.
> 
> I mean it IS nice that we have a physical security level but I wouldn't have 
> offered that feature from the beginning on.
> 
> If you want to be safe when your computer gets seized you absolutely have to 
> do full disk encryption, something will ALWAYS leak out otherwise.
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Future of disk encryption in Freenet?

[Matthew Toseland]

On Saturday 31 July 2010 14:52:43 xor wrote:
> On Friday 30 July 2010 04:29:54 pm Matthew Toseland wrote:
> > 
> > 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. 
> 
> Offering to reconfigure swap to be encrypted is out of scope. And not 
> possible 
> on Windows
> 
> >  2. Give up on encrypting anything on disk, and
> >  offer to install TrueCrypt if it isn't already installed.
> 
> Offering TrueCrypt is out of scope
> 
> I see a third option:
> 
> 3. Realize that most users have a real LOAD of stuff on their hard disks 
> which 
> could get them screwed. Get rid of physical security. Encrypting the Freenet 
> stuff does not help because they will use browsers which cache dangerous 
> stuff 
> and do downloads of dangerous stuff etc. The really paranoid ones will use 
> TrueCrypt anyway. And encryption makes stuff slow.
> 
> I mean it IS nice that we have a physical security level but I wouldn't have 
> offered that feature from the beginning on.
> 
> If you want to be safe when your computer gets seized you absolutely have to 
> do full disk encryption, something will ALWAYS leak out otherwise.
> 
This is the typical, modularist, perfectionist unix philosophy that so many 
geeks espouse. It has many advantages. It is not however what is best for the 
*typical* end user.

It needs to be possible to install Freenet quickly and easily, and to then use 
it without grossly compromising yourself. If you choose to improve your local 
security later on, or if you do something that we have clearly warned against, 
that's not our problem.

But we cannot expect users to wait for hours while Truecrypt creates volumes, 
nor can we leave users who just want to try it *completely* unprotected.

What we can do is:
- Offer to turn on swap encryption in the installer, since on Windows 7 and 
Vista Business/Ultimate it is very easy, and since as a java application we do 
not have access to locked memory (unlike e.g. pgp).
- Ask the user what their physical security needs are.
- Prevent obvious threats such as web-bugs in HTML, and caching of pages.
- Strongly recommend, and automatically use if possible, the "incognito" or 
"privacy" mode present in both Chrome and Firefox in recent versions. Combined 
with the above, this makes HTML essentially safe.
- Encrypt everything that we usefully can encrypt.
- Warn them when they are going to do something potentially dangerous: 
Downloading a file to disk (as opposed to temporary space), loading a file that 
is likely to be opened in an external tool i.e. be written to disk first, etc. 
Make the warning permanently dismissable.
- Recommend to them that they install Truecrypt, and provide a hyperlink.

This is the philosophy that we have taken so far, partly as a result of my 
talking with people with contacts in Nedanet. What they told me was that 
physical security is by far the biggest threat. Even before that, we have 
always taken reasonable precautions - if we take the minimalist approach we 
wouldn't even filter HTML, we would stick instructions for setting up a safe 
browsing VM in a README somewhere!

The point is that Freenet should be:
1) Easy AND
2) Secure by default unless it tells you otherwise
-- 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: 

[freenet-dev] Future of disk encryption in Freenet?

[Matthew Toseland]

On Saturday 31 July 2010 15:45:59 Cory Nelson wrote:
> On Fri, Jul 30, 2010 at 9:58 AM, Matthew Toseland
>  wrote:
> > On Friday 30 July 2010 17:02:35 Cory Nelson wrote:
> >> 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?
> 
> Large pages seem to work with -XX:+UseLargePages
> 
> Found here:
> http://www.oracle.com/technetwork/java/javase/tech/largememory-jsp-137182.html
> http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

Which has nothing whatsoever to do with what we are discussing.

It is possible that there is some variant on ByteBuffer.allocateDirect() in a 
recent JVM that allows us to allocate some space that is locked in memory, 
which would provide additional confidentiality for keys. Anything that is just 
created as an object - *and that includes the temporary structures involved in 
encryption implemented in java* (whether by us or by sun) - is potentially 
swappable.
-- 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: 

[freenet-dev] Future of disk encryption in Freenet?

[Cory Nelson]

On Sat, Jul 31, 2010 at 10:38 AM, Matthew Toseland
 wrote:
> On Saturday 31 July 2010 15:45:59 Cory Nelson wrote:
>> On Fri, Jul 30, 2010 at 9:58 AM, Matthew Toseland
>>  wrote:
>> > On Friday 30 July 2010 17:02:35 Cory Nelson wrote:
>> >> 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?
>>
>> Large pages seem to work with -XX:+UseLargePages
>>
>> Found here:
>> http://www.oracle.com/technetwork/java/javase/tech/largememory-jsp-137182.html
>> http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
>
> Which has nothing whatsoever to do with what we are discussing.
>
> It is possible that there is some variant on ByteBuffer.allocateDirect() in a 
> recent JVM that allows us to allocate some space that is locked in memory, 
> which would provide additional confidentiality for keys. Anything that is 
> just created as an object - *and that includes the temporary structures 
> involved in encryption implemented in java* (whether by us or by sun) - is 
> potentially swappable.

Perhaps I am misunderstanding those Java pages, but it looked to me
like that option makes Java use large pages for all allocations
(objects included).  I don't know about Linux but in Windows large
pages are _always_ locked in memory -- they are not swappable.

-- 
Cory Nelson
http://int64.org

[freenet-dev] Future of disk encryption in Freenet?

[xor]

On Friday 30 July 2010 04:29:54 pm Matthew Toseland wrote:
> 
> 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. 

Offering to reconfigure swap to be encrypted is out of scope. And not possible 
on Windows

>  2. Give up on encrypting anything on disk, and
>  offer to install TrueCrypt if it isn't already installed.

Offering TrueCrypt is out of scope

I see a third option:

3. Realize that most users have a real LOAD of stuff on their hard disks which 
could get them screwed. Get rid of physical security. Encrypting the Freenet 
stuff does not help because they will use browsers which cache dangerous stuff 
and do downloads of dangerous stuff etc. The really paranoid ones will use 
TrueCrypt anyway. And encryption makes stuff slow.

I mean it IS nice that we have a physical security level but I wouldn't have 
offered that feature from the beginning on.

If you want to be safe when your computer gets seized you absolutely have to 
do full disk encryption, something will ALWAYS leak out otherwise.
-- 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: 

[freenet-dev] Future of disk encryption in Freenet?

[Cory Nelson]

On Fri, Jul 30, 2010 at 9:58 AM, Matthew Toseland
 wrote:
> On Friday 30 July 2010 17:02:35 Cory Nelson wrote:
>> 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?

Large pages seem to work with -XX:+UseLargePages

Found here:
http://www.oracle.com/technetwork/java/javase/tech/largememory-jsp-137182.html
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html


-- 
Cory Nelson
http://int64.org

Re: [freenet-dev] Future of disk encryption in Freenet?

[xor]

On Friday 30 July 2010 04:29:54 pm Matthew Toseland wrote:
 
 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. 

Offering to reconfigure swap to be encrypted is out of scope. And not possible 
on Windows

  2. Give up on encrypting anything on disk, and
  offer to install TrueCrypt if it isn't already installed.

Offering TrueCrypt is out of scope

I see a third option:

3. Realize that most users have a real LOAD of stuff on their hard disks which 
could get them screwed. Get rid of physical security. Encrypting the Freenet 
stuff does not help because they will use browsers which cache dangerous stuff 
and do downloads of dangerous stuff etc. The really paranoid ones will use 
TrueCrypt anyway. And encryption makes stuff slow.

I mean it IS nice that we have a physical security level but I wouldn't have 
offered that feature from the beginning on.

If you want to be safe when your computer gets seized you absolutely have to 
do full disk encryption, something will ALWAYS leak out otherwise.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Future of disk encryption in Freenet?

[Cory Nelson]

On Fri, Jul 30, 2010 at 9:58 AM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
 On Friday 30 July 2010 17:02:35 Cory Nelson wrote:
 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?

Large pages seem to work with -XX:+UseLargePages

Found here:
http://www.oracle.com/technetwork/java/javase/tech/largememory-jsp-137182.html
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html


-- 
Cory Nelson
http://int64.org
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Future of disk encryption in Freenet?

[Matthew Toseland]

On Saturday 31 July 2010 15:45:59 Cory Nelson wrote:
 On Fri, Jul 30, 2010 at 9:58 AM, Matthew Toseland
 t...@amphibian.dyndns.org wrote:
  On Friday 30 July 2010 17:02:35 Cory Nelson wrote:
  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?
 
 Large pages seem to work with -XX:+UseLargePages
 
 Found here:
 http://www.oracle.com/technetwork/java/javase/tech/largememory-jsp-137182.html
 http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

Which has nothing whatsoever to do with what we are discussing.

It is possible that there is some variant on ByteBuffer.allocateDirect() in a 
recent JVM that allows us to allocate some space that is locked in memory, 
which would provide additional confidentiality for keys. Anything that is just 
created as an object - *and that includes the temporary structures involved in 
encryption implemented in java* (whether by us or by sun) - is potentially 
swappable.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Future of disk encryption in Freenet?

[Matthew Toseland]

On Saturday 31 July 2010 14:52:43 xor wrote:
 On Friday 30 July 2010 04:29:54 pm Matthew Toseland wrote:
  
  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. 
 
 Offering to reconfigure swap to be encrypted is out of scope. And not 
 possible 
 on Windows
 
   2. Give up on encrypting anything on disk, and
   offer to install TrueCrypt if it isn't already installed.
 
 Offering TrueCrypt is out of scope
 
 I see a third option:
 
 3. Realize that most users have a real LOAD of stuff on their hard disks 
 which 
 could get them screwed. Get rid of physical security. Encrypting the Freenet 
 stuff does not help because they will use browsers which cache dangerous 
 stuff 
 and do downloads of dangerous stuff etc. The really paranoid ones will use 
 TrueCrypt anyway. And encryption makes stuff slow.
 
 I mean it IS nice that we have a physical security level but I wouldn't have 
 offered that feature from the beginning on.
 
 If you want to be safe when your computer gets seized you absolutely have to 
 do full disk encryption, something will ALWAYS leak out otherwise.
 
This is the typical, modularist, perfectionist unix philosophy that so many 
geeks espouse. It has many advantages. It is not however what is best for the 
*typical* end user.

It needs to be possible to install Freenet quickly and easily, and to then use 
it without grossly compromising yourself. If you choose to improve your local 
security later on, or if you do something that we have clearly warned against, 
that's not our problem.

But we cannot expect users to wait for hours while Truecrypt creates volumes, 
nor can we leave users who just want to try it *completely* unprotected.

What we can do is:
- Offer to turn on swap encryption in the installer, since on Windows 7 and 
Vista Business/Ultimate it is very easy, and since as a java application we do 
not have access to locked memory (unlike e.g. pgp).
- Ask the user what their physical security needs are.
- Prevent obvious threats such as web-bugs in HTML, and caching of pages.
- Strongly recommend, and automatically use if possible, the incognito or 
privacy mode present in both Chrome and Firefox in recent versions. Combined 
with the above, this makes HTML essentially safe.
- Encrypt everything that we usefully can encrypt.
- Warn them when they are going to do something potentially dangerous: 
Downloading a file to disk (as opposed to temporary space), loading a file that 
is likely to be opened in an external tool i.e. be written to disk first, etc. 
Make the warning permanently dismissable.
- Recommend to them that they install Truecrypt, and provide a hyperlink.

This is the philosophy that we have taken so far, partly as a result of my 
talking with people with contacts in Nedanet. What they told me was that 
physical security is by far the biggest threat. Even before that, we have 
always taken reasonable precautions - if we take the minimalist approach we 
wouldn't even filter HTML, we would stick instructions for setting up a safe 
browsing VM in a README somewhere!

The point is that Freenet should be:
1) Easy AND
2) Secure by default unless it tells you otherwise


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Future of disk encryption in Freenet?

[Steve Oliver]

That's a good point, stop worrying about the physical side of things because it 
is a bit pointless. Perhaps just recommend that the user install Truecrypt and 
refer them to the Truecrypt site, give them a strong warning that if their 
drive is not encrypted, Freenet can't actually protect them from physical 
attacks.


On Jul 31, 2010, at 9:52 AM, xor wrote:

 On Friday 30 July 2010 04:29:54 pm Matthew Toseland wrote:
 
 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. 
 
 Offering to reconfigure swap to be encrypted is out of scope. And not 
 possible 
 on Windows
 
 2. Give up on encrypting anything on disk, and
 offer to install TrueCrypt if it isn't already installed.
 
 Offering TrueCrypt is out of scope
 
 I see a third option:
 
 3. Realize that most users have a real LOAD of stuff on their hard disks 
 which 
 could get them screwed. Get rid of physical security. Encrypting the Freenet 
 stuff does not help because they will use browsers which cache dangerous 
 stuff 
 and do downloads of dangerous stuff etc. The really paranoid ones will use 
 TrueCrypt anyway. And encryption makes stuff slow.
 
 I mean it IS nice that we have a physical security level but I wouldn't have 
 offered that feature from the beginning on.
 
 If you want to be safe when your computer gets seized you absolutely have to 
 do full disk encryption, something will ALWAYS leak out otherwise.
 ___
 Devl mailing list
 Devl@freenetproject.org
 http://freenetproject.org/cgi-bin/mailman/listinfo/devl

___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Future of disk encryption in Freenet?

[Cory Nelson]

On Sat, Jul 31, 2010 at 10:38 AM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
 On Saturday 31 July 2010 15:45:59 Cory Nelson wrote:
 On Fri, Jul 30, 2010 at 9:58 AM, Matthew Toseland
 t...@amphibian.dyndns.org wrote:
  On Friday 30 July 2010 17:02:35 Cory Nelson wrote:
  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?

 Large pages seem to work with -XX:+UseLargePages

 Found here:
 http://www.oracle.com/technetwork/java/javase/tech/largememory-jsp-137182.html
 http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

 Which has nothing whatsoever to do with what we are discussing.

 It is possible that there is some variant on ByteBuffer.allocateDirect() in a 
 recent JVM that allows us to allocate some space that is locked in memory, 
 which would provide additional confidentiality for keys. Anything that is 
 just created as an object - *and that includes the temporary structures 
 involved in encryption implemented in java* (whether by us or by sun) - is 
 potentially swappable.

Perhaps I am misunderstanding those Java pages, but it looked to me
like that option makes Java use large pages for all allocations
(objects included).  I don't know about Linux but in Windows large
pages are _always_ locked in memory -- they are not swappable.

-- 
Cory Nelson
http://int64.org
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Future of disk encryption in Freenet?

[Matthew Toseland]

On Friday 30 July 2010 17:02:35 Cory Nelson wrote:
> On Fri, Jul 30, 2010 at 7:29 AM, 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.
> 
> 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: 

[freenet-dev] Future of disk encryption in Freenet?

[Matthew Toseland]

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
-- 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: 

[freenet-dev] Future of disk encryption in Freenet?

[Cory Nelson]

On Fri, Jul 30, 2010 at 7:29 AM, 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.

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

Re: [freenet-dev] Future of disk encryption in Freenet?

[Cory Nelson]

On Fri, Jul 30, 2010 at 7:29 AM, Matthew Toseland
t...@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
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Future of disk encryption in Freenet?

[Matthew Toseland]

On Friday 30 July 2010 17:02:35 Cory Nelson wrote:
 On Fri, Jul 30, 2010 at 7:29 AM, Matthew Toseland
 t...@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?


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl