NIP-04 by itself is not vulnerable and is secure against these “attacks” as signatures exist
Discussion
AES-CBC (the core of nip04) has been removed from many crypto suites, including TLS 1.3, due the many security issues in poor implementations, mostly related to oracle padding attacks, which are also possible in nip04.
Said attack is not possible in NIP04 due to signatures.
Talking about attacks without knowledge is easy.
Is it a bad spec? Mostly. Is it so bad that we have to rip out every use case? Probably not.
Things like padding can be retrofitted into existing NIP-04 use cases. For example JSON lists can use space padding.
"Probably" is not a word you want to use in security systems.
Again, is there an *applicable* attack on NIP-04? There are good reasons to remove it (unifying encryption standards) but it is not the boogeyman you present it as.
I am not presenting anything. Several cryptographers did in multiple discussions. Fiatjaf built nip04 without any deeper knowledge in encryption. That alone should be a massive red flag. I don't understand this need you have to keep defending a lausy spec. Especially when others specs are readily available and have been fully vetted.
To be fair, the same cryptographers that pushed for NIP-44, also lied about NIP-04 leaking private keys.
The "attack" they presented would require:
- A way to extract an AES key from a pair of chosen ciphertexts + their plaintext (or the other way around)
- At least millions of rounds of user interaction in an unusual way
- A way to forge signatures that uses keys derived from the user's private key
No need to forge signatures if you only want to decrypt it. You can just build an app that uses Amber to sign locally. Doing millions locally is quite easy. Is fact, billions is quite easy.
Again, I don't understand the need to give people the risk of somebody putting that together.
> - A way to extract an AES key from a pair of chosen ciphertexts + their plaintext (or the other way around)
Also fulfill this. The answer is that you can't.
The problem here is that the risks of NIP-04 have been extremely exaggerated. It is not an ideal spec and it should be moved off of, but the idea that it presents *any risk* is absurd.
No, the problem is that the risks to nip04 are unknown because it depends so much on how signers and clients implement NIP-04. It SHOULD be exaggerated exactly because devs can and will fuck it up. Its virtually impossible to fuck an implementation of nip44 up.
The risks of NIP04 are very known.
The people that were fearmongering about NIP04 being the end of the world were the same that were getting paid to create a replacement which needed to be fancy and critical, to earn them a large grant.
Unless your client has gone rogue, and there is a critical flaw in AES (both!), it is impossible to realistically break NIP04.
Lol, what is this? Grudge? Are you jealous Paul did the work and got a tiny grant for the huge amount of hours the put into? You know he didn't receive the grant right? He donated back to open sats to pay for the audit on his own code. Something no one ever did in NIP04.
No one should ever even consider using nip04 for anything.
There is no grudge, only the fact that they pushed the narrative that NIP-04 will leak private keys to unknowing devs and users by abusing their position, for personal gain.
If anything, NIP-44 did not resolve significantly more critical problems like the fact that approving [en/de]cryption is still a blind operation.
Not that an encryption scheme requires an immense amount of hours. The horse of two-party asymmetric encryption has been beaten to death and you can find countless spins on the same goal.
The design of anything on nostr should allow for a high percentage of normies losing or exposing their nsecs, and this makes all this Encryption A vs Encryption B stuff moot.
Shared keys, not private keys.
What the fuck are you talking about that NIP44 didn't resolve any significant problems? Now you are just being malicious. It's clearly better spec, better secured, easier to implement to avoid issues, and audited. Why are you dismissing these improvements?
The blind operation will always be there for very generic encryption schemes like the one we need in nostr. You can add anything else you need outside the ciphertext on nostr.
It is clearly said to be private keys and was pushed as such.
I did not say NIP-44 did not resolve ANY significant problems, but it glossed over much more critical ones. All of the attacks that are possible on NIP-04 are unrealistic in reality, but the attack that an application can ask to decrypt lists and then siphon off all your DMs is very real.
NIP-04 was poorly designed, but saying that I am acting malicious for showing you that:
- part of the push for it was based on lies
- that the risks were falsely marketed
- that the paper's attacks on NIP-04 assume major flaws in implementation (no signature checking)
is bullshit.
So, what you are saying is that we should dismiss the work and give credit to lousy, outdated schemes that we know are a risk just because nip44 didn't solve a problem that is not even theirs to solve?
I think you are being malicious. You are clearly mixing responsibilities between distinct security layers to muddle the waters, confuse everyone and make a point based on a grudge you had with the developer. It's just sad.
Can you please show me which sentence is saying that we should dismiss NIP-44 and stick with NIP-04? Or that I have any reason to have something against Paul?
NIP-44 was pushed on false premises.
NIP-04 is not great.
But the risks of it are not as much as an immediate threat as there being no way to control encryption access, and intent confusion where the same encrypted blobs could be reused in different places with different meanings.
This could have been addressed by the spec via inclusion of AD.
Just read this entire conversation. You keep suggesting that nip44 did nip04 dirty even though it is clearly better. I have never seen you advocating *cleanly* for NIP-44. You always write as if you wanted NIP-04 back, which will never happen. I don't know why you do this, but you do. It's very clear. I think you like to have grudges and those trump any rational analysis on the debate.
So your assumptions are automatically fact? Interesting.
I do not want NIP-04 back and I have never stated that.
But NIP-44 was rushed through based on false information, out of thin air, while important concerns that have existed for a long while (such as encryption intent) not being considered.
That is what I have stated and what you keep trying to intentionally misinterpret as “wanting NIP-04 back”.
Nip44 wasn't rushed. I don't know why you would say that. Again.. your grudge shows..
Everything points back to you selectively misinterpreting what I am saying to prove a nonexistent point, and making up me having a grudge.
It was rushed. The sentiment that NIP-04 will cause a catastrophe and nsecs will be leaked was pushed strongly during its proposal to ordinary users that did not know any better. And all while major gaps still exist.
It took us 2 years to develop, test, audit and verify nip44. How long did you want it to take to not be rushed? We needed to get out of nip04 fast. Everybody was complaining about how terrible it was and it was affecting Nostr's image everywhere, but especially in the cryptography community, which knew very well how idiotic the scheme was.
Since nip44, no one has dared to say Nostr devs have no idea what they are doing in encryption.
2 years? It only took a few months at most, and the specification was likely outlined within an hour.
The only thing that has taken 2 years is convincing devs that the absurd gift wrap standard (independent of NIP-44) is a good idea, which continues to be proof that Nostr devs truly have no idea what they are doing.
By trying to get a solution to obscure complaints fast the only thing we have done is left much more realistic problems like encryption intent unsolved.
Nostr’s image was not significantly impacted by NIP-04 except research papers that like to dunk on unrealistic scenarios, and NIP-44 *adoption* (due to it mostly being a low practical benefit change) is still nowhere near completion, partly because the only scheme using it also happens to be shit.
I see you don't even know we changed cryptographic curves (a fundamental step) twice 7 months after the first idea and had to retest everything.
I am not even including giftwrapping and the NIP-17 scheme. 2 years was just NIP44.
I am going to stop this discussion because you clearly have a grudge and your ego is overwritting any rational discussion on this. There is no point. You just want to create a fuzz about it even though you agree NIP44 is significantly better than nip04.
Or you are not getting it, considering that you said it took 2 years to do NIP-44 when it did not, and that changes to the core public key scheme of Nostr was required twice
How can you claim to know how long things too if you werent even there? I was. Why would you even make such claims? I don't get it. Your ego must really be hurt by something. This is not normal.
You know, the development process is open for everyone to seed there is no closed committee for this. Even including “empty” time spent on waiting for merges, and a very liberal definition of the start and end time, 2 years is nowhere close.
All you are doing is attacks on me and absolutely nothing of substance about reality, which is pretty disappointing to see.
Not the 1st time your personal views have prevented you from seeing the reality 🤷
Please narrate this whole thread on BA. Best thing since gargling peters balls