2022-07-27 19:51:53 +08:00
|
|
|
/****************************************************************************
|
|
|
|
|
* include/crypto/xform.h
|
2024-12-18 06:39:15 +01:00
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: OAR
|
|
|
|
|
* SPDX-FileCopyrightText: 2000 Angelos D. Keromytis
|
|
|
|
|
* SPDX-FileContributor: Angelos D. Keromytis (angelos@cis.upenn.edu)
|
2022-07-27 19:51:53 +08:00
|
|
|
*
|
2022-07-18 15:00:30 +08:00
|
|
|
* The author of this code is Angelos D. Keromytis (angelos@cis.upenn.edu)
|
|
|
|
|
*
|
|
|
|
|
* This code was written by Angelos D. Keromytis in Athens, Greece, in
|
|
|
|
|
* February 2000. Network Security Technologies Inc. (NSTI) kindly
|
|
|
|
|
* supported the development of this code.
|
|
|
|
|
*
|
|
|
|
|
* Copyright (c) 2000 Angelos D. Keromytis
|
|
|
|
|
*
|
|
|
|
|
* Permission to use, copy, and modify this software with or without fee
|
|
|
|
|
* is hereby granted, provided that this entire notice is included in
|
|
|
|
|
* all source code copies of any software which is or includes a copy or
|
|
|
|
|
* modification of this software.
|
|
|
|
|
*
|
|
|
|
|
* THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR
|
|
|
|
|
* IMPLIED WARRANTY. IN PARTICULAR, NONE OF THE AUTHORS MAKES ANY
|
|
|
|
|
* REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE
|
|
|
|
|
* MERCHANTABILITY OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR
|
|
|
|
|
* PURPOSE.
|
2024-12-18 06:39:15 +01:00
|
|
|
*
|
2022-07-27 19:51:53 +08:00
|
|
|
****************************************************************************/
|
2022-07-18 15:00:30 +08:00
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
#ifndef __INCLUDE_CRYPTO_XFORM_H
|
|
|
|
|
#define __INCLUDE_CRYPTO_XFORM_H
|
|
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
|
* Included Files
|
|
|
|
|
****************************************************************************/
|
2022-07-18 15:00:30 +08:00
|
|
|
|
2022-07-28 17:52:21 +08:00
|
|
|
#include <sys/types.h>
|
2022-07-18 15:00:30 +08:00
|
|
|
#include <crypto/md5.h>
|
|
|
|
|
#include <crypto/sha1.h>
|
|
|
|
|
#include <crypto/rmd160.h>
|
|
|
|
|
#include <crypto/sha2.h>
|
|
|
|
|
#include <crypto/gmac.h>
|
|
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
#define AESCTR_NONCESIZE 4
|
|
|
|
|
#define AESCTR_IVSIZE 8
|
|
|
|
|
#define AESCTR_BLOCKSIZE 16
|
2023-08-14 11:57:02 +08:00
|
|
|
#define AESOFB_IVSIZE 16
|
2022-07-18 15:00:30 +08:00
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
#define AES_XTS_BLOCKSIZE 16
|
|
|
|
|
#define AES_XTS_IVSIZE 8
|
|
|
|
|
#define AES_XTS_ALPHA 0x87 /* GF(2^128) generator polynomial */
|
2022-07-18 15:00:30 +08:00
|
|
|
|
|
|
|
|
/* Declarations */
|
2022-07-27 19:51:53 +08:00
|
|
|
|
|
|
|
|
struct auth_hash
|
|
|
|
|
{
|
|
|
|
|
int type;
|
|
|
|
|
FAR char *name;
|
|
|
|
|
uint16_t keysize;
|
|
|
|
|
uint16_t hashsize;
|
|
|
|
|
uint16_t authsize;
|
|
|
|
|
uint16_t ctxsize;
|
|
|
|
|
uint16_t blocksize;
|
2024-08-24 19:21:12 -04:00
|
|
|
CODE void (*init)(FAR void *);
|
|
|
|
|
CODE void (*setkey)(FAR void *, FAR const uint8_t *, uint16_t);
|
|
|
|
|
CODE void (*reinit)(FAR void *, FAR const uint8_t *, uint16_t);
|
|
|
|
|
CODE int (*update)(FAR void *, FAR const uint8_t *, size_t);
|
|
|
|
|
CODE void (*final)(FAR uint8_t *, FAR void *);
|
2022-07-18 15:00:30 +08:00
|
|
|
};
|
|
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
struct enc_xform
|
|
|
|
|
{
|
|
|
|
|
int type;
|
|
|
|
|
FAR char *name;
|
|
|
|
|
uint16_t blocksize;
|
|
|
|
|
uint16_t ivsize;
|
|
|
|
|
uint16_t minkey;
|
|
|
|
|
uint16_t maxkey;
|
|
|
|
|
uint16_t ctxsize;
|
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
|
|
|
CODE void (*encrypt)(caddr_t, FAR uint8_t *, size_t);
|
|
|
|
|
CODE void (*decrypt)(caddr_t, FAR uint8_t *, size_t);
|
2024-08-24 19:21:12 -04:00
|
|
|
CODE int (*setkey)(FAR void *, FAR uint8_t *, int len);
|
|
|
|
|
CODE void (*reinit)(caddr_t, FAR uint8_t *);
|
2022-07-18 15:00:30 +08:00
|
|
|
};
|
|
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
struct comp_algo
|
|
|
|
|
{
|
|
|
|
|
int type;
|
|
|
|
|
FAR char *name;
|
|
|
|
|
size_t minlen;
|
|
|
|
|
CODE uint32_t (*compress) (FAR uint8_t *, uint32_t, FAR uint8_t **);
|
|
|
|
|
CODE uint32_t (*decompress) (FAR uint8_t *, uint32_t, FAR uint8_t **);
|
2022-07-18 15:00:30 +08:00
|
|
|
};
|
|
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
union authctx
|
|
|
|
|
{
|
|
|
|
|
MD5_CTX md5ctx;
|
|
|
|
|
SHA1_CTX sha1ctx;
|
|
|
|
|
RMD160_CTX rmd160ctx;
|
|
|
|
|
SHA2_CTX sha2_ctx;
|
|
|
|
|
AES_GMAC_CTX aes_gmac_ctx;
|
2022-07-18 15:00:30 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
extern const struct enc_xform enc_xform_3des;
|
|
|
|
|
extern const struct enc_xform enc_xform_blf;
|
|
|
|
|
extern const struct enc_xform enc_xform_cast5;
|
|
|
|
|
extern const struct enc_xform enc_xform_aes;
|
|
|
|
|
extern const struct enc_xform enc_xform_aes_ctr;
|
2026-07-14 23:45:04 -03:00
|
|
|
extern const struct enc_xform enc_xform_aes_ctr_ssh;
|
2022-07-18 15:00:30 +08:00
|
|
|
extern const struct enc_xform enc_xform_aes_gcm;
|
|
|
|
|
extern const struct enc_xform enc_xform_aes_gmac;
|
2024-07-08 21:01:44 +08:00
|
|
|
extern const struct enc_xform enc_xform_aes_cmac;
|
2022-07-18 15:00:30 +08:00
|
|
|
extern const struct enc_xform enc_xform_aes_xts;
|
2023-08-14 11:57:02 +08:00
|
|
|
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;
|
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
|
|
|
extern const struct enc_xform enc_xform_chacha20;
|
2026-07-10 18:48:43 -03:00
|
|
|
extern const struct enc_xform enc_xform_chacha20_djb;
|
2022-07-18 15:00:30 +08:00
|
|
|
extern const struct enc_xform enc_xform_chacha20_poly1305;
|
|
|
|
|
extern const struct enc_xform enc_xform_null;
|
|
|
|
|
|
|
|
|
|
extern const struct auth_hash auth_hash_hmac_md5_96;
|
|
|
|
|
extern const struct auth_hash auth_hash_hmac_sha1_96;
|
|
|
|
|
extern const struct auth_hash auth_hash_hmac_ripemd_160_96;
|
2026-07-03 17:45:04 -04:00
|
|
|
extern const struct auth_hash auth_hash_hmac_sha2_224_114;
|
2022-07-18 15:00:30 +08:00
|
|
|
extern const struct auth_hash auth_hash_hmac_sha2_256_128;
|
|
|
|
|
extern const struct auth_hash auth_hash_hmac_sha2_384_192;
|
|
|
|
|
extern const struct auth_hash auth_hash_hmac_sha2_512_256;
|
|
|
|
|
extern const struct auth_hash auth_hash_gmac_aes_128;
|
|
|
|
|
extern const struct auth_hash auth_hash_gmac_aes_192;
|
|
|
|
|
extern const struct auth_hash auth_hash_gmac_aes_256;
|
|
|
|
|
extern const struct auth_hash auth_hash_chacha20_poly1305;
|
2023-07-14 20:49:47 +08:00
|
|
|
extern const struct auth_hash auth_hash_md5;
|
2023-10-30 15:38:41 +08:00
|
|
|
extern const struct auth_hash auth_hash_poly1305;
|
2023-10-25 16:00:13 +08:00
|
|
|
extern const struct auth_hash auth_hash_ripemd_160;
|
2023-07-14 20:49:47 +08:00
|
|
|
extern const struct auth_hash auth_hash_sha1;
|
2023-08-08 14:02:52 +08:00
|
|
|
extern const struct auth_hash auth_hash_sha2_224;
|
2023-07-14 20:49:47 +08:00
|
|
|
extern const struct auth_hash auth_hash_sha2_256;
|
2023-08-08 14:02:52 +08:00
|
|
|
extern const struct auth_hash auth_hash_sha2_384;
|
2023-07-14 20:49:47 +08:00
|
|
|
extern const struct auth_hash auth_hash_sha2_512;
|
2024-07-02 13:34:52 +08:00
|
|
|
extern const struct auth_hash auth_hash_crc32;
|
2024-07-08 21:01:44 +08:00
|
|
|
extern const struct auth_hash auth_hash_cmac_aes_128;
|
2022-07-18 15:00:30 +08:00
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
#endif /* __INCLUDE_CRYPTO_XFORM_H */
|
