nuttx/include/crypto/chachapoly.h

103 lines
3.2 KiB
C
Raw Normal View History

/****************************************************************************
* include/crypto/chachapoly.h
*
* SPDX-License-Identifier: ISC
* SPDX-FileCopyrightText:2015 Mike Belopuhov
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
****************************************************************************/
#ifndef __INCLUDE_CRYPTO_CHACHAPOLY_H
#define __INCLUDE_CRYPTO_CHACHAPOLY_H
#define CHACHA20_KEYSIZE 32
#define CHACHA20_CTR 4
#define CHACHA20_SALT 4
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>
2026-07-10 14:13:58 +08:00
#define CHACHA20_NONCE 4
#define CHACHA20_BLOCK_LEN 64
struct chacha20_ctx
{
uint8_t block[CHACHA20_BLOCK_LEN];
uint8_t nonce[CHACHA20_NONCE];
};
int chacha20_setkey(FAR void *, FAR uint8_t *, int);
void chacha20_reinit(caddr_t, FAR uint8_t *);
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>
2026-07-10 14:13:58 +08:00
void chacha20_crypt(caddr_t, FAR uint8_t *, size_t);
void chachapoly_reinit(caddr_t, FAR uint8_t *);
int chacha20_djb_setkey(FAR void *, FAR uint8_t *, int);
void chacha20_djb_reinit(caddr_t, FAR uint8_t *);
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>
2026-07-10 14:13:58 +08:00
#define POLY1305_KEYLEN 64
#define POLY1305_TAGLEN 16
#define POLY1305_BLOCK_LEN 16
struct poly1305_ctx
{
/* r, h, pad, leftover */
unsigned long state[5 + 5 + 4];
size_t leftover;
unsigned char buffer[POLY1305_BLOCK_LEN];
unsigned char final;
};
typedef struct
{
uint8_t key[POLY1305_KEYLEN];
/* counter, salt */
uint8_t nonce[CHACHA20_NONCE];
struct chacha20_ctx chacha;
struct poly1305_ctx poly;
}
CHACHA20_POLY1305_CTX;
void chacha20_poly1305_init(FAR void *);
void chacha20_poly1305_setkey(FAR void *, FAR const uint8_t *, uint16_t);
void chacha20_poly1305_reinit(FAR void *, FAR const uint8_t *, uint16_t);
int chacha20_poly1305_update(FAR void *, FAR const uint8_t *, size_t);
void chacha20_poly1305_final(FAR uint8_t *, FAR void *);
/* WireGuard crypto */
#define CHACHA20POLY1305_KEY_SIZE CHACHA20_KEYSIZE
#define CHACHA20POLY1305_AUTHTAG_SIZE POLY1305_TAGLEN
#define XCHACHA20POLY1305_NONCE_SIZE 24
void chacha20poly1305_encrypt(
FAR uint8_t *, FAR const uint8_t *, const size_t,
FAR const uint8_t *, const size_t, const uint64_t,
FAR const uint8_t *);
int chacha20poly1305_decrypt(
FAR uint8_t *, FAR const uint8_t *, const size_t,
FAR const uint8_t *, const size_t, const uint64_t,
FAR const uint8_t *);
void xchacha20poly1305_encrypt(
FAR uint8_t *, FAR const uint8_t *, const size_t,
FAR const uint8_t *, const size_t,
FAR const uint8_t *,
FAR const uint8_t *);
int xchacha20poly1305_decrypt(
FAR uint8_t *, FAR const uint8_t *, const size_t,
FAR const uint8_t *, const size_t,
FAR const uint8_t *,
FAR const uint8_t *);
#endif /* __INCLUDE_CRYPTO_CHACHAPOLY_H */