Soatok

Good job releasing your project! It's a cool idea and surprisingly minimalist. That said, I've found a number of cryptographic flaws in the application source. This should not be used in instances where the encryption is mission-critical.

1) You generate a random key [0] and then feed it into PBKDF2 [1] to generate a 32-byte AES-GCM key. If you can generate 32 random bytes instead of 10 reduced-ASCII characters and a key stretch, just do that. PBKDF2 is for turning a password into a key, and it's far from the recommended algorithm nowadays; prefer scrypt if you need to do this sort of thing.

2) AES-GCM with random 12-byte nonces. Never use random IVs with GCM; this breaks the authentication [2] [3]. Given the pitfalls of AES-GCM with respect to random nonces, you might prefer switching to XSalsa20+Poly1305. The advantage of XSalsa is it has an extended nonce length, so you can use random nonces without fear.

3) Random key derivation with a restricted character set can make brute force attacks easier. You should have a 256-bit random key, and if you want that key to be within a certain character set, then encode the byte output from the CSPRNG using that character set.

4) 1fps achieves symmetric key distribution via a URL with a fragment identifier ("#") which IIRC is not sent to the server. Therefore it assumes you have a secure key distribution channel - the link contains the key, so it's important that only the intended recipient can view the part after the "#". If the…

Doesn't help that all of the major decentralized protocols have been very effectively undermined and pushed aside.

GTalk first de-federated (weakening XMPP as a whole), then killed XMPP support completely. Reader effectively killed RSS for casual users. Email has been swallowed whole by the oligopoly of GMail+Yahoo+Outlook+iCloud+etc; spam is a real problem, so if you're self-hosting your email, you kinda expect to be blocked by default by the large networks.

Existing, corporate-backed efforts are "open-washing" their services.

Signal is supposed to be using an open protocol, but IIRC won't even let you join their network if you use an alt client.

Following Twitter's demise, Bluesky popped up, and promised federation. I didn't check in a while - did it happen yet?

Actually open networks? Mastodon took off like crazy, but everyone tried to register on the "main", biggest instance - we got bamboozled so hard, we can't even comprehend what "decentralized" is actually supposed to mean.

ActivityPub as a protocol? Ted Unangst decided to build his own client from the spec, and was constantly running into Mastodonisms. <https://flak.tedunangst.com/search?q=activitypub>

Matrix? It has effectively one client (Element) that isn't a security disaster. <https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/>

Anything left, worth of anyone's attention?

Which is ironic, because my whole point is "if you want to fight it, try to be credible". Every bit of energy spent saying "it's fundamentally not possible to do that, you would have to be stupid to consider it" is, IMHO, wasted.

Because what I read is "ok, this person is either not competent to talk about it, or arguing in bad faith, so I won't listen to them".

And to be very honest, I can't remember a good argument against "privacy-preserving age verification". It's mostly "hmm I don't like it, that should be the responsibility of the parents anyway".

The EFF has a valid point which is "such technology will leave people out who won't be able to access important services". I don't have a definitive stance on it, but that would be worth debating. I can't remember another argument from the EFF. Pretty sure they don't say "it's technically impossible to do".

Actually Soatok [1] starts by acknowledging it's possible, before going straight to their opinion: "we should not do it". Again, I think it's a debate worth having.

But I won't debate with people who either don't have a clue or downright lie about it, saying "it's not possible, period".

[1]: https://soatok.blog/2025/07/31/age-verification-doesnt-need-to-be-a-privacy-footgun/

This changed about two years ago, when they added usernames. ( https://signal.org/blog/phone-number-privacy-usernames/ )

Signal can still tell law enforcement (1) whether a phone number is registered with Signal, and (2) when that phone number signed up and (3) when it was last active. That's all, and not very concerning to me.
To prevent an enumeration attack (e.g. an attacker who adds every phone number to their system contacts), you can also disable discovery my phone number.

While Session prevents that, Session lacks forward secrecy. This is very serious- it's silly to compare Session to Signal when Session is flawed in its cryptography. (Details and further reading here https://soatok.blog/2025/01/14/dont-use-session-signal-fork/ ). Session has recently claimed they will be upgrading their cryptography in V2 to be up to Signal's standard (forward secrecy and post-quantum security), but until then, I don't think it's worth considering.

I agree that Briar is better, but unfortunately, it can't run on iPhones. I'm in the United States and that excludes 59% of the general population, and about 90% of my generation. It's not at fault of the Briar project, but it's a moot point when I can't use it to talk to people I know.

> I've literally blogged about tool recommendations before

Do you happen to know of a similar resource applicable to common HN deployment scenarios, like regular client-server auth?

For example, in your Beyond Bcrypt blog post[0] you seem to propose hand-writing a wrapper around bcrypt as the best option for regular password hashing. Are there any vetted cross-language libraries which take care of this? If one isn't available, should I risk writing my own wrapper, or stick with your proposed scrypt/argon2 parameters[1] instead? Should I perhaps be using some kind of PAKE to authenticate users?

The internet is filled with terrible advice ("hash passwords, you can use md5"), outdated advice ("hash passwords, use SHA with a salt"), and incomplete advice ("just use bcrypt") - followed up by people telling you what not to do ("don't use bcrypt - it suffers from truncation and opens you up to DDOS"). But to me as an average programmer, that just leave behind a huge void. Where are the well-vetted batteries-included solutions I can just deploy without having to worry about it?

[0]: https://soatok.blog/2024/11/27/beyond-bcrypt/

[1]: https://soatok.blog/2022/12/29/what-we-do-in-the-etc-shadow-cryptography-with-passwords/

Ack. Thanks for the points. Un-packing a few things:

3. Definitely — We're working to cut our dependencies in the coming months. Most existing dependencies (the backend at least - I focus more here) we stick to those widely used; there're also certain dependencies directly linked to integrations with third-party platforms (e.g. AWS, Octokit - GitHub, etc.).

4. We'll take a look — This is on our immediate roadmap as well.

5. We actually did evaluate both PKDF2 and Argon2id options in addition to seeing what other secure platforms are doing. We found most to start out with PKDF2 but overtime to introduce support for Argon2id — Take Bitwarden and Dashlane as two examples of this; Bitwarden of which introduced it as of only a few months back. This article may help: https://soatok.blog/2022/12/29/what-we-do-in-the-etc-shadow-cryptography-with-passwords/

The choice of Argon2id KDF is sound and recommended; we have it with memory cost of 64MiB, ops cost of 3, and parallelism of 1.

6. argon2-browser is still used well and reliably throughout the ecosystem — take Bitwarden as the biggest example of a solution recently making the switch to use it.

Anyways, happy to move this discussion to email!