APEX-256 with ASCON
If a standard exists and it fits, use it. ASCON is a NIST standard for small devices. So we run it next to APEX-256 instead of arguing with it.
A control lane and a bulk lane
Control lane: ASCON-128
Handshake confirmation, message headers and small control messages. Authenticated encryption from a NIST standard (SP 800-232). Short messages, so the cost stays small.
Bulk lane: APEX-256
Long streams: sensor logs, firmware images, video. Ciphertext is the same length as plaintext, operating inside a 40-byte self-contained zero-allocation context with no per-block padding, optional 256-bit X256 nonces, 256-byte forward-secrecy ratcheting, and 4x to 8x fast multi-byte extraction.
The handoff
A KEM handshake produces the session secret. A key-derivation step feeds the ASCON-128 key and nonce for the control lane, and the APEX-256 key and nonce for the bulk lane. The control lane carries the header that tells the receiver what the bulk stream is.
Why bother? The ASCON lane gives auditors and legacy equipment a standard they already recognize. The APEX-256 lane keeps long messages from growing.
Where this stands
A prototype harness runs the handoff end to end on a desktop build. It has not been through an on-silicon evaluation, and nobody outside our lab has reviewed it.
The bulk lane is not authenticated by itself. If you need authentication there, it needs its own tag, and ASCON can supply one. How much per-message overhead you can afford decides that choice. We think the split makes sense. We have not yet benchmarked it against ASCON alone on real boards, so we are not printing numbers.