crypto: Add standalone CHACHA20 stream cipher on the unified enc path.

[ThePassionate]

Summary

Add a raw CRYPTO_CHACHA20 stream cipher to the OCF crypto framework (/dev/crypto) so applications such as an SSH server (chacha20-poly1305) can use ChaCha20 directly, not only as part of the ChaCha20-Poly1305 AEAD.

Instead of introducing a separate multi-buffer stream path (parallel encrypt_multi/decrypt_multi callbacks), extend the existing enc_xform encrypt/decrypt callback signature with a length argument:

void (*encrypt)(caddr_t, FAR uint8_t *, size_t len);
void (*decrypt)(caddr_t, FAR uint8_t *, size_t len);

With that single change every cipher, block or stream, flows through the same swcr_encdec path. swcr_encdec already handles a short final block via buflen = MIN(i, blocksize), so arbitrary-length data works without a second code path. This is exactly how the existing stream ciphers (AES-CTR/OFB/CFB) already behave: the cipher keeps its own counter in the context and swcr_encdec feeds it whole blocks (only the last one may be shorter). chacha20_crypt likewise relies on the underlying chacha state block counter (input[12]) to continue the keystream across calls, so no per-call keystream caching is needed.

• xform.h/xform.c: add size_t len to encrypt/decrypt; add enc_xform_chacha20 (blocksize 64, 12-byte IV, RFC 8439 layout).
• chachapoly.c/chacha_private.h: chacha_ivsetup now uses a 4-byte counter and a 12-byte nonce (RFC 8439); chacha20_crypt encrypts the requested length in one pass, mirroring aes_ctr_crypt.
• cryptodev.c/cryptosoft.c: register CRYPTO_CHACHA20 as a txform cipher and route new sessions to enc_xform_chacha20.

This keeps all ciphers on one uniform path instead of maintaining two, and any future stream cipher drops in with just an xform table entry.

Impact

extends an internal kernel callback signature (enc_xform encrypt/decrypt). All in-tree implementations are updated in the same commit and the user-facing /dev/crypto ABI is unchanged, so this is self-contained and not a breaking change for existing configurations.

Testing

Build host: Ubuntu Linux x86_64, GCC (host sim toolchain)
Target: sim:crypto (CONFIG_ARCH=sim)
Enabled regression tests (cover both code paths through swcr_encdec):

3DES-CBC, AES-CBC — block ciphers, non-reinit CBC branch
AES-CTR — stream cipher, reinit branch (same path as the new CHACHA20)
AES-XTS — block cipher with reinit
CHACHA20 — new algorithm, incl. a 375-byte multi-block vector
HMAC — auth path

    NuttShell (NSH) NuttX-13.0.0-RC0
    nsh> des3cbc
    ok, encrypt with /dev/crypto, decrypt with /dev/crypto
    nsh> aescbc
    aescbc test ok
    nsh> aesctr
    OK test vector 0
    OK test vector 1
    OK test vector 2
    OK test vector 3
    OK test vector 4
    OK test vector 5
    OK test vector 6
    OK test vector 7
    OK test vector 8
    nsh> aesxts
    OK encrypt test vector 0
    OK decrypt test vector 0
    OK encrypt test vector 1
    OK decrypt test vector 1
    OK encrypt test vector 2
    OK decrypt test vector 2
    OK encrypt test vector 3
    OK decrypt test vector 3
    OK encrypt test vector 4
    OK decrypt test vector 4
    OK encrypt test vector 5
    OK decrypt test vector 5
    OK encrypt test vector 6
    OK decrypt test vector 6
    OK encrypt test vector 7
    OK decrypt test vector 7
    OK encrypt test vector 8
    OK decrypt test vector 8
    OK encrypt test vector 9
    OK decrypt test vector 9
    OK encrypt test vector 10
    OK decrypt test vector 10
    OK encrypt test vector 11
    OK decrypt test vector 11
    OK encrypt test vector 12
    OK decrypt test vector 12
    OK encrypt test vector 13
    OK decrypt test vector 13
    nsh> chacha20
    run(0) start
    OK test vector 0
    run(1) start
    OK test vector 1
    chacha20: 2/2 vectors passed
    nsh> hmac
    hmac md5 success
    hmac md5 success
    hmac md5 success
    hmac md5 success
    hmac md5 success
    hmac sha1 success
    hmac sha1 success
    hmac sha1 success
    hmac sha1 success
    hmac sha1 success
    hmac sha256 success
    hmac sha256 success
    hmac sha256 success
    hmac sha256 success
    hmac sha256 success
    nsh>

Note: Please adhere to Contributing Guidelines.

[xiaoxiang781216]

please fix the conflict, @ThePassionate

[github-actions]

MemBrowse Memory Report

No memory changes detected for:

• arduino-mega2560
• esp32-devkitc
• hifive1-revb
• mirtoo
• qemu-armv8a
• qemu-intel64
• rx65n-rsk2mb
• s698pm-dkit
• stm32-nucleo-f103rb

[FelipeMdeO]

Hello @ThePassionate , nice done.
I believe your implementation is more mature than mine because you've likely been using and testing it for longer, thanks for sharing.

I will test dropbear app using it and I share the results with you, can you wait 1 ~ 2 days, please?

Also, thanks for sharing @xiaoxiang781216 .

[FelipeMdeO]

Hello @ThePassionate and @xiaoxiang781216, one compatibility issue I'd like to flag, though, since my use case is exactly the one mentioned in your summary (SSH chacha20-poly1305@openssh.com): this PR changes chacha_ivsetup to the RFC 8439/IETF layout (32-bit counter in input[12] + 96-bit nonce in input[13..15]), but the OpenSSH cipher uses the original DJB construction — 64-bit counter (input[12..13]) + 64-bit nonce (input[14..15]).

Would you be open to accommodating the DJB 64/64 variant as well — e.g. accepting a 16-byte IV (8-byte LE counter + 8-byte nonce) like FreeBSD's enc_xform_chacha20 does, or keeping both layouts selectable? With that, your unified path would cover the SSH case too and I can build the Dropbear side directly on top of it.

[FelipeMdeO]

Hello, I added DJB algo in your implementation, please take a look this patch: https://github.com/FelipeMdeO/nuttx/tree/feature/crypto-chacha20-djb.
I can open PR after your merge or you can check and add it to your PR.

[xiaoxiang781216]

Hello, I added DJB algo in your implementation, please take a look this patch: https://github.com/FelipeMdeO/nuttx/tree/feature/crypto-chacha20-djb. I can open PR after your merge or you can check and add it to your PR.

let's merge your change after this pr get merged.