[whispersystems] Data encryption on devices/threat model

[Natanji]

Hi all,
I've been using Signal/TextSecure for a really long time and have been
really happy about the additional of Signal Desktop. However, I noticed
that Signal Desktop does not give users the option to encrypt the data
on the device with a user-defined password, which is something the
Android app offers.

I believe this is a very real threat to user's security and no full,
public version of Signal should be released that doesn't offer this
option. This has a lot to do with what I view as the threat model for
Signal Desktop, and I want to explain here why I think that Signal
Desktop should actually *never* store unencrypted data on a user's
device, and perhaps even *force* users to encrypt the data with a
user-defined password.

One reason for this is that on most Desktop OSes (e.g. Windows), the
data folder can be accessed by any program running on the computer. This
is different from the Android and iOS system where each app runs in a
much more sandboxed environment. We've seen in the past that even
popular applications like Skype somehow access delicate data such as the
Firefox password database. What I'm saying is, you cannot prevent apps
on Desktop from reading out all the data that Signal has saved. You
might be able to prevent an app from directly accessing another app's
memory and getting all the files from there though - I don't know enough
about this, I'm not an expert on Linux/Windows permissions.

Also, full device encryption isn't ubiquitous on Desktop OSes, but both
standard on iOS and Android. So when a device gets lost in a turned-off
state, it's arguably worse on a Desktop OS. We also should inform users
about what they need to do if their device ever gets lost (e.g., remove
it from the "devices" listed in the mobile app immediately)

In any case, I am wondering about the current threat model that Whisper
Systems sees for Signal, and in what way this issue has perhaps already
been addressed? Signal Desktop is just out, so it's crucial that users
are informed about ways by which they can protect their data.

(This issue was brought up in Signal Desktop bug #452, and I was
referred to this mailing list there, so here I am.)

Cheers,
Natanji

