Security
The security peripherals are the hardware RNG — a true entropy source for keys and nonces — and the crypto accelerators (AES, HASH, PKA). Today the SDK wraps the RNG with core_rng over ll_rng; the accelerators are present in silicon and used by the BLE stack but don’t have Core wrappers yet. Use the Core / HAL / LL toggle at the top of the sidebar to switch.
Overview
The RNG is an analog-noise-based generator — genuinely random, not a PRNG seeded from a clock. It’s available on the M4 and M33 Cores; Core.ST.L0 (M0+) has no RNG. There’s no HAL layer — the Core wrapper sits straight on the register layer.
Random numbers
Initialize once (it enables the RNG’s 48 MHz clock and blocks until the first value is ready), then read 32-bit values or fill a buffer:
#include "core.h" // not on Core.ST.L0
core_rng_init();
uint32_t r = core_rng_read(); // one 32-bit value
uint32_t buf[4];
uint32_t n = core_rng_fill(buf, 4); // returns how many were generated
if (core_rng_error()) { /* seed or clock error */ }
core_rng_deinit();Crypto engines
The M33 Cores carry hardware crypto blocks beyond the RNG. They’re wired up for the BLE stack’s needs but aren’t yet exposed as core_* wrappers:
- AES — hardware AES-128/256, faster and lower-power than software crypto.
- PKA / ECC — public-key accelerator for elliptic-curve math (BLE pairing ECDH, certificates).
- HASH — SHA-256 / HMAC for integrity and message authentication.
See the matrix below for where each stands per Core; the implementation status tracks them as they gain Core APIs.
Cross-architecture support
The RNG is the verified piece today (where the peripheral exists); AES is present on the wireless Core for the BLE stack, and PKA/HASH are still ahead:
See the implementation status for the full matrix.
API reference
uint32_t core_rng_read(void);void core_rng_init(void);uint32_t core_rng_fill(uint32_t * buf, uint32_t count);int core_rng_error(void);void core_rng_deinit(void);Generated from core_rng.h — tiles@2a1a847.

