You can write algorithms that leak every bit of your secrets, trivially. The npm "elliptic" package does this. Daniel Bleichenbacher has tested several packages' timing leakage in Rooterberg that are easily exploited: https://github.com/bleichenbacher-daniel/Rooterberg/blob/mai...
You can use algorithm implementations that do not have secret-dependent timing differences in any language, as long as you are clear that your guarantees do not extend to the underlying runtime or to compiler optimizations. This isn't perfect, but it's better.
You can go further Rust-to-WASM and use tools like https://github.com/trailofbits/skills/tree/main/plugins/cons... to check the assembly and the runtime that the assembly runs in. (Most of the linked Claude skill is a Python program. It just relies on AI to eliminate false positives.)
Read the whole thing, but OK you didn't accuse anyone of being evil yet. But let me clarify that even if a later optimization breaks your constant time property that still wouldn't be evil.
You walked back putting an accusation of evil in my mouth while following up with warning me not to make an accusation I would not make to begin with. Incredible.
People seem to get on with Discord invite links just fine. You don't have to do the "confirm that all these emoji are the same on both your devices" dance to stop spam.
> People seem to get on with Discord invite links just fine.
Discord is used by a narrow group of technically literate people. Signal is for everyone. Your grandparents probably don't use Discord, but if they can text then they can use Signal.
If your concern is "muh phone number", then you can pay and not have to give the phone number to sign up.
It's already the case today (and has been for years) that you don't need to give strangers your phone number to chat on Signal. My username is soatok.45; try to get my phone number if you can.
If you want absolutely no info to be collected, ever, and there to be zero cost on the end user too, be prepared to welcome your new spam overlords. Because the people who will benefit the most from a zero cost signup that only requires a username are spammers.
I'm a bit surprised by this dismissal. Of course some info must be collected, or there must be some cost to enter (probably both I mean phone number is also a cost, but one most people already sunk). But we can still debate the best way, right?
For example:
* Are you absolutely positive signal will never have a bug that let attackers reveal contact phone numbers? I really trust in their secure coding skills, but this class of vulnerabilities (like 2fa leaj) happened to even the biggest players.
* One of the reasons signal collects phone numbers (and asks for a contacts permission) is to check which contracts are already on signal. For some people or in some governments even having a signal account is an opsec problem (to be fair, they have a secure privacy-preserving protocol for this - as you know - and it's possible to avoid this footgun if necessary)
Trying to position the conversation as "we're on the same team, trying to figure the problem out together" also helps a lot of the intensity of these conversations melt away.
No, state's cannot e.g. discriminate on the basis of race by allowing corporations only composed of certain races. States also cannot infringe on the right to assemble or speak, by prohibiting people from supporting political candidates when they are organized as such a group.
But, generally, yes. States can require that the owners / members / corporate books / etc. of a company be disclosed publicly. If owners don't want their books disclosed, then they can forego the immunity that the corporate forms provide.
> About the post you linked, see [1] and [2], which makes me question both whether that is an actual vulnerability (Signal, the messenger recommended by the author, also didn't have that check, and it's addition is absent from release notes and CVEs)
I've edited the above linked post several times to make this clearer, but people still keep linking Matrix's flawed response as if it actually addressed the issue. It does not.
The issue is not as simple as "did the check exist? [y/n]". There are actually two issues:
1. Did the check exist? [y/n]
2. Did the group key agreement protocol fall to shit if the check was omitted? [y/n]
Matrix was (n, y) due to how Megolm manages keys in group contexts. Signal was (n, n) due to their protocol design.
Matrix tried to defend point 1 when the blog post was about both 1 and 2.
(Post-Quantum MLS, for comparison, would also have been impervious to this issue due to how KEMs work. Another point in favor of MLS adoption.)
> and whether the post was made in good faith (the check was added to libsignal on the same day that the author disclosed the vulnerability to Matrix, which can be a coincidence, but doesn't seem likely given that the code has been there for years).
Even if you assume the worst possible interpretation of this coincidence (which, sure, you're free to if you want-- you would be wrong if you did, of course): What does it even matter?
Like, what is the notion of "good faith" that's even necessary for someone to do independent security research and publish criticism of the cryptography used by a software project that's being propped up by EU sovereignty movements?
In my opinion, this is a stupid and vacuous framing.
Signal omitting the check didn't harm Signal's confidentiality. Matrix omitting the check demonstrably did.
---
Also, if you're going to decry my blog post for not enumerating unrelated security bugs (n.b., the blog post was about Matrix, not Signal, so why would I talk about Signal's code in that post???), be aware that I reported non-cryptographic bugs to Element (Matrix client) and Conversations (XMPP client) around the same time. Only XMPP actually credited me with any fixes.
(Not to detract from anyone's cleverness or hard work.)
reply