If your system is compromised to such an extend, it really doesn’t make much difference how the keys are stored at rest.

Why? They would need access to the device

What’s wrong with the Flatpak permissions system on Linux?

What does Windows do? Genuine question, I’ve not used it since the 7 days. Regarding Linux, that’s true for stuff installed through regular package managers and whatnot, but Flatpak is pushing a more sandboxed and permission oriented system, akin to Android.

Whole disk encryption wouldn’t change your daily usage, no. It just means that when you boot your PC you have to enter your passphrase. And if your device becomes unbootable for whatever reason, and you want to access your drive, you’ll just have to decrypt it first to be able to read it/write to it, e.g. if you want to rescue files from a bricked computer. But there’s no reason not to encrypt your drive. I can’t think of any downsides.

It’s transparent for end user basically, but protects the laptop at least when outside and if someone steals the computer. As long as it was properly shutdown.

No, the average user will never know the difference. I couldn’t tell you exactly what the current performance impact is for hardware encryption, but it’s likely around 1-4% depending on the platform (I use LUKS under Linux).

For gamers, it’s likely a 1-5 FPS loss, depending on your hardware, which is negligible in my experience. I play mostly first and third person shooter-style games at 1440p/120hz, targeting 60-90 FPS, and there’s no noticeable impact (Ryzen 5600 / RX 6800XT).

It depends on how you set it up. I think the default in some cases (like Windows Bitlocker) is to store the key in TPM, so everything becomes transparent to the user at that point, although many disagree with this method for privacy/security reasons.

The other method is to provide a password or keyfile during bootup, which does change something for the end user somewhat.

It does help greatly in general though, because all of your data will be encrypted when the device is at rest. Theft and B&Es will no longer present a risk to your privacy.

Per-app permissions address this specific threat model directly. Containerized apps, such as those provided by Flatpak can ensure that apps remain sandboxed and unable to access data without explicit authorization.

Source:

If your device is turned on and you are logged in, your data is no longer at rest.

Signal data will be encrypted if your disk is also encrypted.

If your device’s storage is not encrypted, and you don’t have any type of verified boot process, then thats on you, not Signal.

TPM isn’t all that reliable. You will have people upgrading their pc, or windows update updating their bios, or any number of other reasons reset their tpm keys, and currently nothing will happen. In effect people would see Signal completely break and loose all their data, often seemingly for no reason.

Talking to windows or through it to the TPM also seems sketchy.

In the current state of Windows, the sensible choice is to leave hardware-based encryption to the OS in the form of disk encryption, unfortunate as it is. The great number of people who loose data or have to recover their backup disk encryption key from their Microsoft account tells how easily that system is disturbed (And that Microsoft has the decryption keys for your encrypted date).

Oh no, tell that to SSH.

unless you’re reading ciphertext yourself, this doesn’t make sense

It doesn’t use plain text. It is end to end encrypted but that isn’t what this “issue” is

It is the same concept. Once your machine is pwded you are screwed

Needing to enter a secure passphrase each time you want to use signal in exchange for one more fragile layer of defence for that one part of your data in a scenario that would normally mean you've already lost unless you're running a super-secure compartmentalized operating system like qubes or something is probably not worth it for most people.

That’s not how this works.

This sort of “dismissive security through ignorance” is how we get so many damn security breaches these days.

I see this every day with software engineers, a group that you would think would be above the bar on security. Unfortunately a little bit of knowledge results in a mountain of confidence (see Dunning Kruger effect). They are just confident in bad choices instead.

“We don’t need to use encryption at rest because if the database is compromised we have bigger problems” really did a lot to protect the last few thousand companies from preventable data exfiltration that was in fact the largest problem they had.

Turns out that having read access to the underlying storage for the database doesn’t necessarily mean that the database and all of your internal systems are more compromised. It just means that the decision makers were making poor decisions based on a lack of risk modeling knowledge.

That said the real question I have for you here is:

Are you confident in your omniscience in that you can enumerate all risks and attack factors that can result in data being exfiltrated from a device?

If not, then why comment as if you are?

Moxie tried to put a crypto-coin into signal. He is not to be trusted in the slightest.

Meeting in person.

Matrix or xmpp, bonus points with a personal server

Thanks to interest of late, the conversations and gajim apps have come a long way in recent years, and matrix has made good strides too with element-x

(for Android) molly.im

That depends on your threat model. What are you worried about?

They can’t control if the encryption keys are stored in plaintext?

Those are outside Signal’s scope and depend entirely on your OS and your (or your sysadmin’s) security practices (eg. I’m almost sure in linux you need extra privileges for those things on top of just read access to the user’s home directory).

The point is, why didn’t the Signal devs code it the proper way and obtain the credentials every time (interactively from the user or automatically via the OS password manager) instead of just storing them in plain text?

(for Android) molly.im restores the encryption to this file and adds other useful things

Not necessarily.

en.m.wikipedia.org/wiki/Swiss_cheese_model

If you read anything, at least read this link to self correct.

This is a common area where non-security professionals out themselves as not actually being such: The broken/fallacy reasoning about security risk management. Generally the same “Dismissive security by way of ignorance” premises.

It’s fundamentally the same as “safety” (Think OSHA and CSB) The same thought processes, the same risk models, the same risk factors…etc

