crypto: Add ChaCha20/ChaCha20-Poly1305 to /dev/crypto, fix RFC 8439 nonce.

Expose the ChaCha20 stream cipher and the ChaCha20-Poly1305 AEAD through
the OCF crypto framework (/dev/crypto) so applications such as an SSH
server (chacha20-poly1305) can use them directly, and fix the underlying
ChaCha nonce/counter layout so both match RFC 8439.

RFC 8439 nonce layout fix
-------------------------
chacha_ivsetup() previously used the original DJB layout: a 64-bit block
counter (input[12..13]) followed by a 64-bit nonce (input[14..15]). RFC
8439 defines a 32-bit block counter (input[12]) and a 96-bit / 12-byte
nonce (input[13..15]). With the old layout the existing ChaCha20-Poly1305
AEAD could not reproduce the RFC 8439 test vectors (the last 4 bytes of a
12-byte nonce were consumed as the high half of the counter). This
commit switches chacha_ivsetup() to the RFC 8439 layout and updates the
ChaCha20-Poly1305 one-shot helpers to pass a 12-byte nonce accordingly.

Standalone ChaCha20 on the unified enc path
-------------------------------------------
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.

  * chacha_private.h: chacha_ivsetup uses a 4-byte counter and a 12-byte
    nonce (RFC 8439).
  * chachapoly.c / chachapoly.h: split reinit into chacha20_reinit (raw,
    counter 0) and chachapoly_reinit (AEAD, counter 1); chacha20_crypt
    takes a length and encrypts it in one pass, mirroring aes_ctr_crypt;
    12-byte nonce for the one-shot AEAD helpers.
  * xform.h / xform.c: add size_t len to encrypt/decrypt; add
    enc_xform_chacha20 (blocksize 64, 12-byte IV).
  * cryptodev.c / cryptosoft.c: register CRYPTO_CHACHA20 as a txform
    cipher, route new sessions to enc_xform_chacha20, feed the AEAD AAD
    through crp_aad/crp_aadlen, and handle the short final block in
    swcr_encdec.
  * cryptodev.h: add CRYPTO_CHACHA20; bump EALG_MAX_BLOCK_LEN to 64.

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)
  Ran the crypto test apps. ChaCha20 uses RFC 8439 2.4.2 vectors
  (including a 375-byte multi-block vector exercising cross-block counter
  continuity); ChaCha20-Poly1305 uses the RFC 8439 2.8.2 AEAD vector.
  A full regression of the other ciphers was run to confirm the extended
  encrypt/decrypt signature does not change their behaviour:

    nsh> chacha20
    chacha20: 2/2 vectors passed
    nsh> chachapoly
    OK test vector 0
    chachapoly: 1/1 vectors passed
    nsh> des3cbc          -> all vectors OK
    nsh> aescbc           -> all vectors OK
    nsh> aesctr           -> all vectors OK
    nsh> aesxts           -> 14 vectors OK (encrypt + decrypt)
    nsh> hmac             -> md5 / sha1 / sha256 all success

Signed-off-by: makejian <makejian@xiaomi.com>

include/crypto/chachapoly.h

@@ -23,7 +23,7 @@
 #define CHACHA20_KEYSIZE   32
 #define CHACHA20_CTR       4
 #define CHACHA20_SALT      4
-#define CHACHA20_NONCE     8
+#define CHACHA20_NONCE     4
 #define CHACHA20_BLOCK_LEN 64
 
 struct chacha20_ctx
@@ -34,9 +34,10 @@ struct chacha20_ctx
 
 int chacha20_setkey(FAR void *, FAR uint8_t *, int);
 void chacha20_reinit(caddr_t, FAR uint8_t *);
-void chacha20_crypt(caddr_t, FAR uint8_t *);
+void chacha20_crypt(caddr_t, FAR uint8_t *, size_t);
+void chachapoly_reinit(caddr_t, FAR uint8_t *);
 
-#define POLY1305_KEYLEN 32
+#define POLY1305_KEYLEN 64
 #define POLY1305_TAGLEN 16
 #define POLY1305_BLOCK_LEN 16
 

include/crypto/cryptodev.h

@@ -91,7 +91,7 @@
 #define BLOWFISH_BLOCK_LEN    8
 #define CAST128_BLOCK_LEN     8
 #define RIJNDAEL128_BLOCK_LEN 16
-#define EALG_MAX_BLOCK_LEN    16
+#define EALG_MAX_BLOCK_LEN    64
 
 /* Keep this updated */
 
@@ -140,7 +140,8 @@
 #define CRYPTO_PBKDF2_HMAC_SHA256 39
 #define CRYPTO_ESN              40 /* Support for Extended Sequence Numbers */
 #define CRYPTO_SHA2_224_HMAC    41
-#define CRYPTO_ALGORITHM_MAX    41 /* Keep updated */
+#define CRYPTO_CHACHA20         42
+#define CRYPTO_ALGORITHM_MAX    42 /* Keep updated */
 
 /* Algorithm flags */
 

include/crypto/xform.h

@@ -76,8 +76,8 @@ struct enc_xform
   uint16_t minkey;
   uint16_t maxkey;
   uint16_t ctxsize;
-  CODE void (*encrypt)(caddr_t, FAR uint8_t *);
-  CODE void (*decrypt)(caddr_t, FAR uint8_t *);
+  CODE void (*encrypt)(caddr_t, FAR uint8_t *, size_t);
+  CODE void (*decrypt)(caddr_t, FAR uint8_t *, size_t);
   CODE int  (*setkey)(FAR void *, FAR uint8_t *, int len);
   CODE void (*reinit)(caddr_t, FAR uint8_t *);
 };
@@ -112,6 +112,7 @@ extern const struct enc_xform enc_xform_aes_xts;
 extern const struct enc_xform enc_xform_aes_ofb;
 extern const struct enc_xform enc_xform_aes_cfb_8;
 extern const struct enc_xform enc_xform_aes_cfb_128;
+extern const struct enc_xform enc_xform_chacha20;
 extern const struct enc_xform enc_xform_chacha20_poly1305;
 extern const struct enc_xform enc_xform_null;