Signal under fire for storing encryption keys in plaintext
stackdiary.comPopular encrypted messaging app Signal is facing criticism over a security issue in its desktop application. Researchers and app users are raising
You must log in or register to comment.
A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn’t great, if contents of the website are behind a paywall maybe copy them into the post
- Don’t promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
Chat rooms
-
[Matrix/Element]Dead
much thanks to @gary_host_laptop for the logo design :)
- 0 users online
- 57 users / day
- 383 users / week
- 1.5K users / month
- 5.7K users / 6 months
- 1 subscriber
- 2.97K Posts
- 74.6K Comments
- Modlog
You act as though you somehow have more knowledge than everyone else. They problem is that you don’t understand encryption and permissions. You can’t just magically make something unreadable by programs with the same permission level. If you encrypt it there will need to be a key to decrypt it. That can could conceivably be encrypted with a password but that would require someone to enter a password. If they don’t enter a password they key will be stored plain text so anyone could easily decrypt your messages. Programs running as a user have the same permissions as that user. Does that make sense? You can’t just make something selectively unreadable with the current security model. I guess you could try to implement some sort or privileged daemon but that would open up more issues than it solved.
I would have a problem if Signal claimed that the desktop messages were encrypted at rest. However, they don’t make any such claim. If you are concerned about security I would recommend running everything in virtual machines and flatpaks. This way the chances of something misbehaving in a way that causes harm is minimized.
I’m not claiming some grand level of knowledge here. I also cannot enumerate all risks. The difference is that I know that I don’t know, and the danger that poses towards cognitive biases when it comes to false confidence, and a lack of effective risk management. I’m a professional an adjacent field, mid way into pivoting into cybersecurity, I used to think the same way, that’s why I’m so passionate here. It’s painful to see arguments and thought processes counter to the fundamentals of security & safety that I’ve been learning the past few years. So, yeah, I’m gonna call it out and try and inform.
All that crap said:
And you are right, the problem gets moved. However, that’s the point, that’s how standardization works, and how it’s supposed to work. It’s a force multiplier, it smooths out the implementation. Moving the problem to the OS level means that EVERYONE benefits from advanced in Windows/Macos/Linux. Automatically.
It’s not signal’s responsibility, it shouldn’t be unless that’s a problem they specifically aim to solve. They have the tools available to them already, electron has a standardized API for this,
secureStorage. Which handles the OS interop for them.I’m not arguing that signal needs to roll their own here. The expectation is that they, at least, utilize the OS provided features made available to their software.