mleku™️ @mleku - 2mo
in https://github.com/indra-labs/indra i use a random amount, the actual length of the message is underneath the encryption, i forget exactly what ratio i used but it randomises from real to some amount more the scheme in nip-44 is retardo
the proper way to do it is to put a length prefix right at the start of the encrypted block, and if you use a counter mode, you can just decrypt that first part and find out how much you need to decrypt, and then you do it any other garbage should just be ignored, just like with nostr envelopes, once you have decoded the expected fields who gives a fuck if it's got 5gb of rubbish after it
well, any cipher mode should let you pick up the first 32 bytes obligation free
also, fuck whoever devised nip-44 i wanna slap them all with a Boneh and Koblitz very firmly
ok, but this "only powers of two" thing is goddamned retarded it should not matter how the sender decides to pad out their data, because i understand it that some runtime environments don't have credible CSPRNGs, though thank fuck they are vanishing into history i mean fucks sake you can seed a crappy PRNG with the actual length and get some number that is moderately fucking random "to the nearest power of two" is not ok though, not in a million years
it's in the websocket protocol anyway it's just a waste of processing to decode potentially 50% of a message that is padded for nothing, especially when your decryption engine is javascript