Thanks for your efforts, Daniel. I didn’t know about the 64 KB limitation myself.
nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgswaehxw309ahx7um5wghx6mmd9u2mk7fe, nostr:nprofile1qqs8evfumcr8pevs7qkta84qlnc7qhkmchxg5syhx8a9gdjyqxqu78gppemhxue69uhkummn9ekx7mp0dpmzxy, apologies for bothering you. Is the 65,535-byte plaintext padding limitation described here a hard limit for what can be encrypted with NIP-44, or should NIP-44 be breaking down plaintext into 64 KB blocks and only applying padding to the last one?
"Validate plaintext length. Minimum is 1 byte, maximum is 65535 bytes"
If it’s the former, we shouldn’t be using NIP-44 encryption for the lists/sets in NIP-51. If it’s the latter, then this looks like a bug.
NIP-04 weaknesses have also been greatly exaggerated and feel like an intentional attempt to force through their own encryption scheme.
It was sold on the premise that "NIP-04 could leak your private keys" while that would require an uncountable rounds of user interaction, a key-recovery attack on AES and getting the user to sign events with *modified versions of their nsecs*.
Every cryptographer that I showed the nip04 spec thought it was a joke, because it was so bad in so many angles.
It is a joke, the primary concern being that an AES key should only be reused for so long.
But the rush to replace it, while the author is fearmongering people with attacks that are infeasible, with issues like message size in the spec and unnecessary complexity like MACs *when the data is already signed* is simply nonsense.
Rush? It took two full years to to the change. And nostr:nprofile1qqs8evfumcr8pevs7qkta84qlnc7qhkmchxg5syhx8a9gdjyqxqu78gppemhxue69uhkummn9ekx7mp0dpmzxy was the only one to actually provide any alternative. No one else did anything.
