The existing CRYPTO_AES_CTR is the RFC 3686 profile: the last 4 bytes of
the key are a nonce, the IV is 8 bytes and only the low 32 bits of the
counter block are incremented. SSH aes128/192/256-ctr (RFC 4344) instead
uses the key as-is (no embedded nonce) and treats the whole 16-byte IV as
the initial counter block, incremented as a 128-bit big-endian integer,
with the first keystream block being E(IV).
Add CRYPTO_AES_CTR_SSH as a new enc_xform mirroring the CRYPTO_CHACHA20_DJB
addition. It reuses struct aes_ctr_ctx and the AES block; only setkey (full
key, no nonce), reinit (full 16-byte counter) and crypt (encrypt-then-
increment over all 16 bytes) differ from the RFC 3686 variant.
Keystream validated against `openssl enc -aes-128-ctr`, including a counter
that carries across byte boundaries and a non-block-aligned tail.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Description:
In kernel builds, any unprivileged process running on the NuttX device
can open /dev/efuse and attempt to read/write fuse content. Reading the
fuses may provide valuable information to an attacker controlling the user
process. The write operation, in extreme cases where the fuse blocks are
not locked, may brick the device.
This is part of https://github.com/apache/nuttx/issues/19410
Compiles ok.
Signed-off-by: Catalin Visinescu <catalin_visinescu@yahoo.com>
CRYPTO_CHACHA20 implements the RFC 8439/IETF parameterization (32-bit
counter + 96-bit nonce). SSH's chacha20-poly1305@openssh.com uses the
original DJB construction instead: a 64-bit block counter in state
words 12..13 and a 64-bit nonce in words 14..15 (libtomcrypt's
chacha_ivctr64). The two layouts produce different keystreams for the
same key, so an SSH server cannot interoperate with OpenSSH clients
through the IETF variant.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
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>
Since already have support for SHA2-224, extend cryptodev/cryptosoft
to support HMAC version of SHA2-224.
Signed-off-by: Peter Barada <peter.barada@gmail.com>
This adds support for PBKDF2 (SHA1 and SHA256) while leveraging
the existing infrastructure for HMAC.
Signed-off-by: Vlad Pruteanu <pruteanuvlad1611@yahoo.com>
Add support for generating AES keys (128/192/256 bits) using the software key management backend.
The generated keys are random numbers produced by the system PRNG.
Signed-off-by: makejian <makejian@xiaomi.com>
This patch adds support for managing cryptographic keys using MTD storage.
It enables the persistence of keys across reboots using a software-based key management system.
Includes fixes for compilation warnings and validation logic.
Signed-off-by: makejian <makejian@xiaomi.com>
The callback parameters are currently passed in by the upper layer, so the release process in close should not be performed here.
This prevents double-free issues and ensures proper resource management.
Signed-off-by: makejian <makejian@xiaomi.com>
Fix incorrect memory management for asynchronous process callbacks.
Ensure callback memory is self-managed to prevent leaks or use-after-free issues.
Signed-off-by: makejian <makejian@xiaomi.com>
Add support for exporting RSA operations with PKCS#1 v1.5 and PSS padding schemes through the cryptodev interface.
This enables both traditional and modern RSA signature schemes:
- CRK_RSA_PKCS15_SIGN/VERIFY for PKCS#1 v1.5 padding
- CRK_RSA_PSS_SIGN/VERIFY for PSS padding
Signed-off-by: makejian <makejian@xiaomi.com>
Replace dynamic memory allocation with stack-based variables in cryptodev_op().
This eliminates kmm_malloc/kmm_free overhead and simplifies error handling
by removing the need for goto bail cleanup paths.
Signed-off-by: makejian <makejian@xiaomi.com>
Add ivlen field to crypt_op and crp_ivlen to cryptop structure to support
cipher algorithms with different IV lengths.
Signed-off-by: makejian <makejian@xiaomi.com>
Add olen field to crypt_op structure and crp_olen to cryptop structure
to support output length tracking in virtio crypto mode.
Signed-off-by: makejian <makejian@xiaomi.com>
Add key management interfaces and support for generating key pairs in RSA and ECDSA cryptographic processes to the cryptodev module.
Signed-off-by: makejian <makejian@xiaomi.com>
Extend AES-CBC algorithm support to include 192-bit and 256-bit key sizes in addition to the existing 128-bit support. This enables broader compatibility with cryptographic standards and provides applications with additional key length options for enhanced security requirements.
Signed-off-by: makejian <makejian@xiaomi.com>
This patch is a rework of the NuttX file descriptor implementation. The
goal is two-fold:
1. Improve POSIX compliance. The old implementation tied file description
to inode only, not the file struct. POSIX however dictates otherwise.
2. Fix a bug with descriptor duplication (dup2() and dup3()). There is
an existing race condition with this POSIX API that currently results
in a kernel side crash.
The crash occurs when a partially open / closed file descriptor is
duplicated. The reason for the crash is that even if the descriptor is
closed, the file might still be in use by the kernel (due to e.g. ongoing
write to file). The open file data is changed by file_dup3() and this
causes a crash in the device / drivers themselves as they lose access to
the inode and private data.
The fix is done by separating struct file into file and file descriptor
structs. The file struct can live on even if the descriptor is closed,
fixing the crash. This also fixes the POSIX issue, as two descriptors
can now point to the same file.
Signed-off-by: Ville Juven <ville.juven@unikie.com>
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Summary:
1.Modified the i_crefs from int16_t to atomic_int
2.Modified the i_crefs add, delete, read, and initialize interfaces to atomic operations
The purpose of this change is to avoid deadlock in cross-core scenarios, where A Core blocks B Core’s request for a write operation to A Core when A Core requests a read operation to B Core.
Signed-off-by: chenrun1 <chenrun1@xiaomi.com>
(1) RSA_PKCS15_VERIFY Misspell
(2) if iv not provided during decryption, iv should get from data.
It was not discovered before because all symmetric decryption comes with iv.
Signed-off-by: makejian <makejian@xiaomi.com>
in user space
Use the flag (COP_FLAG_UPDATE)structure member to mark
whether it is just input data.
like this:
can do manys times,just input data
....
cryp.ses = session.ses;
cryp.op = COP_ENCRYPT;
cryp.src = (caddr_t) s;
cryp.len = len;
cryp.flags = COP_FLAG_UPDATE;
cryp.dst = 0;
cryp.mac = (caddr_t) out;
cryp.iv = 0;
if (ioctl(cryptodev_fd, CIOCCRYPT, &cryp) == -1)
{
warn("CIOCCRYPT");
goto err;
}
can do manys times like frist...
then,the last time
Don't use any flay structure member to mark
this is last time,need get final result
....
cryp.ses = session.ses;
cryp.op = COP_ENCRYPT;
cryp.src = (caddr_t) s;
cryp.len = len;
cryp.flags = 0;
cryp.dst = 0;
cryp.mac = (caddr_t) out;
cryp.iv = 0;
if (ioctl(cryptodev_fd, CIOCCRYPT, &cryp) == -1)
{
warn("CIOCCRYPT");
goto err;
}
....
that will get last result.
Signed-off-by: anjiahao <anjiahao@xiaomi.com>
since mmap may exist in block_operations, but truncate may not,
moving mmap beforee truncate could make three struct more compatible
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
- Add mmap into file_operations and remove it from ioctl definitions.
- Add mm_map structure definitions to support future unmapping
- Modify all drivers to initialize the operations struct accordingly
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
- Add truncate into file_operations
- Move truncate to be common for mountpt_operations and file_operations
- Modify all drivers to initialize the operations struct accordingly
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
1.fix type warning for compile
2.hamc key can less than specified length
3.add new version algorithms to cryptodev
sha256hmac
sha384hmac
sha512hmac
aes128gmac
Signed-off-by: anjiahao <anjiahao@xiaomi.com>
public header files put into include/crpyto
private header/source files put into crpyto
crypto.c cryptodev.[c|h] cryptosoft.[c|h] come from:
commit id is f245bed2a7593bf0decce50caaed4ce05fefd6cf
the rest come from:
commit id is 61b0e532b2dce0a91cf3ea67d346645a61a88cdd
Signed-off-by: anjiahao <anjiahao@xiaomi.com>
