Why can't we have nice things? stackdiary.com/signal-under-fire-for-storing-encryption-keys-in-plaintext/
This is pure incompetence
+bonifartius 𒂼𒄄
@zleap @mttaggart that they don't encrypt keys on the desktop isn't. either you can trust a device or you can't. it's trivial to extract the keys in some way by just waiting for them to be unlocked.
what really is a blunder is that they don't do something about multiple concurrent sessions using the same keys.
How is it trivial to get the keys when using an API to store secrets?
https://specifications.freedesktop.org/secret-service/latest/ch01.html
@alxlg
freedesktop, the place everything has to use dbus.
to quote the specification you linked:
> You must specify a session when retrieving or storing a secret. The session controls how the secret is encoded during transfer. Since this is a D-Bus API, the data in all method calls and other accesses in this API will go through multiple processes, and may be cached arbitrarilyby the OS or elsewhere.
>
> The Secrets API has provision to encrypt secrets while in transit between the service and the client application. The encryption is not envisioned to withstand man in the middle attacks, or other active attacks. It is envisioned to minimize storage of plain text secrets in memory and prevent storage plain text storage of secrets in a swap file or other caching mechanism.
i'll rest my case.
Signal was supposed to use that API, if you can tell me how:
> it's trivial to extract the keys in some way by just waiting for them to be unlocked.
with that API?
I don't care about your opinion on Dbus.
@alxlg sorry, that was a bit confrontational.
"desktop" linux has a real complexity problem, starting with systemd at the bottom all the way up to the desktop environments. pushing secrets over a message_bus_ is very questionable.