ThePassionate commented on PR #19393: URL: https://github.com/apache/nuttx/pull/19393#issuecomment-4932400957
Thanks for working on this. I'd suggest a different, more unified approach here rather than adding a parallel **encrypt_multi/decrypt_multi** path with new chacha20_stream_* helpers. The framework already supports stream ciphers through the existing encrypt/decrypt callbacks (e.g. AES-CTR/OFB/CFB). Rather than forking the interface into a separate stream path, we can just extend the existing encrypt/decrypt signature to carry a length: `CODE void (*encrypt)(caddr_t, FAR uint8_t *, size_t len);` `CODE void (*decrypt)(caddr_t, FAR uint8_t *, size_t len);` With that single change: swcr_encdec handles a partial final block via buflen = MIN(i, blocksize), so arbitrary-length stream data flows through the existing single path. chacha20_crypt just gains a len argument and keeps leftover keystream bytes across calls (keystream8[64] + keystream_bytes_used) to keep the stream continuous. The enc_xform_chacha20 entry reuses the existing chacha20_crypt/setkey/reinit — no new symbols, no special-case branch. This keeps all ciphers (block and stream) on one uniform path instead of maintaining two. Any future stream cipher then drops in with just an xform table entry. Exposing both encrypt_multi and the block callbacks adds a second parallel code path that we'd have to keep in sync long term, which I think is best avoided. I already have a patch implementing this (extending the encrypt/decrypt signature + chacha20 export on the unified path). I'm happy to share it so we can align on the unified approach. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