[#359]

hey, Natanji,

i would say that Signal's threat model is� - stop global/local passive
mass surveilence.

so Signal apps are made to be used efortlessly by an average citizen.

if, as you propose, we *force* average user to encrypt their data,
possibly with a strong password, then you've alreday lost masses of
users and the app would only be used by techies (like tens of other
similar apps) because user experience it's not efortless anymore.

and if your threat model is stricter, you can still use Signal, only you
have to also follow stricter rules. you encrypt your device, you use
linux, ...

expecting from average user to constantly encrypt/decrypt Signal
is a dream.


- jure

Post by Natanji
Hi all,

I've been using Signal/TextSecure for a really long time and have been
really happy about the additional of Signal Desktop. However, I noticed
that Signal Desktop does not give users the option to encrypt the data
on the device with a user-defined password, which is something the
Android app offers.

I believe this is a very real threat to user's security and no full,
public version of Signal should be released that doesn't offer this
option. This has a lot to do with what I view as the threat model for
Signal Desktop, and I want to explain here why I think that Signal
Desktop should actually **never** store unencrypted data on a user's
device, and perhaps even **force** users to encrypt the data with a user-
defined password.

One reason for this is that on most Desktop OSes (e.g. Windows), the
data folder can be accessed by any program running on the computer. This
is different from the Android and iOS system where each app runs in a
much more sandboxed environment. We've seen in the past that even
popular applications like Skype somehow access delicate data such as the
Firefox password database. What I'm saying is, you cannot prevent apps
on Desktop from reading out all the data that Signal has saved. You
might be able to prevent an app from directly accessing another app's
memory and getting all the files from there though - I don't know enough
about this, I'm not an expert on Linux/Windows permissions.

Also, full device encryption isn't ubiquitous on Desktop OSes, but both
standard on iOS and Android. So when a device gets lost in a turned-off
state, it's arguably worse on a Desktop OS. We also should inform users
about what they need to do if their device ever gets lost (e.g., remove
it from the "devices" listed in the mobile app immediately)

In any case, I am wondering about the current threat model that Whisper
Systems sees for Signal, and in what way this issue has perhaps already
been addressed? Signal Desktop is just out, so it's crucial that users
are informed about ways by which they can protect their data.

(This issue was brought up in Signal Desktop bug #452, and I was
referred to this mailing list there, so here I am.)

Cheers, Natanji

[John Maguire]

Hello,

I agree that forcing a user's password would probably hurt user adoption.
However, I think Natanji brings up a great point, and passive mass
surveilance is still possible this way.

We know for a fact that government bodies have released worms with the
intent of spying before.

I guess my point is, it should probably definitely be an option, even if
it's not mandatory.

However, don't the main browsers also attempt to store saved passwords,
etc. with the OS-provided encryption layer these days? (i.e. Keychain for
OSX, not sure for Linux/Windows -- iirc, the Windows method pretty much
restricts access to the data from other user accounts, but not necssarily
from other applications running on the logged-in user's account.) Would it
be possible to implement something of that nature?

John

Post by #359
hey, Natanji,
i would say that Signal's threat model is - stop global/local passive
mass surveilence.
so Signal apps are made to be used efortlessly by an average citizen.
if, as you propose, we *force* average user to encrypt their data,
possibly with a strong password, then you've alreday lost masses of users
and the app would only be used by techies (like tens of other similar apps)
because user experience it's not efortless anymore.
and if your threat model is stricter, you can still use Signal, only you
have to also follow stricter rules. you encrypt your device, you use linux,
...
expecting from average user to constantly encrypt/decrypt Signal is a
dream.
- jure
Hi all,
I've been using Signal/TextSecure for a really long time and have been
really happy about the additional of Signal Desktop. However, I noticed
that Signal Desktop does not give users the option to encrypt the data
on the device with a user-defined password, which is something the
Android app offers.
I believe this is a very real threat to user's security and no full,
public version of Signal should be released that doesn't offer this
option. This has a lot to do with what I view as the threat model for
Signal Desktop, and I want to explain here why I think that Signal
Desktop should actually **never** store unencrypted data on a user's
device, and perhaps even **force** users to encrypt the data with a
user-defined password.
One reason for this is that on most Desktop OSes (e.g. Windows), the
data folder can be accessed by any program running on the computer. This
is different from the Android and iOS system where each app runs in a
much more sandboxed environment. We've seen in the past that even
popular applications like Skype somehow access delicate data such as the
Firefox password database. What I'm saying is, you cannot prevent apps
on Desktop from reading out all the data that Signal has saved. You
might be able to prevent an app from directly accessing another app's
memory and getting all the files from there though - I don't know enough
about this, I'm not an expert on Linux/Windows permissions.
Also, full device encryption isn't ubiquitous on Desktop OSes, but both
standard on iOS and Android. So when a device gets lost in a turned-off
state, it's arguably worse on a Desktop OS. We also should inform users
about what they need to do if their device ever gets lost (e.g., remove
it from the "devices" listed in the mobile app immediately)
In any case, I am wondering about the current threat model that Whisper
Systems sees for Signal, and in what way this issue has perhaps already
been addressed? Signal Desktop is just out, so it's crucial that users
are informed about ways by which they can protect their data.
(This issue was brought up in Signal Desktop bug #452, and I was
referred to this mailing list there, so here I am.)
Cheers,
Natanji

[#359]

if your computer gets compromised (via malicious app, trojan...) you've
already lost the game. there's no way for encrypted database to save you
and that applies to Signal, Keychain, KeePass... maybe you could get
somwhere with Qbes OS, but there you have different threat models...


- jure

Hello, I agree that forcing a user's password would probably hurt user
adoption. However, I think Natanji brings up a great point, and
passive mass surveilance is still possible this way.
We know for a fact that government bodies have released worms with the
intent of spying before. I guess my point is, it should probably
definitely be an option, even if it's not mandatory.
However, don't the main browsers also attempt to store saved
passwords, etc. with the OS-provided encryption layer these days?
(i.e. Keychain for OSX, not sure for Linux/Windows -- iirc, the
Windows method pretty much restricts access to the data from other
user accounts, but not necssarily from other applications running on
the logged-in user's account.) Would it be possible to implement
something of that nature? John

Post by #359
__
hey, Natanji,
i would say that Signal's threat model is� - stop global/local
passive mass surveilence.
so Signal apps are made to be used efortlessly by an average citizen.
if, as you propose, we *force* average user to encrypt their data,
possibly with a strong password, then you've alreday lost masses of
users and the app would only be used by techies (like tens of other
similar apps) because user experience it's not efortless anymore.
and if your threat model is stricter, you can still use Signal, only
you have to also follow stricter rules. you encrypt your device, you
use linux, ...
expecting from average user to constantly encrypt/decrypt Signal is
a dream.
- jure

Post by Natanji
Hi all,

I've been using Signal/TextSecure for a really long time and have been
really happy about the additional of Signal Desktop. However, I noticed
that Signal Desktop does not give users the option to encrypt the data
on the device with a user-defined password, which is something the
Android app offers.

I believe this is a very real threat to user's security and no full,
public version of Signal should be released that doesn't offer this
option. This has a lot to do with what I view as the threat model for
Signal Desktop, and I want to explain here why I think that Signal
Desktop should actually **never** store unencrypted data on a user's
device, and perhaps even **force** users to encrypt the data with a user-
defined password.

One reason for this is that on most Desktop OSes (e.g. Windows), the
data folder can be accessed by any program running on the computer. This
is different from the Android and iOS system where each app runs in a
much more sandboxed environment. We've seen in the past that even
popular applications like Skype somehow access delicate data such as the
Firefox password database. What I'm saying is, you cannot prevent apps
on Desktop from reading out all the data that Signal has saved. You
might be able to prevent an app from directly accessing another app's
memory and getting all the files from there though - I don't know enough
about this, I'm not an expert on Linux/Windows permissions.

Also, full device encryption isn't ubiquitous on Desktop OSes, but both
standard on iOS and Android. So when a device gets lost in a turned-off
state, it's arguably worse on a Desktop OS. We also should inform users
about what they need to do if their device ever gets lost (e.g., remove
it from the "devices" listed in the mobile app immediately)

In any case, I am wondering about the current threat model that Whisper
Systems sees for Signal, and in what way this issue has perhaps already
been addressed? Signal Desktop is just out, so it's crucial that users
are informed about ways by which they can protect their data.

(This issue was brought up in Signal Desktop bug #452, and I was
referred to this mailing list there, so here I am.)

Cheers, Natanji

[Jean-Philippe Cugnet]

Hi,

i would say that Signal's threat model is - stop global/local passive mass surveilence.
so Signal apps are made to be used efortlessly by an average citizen.
if, as you propose, we *force* average user to encrypt their data, possibly with a strong password, then you've alreday lost masses of users and the app would only be used by techies (like tens of other similar apps) because user experience it's not efortless anymore.

I think Signal Desktop should a least *propose* to encrypt local database.

and if your threat model is stricter, you can still use Signal, only you have to also follow stricter rules. you encrypt your device, you use linux, ...

In this case, encrypting the database is needed to avoid other apps from accessing the conversations.

expecting from average user to constantly encrypt/decrypt Signal is a dream.

There is maybe a solution for that: it is possible to use the system keychain to store a password. Even better: Signal Desktop should create a random strong password to encrypt the database and store it in the keychain. It would be transparent for user and more secure. In the case the keychain is reset, Signal Desktop would just ask for pairing again.

Jean-Philippe

[Moxie Marlinspike]

Thanks but we're not going to do this. Desktop platforms already have
solid FDE, screenlocks, and Chrome profiles. The millisecond that
Android has reasonable FDE support, we'll remove local encryption as an
option there as well.

Thanks,

- moxie

Post by Natanji
Hi all,
I've been using Signal/TextSecure for a really long time and have been
really happy about the additional of Signal Desktop. However, I noticed
that Signal Desktop does not give users the option to encrypt the data
on the device with a user-defined password, which is something the
Android app offers.
I believe this is a very real threat to user's security and no full,
public version of Signal should be released that doesn't offer this
option. This has a lot to do with what I view as the threat model for
Signal Desktop, and I want to explain here why I think that Signal
Desktop should actually *never* store unencrypted data on a user's
device, and perhaps even *force* users to encrypt the data with a
user-defined password.
One reason for this is that on most Desktop OSes (e.g. Windows), the
data folder can be accessed by any program running on the computer. This
is different from the Android and iOS system where each app runs in a
much more sandboxed environment. We've seen in the past that even
popular applications like Skype somehow access delicate data such as the
Firefox password database. What I'm saying is, you cannot prevent apps
on Desktop from reading out all the data that Signal has saved. You
might be able to prevent an app from directly accessing another app's
memory and getting all the files from there though - I don't know enough
about this, I'm not an expert on Linux/Windows permissions.
Also, full device encryption isn't ubiquitous on Desktop OSes, but both
standard on iOS and Android. So when a device gets lost in a turned-off
state, it's arguably worse on a Desktop OS. We also should inform users
about what they need to do if their device ever gets lost (e.g., remove
it from the "devices" listed in the mobile app immediately)
In any case, I am wondering about the current threat model that Whisper
Systems sees for Signal, and in what way this issue has perhaps already
been addressed? Signal Desktop is just out, so it's crucial that users
are informed about ways by which they can protect their data.
(This issue was brought up in Signal Desktop bug #452, and I was
referred to this mailing list there, so here I am.)
Cheers,
Natanji

[Laurence Berland]

Out of curiosity, what's wrong with current android full disk encryption?

Post by Moxie Marlinspike
Thanks but we're not going to do this. Desktop platforms already have
solid FDE, screenlocks, and Chrome profiles. The millisecond that
Android has reasonable FDE support, we'll remove local encryption as an
option there as well.
Thanks,
- moxie

Post by Natanji
Hi all,
I've been using Signal/TextSecure for a really long time and have been
really happy about the additional of Signal Desktop. However, I noticed
that Signal Desktop does not give users the option to encrypt the data
on the device with a user-defined password, which is something the
Android app offers.
I believe this is a very real threat to user's security and no full,
public version of Signal should be released that doesn't offer this
option. This has a lot to do with what I view as the threat model for
Signal Desktop, and I want to explain here why I think that Signal
Desktop should actually *never* store unencrypted data on a user's
device, and perhaps even *force* users to encrypt the data with a
user-defined password.
One reason for this is that on most Desktop OSes (e.g. Windows), the
data folder can be accessed by any program running on the computer. This
is different from the Android and iOS system where each app runs in a
much more sandboxed environment. We've seen in the past that even
popular applications like Skype somehow access delicate data such as the
Firefox password database. What I'm saying is, you cannot prevent apps
on Desktop from reading out all the data that Signal has saved. You
might be able to prevent an app from directly accessing another app's
memory and getting all the files from there though - I don't know enough
about this, I'm not an expert on Linux/Windows permissions.
Also, full device encryption isn't ubiquitous on Desktop OSes, but both
standard on iOS and Android. So when a device gets lost in a turned-off
state, it's arguably worse on a Desktop OS. We also should inform users
about what they need to do if their device ever gets lost (e.g., remove
it from the "devices" listed in the mobile app immediately)
In any case, I am wondering about the current threat model that Whisper
Systems sees for Signal, and in what way this issue has perhaps already
been addressed? Signal Desktop is just out, so it's crucial that users
are informed about ways by which they can protect their data.
(This issue was brought up in Signal Desktop bug #452, and I was
referred to this mailing list there, so here I am.)
Cheers,
Natanji

--
http://www.thoughtcrime.org

[Nino White]

I find that disturbing, I would rather signal still keep local encryption
for Android devices. that way if your device password ever gets
compromised you still have that second layer of security to keep your
messages safe.

Post by Laurence Berland
Out of curiosity, what's wrong with current android full disk encryption?

Post by Moxie Marlinspike
Thanks but we're not going to do this. Desktop platforms already have
solid FDE, screenlocks, and Chrome profiles. The millisecond that
Android has reasonable FDE support, we'll remove local encryption as an
option there as well.
Thanks,
- moxie

Post by Natanji
Hi all,
I've been using Signal/TextSecure for a really long time and have been
really happy about the additional of Signal Desktop. However, I noticed
that Signal Desktop does not give users the option to encrypt the data
on the device with a user-defined password, which is something the
Android app offers.
I believe this is a very real threat to user's security and no full,
public version of Signal should be released that doesn't offer this
option. This has a lot to do with what I view as the threat model for
Signal Desktop, and I want to explain here why I think that Signal
Desktop should actually *never* store unencrypted data on a user's
device, and perhaps even *force* users to encrypt the data with a
user-defined password.
One reason for this is that on most Desktop OSes (e.g. Windows), the
data folder can be accessed by any program running on the computer. This
is different from the Android and iOS system where each app runs in a
much more sandboxed environment. We've seen in the past that even
popular applications like Skype somehow access delicate data such as the
Firefox password database. What I'm saying is, you cannot prevent apps
on Desktop from reading out all the data that Signal has saved. You
might be able to prevent an app from directly accessing another app's
memory and getting all the files from there though - I don't know enough
about this, I'm not an expert on Linux/Windows permissions.
Also, full device encryption isn't ubiquitous on Desktop OSes, but both
standard on iOS and Android. So when a device gets lost in a turned-off
state, it's arguably worse on a Desktop OS. We also should inform users
about what they need to do if their device ever gets lost (e.g., remove
it from the "devices" listed in the mobile app immediately)
In any case, I am wondering about the current threat model that Whisper
Systems sees for Signal, and in what way this issue has perhaps already
been addressed? Signal Desktop is just out, so it's crucial that users
are informed about ways by which they can protect their data.
(This issue was brought up in Signal Desktop bug #452, and I was
referred to this mailing list there, so here I am.)
Cheers,
Natanji

--
http://www.thoughtcrime.org

[Natanji]

Hi Moxie,
I'm aware you just gave a very short answer, but since you didn't
actually engage in any conversation about the threats I described, your
answer is just quite unsatisfying. You haven't said anything about what
Signal's plan for these issues is; for instance, even if I use Chrome
profiles with a password, Signal Desktop might store temporary data
locally in unencrypted form - I simply don't know. Googling "Chrome
profiles encryption" or "how do I encrypt chrome profile" doesn't lead
to anything meaningful, so I don't even know if Chrome Profiles are
encrypted or with what kind of encryption this happens; it's an
extremely underused feature, I'd guess, if Google's otherwise excellent
documentation is just completely lacking. Do Chrome profiles with a
password encrypt all application data? If yes, can you show me where it
says that?

In any case, users need to be informed a lot more about how to use
Signal really securely. For this, we need to understand what kinds of
threats Signal is meant to protect against, and which it isn't. Please
take the time to actually engage in a discussion about this, and at
least explain how the threats described are either mitigated by Signal,
or why they are not even part of your threat model.

Because to me, it looks like Signal Desktop is just a really easy way to
break a lot of the excellent security and privacy that Signal on mobile
achieves. You are literally leaving private keys that can access all
Signal messages of the account just lying around in a folder that any
other Windows application can access. Maybe I don't understand some part
of your mitigation, but that seems like an outright horrible idea.

I'm sorry if I come off as paranoid, and please take your time to reply.
I'm just confused that you are just shooting this discussion down like
this when you usually take hints at security problems very seriously.

Cheers,
Natanji

Post by Moxie Marlinspike
Thanks but we're not going to do this. Desktop platforms already have
solid FDE, screenlocks, and Chrome profiles. The millisecond that
Android has reasonable FDE support, we'll remove local encryption as an
option there as well.
Thanks,
- moxie

Post by Natanji
Hi all,
I've been using Signal/TextSecure for a really long time and have been
really happy about the additional of Signal Desktop. However, I noticed
that Signal Desktop does not give users the option to encrypt the data
on the device with a user-defined password, which is something the
Android app offers.
I believe this is a very real threat to user's security and no full,
public version of Signal should be released that doesn't offer this
option. This has a lot to do with what I view as the threat model for
Signal Desktop, and I want to explain here why I think that Signal
Desktop should actually *never* store unencrypted data on a user's
device, and perhaps even *force* users to encrypt the data with a
user-defined password.
One reason for this is that on most Desktop OSes (e.g. Windows), the
data folder can be accessed by any program running on the computer. This
is different from the Android and iOS system where each app runs in a
much more sandboxed environment. We've seen in the past that even
popular applications like Skype somehow access delicate data such as the
Firefox password database. What I'm saying is, you cannot prevent apps
on Desktop from reading out all the data that Signal has saved. You
might be able to prevent an app from directly accessing another app's
memory and getting all the files from there though - I don't know enough
about this, I'm not an expert on Linux/Windows permissions.
Also, full device encryption isn't ubiquitous on Desktop OSes, but both
standard on iOS and Android. So when a device gets lost in a turned-off
state, it's arguably worse on a Desktop OS. We also should inform users
about what they need to do if their device ever gets lost (e.g., remove
it from the "devices" listed in the mobile app immediately)
In any case, I am wondering about the current threat model that Whisper
Systems sees for Signal, and in what way this issue has perhaps already
been addressed? Signal Desktop is just out, so it's crucial that users
are informed about ways by which they can protect their data.
(This issue was brought up in Signal Desktop bug #452, and I was
referred to this mailing list there, so here I am.)
Cheers,
Natanji

[Moxie Marlinspike]

Post by Natanji
Because to me, it looks like Signal Desktop is just a really easy way to
break a lot of the excellent security and privacy that Signal on mobile
achieves. You are literally leaving private keys that can access all
Signal messages of the account just lying around in a folder that any
other Windows application can access. Maybe I don't understand some part
of your mitigation, but that seems like an outright horrible idea.

If your device is compromised, everything on that device is compromised.
This isn't unique to Signal. The purpose of disk encryption in all
cases is to prevent offline attacks, it is not designed to stop malware
or online exploitation.

The only reason we implement a limited form of disk encryption ourselves
on Android is because Android's stock FDE is tied to the screenlock
passphrase. Fortunately, desktop OSes are less restrictive, so we don't
have to reinvent the wheel there.

If Android's FDE support ever gets close to iOS or desktop OSes, we'll
remove support for local encryption there as well.

- moxie

Post by Natanji

Post by Moxie Marlinspike
Thanks but we're not going to do this. Desktop platforms already have
solid FDE, screenlocks, and Chrome profiles. The millisecond that
Android has reasonable FDE support, we'll remove local encryption as an
option there as well.
Thanks,
- moxie

Post by Natanji
Hi all,
I've been using Signal/TextSecure for a really long time and have been
really happy about the additional of Signal Desktop. However, I noticed
that Signal Desktop does not give users the option to encrypt the data
on the device with a user-defined password, which is something the
Android app offers.
I believe this is a very real threat to user's security and no full,
public version of Signal should be released that doesn't offer this
option. This has a lot to do with what I view as the threat model for
Signal Desktop, and I want to explain here why I think that Signal
Desktop should actually *never* store unencrypted data on a user's
device, and perhaps even *force* users to encrypt the data with a
user-defined password.
One reason for this is that on most Desktop OSes (e.g. Windows), the
data folder can be accessed by any program running on the computer. This
is different from the Android and iOS system where each app runs in a
much more sandboxed environment. We've seen in the past that even
popular applications like Skype somehow access delicate data such as the
Firefox password database. What I'm saying is, you cannot prevent apps
on Desktop from reading out all the data that Signal has saved. You
might be able to prevent an app from directly accessing another app's
memory and getting all the files from there though - I don't know enough
about this, I'm not an expert on Linux/Windows permissions.
Also, full device encryption isn't ubiquitous on Desktop OSes, but both
standard on iOS and Android. So when a device gets lost in a turned-off
state, it's arguably worse on a Desktop OS. We also should inform users
about what they need to do if their device ever gets lost (e.g., remove
it from the "devices" listed in the mobile app immediately)
In any case, I am wondering about the current threat model that Whisper
Systems sees for Signal, and in what way this issue has perhaps already
been addressed? Signal Desktop is just out, so it's crucial that users
are informed about ways by which they can protect their data.
(This issue was brought up in Signal Desktop bug #452, and I was
referred to this mailing list there, so here I am.)
Cheers,
Natanji

[Natanji]

Moxie, there is a huge difference in ways that a device can be seen as
"compromised".

Correct me if I'm wrong, but in Signal for Android and iOS, it literally
doesn't matter if any other app tries to access the Signal database -
the OS will prevent this access in both cases. So unless you have an
actual exploit that escalates privileges, you cannot say that a device
is "compromised" just because an app gets installed that wants to read
the Signal database.

And arguably that is very different on Desktop devices. Plus you have
less of a walled garden from appstores, so users do install/run software
from untrusted sources a lot (which doesn't happen on mobile platforms).
And what I'm saying is that on Windows for instance, you do not *need*
any exploit. You can be any other application running on the same
machine and the OS will *not* prevent access to the database.

Do you understand why these cases are completely different? One of them
needs an exploit that is possibly worth millions. The other is just a
freebie that will always work, and for which you currently seem to have
absolutely zero mitigation techniques. Does that really make no
difference to you?

Post by Moxie Marlinspike

Post by Natanji
Because to me, it looks like Signal Desktop is just a really easy way to
break a lot of the excellent security and privacy that Signal on mobile
achieves. You are literally leaving private keys that can access all
Signal messages of the account just lying around in a folder that any
other Windows application can access. Maybe I don't understand some part
of your mitigation, but that seems like an outright horrible idea.

If your device is compromised, everything on that device is compromised.
This isn't unique to Signal. The purpose of disk encryption in all
cases is to prevent offline attacks, it is not designed to stop malware
or online exploitation.
The only reason we implement a limited form of disk encryption ourselves
on Android is because Android's stock FDE is tied to the screenlock
passphrase. Fortunately, desktop OSes are less restrictive, so we don't
have to reinvent the wheel there.
If Android's FDE support ever gets close to iOS or desktop OSes, we'll
remove support for local encryption there as well.
- moxie

Post by Natanji

Post by Moxie Marlinspike
Thanks but we're not going to do this. Desktop platforms already have
solid FDE, screenlocks, and Chrome profiles. The millisecond that
Android has reasonable FDE support, we'll remove local encryption as an
option there as well.
Thanks,
- moxie

Post by Natanji
Hi all,
I've been using Signal/TextSecure for a really long time and have been
really happy about the additional of Signal Desktop. However, I noticed
that Signal Desktop does not give users the option to encrypt the data
on the device with a user-defined password, which is something the
Android app offers.
I believe this is a very real threat to user's security and no full,
public version of Signal should be released that doesn't offer this
option. This has a lot to do with what I view as the threat model for
Signal Desktop, and I want to explain here why I think that Signal
Desktop should actually *never* store unencrypted data on a user's
device, and perhaps even *force* users to encrypt the data with a
user-defined password.
One reason for this is that on most Desktop OSes (e.g. Windows), the
data folder can be accessed by any program running on the computer. This
is different from the Android and iOS system where each app runs in a
much more sandboxed environment. We've seen in the past that even
popular applications like Skype somehow access delicate data such as the
Firefox password database. What I'm saying is, you cannot prevent apps
on Desktop from reading out all the data that Signal has saved. You
might be able to prevent an app from directly accessing another app's
memory and getting all the files from there though - I don't know enough
about this, I'm not an expert on Linux/Windows permissions.
Also, full device encryption isn't ubiquitous on Desktop OSes, but both
standard on iOS and Android. So when a device gets lost in a turned-off
state, it's arguably worse on a Desktop OS. We also should inform users
about what they need to do if their device ever gets lost (e.g., remove
it from the "devices" listed in the mobile app immediately)
In any case, I am wondering about the current threat model that Whisper
Systems sees for Signal, and in what way this issue has perhaps already
been addressed? Signal Desktop is just out, so it's crucial that users
are informed about ways by which they can protect their data.
(This issue was brought up in Signal Desktop bug #452, and I was
referred to this mailing list there, so here I am.)
Cheers,
Natanji

[Connor Lanigan]

[Johan Wevers]

Post by Moxie Marlinspike
If Android's FDE support ever gets close to iOS or desktop OSes, we'll
remove support for local encryption there as well.

However, that would still let all older devices that won't be updated
anymore open to a hole. Unless you drop support for all but the latest
Android versions, which means they will have to compile their own
version without expiration.

[Danny Wu]

Local filesystem access != compromised system. A few months ago, if you
opened a PDF in Firefox, you could have had your Signal texts sent to a
remote server.

https://blog.mozilla.org/security/2015/08/06/firefox-exploit-found-in-the-wild/

There are a lot of vulnerabilities / malware that allows for local file
access, but not any additional privileges (like even unprivileged code
execution).

[Farkas Levente]

Post by Moxie Marlinspike
The only reason we implement a limited form of disk encryption ourselves
on Android is because Android's stock FDE is tied to the screenlock
passphrase. Fortunately, desktop OSes are less restrictive, so we don't
have to reinvent the wheel there.
If Android's FDE support ever gets close to iOS or desktop OSes, we'll
remove support for local encryption there as well.

that's a really big problem and would ba a very bad decision!
first of all android fde is very slow even on the latest hardware and
software version see this link:
http://www.anandtech.com/show/8725/encryption-and-storage-performance-in-android-50-lollipop

and the real problem is that fde is good for offline access while i
really would like to protect my message database against anyone! eg: if
i give my unlocked phone to anyone to do something with it but signal is
password protected i still wouldn't like to access my unencrypted signal
database file (eg copy that and send by email to himself!). and this is
a real life scenario!!!

if you don't understand the real risk here than it's a big problem!

[Natanji]

Well, since Android 5 there is a guest mode that allows you to do this
much better. Presumambly very few people know it is there however and
how to use it, and millions of devices don't have Android 5 yet, so eh.

I've understood much better (after what Moxie and Connor wrote) why they
see local encryption of the signal data as not really helping. I still
disagree because I perceive attacks via keylogging, screenshotting the
chat window etc. as much more involved than just copying and sending the
whole unencrypted database. Ultimately this is a problem of the Desktop
platforms all not really offering very good ways of protecting user
data. Presumably you are rather safe on Linux when using AppArmor,
allowing only Chrome to access its profile folder and files. But on
Windows or MacOS I know of no alternative that offers this, and most
Linux distributions don't come with AppArmor enabled. Desktop OSes are
just broken in that regard.

I suppose why I feel so strongly against this is because Signal
Desktop's approach really goes against the best practices regarding
private keys that I've learned in the FOSS world; I would never leave
unencrypted PGP or SSH keys lying around on my computer, for instance,
and everyone advises against that. But Signal is doing the equivalent of
that here. If anything, the actual key material belongs into the OSes
keyring that protects it from unauthorized access, and has been hardened
to do so properly.

I guess this perhaps goes to show that while mobile platforms are sealed
down enough for encrypted communications to work, it's not really
advisable to try the same thing on Desktop platforms. It just isn't
nearly as secure, at least when other programs besides Signal are
installed on the OS, because Desktop OSes don't compartmentalize their
apps and data properly. But then again, previous solutions such as OTR
also just leave their private keys lying around, so eh... Signal Desktop
is still just as secure as previous Desktop messaging solutions, I guess.

Post by Farkas Levente

Post by Moxie Marlinspike
The only reason we implement a limited form of disk encryption ourselves
on Android is because Android's stock FDE is tied to the screenlock
passphrase. Fortunately, desktop OSes are less restrictive, so we don't
have to reinvent the wheel there.
If Android's FDE support ever gets close to iOS or desktop OSes, we'll
remove support for local encryption there as well.

that's a really big problem and would ba a very bad decision!
first of all android fde is very slow even on the latest hardware and
http://www.anandtech.com/show/8725/encryption-and-storage-performance-in-android-50-lollipop
and the real problem is that fde is good for offline access while i
really would like to protect my message database against anyone! eg: if
i give my unlocked phone to anyone to do something with it but signal is
password protected i still wouldn't like to access my unencrypted signal
database file (eg copy that and send by email to himself!). and this is
a real life scenario!!!
if you don't understand the real risk here than it's a big problem!

[Per Guth]

Post by Natanji
because Desktop OSes don't compartmentalize their
apps and data properly.

You could try https://www.qubes-os.org/

Viele Gruesse,
Per

***

In another exchange leaked [...], Zuckerberg explained to a friend that
his control of Facebook gave him access to any information he wanted
[...]:
ZUCK: yea so if you ever need info about anyone at harvard
ZUCK: just ask
ZUCK: i have over 4000 emails, pictures, addresses, sns
FRIEND: what!? how’d you manage that one?
ZUCK: people just submitted it
ZUCK: i don’t know why
ZUCK: they “trust me”
ZUCK: dumb fucks

- http://www.newyorker.com/magazine/2010/09/20/the-face-of-facebook

[Mark Senior]

I think relying on Android FDE - even a hypothetical revamped FDE that uses
a strong passphrase on boot-up, separate from the screen lock code.

- What are the odds that a seized or stolen Android phone will be powered
down at the time it's taken? Practically nil - so the actual barrier to
getting into the Android device is the screen lock code in almost every
case.

- Even if Android FDE is improved considerably, that's not going to make it
available on a lot of Android devices. The OEM OS on my current phone had
no support for FDE, even though it was based on an Android version that
could have supported it.

I really like the timed database lock on my Signal DB. I figure the screen
lock code is a decent bet to keep my data protected for a few hours - short
enough that the data is still barely decreased in value, but hopefully long
enough for the database to lock up.

If the encryption for the data were just FDE, it can be held off
indefinitely by simply connecting the phone to a charger until the screen
lock can be bypassed.

Regards
Mark

because Desktop OSes don't compartmentalize their apps and data properly.
You could try https://www.qubes-os.org/
Viele Gruesse, Per *** In another exchange leaked [...], Zuckerberg
explained to a friend that his control of Facebook gave him access to any
information he wanted [...]: ZUCK: yea so if you ever need info about
anyone at harvard ZUCK: just ask ZUCK: i have over 4000 emails, pictures,
addresses, sns FRIEND: what!? how’d you manage that one? ZUCK: people just
submitted it ZUCK: i don’t know why ZUCK: they “trust me” ZUCK: dumb fucks
- http://www.newyorker.com/magazine/2010/09/20/the-face-of-facebook

[Mark Senior]

Oops. Missed an important part of the sentence the first time around

I think relying on Android FDE - even a hypothetical revamped FDE that uses
a strong passphrase on boot-up, separate from the screen lock code - *would
be a bad idea*.

Post by Mark Senior
I think relying on Android FDE - even a hypothetical revamped FDE that
uses a strong passphrase on boot-up, separate from the screen lock code.
- What are the odds that a seized or stolen Android phone will be powered
down at the time it's taken? Practically nil - so the actual barrier to
getting into the Android device is the screen lock code in almost every
case.
- Even if Android FDE is improved considerably, that's not going to make
it available on a lot of Android devices. The OEM OS on my current phone
had no support for FDE, even though it was based on an Android version that
could have supported it.
I really like the timed database lock on my Signal DB. I figure the
screen lock code is a decent bet to keep my data protected for a few hours
- short enough that the data is still barely decreased in value, but
hopefully long enough for the database to lock up.
If the encryption for the data were just FDE, it can be held off
indefinitely by simply connecting the phone to a charger until the screen
lock can be bypassed.
Regards
Mark

because Desktop OSes don't compartmentalize their apps and data properly.
You could try https://www.qubes-os.org/
Viele Gruesse, Per *** In another exchange leaked [...], Zuckerberg
explained to a friend that his control of Facebook gave him access to any
information he wanted [...]: ZUCK: yea so if you ever need info about
anyone at harvard ZUCK: just ask ZUCK: i have over 4000 emails, pictures,
addresses, sns FRIEND: what!? how’d you manage that one? ZUCK: people just
submitted it ZUCK: i don’t know why ZUCK: they “trust me” ZUCK: dumb fucks
- http://www.newyorker.com/magazine/2010/09/20/the-face-of-facebook

[Rashed H. Sayem]

why am I getting so many emails? i didn't want that for god sake. how to
unsubscribe?

Post by Mark Senior
Oops. Missed an important part of the sentence the first time around
I think relying on Android FDE - even a hypothetical revamped FDE that
uses a strong passphrase on boot-up, separate from the screen lock code - *would
be a bad idea*.

Post by Mark Senior
I think relying on Android FDE - even a hypothetical revamped FDE that
uses a strong passphrase on boot-up, separate from the screen lock code.
- What are the odds that a seized or stolen Android phone will be powered
down at the time it's taken? Practically nil - so the actual barrier to
getting into the Android device is the screen lock code in almost every
case.
- Even if Android FDE is improved considerably, that's not going to make
it available on a lot of Android devices. The OEM OS on my current phone
had no support for FDE, even though it was based on an Android version that
could have supported it.
I really like the timed database lock on my Signal DB. I figure the
screen lock code is a decent bet to keep my data protected for a few hours
- short enough that the data is still barely decreased in value, but
hopefully long enough for the database to lock up.
If the encryption for the data were just FDE, it can be held off
indefinitely by simply connecting the phone to a charger until the screen
lock can be bypassed.
Regards
Mark

because Desktop OSes don't compartmentalize their apps and data properly.
You could try https://www.qubes-os.org/
Viele Gruesse, Per *** In another exchange leaked [...], Zuckerberg
explained to a friend that his control of Facebook gave him access to any
information he wanted [...]: ZUCK: yea so if you ever need info about
anyone at harvard ZUCK: just ask ZUCK: i have over 4000 emails, pictures,
addresses, sns FRIEND: what!? how’d you manage that one? ZUCK: people just
submitted it ZUCK: i don’t know why ZUCK: they “trust me” ZUCK: dumb fucks
- http://www.newyorker.com/magazine/2010/09/20/the-face-of-facebook

[Eric Hartsuyker]

If you click "View Original", this is in the header:

List-Unsubscribe:
<mailto:***@lists.riseup.net?subject=unsubscribe%20whispersystems>

So that might be how to do it. Or, y'know, go to Rise Up, sign in, and
manage your account on your own.

-E

Post by Rashed H. Sayem
why am I getting so many emails? i didn't want that for god sake. how to
unsubscribe?

Post by Mark Senior
Oops. Missed an important part of the sentence the first time around
I think relying on Android FDE - even a hypothetical revamped FDE that
uses a strong passphrase on boot-up, separate from the screen lock code - *would
be a bad idea*.

Post by Mark Senior
I think relying on Android FDE - even a hypothetical revamped FDE that
uses a strong passphrase on boot-up, separate from the screen lock code.
- What are the odds that a seized or stolen Android phone will be
powered down at the time it's taken? Practically nil - so the actual
barrier to getting into the Android device is the screen lock code in
almost every case.
- Even if Android FDE is improved considerably, that's not going to make
it available on a lot of Android devices. The OEM OS on my current phone
had no support for FDE, even though it was based on an Android version that
could have supported it.
I really like the timed database lock on my Signal DB. I figure the
screen lock code is a decent bet to keep my data protected for a few hours
- short enough that the data is still barely decreased in value, but
hopefully long enough for the database to lock up.
If the encryption for the data were just FDE, it can be held off
indefinitely by simply connecting the phone to a charger until the screen
lock can be bypassed.
Regards
Mark

because Desktop OSes don't compartmentalize their apps and data properly.
You could try https://www.qubes-os.org/
Viele Gruesse, Per *** In another exchange leaked [...], Zuckerberg
explained to a friend that his control of Facebook gave him access to any
information he wanted [...]: ZUCK: yea so if you ever need info about
anyone at harvard ZUCK: just ask ZUCK: i have over 4000 emails, pictures,
addresses, sns FRIEND: what!? how’d you manage that one? ZUCK: people just
submitted it ZUCK: i don’t know why ZUCK: they “trust me” ZUCK: dumb fucks
- http://www.newyorker.com/magazine/2010/09/20/the-face-of-facebook

[Angel Stoleski]

This is weird, making Signal from most secure to least secure just doesn't
make sense.
The purpose of local encryption is, yes, preventing offline attacks, but if
someone has to attack one passphrase and one structure(android), and at
least two passphrases which the one for Signal will be for sure harder to
attack, there is a big difference. Good luck with ruining what you've
created so far.

As Farkas Levente says: if you don't understand the real risk here than
it's a big problem!

Post by Farkas Levente

Post by Moxie Marlinspike
The only reason we implement a limited form of disk encryption ourselves
on Android is because Android's stock FDE is tied to the screenlock
passphrase. Fortunately, desktop OSes are less restrictive, so we don't
have to reinvent the wheel there.
If Android's FDE support ever gets close to iOS or desktop OSes, we'll
remove support for local encryption there as well.

that's a really big problem and would ba a very bad decision!
first of all android fde is very slow even on the latest hardware and
http://www.anandtech.com/show/8725/encryption-and-storage-performance-in-android-50-lollipop
and the real problem is that fde is good for offline access while i
really would like to protect my message database against anyone! eg: if
i give my unlocked phone to anyone to do something with it but signal is
password protected i still wouldn't like to access my unencrypted signal
database file (eg copy that and send by email to himself!). and this is
a real life scenario!!!
if you don't understand the real risk here than it's a big problem!
--
Levente "Si vis pacem para bellum!"

[Christopher Sheats]

The "lowest hanging fruit" is shoulder surfing someone's device
passphrase or passcode. We type it in 50 times a day. But we don't
always need Signal access.

Keep opt-in layered security, please.

Christopher

Post by Moxie Marlinspike
Thanks but we're not going to do this. Desktop platforms already have
solid FDE, screenlocks, and Chrome profiles. The millisecond that
Android has reasonable FDE support, we'll remove local encryption as an
option there as well.
Thanks,
- moxie

Post by Natanji
Hi all,
I've been using Signal/TextSecure for a really long time and have been
really happy about the additional of Signal Desktop. However, I noticed
that Signal Desktop does not give users the option to encrypt the data
on the device with a user-defined password, which is something the
Android app offers.
I believe this is a very real threat to user's security and no full,
public version of Signal should be released that doesn't offer this
option. This has a lot to do with what I view as the threat model for
Signal Desktop, and I want to explain here why I think that Signal
Desktop should actually *never* store unencrypted data on a user's
device, and perhaps even *force* users to encrypt the data with a
user-defined password.
One reason for this is that on most Desktop OSes (e.g. Windows), the
data folder can be accessed by any program running on the computer. This
is different from the Android and iOS system where each app runs in a
much more sandboxed environment. We've seen in the past that even
popular applications like Skype somehow access delicate data such as the
Firefox password database. What I'm saying is, you cannot prevent apps
on Desktop from reading out all the data that Signal has saved. You
might be able to prevent an app from directly accessing another app's
memory and getting all the files from there though - I don't know enough
about this, I'm not an expert on Linux/Windows permissions.
Also, full device encryption isn't ubiquitous on Desktop OSes, but both
standard on iOS and Android. So when a device gets lost in a turned-off
state, it's arguably worse on a Desktop OS. We also should inform users
about what they need to do if their device ever gets lost (e.g., remove
it from the "devices" listed in the mobile app immediately)
In any case, I am wondering about the current threat model that Whisper
Systems sees for Signal, and in what way this issue has perhaps already
been addressed? Signal Desktop is just out, so it's crucial that users
are informed about ways by which they can protect their data.
(This issue was brought up in Signal Desktop bug #452, and I was
referred to this mailing list there, so here I am.)
Cheers,
Natanji

[Danny Wu]

So, wait, if someone is logged into their Google account and has Chrome
Sync enabled (which is opt-out), then Google gets all their unencrypted
messages as it's automatically sync'd with chrome profiles??

Post by Christopher Sheats
The "lowest hanging fruit" is shoulder surfing someone's device
passphrase or passcode. We type it in 50 times a day. But we don't
always need Signal access.
Keep opt-in layered security, please.
Christopher

Post by Moxie Marlinspike
Thanks but we're not going to do this. Desktop platforms already have
solid FDE, screenlocks, and Chrome profiles. The millisecond that
Android has reasonable FDE support, we'll remove local encryption as an
option there as well.
Thanks,
- moxie

Post by Natanji
Hi all,
I've been using Signal/TextSecure for a really long time and have been
really happy about the additional of Signal Desktop. However, I noticed
that Signal Desktop does not give users the option to encrypt the data
on the device with a user-defined password, which is something the
Android app offers.
I believe this is a very real threat to user's security and no full,
public version of Signal should be released that doesn't offer this
option. This has a lot to do with what I view as the threat model for
Signal Desktop, and I want to explain here why I think that Signal
Desktop should actually *never* store unencrypted data on a user's
device, and perhaps even *force* users to encrypt the data with a
user-defined password.
One reason for this is that on most Desktop OSes (e.g. Windows), the
data folder can be accessed by any program running on the computer. This
is different from the Android and iOS system where each app runs in a
much more sandboxed environment. We've seen in the past that even
popular applications like Skype somehow access delicate data such as the
Firefox password database. What I'm saying is, you cannot prevent apps
on Desktop from reading out all the data that Signal has saved. You
might be able to prevent an app from directly accessing another app's
memory and getting all the files from there though - I don't know enough
about this, I'm not an expert on Linux/Windows permissions.
Also, full device encryption isn't ubiquitous on Desktop OSes, but both
standard on iOS and Android. So when a device gets lost in a turned-off
state, it's arguably worse on a Desktop OS. We also should inform users
about what they need to do if their device ever gets lost (e.g., remove
it from the "devices" listed in the mobile app immediately)
In any case, I am wondering about the current threat model that Whisper
Systems sees for Signal, and in what way this issue has perhaps already
been addressed? Signal Desktop is just out, so it's crucial that users
are informed about ways by which they can protect their data.
(This issue was brought up in Signal Desktop bug #452, and I was
referred to this mailing list there, so here I am.)
Cheers,
Natanji

[John Maguire]

Messages aren't synced through Google Sync. Only the extension itself would
be.

I am curious if there's an answer to the specific argument of rogue
software looking at the file system. File disk encryption does not prevent
this. As far as I'm aware neither does Google Chrome profiles, and
certainly not a screenlock.

John Maguire

Post by Danny Wu
So, wait, if someone is logged into their Google account and has Chrome
Sync enabled (which is opt-out), then Google gets all their unencrypted
messages as it's automatically sync'd with chrome profiles??

Post by Christopher Sheats
The "lowest hanging fruit" is shoulder surfing someone's device
passphrase or passcode. We type it in 50 times a day. But we don't
always need Signal access.
Keep opt-in layered security, please.
Christopher

Post by Moxie Marlinspike
Thanks but we're not going to do this. Desktop platforms already have
solid FDE, screenlocks, and Chrome profiles. The millisecond that
Android has reasonable FDE support, we'll remove local encryption as an
option there as well.
Thanks,
- moxie

Post by Natanji
Hi all,
I've been using Signal/TextSecure for a really long time and have been
really happy about the additional of Signal Desktop. However, I noticed
that Signal Desktop does not give users the option to encrypt the data
on the device with a user-defined password, which is something the
Android app offers.
I believe this is a very real threat to user's security and no full,
public version of Signal should be released that doesn't offer this
option. This has a lot to do with what I view as the threat model for
Signal Desktop, and I want to explain here why I think that Signal
Desktop should actually *never* store unencrypted data on a user's
device, and perhaps even *force* users to encrypt the data with a
user-defined password.
One reason for this is that on most Desktop OSes (e.g. Windows), the
data folder can be accessed by any program running on the computer.

This

Post by Moxie Marlinspike

Post by Natanji
is different from the Android and iOS system where each app runs in a
much more sandboxed environment. We've seen in the past that even
popular applications like Skype somehow access delicate data such as

the

Post by Moxie Marlinspike

Post by Natanji
Firefox password database. What I'm saying is, you cannot prevent apps
on Desktop from reading out all the data that Signal has saved. You
might be able to prevent an app from directly accessing another app's
memory and getting all the files from there though - I don't know

enough

Post by Moxie Marlinspike

Post by Natanji
about this, I'm not an expert on Linux/Windows permissions.
Also, full device encryption isn't ubiquitous on Desktop OSes, but both
standard on iOS and Android. So when a device gets lost in a turned-off
state, it's arguably worse on a Desktop OS. We also should inform users
about what they need to do if their device ever gets lost (e.g., remove
it from the "devices" listed in the mobile app immediately)
In any case, I am wondering about the current threat model that Whisper
Systems sees for Signal, and in what way this issue has perhaps already
been addressed? Signal Desktop is just out, so it's crucial that users
are informed about ways by which they can protect their data.
(This issue was brought up in Signal Desktop bug #452, and I was
referred to this mailing list there, so here I am.)
Cheers,
Natanji

[Laurence Berland]

I'd still like to know what the android fde flaws are that Moxie alluded to
are, because many people seem to rely on the android fde.

Post by John Maguire
Messages aren't synced through Google Sync. Only the extension itself
would be.
I am curious if there's an answer to the specific argument of rogue
software looking at the file system. File disk encryption does not prevent
this. As far as I'm aware neither does Google Chrome profiles, and
certainly not a screenlock.
John Maguire

Post by Danny Wu
So, wait, if someone is logged into their Google account and has Chrome
Sync enabled (which is opt-out), then Google gets all their unencrypted
messages as it's automatically sync'd with chrome profiles??

Post by Christopher Sheats
The "lowest hanging fruit" is shoulder surfing someone's device
passphrase or passcode. We type it in 50 times a day. But we don't
always need Signal access.
Keep opt-in layered security, please.
Christopher

Post by Moxie Marlinspike
Thanks but we're not going to do this. Desktop platforms already have
solid FDE, screenlocks, and Chrome profiles. The millisecond that
Android has reasonable FDE support, we'll remove local encryption as an
option there as well.
Thanks,
- moxie

Post by Natanji
Hi all,
I've been using Signal/TextSecure for a really long time and have been
really happy about the additional of Signal Desktop. However, I

noticed

Post by Moxie Marlinspike

Post by Natanji
that Signal Desktop does not give users the option to encrypt the data
on the device with a user-defined password, which is something the
Android app offers.
I believe this is a very real threat to user's security and no full,
public version of Signal should be released that doesn't offer this
option. This has a lot to do with what I view as the threat model for
Signal Desktop, and I want to explain here why I think that Signal
Desktop should actually *never* store unencrypted data on a user's
device, and perhaps even *force* users to encrypt the data with a
user-defined password.
One reason for this is that on most Desktop OSes (e.g. Windows), the
data folder can be accessed by any program running on the computer.

This

Post by Moxie Marlinspike

Post by Natanji
is different from the Android and iOS system where each app runs in a
much more sandboxed environment. We've seen in the past that even
popular applications like Skype somehow access delicate data such as

the

Post by Moxie Marlinspike

Post by Natanji
Firefox password database. What I'm saying is, you cannot prevent apps
on Desktop from reading out all the data that Signal has saved. You
might be able to prevent an app from directly accessing another app's
memory and getting all the files from there though - I don't know

enough

Post by Moxie Marlinspike

Post by Natanji
about this, I'm not an expert on Linux/Windows permissions.
Also, full device encryption isn't ubiquitous on Desktop OSes, but

both

Post by Moxie Marlinspike

Post by Natanji
standard on iOS and Android. So when a device gets lost in a

turned-off

Post by Moxie Marlinspike

Post by Natanji
state, it's arguably worse on a Desktop OS. We also should inform

users

Post by Moxie Marlinspike

Post by Natanji
about what they need to do if their device ever gets lost (e.g.,

remove

Post by Moxie Marlinspike

Post by Natanji
it from the "devices" listed in the mobile app immediately)
In any case, I am wondering about the current threat model that

Whisper

Post by Moxie Marlinspike

Post by Natanji
Systems sees for Signal, and in what way this issue has perhaps

already

Post by Moxie Marlinspike

Post by Natanji
been addressed? Signal Desktop is just out, so it's crucial that users
are informed about ways by which they can protect their data.
(This issue was brought up in Signal Desktop bug #452, and I was
referred to this mailing list there, so here I am.)
Cheers,
Natanji

[#359]

"While Android's disk encryption is a useful security feature without
any (currently) know flaws, its biggest weakness is that it requires you
to use the device unlock PIN or password to protect the disk encryption
key. Since those are usually rather short, this opens a door to
practical brute force attacks against encrypted volumes."

http://nelenkov.blogspot.fr/2012/08/changing-androids-disk-encryption.html

Setting a separate, more complex disk encryption password currently
requires root access, having a long strong password to unlock display is
impractical.


- jure

Post by Laurence Berland
I'd still like to know what the android fde flaws are that Moxie
alluded to are, because many people seem to rely on the android fde.

Post by John Maguire
Messages aren't synced through Google Sync. Only the extension itself
would be.
I am curious if there's an answer to the specific argument of rogue
software looking at the file system. File disk encryption does not
prevent this. As far as I'm aware neither does Google Chrome
profiles, and certainly not a screenlock.
John Maguire

Post by Danny Wu
So, wait, if someone is logged into their Google account and has
Chrome Sync enabled (which is opt-out), then Google gets all their
unencrypted messages as it's automatically sync'd with chrome
profiles??
On Tue, Dec 8, 2015 at 10:56 AM, Christopher Sheats

Post by Christopher Sheats
The "lowest hanging fruit" is shoulder surfing someone's device

passphrase or passcode. We type it in 50 times a day. But we don't
always need Signal access.
Keep opt-in layered security, please.
Christopher

Post by Laurence Berland
Thanks but we're not going to do this.� Desktop platforms already have
solid FDE, screenlocks, and Chrome profiles.� The millisecond that
Android has reasonable FDE support, we'll remove local
encryption as an
option there as well.
Thanks,
- moxie

Post by John Maguire
Hi all,
I've been using Signal/TextSecure for a really long time and
have been
really happy about the additional of Signal Desktop. However, I noticed
that Signal Desktop does not give users the option to encrypt
the data
on the device with a user-defined password, which is something the
Android app offers.
I believe this is a very real threat to user's security and no full,
public version of Signal should be released that doesn't offer this
option. This has a lot to do with what I view as the threat model for
Signal Desktop, and I want to explain here why I think that Signal
Desktop should actually *never* store unencrypted data on a user's
device, and perhaps even *force* users to encrypt the data with a
user-defined password.
One reason for this is that on most Desktop OSes (e.g. Windows), the
data folder can be accessed by any program running on the
computer. This
is different from the Android and iOS system where each app runs in a
much more sandboxed environment. We've seen in the past that even
popular applications like Skype somehow access delicate data
such as the
Firefox password database. What I'm saying is, you cannot
prevent apps
on Desktop from reading out all the data that Signal has saved. You
might be able to prevent an app from directly accessing another app's
memory and getting all the files from there though - I don't
know enough
about this, I'm not an expert on Linux/Windows permissions.
Also, full device encryption isn't ubiquitous on Desktop OSes, but both
standard on iOS and Android. So when a device gets lost in a
turned-off
state, it's arguably worse on a Desktop OS. We also should
inform users
about what they need to do if their device ever gets lost
(e.g., remove
it from the "devices" listed in the mobile app immediately)
In any case, I am wondering about the current threat model that Whisper
Systems sees for Signal, and in what way this issue has perhaps already
been addressed? Signal Desktop is just out, so it's crucial
that users
are informed about ways by which they can protect their data.
(This issue was brought up in Signal Desktop bug #452, and I was
referred to this mailing list there, so here I am.)
Cheers,
Natanji

[Nick _]

Post by Laurence Berland
I'd still like to know what the android fde flaws are that Moxie alluded
to are, because many people seem to rely on the android fde.

I'm obviously not Moxie, but one problem with Android FDE is that it's
early implementations are easy for skilled actors to brute force. Up until
Android 4.3, FDE was implemented using dm-crypt with a 128 bit randomly
generated master key. This master key was, unfortunately, protected with
lock-screen password. For most users, that is trivial to brute force. More
details can be found here [1] on Nikolay Elenkov's excellent Android
security blog.

In Android 4.4, the master key was protected using scrypt, but this turned
out to be a minor improvement; it merely lengthened the brute force time
from seconds to minutes.

By Android 5.0, Android developers realized this security flaw and changed
master key protection. From "source.android.com" [2]:

"Hardware backing is implemented by using Trusted Execution Environment’s
(TEE) signing capability. Previously, we encrypted the master key with a
key generated by applying scrypt to the user's password and the stored
salt. In order to make the key resilient against off-box attacks, we extend
this algorithm by signing the resultant key with a stored TEE key."

I'm not aware of any attacks against the new FDE encryption scheme, but I
think we're all aware that the majority of Android devices out there are
running Android versions using a flawed FDE scheme.

[1]
http://nelenkov.blogspot.co.uk/2014/10/revisiting-android-disk-encryption.html

[2] https://source.android.com/security/encryption/index.html

--

Nick

[Eric Mill]

I'm not sure if Moxie is referring to this specifically, but I recall that
one problem with Android 5.0's FDE is that the primary encryption
passphrase you create for the disk (which you must type in on boot) is also
the same passphrase you need to use to unlock the phone screen during
normal operation. Since no one will tolerate typing in a strong passphrase
for every screen unlock, the only usable way to use a passphrase for FDE is
a short one that wouldn't resist an offline attack for any serious length
of time.

I don't know if Android 6.0's FDE is any better, though I note that with my
Nexus 5X, I can set a strong passphrase for disk encryption but can set a
non-passphrase option to unlock the phone screen. In my case, I'm using the
fingerprint unlock for screen unlocking.

There are some gaps in my description above -- I am not sure if 5.0 allowed
non-passphrase unlock methods, or if the situation has meaningfully changed
-- but the use of the same passphrase for boot and screen unlock is what I
recall learning about. I also recall that CyanogenMod specifically
addressed that and lets users set a different passphrase for both
operations.

Hopefully, someone with more detailed knowledge of the state of Android FDE
can fill in the gaps in my description.

-- Eric

Post by Laurence Berland
I'd still like to know what the android fde flaws are that Moxie alluded
to are, because many people seem to rely on the android fde.

Post by John Maguire
Messages aren't synced through Google Sync. Only the extension itself
would be.
I am curious if there's an answer to the specific argument of rogue
software looking at the file system. File disk encryption does not prevent
this. As far as I'm aware neither does Google Chrome profiles, and
certainly not a screenlock.
John Maguire

Post by Danny Wu
So, wait, if someone is logged into their Google account and has Chrome
Sync enabled (which is opt-out), then Google gets all their unencrypted
messages as it's automatically sync'd with chrome profiles??

Post by Christopher Sheats
The "lowest hanging fruit" is shoulder surfing someone's device
passphrase or passcode. We type it in 50 times a day. But we don't
always need Signal access.
Keep opt-in layered security, please.
Christopher

Post by Moxie Marlinspike
Thanks but we're not going to do this. Desktop platforms already have
solid FDE, screenlocks, and Chrome profiles. The millisecond that
Android has reasonable FDE support, we'll remove local encryption as

an

Post by Moxie Marlinspike
option there as well.
Thanks,
- moxie

Post by Natanji
Hi all,
I've been using Signal/TextSecure for a really long time and have

been

Post by Moxie Marlinspike

Post by Natanji
really happy about the additional of Signal Desktop. However, I

noticed

Post by Moxie Marlinspike

Post by Natanji
that Signal Desktop does not give users the option to encrypt the

data

Post by Moxie Marlinspike

Post by Natanji
on the device with a user-defined password, which is something the
Android app offers.
I believe this is a very real threat to user's security and no full,
public version of Signal should be released that doesn't offer this
option. This has a lot to do with what I view as the threat model for
Signal Desktop, and I want to explain here why I think that Signal
Desktop should actually *never* store unencrypted data on a user's
device, and perhaps even *force* users to encrypt the data with a
user-defined password.
One reason for this is that on most Desktop OSes (e.g. Windows), the
data folder can be accessed by any program running on the computer.

This

Post by Moxie Marlinspike

Post by Natanji
is different from the Android and iOS system where each app runs in a
much more sandboxed environment. We've seen in the past that even
popular applications like Skype somehow access delicate data such as

the

Post by Moxie Marlinspike

Post by Natanji
Firefox password database. What I'm saying is, you cannot prevent

apps

Post by Moxie Marlinspike

Post by Natanji
on Desktop from reading out all the data that Signal has saved. You
might be able to prevent an app from directly accessing another app's
memory and getting all the files from there though - I don't know

enough

Post by Moxie Marlinspike

Post by Natanji
about this, I'm not an expert on Linux/Windows permissions.
Also, full device encryption isn't ubiquitous on Desktop OSes, but

both

Post by Moxie Marlinspike

Post by Natanji
standard on iOS and Android. So when a device gets lost in a

turned-off

Post by Moxie Marlinspike

Post by Natanji
state, it's arguably worse on a Desktop OS. We also should inform

users

Post by Moxie Marlinspike

Post by Natanji
about what they need to do if their device ever gets lost (e.g.,

remove

Post by Moxie Marlinspike

Post by Natanji
it from the "devices" listed in the mobile app immediately)
In any case, I am wondering about the current threat model that

Whisper

Post by Moxie Marlinspike

Post by Natanji
Systems sees for Signal, and in what way this issue has perhaps

already

Post by Moxie Marlinspike

Post by Natanji
been addressed? Signal Desktop is just out, so it's crucial that

users

Post by Moxie Marlinspike

Post by Natanji
are informed about ways by which they can protect their data.
(This issue was brought up in Signal Desktop bug #452, and I was
referred to this mailing list there, so here I am.)
Cheers,
Natanji