2022-07-27 19:51:53 +08:00
|
|
|
/****************************************************************************
|
|
|
|
|
* crypto/chachapoly.c
|
|
|
|
|
*
|
2024-09-09 16:39:39 +02:00
|
|
|
* SPDX-License-Identifier: ISC
|
|
|
|
|
* SPDX-FileCopyrightText: Copyright (c) 2015 Mike Belopuhov
|
2022-07-18 15:00:30 +08:00
|
|
|
*
|
|
|
|
|
* 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.
|
2022-07-27 19:51:53 +08:00
|
|
|
****************************************************************************/
|
|
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
|
* Included Files
|
|
|
|
|
****************************************************************************/
|
2022-07-18 15:00:30 +08:00
|
|
|
|
2022-07-28 17:52:21 +08:00
|
|
|
#include <endian.h>
|
2022-07-18 15:00:30 +08:00
|
|
|
#include <sys/param.h>
|
|
|
|
|
|
|
|
|
|
#include <crypto/poly1305.h>
|
|
|
|
|
#include <crypto/chachapoly.h>
|
|
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
#include "chacha_private.h"
|
|
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
|
* Private Data
|
|
|
|
|
****************************************************************************/
|
|
|
|
|
|
|
|
|
|
static const uint8_t pad0[16];
|
|
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
|
* Public Functions
|
|
|
|
|
****************************************************************************/
|
|
|
|
|
|
|
|
|
|
int chacha20_setkey(FAR void *sched, FAR uint8_t *key, int len)
|
2022-07-18 15:00:30 +08:00
|
|
|
{
|
2022-07-27 19:51:53 +08:00
|
|
|
FAR struct chacha20_ctx *ctx = (FAR struct chacha20_ctx *)sched;
|
|
|
|
|
|
|
|
|
|
if (len != CHACHA20_KEYSIZE + CHACHA20_SALT)
|
|
|
|
|
{
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
2022-07-18 15:00:30 +08:00
|
|
|
|
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
|
|
|
memcpy(ctx->nonce, key + CHACHA20_KEYSIZE,
|
2022-07-27 19:51:53 +08:00
|
|
|
CHACHA20_SALT);
|
|
|
|
|
chacha_keysetup((FAR chacha_ctx *)&ctx->block, key, CHACHA20_KEYSIZE * 8);
|
|
|
|
|
return 0;
|
2022-07-18 15:00:30 +08:00
|
|
|
}
|
|
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
void chacha20_reinit(caddr_t key, FAR uint8_t *iv)
|
2022-07-18 15:00:30 +08:00
|
|
|
{
|
2022-07-27 19:51:53 +08:00
|
|
|
FAR struct chacha20_ctx *ctx = (FAR struct chacha20_ctx *)key;
|
2022-07-18 15:00:30 +08:00
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
chacha_ivsetup((FAR chacha_ctx *)ctx->block, iv, ctx->nonce);
|
2022-07-18 15:00:30 +08:00
|
|
|
}
|
|
|
|
|
|
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 key, FAR uint8_t *data, size_t len)
|
|
|
|
|
{
|
|
|
|
|
FAR struct chacha20_ctx *ctx = (FAR struct chacha20_ctx *)key;
|
|
|
|
|
|
|
|
|
|
/* The underlying chacha state keeps its own block counter (input[12]),
|
|
|
|
|
* so successive calls continue the keystream seamlessly. This mirrors
|
|
|
|
|
* how aes_ctr_crypt relies on swcr_encdec feeding whole blocks (only the
|
|
|
|
|
* final block may be shorter), keeping every stream cipher on one path.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
chacha_encrypt_bytes((FAR chacha_ctx *)ctx, data, data, len);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void chachapoly_reinit(caddr_t key, FAR uint8_t *iv)
|
2022-07-18 15:00:30 +08:00
|
|
|
{
|
2022-07-27 19:51:53 +08:00
|
|
|
FAR struct chacha20_ctx *ctx = (FAR struct chacha20_ctx *)key;
|
2022-07-18 15:00:30 +08:00
|
|
|
|
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
|
|
|
/* initial counter is 1 */
|
|
|
|
|
|
|
|
|
|
ctx->nonce[0] = 1;
|
|
|
|
|
chacha_ivsetup((FAR chacha_ctx *)ctx->block, iv, ctx->nonce);
|
2022-07-18 15:00:30 +08:00
|
|
|
}
|
2026-07-10 18:48:43 -03:00
|
|
|
|
|
|
|
|
int chacha20_djb_setkey(FAR void *sched, FAR uint8_t *key, int len)
|
|
|
|
|
{
|
|
|
|
|
FAR struct chacha20_ctx *ctx = (FAR struct chacha20_ctx *)sched;
|
|
|
|
|
|
|
|
|
|
if (len != CHACHA20_KEYSIZE)
|
|
|
|
|
{
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
chacha_keysetup((FAR chacha_ctx *)ctx->block, key, CHACHA20_KEYSIZE * 8);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void chacha20_djb_reinit(caddr_t key, FAR uint8_t *iv)
|
|
|
|
|
{
|
|
|
|
|
FAR struct chacha20_ctx *ctx = (FAR struct chacha20_ctx *)key;
|
|
|
|
|
|
|
|
|
|
/* Original DJB ChaCha20 layout, as used by chacha20-poly1305@openssh.com
|
|
|
|
|
* (libtomcrypt chacha_ivctr64): the 16-byte IV is loaded verbatim into
|
|
|
|
|
* state words 12..15 as a 64-bit little-endian block counter followed by
|
|
|
|
|
* a 64-bit nonce.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
chacha_ivsetup((FAR chacha_ctx *)ctx->block, iv + 4, iv);
|
|
|
|
|
}
|
2022-07-18 15:00:30 +08:00
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
void chacha20_poly1305_init(FAR void *xctx)
|
2022-07-18 15:00:30 +08:00
|
|
|
{
|
2022-07-27 19:51:53 +08:00
|
|
|
FAR CHACHA20_POLY1305_CTX *ctx = xctx;
|
2022-07-18 15:00:30 +08:00
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
memset(ctx, 0, sizeof(*ctx));
|
2022-07-18 15:00:30 +08:00
|
|
|
}
|
|
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
void chacha20_poly1305_setkey(FAR void *xctx, FAR const uint8_t *key,
|
|
|
|
|
uint16_t klen)
|
2022-07-18 15:00:30 +08:00
|
|
|
{
|
2022-07-27 19:51:53 +08:00
|
|
|
FAR CHACHA20_POLY1305_CTX *ctx = xctx;
|
2022-07-18 15:00:30 +08:00
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
/* salt is provided with the key material */
|
|
|
|
|
|
|
|
|
|
memcpy(ctx->nonce + CHACHA20_CTR, key + CHACHA20_KEYSIZE,
|
|
|
|
|
CHACHA20_SALT);
|
|
|
|
|
chacha_keysetup((FAR chacha_ctx *)&ctx->chacha, key, CHACHA20_KEYSIZE * 8);
|
2022-07-18 15:00:30 +08:00
|
|
|
}
|
|
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
void chacha20_poly1305_reinit(FAR void *xctx, FAR const uint8_t *iv,
|
|
|
|
|
uint16_t ivlen)
|
2022-07-18 15:00:30 +08:00
|
|
|
{
|
2022-07-27 19:51:53 +08:00
|
|
|
FAR CHACHA20_POLY1305_CTX *ctx = xctx;
|
|
|
|
|
|
|
|
|
|
/* initial counter is 0 */
|
2022-07-18 15:00:30 +08:00
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
chacha_ivsetup((FAR chacha_ctx *)&ctx->chacha, iv, ctx->nonce);
|
|
|
|
|
chacha_encrypt_bytes((FAR chacha_ctx *)&ctx->chacha, ctx->key, ctx->key,
|
|
|
|
|
POLY1305_KEYLEN);
|
2023-08-22 14:54:01 +08:00
|
|
|
poly1305_begin((FAR poly1305_state *)&ctx->poly, ctx->key);
|
2022-07-18 15:00:30 +08:00
|
|
|
}
|
|
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
int chacha20_poly1305_update(FAR void *xctx, FAR const uint8_t *data,
|
2023-09-18 20:50:57 +08:00
|
|
|
size_t len)
|
2022-07-18 15:00:30 +08:00
|
|
|
{
|
2022-07-27 19:51:53 +08:00
|
|
|
static const unsigned char zeroes[POLY1305_BLOCK_LEN];
|
|
|
|
|
FAR CHACHA20_POLY1305_CTX *ctx = xctx;
|
|
|
|
|
size_t rem;
|
|
|
|
|
|
|
|
|
|
poly1305_update((FAR poly1305_state *)&ctx->poly, data, len);
|
|
|
|
|
|
|
|
|
|
/* number of bytes in the last 16 byte block */
|
|
|
|
|
|
|
|
|
|
rem = (len + POLY1305_BLOCK_LEN) & (POLY1305_BLOCK_LEN - 1);
|
|
|
|
|
if (rem > 0)
|
|
|
|
|
{
|
|
|
|
|
poly1305_update((FAR poly1305_state *)&ctx->poly, zeroes,
|
|
|
|
|
POLY1305_BLOCK_LEN - rem);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
2022-07-18 15:00:30 +08:00
|
|
|
}
|
|
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
void chacha20_poly1305_final(FAR uint8_t *tag, FAR void *xctx)
|
2022-07-18 15:00:30 +08:00
|
|
|
{
|
2022-07-27 19:51:53 +08:00
|
|
|
FAR CHACHA20_POLY1305_CTX *ctx = xctx;
|
2022-07-18 15:00:30 +08:00
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
poly1305_finish((FAR poly1305_state *)&ctx->poly, tag);
|
|
|
|
|
explicit_bzero(ctx, sizeof(*ctx));
|
2022-07-18 15:00:30 +08:00
|
|
|
}
|
|
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
void chacha20poly1305_encrypt(
|
|
|
|
|
FAR uint8_t *dst,
|
|
|
|
|
FAR const uint8_t *src,
|
|
|
|
|
const size_t src_len,
|
|
|
|
|
FAR const uint8_t *ad,
|
|
|
|
|
const size_t ad_len,
|
|
|
|
|
const uint64_t nonce,
|
|
|
|
|
FAR const uint8_t *key)
|
|
|
|
|
{
|
|
|
|
|
poly1305_state poly1305_ctx;
|
|
|
|
|
chacha_ctx ctx;
|
|
|
|
|
union
|
|
|
|
|
{
|
|
|
|
|
uint8_t b0[CHACHA20POLY1305_KEY_SIZE];
|
|
|
|
|
uint64_t lens[2];
|
|
|
|
|
} b =
|
|
|
|
|
{
|
|
|
|
|
{
|
|
|
|
|
0
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
uint64_t le_nonce = htole64(nonce);
|
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
|
|
|
uint8_t le_nonce_array[12];
|
|
|
|
|
explicit_bzero(le_nonce_array, sizeof(le_nonce_array));
|
|
|
|
|
memcpy(le_nonce_array, &le_nonce, sizeof(uint64_t));
|
2022-07-27 19:51:53 +08:00
|
|
|
|
|
|
|
|
chacha_keysetup(&ctx, key, CHACHA20POLY1305_KEY_SIZE * 8);
|
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
|
|
|
chacha_ivsetup(&ctx, le_nonce_array, NULL);
|
2022-07-27 19:51:53 +08:00
|
|
|
chacha_encrypt_bytes(&ctx, b.b0, b.b0, sizeof(b.b0));
|
2023-08-22 14:54:01 +08:00
|
|
|
poly1305_begin(&poly1305_ctx, b.b0);
|
2022-07-27 19:51:53 +08:00
|
|
|
|
|
|
|
|
poly1305_update(&poly1305_ctx, ad, ad_len);
|
|
|
|
|
poly1305_update(&poly1305_ctx, pad0, (0x10 - ad_len) & 0xf);
|
|
|
|
|
|
|
|
|
|
chacha_encrypt_bytes(&ctx, (FAR uint8_t *)src, dst, src_len);
|
|
|
|
|
|
|
|
|
|
poly1305_update(&poly1305_ctx, dst, src_len);
|
|
|
|
|
poly1305_update(&poly1305_ctx, pad0, (0x10 - src_len) & 0xf);
|
|
|
|
|
|
|
|
|
|
b.lens[0] = htole64(ad_len);
|
|
|
|
|
b.lens[1] = htole64(src_len);
|
|
|
|
|
poly1305_update(&poly1305_ctx, (FAR uint8_t *)b.lens, sizeof(b.lens));
|
|
|
|
|
|
|
|
|
|
poly1305_finish(&poly1305_ctx, dst + src_len);
|
|
|
|
|
|
|
|
|
|
explicit_bzero(&ctx, sizeof(chacha_ctx));
|
|
|
|
|
explicit_bzero(&b, sizeof(b));
|
2022-07-18 15:00:30 +08:00
|
|
|
}
|
|
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
int chacha20poly1305_decrypt(
|
|
|
|
|
FAR uint8_t *dst,
|
|
|
|
|
FAR const uint8_t *src,
|
|
|
|
|
const size_t src_len,
|
|
|
|
|
FAR const uint8_t *ad,
|
|
|
|
|
const size_t ad_len,
|
|
|
|
|
const uint64_t nonce,
|
|
|
|
|
FAR const uint8_t *key)
|
|
|
|
|
{
|
|
|
|
|
poly1305_state poly1305_ctx;
|
|
|
|
|
chacha_ctx ctx;
|
|
|
|
|
int ret;
|
|
|
|
|
size_t dst_len;
|
|
|
|
|
union {
|
|
|
|
|
uint8_t b0[CHACHA20POLY1305_KEY_SIZE];
|
|
|
|
|
uint8_t mac[CHACHA20POLY1305_AUTHTAG_SIZE];
|
|
|
|
|
uint64_t lens[2];
|
|
|
|
|
} b =
|
|
|
|
|
{
|
|
|
|
|
{
|
|
|
|
|
0
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
uint64_t le_nonce = htole64(nonce);
|
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
|
|
|
uint8_t le_nonce_array[12];
|
|
|
|
|
explicit_bzero(le_nonce_array, sizeof(le_nonce_array));
|
|
|
|
|
memcpy(le_nonce_array, &le_nonce, sizeof(uint64_t));
|
2022-07-27 19:51:53 +08:00
|
|
|
|
|
|
|
|
if (src_len < CHACHA20POLY1305_AUTHTAG_SIZE)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
chacha_keysetup(&ctx, key, CHACHA20POLY1305_KEY_SIZE * 8);
|
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
|
|
|
chacha_ivsetup(&ctx, le_nonce_array, NULL);
|
2022-07-27 19:51:53 +08:00
|
|
|
chacha_encrypt_bytes(&ctx, b.b0, b.b0, sizeof(b.b0));
|
2023-08-22 14:54:01 +08:00
|
|
|
poly1305_begin(&poly1305_ctx, b.b0);
|
2022-07-27 19:51:53 +08:00
|
|
|
|
|
|
|
|
poly1305_update(&poly1305_ctx, ad, ad_len);
|
|
|
|
|
poly1305_update(&poly1305_ctx, pad0, (0x10 - ad_len) & 0xf);
|
|
|
|
|
|
|
|
|
|
dst_len = src_len - CHACHA20POLY1305_AUTHTAG_SIZE;
|
|
|
|
|
poly1305_update(&poly1305_ctx, src, dst_len);
|
|
|
|
|
poly1305_update(&poly1305_ctx, pad0, (0x10 - dst_len) & 0xf);
|
|
|
|
|
|
|
|
|
|
b.lens[0] = htole64(ad_len);
|
|
|
|
|
b.lens[1] = htole64(dst_len);
|
|
|
|
|
poly1305_update(&poly1305_ctx, (FAR uint8_t *)b.lens, sizeof(b.lens));
|
|
|
|
|
|
|
|
|
|
poly1305_finish(&poly1305_ctx, b.mac);
|
|
|
|
|
|
|
|
|
|
ret = timingsafe_bcmp(b.mac, src + dst_len, CHACHA20POLY1305_AUTHTAG_SIZE);
|
|
|
|
|
if (!ret)
|
|
|
|
|
{
|
|
|
|
|
chacha_encrypt_bytes(&ctx, (FAR uint8_t *) src, dst, dst_len);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
explicit_bzero(&ctx, sizeof(chacha_ctx));
|
|
|
|
|
explicit_bzero(&b, sizeof(b));
|
|
|
|
|
|
|
|
|
|
return !ret;
|
2022-07-18 15:00:30 +08:00
|
|
|
}
|
|
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
void xchacha20poly1305_encrypt(
|
|
|
|
|
FAR uint8_t *dst,
|
|
|
|
|
FAR const uint8_t *src,
|
|
|
|
|
const size_t src_len,
|
|
|
|
|
FAR const uint8_t *ad,
|
|
|
|
|
const size_t ad_len,
|
|
|
|
|
FAR const uint8_t *nonce,
|
|
|
|
|
FAR const uint8_t *key)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
uint32_t derived_key[CHACHA20POLY1305_KEY_SIZE / sizeof(uint32_t)];
|
|
|
|
|
uint64_t h_nonce;
|
|
|
|
|
|
|
|
|
|
memcpy(&h_nonce, nonce + 16, sizeof(h_nonce));
|
|
|
|
|
h_nonce = le64toh(h_nonce);
|
|
|
|
|
hchacha20(derived_key, nonce, key);
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < (sizeof(derived_key) / sizeof(derived_key[0])); i++)
|
|
|
|
|
{
|
|
|
|
|
derived_key[i] = htole32(derived_key[i]);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
chacha20poly1305_encrypt(dst, src, src_len, ad, ad_len,
|
|
|
|
|
h_nonce, (FAR uint8_t *)derived_key);
|
|
|
|
|
explicit_bzero(derived_key, CHACHA20POLY1305_KEY_SIZE);
|
2022-07-18 15:00:30 +08:00
|
|
|
}
|
|
|
|
|
|
2022-07-27 19:51:53 +08:00
|
|
|
int xchacha20poly1305_decrypt(
|
|
|
|
|
FAR uint8_t *dst,
|
|
|
|
|
FAR const uint8_t *src,
|
|
|
|
|
const size_t src_len,
|
|
|
|
|
FAR const uint8_t *ad,
|
|
|
|
|
const size_t ad_len,
|
|
|
|
|
FAR const uint8_t *nonce,
|
|
|
|
|
FAR const uint8_t *key)
|
|
|
|
|
{
|
|
|
|
|
int ret;
|
|
|
|
|
int i;
|
|
|
|
|
uint32_t derived_key[CHACHA20POLY1305_KEY_SIZE / sizeof(uint32_t)];
|
|
|
|
|
uint64_t h_nonce;
|
|
|
|
|
|
|
|
|
|
memcpy(&h_nonce, nonce + 16, sizeof(h_nonce));
|
|
|
|
|
h_nonce = le64toh(h_nonce);
|
|
|
|
|
hchacha20(derived_key, nonce, key);
|
|
|
|
|
for (i = 0; i < (sizeof(derived_key) / sizeof(derived_key[0])); i++)
|
|
|
|
|
{
|
|
|
|
|
derived_key[i] = htole32(derived_key[i]);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ret = chacha20poly1305_decrypt(dst, src, src_len, ad, ad_len,
|
|
|
|
|
h_nonce, (FAR uint8_t *)derived_key);
|
|
|
|
|
explicit_bzero(derived_key, CHACHA20POLY1305_KEY_SIZE);
|
|
|
|
|
|
|
|
|
|
return ret;
|
2022-07-18 15:00:30 +08:00
|
|
|
}
|