ChipTuner on Nostr: Usually padding is required for the cipher's block size, however in nip44 chacha20 is ...
Usually padding is required for the cipher's block size, however in nip44 chacha20 is a stream cipher and will accept arbitrary input lengths
"Concatenating the keystream blocks from the successive blocks forms a keystream. The ChaCha20 function then performs an XOR of this keystream with the plaintext. Alternatively, each keystream block can be XORed with a plaintext block before proceeding to create the next block, saving some memory. There is no requirement for the plaintext to be an integral multiple of 512 bits. If there is extra keystream from the last block, it is discarded. Specific protocols MAY require that the plaintext and ciphertext have certain length. Such protocols need to specify how the plaintext is padded and how much padding it receives."
https://datatracker.ietf.org/doc/html/rfc7539
I believe some ciphers like mleku (npub1fjq…leku) mentioned, depending on their modes, can become vulnerable due to lack of entropy if the input block size is "too small"
"Concatenating the keystream blocks from the successive blocks forms a keystream. The ChaCha20 function then performs an XOR of this keystream with the plaintext. Alternatively, each keystream block can be XORed with a plaintext block before proceeding to create the next block, saving some memory. There is no requirement for the plaintext to be an integral multiple of 512 bits. If there is extra keystream from the last block, it is discarded. Specific protocols MAY require that the plaintext and ciphertext have certain length. Such protocols need to specify how the plaintext is padded and how much padding it receives."
https://datatracker.ietf.org/doc/html/rfc7539
I believe some ciphers like mleku (npub1fjq…leku) mentioned, depending on their modes, can become vulnerable due to lack of entropy if the input block size is "too small"