crypto/chachapoly: add chacha20 stream cipher API

[FelipeMdeO]

Summary

Expose a chacha20 keystream API with a 64-bit block counter on top of the existing private chacha implementation, so flat-build applications (e.g. an SSH server) can reuse the kernel cipher for chacha20-poly1305.

This is necessary in the next steps of Dropbear port where we will stop to use internal dropbear crypto em use NuttX Crypto.

Impact

No relevant impact. Only existing implementations are being shared as an API.

Testing

Build and OSTest

[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

[xiaoxiang781216]

@FelipeMdeO but userspace apps(dropbear) should invoke crypto module through /dev/crypto.

[FelipeMdeO]

@FelipeMdeO but userspace apps(dropbear) should invoke crypto module through /dev/crypto.

Hello @xiaoxiang781216 , I agree with you, I tried this approach to avoid change and maybe crash the crypto lib.

But let me try follow your suggestion. Give me some time to try implement and test.

[FelipeMdeO]

Hello @xiaoxiang781216 I was able to "integrate" chacha into /dev/crypto using enviroments different than espressif.

When I enable CRYPTO_SW_AES required by the /dev/crypto software backend
(CRYPTO_CRYPTODEV_SOFTWARE_CRYPTO depends on it, even though chacha20-poly1305
itself does not use AES), I got a conflict with the Espressif HAL, because aes_encrypt and aes_decrypt are defined on both sides.

On the NuttX side they are in crypto/aes.c:958 and 963.
On the Espressif side they are in
esp-hal-3rdparty/components/wpa_supplicant/esp_supplicant/src/crypto/crypto_mbedtls.c:515 and 530, which is always linked when WiFi is enabled:

    riscv-none-elf-ld: staging/libcrypto.a(aes.o): in function `aes_encrypt':
    aes.c:(.text.aes_encrypt+0x0): multiple definition of `aes_encrypt';
    staging/libarch.a(crypto_mbedtls.o):crypto_mbedtls.c:(.text.aes_encrypt+0x0): first defined here

Note that CRYPTO_SW_AES alone links fine, aes.c is compiled but nothing references it. The crash only happens once the software cryptodev backend (xform.c) pulls aes.o into the link. The same config links fine on sim:nsh, so this is a namespace clash between the esp-hal WiFi stack and CRYPTO_SW_AES, not something specific to Dropbear.

How to reproduce on master

Using a plain WiFi defconfig, no Dropbear and no extra patches:

    ./tools/configure.sh esp32c3-devkit:wifi
    make menuconfig

In menuconfig, enable:

    CONFIG_ALLOW_BSD_COMPONENTS
    CONFIG_CRYPTO
    CONFIG_CRYPTO_SW_AES
    CONFIG_CRYPTO_CRYPTODEV
    CONFIG_CRYPTO_CRYPTODEV_SOFTWARE_CRYPTO

Then run make. The build fails at the final link with the multiple definition of 'aes_encrypt' / 'aes_decrypt' errors above. Enabling only CONFIG_CRYPTO_SW_AES (without the cryptodev software backend) still links fine.

@acassis , @tmedicci can you take a look too, please?

[FelipeMdeO]

Hello, please, don't merge this PR yet.
I opened PR in the espressif side, if they accept we can use /dev/crypto, this is the best approach.

@eren-terzioglu , @tmedicci , @fdcavalcanti can you take a look please? : espressif/esp-hal-3rdparty#13

[FelipeMdeO]

Hello @xiaoxiang781216 , I am closing this PR to use other approach.
The new implementation is in Draft mode yet because I need wait for Espressif to fix build issue.

2 news drafts were opened:
apache/nuttx-apps#3626
#19393