The criticism in that issue is pretty bad, I agree. But the crypto in secrets.js is all kinds of bad:
The use case is sometime calling this tool to decrypt data received over an unauthenticated channel [0], and the author doesn’t seem to get that. The private key will be used differently depending on whether the untrusted ciphertext starts with '$'. This isn’t quite JWT’s alg none issue, but still: never let a message tell you how to authenticate it or decrypt it. That’s the key’s job.
This whole mess does not authenticate. It should. Depending on the use case, this could be catastrophic. And the padding oracle attack may well be real if an attacker can convince the user to try to decrypt a few different messages.
Also, for Pete’s sake, it’s 2025. Use libsodium. Or at least use a KEM and an AEAD.
Even the blog post doesn’t really explain any of the real issues.
[0] One might credibly expect the public key to be sent with some external authentication. It does not follow that the ciphertext sent back is authenticated.
But having bad crypto doesn't mean you have to be aggressive... in fact if the critic's goal is to actually improve the situation (and not just vent or demonstrate their superiority) then being polite and actually answering the questions might go a long way further to remedy it.
You’re right. The problem is that after repeating the same thing hundreds of times to different developers you can develop a bit of an anger toward the situation, as you see the same mistakes play out over and over.
I’m not defending it, but I can understand where it comes from.
What's the point of filing the issue if you're already fed up giving adequate answers then? For a random open source project I'd definitely expect people who file issues to help solve them collaboratively.
I don’t disagree with you. The idea is that there is a lot of information online about how to do it right. I would have stayed to explain, because it’s confusing af, but I think that’s what happened. I don’t think soatok is intentionally self-serving, but I don’t know them personally.
The use case is sometime calling this tool to decrypt data received over an unauthenticated channel [0], and the author doesn’t seem to get that. The private key will be used differently depending on whether the untrusted ciphertext starts with '$'. This isn’t quite JWT’s alg none issue, but still: never let a message tell you how to authenticate it or decrypt it. That’s the key’s job.
This whole mess does not authenticate. It should. Depending on the use case, this could be catastrophic. And the padding oracle attack may well be real if an attacker can convince the user to try to decrypt a few different messages.
Also, for Pete’s sake, it’s 2025. Use libsodium. Or at least use a KEM and an AEAD.
Even the blog post doesn’t really explain any of the real issues.
[0] One might credibly expect the public key to be sent with some external authentication. It does not follow that the ciphertext sent back is authenticated.