And similarly the same negligence towards filling in holes in your “swiss cheese model”.

“Oh that can’t happen because that would mean x,y,z would have to happen and those are even worse”

“Oh that’s not possible because A happening means C would have to happen first, so we don’t need to consider this is a risk”

…etc

The same logic you’re using is the same logic that the industry has decades of evidence showing how wrong it is.

Decades of evidence indicating that you are wrong, you know infinitely less than you think you do, and you most definitely are not capable of exhaustively enumerating all influencing factors. No one is. It’s beyond arrogant for anyone to think that they could 🤦🤦 🤦

Thus, most risks are considered valid risks (this doesn’t necessarily mean they are all mitigatable though). Each risk is a hole in your model. And each hole is in itself at a unique risk of lining up with other holes, and developing into an actual safety or security incident.

In this case

• signal was alerted to this over 6 years ago
• the framework they use for the desktop app already has built-in features for this problem.
  • this is a common problem with common solutions that are industry-wide.
• someone has already made a pull request to enable the electron safe storage API. And signal has ignored it.

Thus this is just straight up negligence on their part.

There’s not really much in the way of good excuses here. We’re talking about a run of the mill problem that has baked in solutions in most major frameworks including the one signal uses.

www.electronjs.org/docs/latest/api/safe-storage

Linux has a sandbox solution growing in popularity, flatpak.

I don’t think apps can read keystrokes for other apps on Wayland.

It’s true, anyone using SSH for secure messaging is absolutely misguided.

Any “secure” so that relies on someone else for security is not secure.

Fuck the scope of E2EE. Signal makes a lot of claims on their website that are laughable. The desktop app is their main weakness. Attachments are stored unencrypted, keys in plaintext. If they were serious about security, they would depricate the windows app and block it from their servers.

WTF does Apple have to do with anything?

Back when the Signal org used to be called Open Whisper Systems it received grants and auditing from the Open Technology Fund which, at the time, was still a part of Radio Free Asia.

web.archive.org/web/…/open-whisper-systems

Signal is actively hostile to alternative clients, or decoupling from Google.

Popular encrypted messaging app Signal is facing criticism over a security issue in its desktop application.

Emphasis mine.

AFAIK Android encrypts entire fs with one key. And ACL is not encryption.

Not true, SSH keys need their passphrase to be used. If you don’t set one, that’s on you.

Kinda expected the SSH key argument. The difference is the average user group.

The average dude with a SSH key that’s used for more than their RPi knows a bit about security, encryption and opsec. They would have a passphrase and/or hardening mechanisms for their system and network in place. They know their risks and potential attack vectors.

The average dude who downloads a desktop app for a messenger that advertises to be secure and E2EE encrypted probably won’t assume that any process might just wire tap their whole “encrypted” communications.

Let’s not forget that the threat model has changed by a lot in the last years, and a lot of effort went into providing additional security measures and best practices. Using a secure credential store, additional encryption and not storing plaintext secrets are a few simple ones of those. And sure, on Linux the SSH key is still a plaintext file. But it’s a deliberate decision of you to keep it as plaintext. You can at least encrypt with a passphrase. You can use the actual working file permission model of Linux and SSH will refuse to use your key with loose permissions. You would do the same on Windows and Mac and use a credential store and an agent to securely store and use your keys.

Just because your SSH key is a plaintext file and the presumption of a secure home dir, you still wouldn’t do a ~/passwords.txt.

SSH has encrypted keys

Yes, in your head, and in your second factor, if possible, keeping derived secrets always encrypted at rest, decrypting at the latest possible moment and not storing (decrypted) secrets in-memory for longer than absolutely necessary at use.

Chrome cookies are encrypted, for exactly the reasons stated. If malware gains access to your system and compromises it in a way that DPAPI calls can be replicated in the way Chrome does it, then your sessions will also be compromised. But this is way harder to do, and at least prevents trivial data exfiltration.

Nope. Your presumption is wrong.

There are too many differences for me to list here, but unlike mobile operating systems, Windows and most Linux desktops do not provide sandboxed environments for userspace apps by default. Apps generally have free reign over the whole system; reading/writing data from/to other apps without restriction or notification. There are virtually no safeguards against malicious actors.

Mobile operating systems significantly restrict system-level storage space, making key areas read-only to prevent data access or manipulation. They also protect app storage, so one app can’t arbitrarily access or modify data stored for a different app.

Mobile operating systems also follow an image-based update model, wherein updates are atomic. System software updates are generally applied successfully all at once or not at all, helping to ensure your phone is never left in a partial or unusable state after a system update.

For desktop users, macOS, and atomic Linux distros combined with Flatpak are the closest comparisons.

A different encrypted messaging service. Decent, but hasn’t taken off despite using email for accounts rather than phone bonkers numbers

Don’t use signal as its not good for anonymity

The irony

It’s plaintext all the way down.

I mean combined with any kind of function, even a trivial kind. A salt derived from some machine state data (a random install id generated on install, a hash of computer name, etc) plus a rot13 or something would still be better than leaving it plaintext.

It is easier to compromise a device than to try and compromise encrypted communications.

Is it possible to seamlessly integrate, so when something requests those keys you’ll get a prompt?

Yes, but you STILL need to enter password on every reboot.

Linux has the secret service API that has been a freedesktop.org standard for 15 years.