When Signal was designed, our threat model was protecting the communications of civil society, journalists, just regular citizens ...
The threat model of military operations & sharing your hate of Europeans was not what Signal was designed for. Ephemeral messages and cryptographic deniability are not fit for communications that require accountability.
But I appreciate their effort to make government more efficient by adding journalists to the chat instead of requiring to go through FOIA.
@kkarhan@infosec.space@fj I still think @signalapp has fundamental flaws like demanding #PII (#PhoneNumbers can't be obtained anonymously around the globe and are trivial to track down to devices and thus users), being subject to #CloudAct as an unnecessary & 100% avoidable risk as well as #Shitcoin-#Scam shilling (#MobileCoin) and it's #proprietary, #SingleVendor & #SingleProvider nature that makes it inferior to real #E2EE with #SelfCustody like #PGP/MIME & #XMPP+#OMEMO!
@kkarhan@infosec.space @fj@mastodon.social some of these are issues, but to be real the suggestion to use PGP and MIME instead of signal is laughable, not only is it nonviable as a replacement, but also is just bad to deal with and use in comparison
firstly, try to achieve similar security as signal with only PGP (or OMEMO), secondly after pulling off that technically impossible feat, try to use it without causing 100x more avoidable security issues than signal does right now
after doing that I think you can appreciate that although signal has many flaws (phone numbers being my biggest issue with them) they are actually still doing state-of-the-art security/privacy/cryptography services and can't easily be replaced by random other tools like this lol
@froge @kkarhan @fj Also XMPP is just bad, not only from a security standpoint (which I trust security experts on, not being one myself) but also as a protocol designed... before smartphones, basically. Being totally married to being connection- instead of session-oriented is basically why Matrix exists, at all.
@kkarhan@bdf2121cc3334b35b6ecda66e471 @froge @fj maybe but it's better than a #proprietary, #SingleBendor & #SingleProvider solutiom as it just works even on #throttled, sub-#2G speeds over #Tor...
- And you get real #E2EE with #SelfCustody of all the Keys!https://infosec.space/@kkarhan/114223266562515116
@kkarhan@froge @fj I'm not replacing @signalapp with "random tools" but good options.
Like @delta & @thunderbird as well as @monocles / #monoclesChat & @gajim which work flawlessly over @torproject / #Tor using @tails / @tails_live / #Tails and @guardianproject / #Orbot respectably.
- Also these allow not only #SelfHosting but just work and I'd highly recommend #monocles as a hoster which finances iself by users paying and allows #anonymous accoubts & payments including not just #Monero but also #CashByMail!
Considering the costs of even acquiring and upkeeping an #anonymous #SIM, I'd rather pay €2 p.m. for #XMPP+#OMEMO and #PGP/MIME-supported #eMail with the option of self-custody than $2,50+ p.m. just to keep a phone number.
- Plus I don't run around with a #tracking device that could be used to #deanonymize me any second...
Or is anyone here expecting @Mer__edith to risk jail for life [infosec.space] amd not comply with #CloudAct?
- If #Signal was as secure as advertised, it would've been shutdown like #EncroChat and #SkyECC!
It stenches like #ANØM, because NOTHING IS FOR FREE and running a #VCmoneyBurningParty is expensive...
@kkarhan@infosec.space @fj@mastodon.social that's fine, I actually really like deltachat and a few others, but none of them pretend to match the same level of security as Signal because they're not actually the same level of security/privacy/confidentiality in the real world, I don't really trust signal self hosting their servers either but that doesn't mean these alternatives match the same level of privacy and security on a technical level
for example the encryption used by Deltachat openly has flaws and doesn't support perfect forward secrecy in the cryptography, this is on purpose, they mention it several times in the documentation, because their goal is to be compatible with existing email systems and that requires protocol constraints and trade offs
Fact is deltachat (and many others on this list) are not as cryptographically secure as signal, and they're not trying to be, and that's fine as long as you understand many of these tools make tradeoffs in their privacy/security in unique ways for their use cases
still doesn't mean any of them will provide the same level of secure and private service that signal does, even if they are more decentralized and cheaper/easier sometimes for some people
@froge @kkarhan @fj decentralization is something you generally dont want, unless you properly solve it at the protocol level. Thats why matrix sucks and will always be inferior to a centralized solution like signal (unless fixed at protocol level, which most likely wont happen).
and yeah, most "competitors" arent really ones, if they think PFS is optional ...
@brahms@chaos.social @kkarhan@infosec.space @fj@mastodon.social I do personally like that Deltachat is secure against a server compromise, and their efforts to hide metadata and content from hostile servers are nice, I think that has something over signal... but the lack of PFS (and indeed the ability to send unencrypted data by default) means other known attacks could be mounted instead, so to say it matches signal is still probably wrong on a technical level
besides a lot of these tools only work if you're smart enough to securely deploy and maintain an entire server yourself, and that is.... not possible for most of the population, even if they're a programmer or work IT-adjacent jobs
@kkarhan @froge @fj @signalapp @delta @thunderbird @monocles @gajim @torproject @tails @tails_live @guardianproject @Mer__edith Signal has been asked for data before. I believe they responded that they have the timestamp the user registered and the timestamp they last logged in, and nothing else.
The CLOUD Act does not allow the US government to force Signal include a backdoor into its clients.
@kkarhan@alwayscurious @froge @fj #CloudAct alone not, but it's just the tip of the iceberg.
- I bet you that @signalapp & @Mer__edith will comply with even the most illegal and cyberfacist orders when facing "rubberhose cryptoanalysis", which is a valid and likely risk factor in the #USA...
Again: The only #security is #decentralization!
- This is why @torproject is still up and running: It cannot be shutdown even when all maintainers are being held at gunpoint.
#Signal is as vulnerable as #EncroChat if it's not a #Honeypot like #ANØM!
@NosirrahSec@infosec.exchange@kkarhan @froge @fj @signalapp @delta @thunderbird @monocles @gajim @torproject @tails @tails_live @guardianproject @Mer__edith Someone explain to me how this isn't a bot just hashtagging random words.
@forthy42@mastodon.net2o.de@froge @kkarhan @fj You confuse crypto security with operational security, a common mistake. While Signal has a ridiculously high level of cryptographic security (much of which it needs, because it does store-and-forward of messages it never should see at all), it is shitty for the reasons above.
Because I'm not happy with either way, I'm working on my net2o protocol, which is peer2peer, and state-of-the-art with how it deals with encryption. It doesn't jump through the hoops to try making store-and-forward on hostile servers feasible, because that's a bug. You never should design your protocol to include this, not even as option.
The reason why people wanted store-and-forward in the not so recent past was that they were offline most of the time, batch-fetched their e-mail through a per-minute landline, and then answered their e-mails and went online again.
This is how I used the Internet 30 years ago. Today, people have their always-online devices, and while there are still interruptions, you don't need that central instance. Especially for group chats, reliable instant transfer (with the exception of those participants which are offline at the moment) is always possible.
@forthy42@mastodon.net2o.de @kkarhan@infosec.space @fj@mastodon.social it's not that I actually confuse these things, it's that the alternatives presented have equally bad operational security problems too, just in new and interesting ways, so it's hardly worth mentioning as a point of comparison to me in general
@kkarhan@froge @forthy42 @fj to me, @signalapp being centralized and not even doing tue absolute minimum of supporting @torproject / #Tor and having at least an #OnionService as #API-Endpoint makes them #UsefulIdiots.
It's several things like that that rubvme the wrong way and that make it uncomfortable.
@kkarhan
PGP leaks metadata by design, and doesn't have forward secrecy by default.
(There is sequoia-pgp, that supposedly “unstuck” the PGP development, but being OOTL I've missed it.)
https://www.latacora.com/blog/2019/07/16/the-pgp-problem/
XMPP+OMEMO has a lot of problems.
https://soatok.blog/2024/08/04/against-xmppomemo/
You're left with Matrix, which has some problems, with a wonky security culture (like not hard-depreciating libolm) and leaking metadata.
Still, if you're against Signal, you're left with Matrix on the top.
@kkarhan@dzwiedziu @fj @signalapp not really, as the #Metadata #FUD cited by #Signal is mitigateable with proper measures.
- You can't even run Signal over @torproject and even if that point is moot when you're forced to quasi-#KYC by virtue of a #PhoneNumber aka. #PII they have neither legitimate interest nor technical reason to demand in the first place!
Every claim that things like #ITsec, #InfoSec, #OpSec & #ComSec can be solved with "Just use Signal!" is "#TechPopulism" at best if not being a "#UsefulIdiot"!
- All #centralized, #SingleVendor & #SingleProbider systems are inherently insecure!
@kkarhan I thought I was able to run signal over tor once. I think it was for messages rather than calls but it still worked
