[dgarske]

Examples showing how to offload post-quantum operations to a device through the wolfCrypt crypto callback (cryptocb) interface - the path a secure element uses for ML-KEM key exchange and ML-DSA signatures.

• pq/ml_kem_cryptocb/ - ML-KEM keygen, encapsulate and decapsulate through a registered callback.
• pq/ml_dsa_cryptocb/ - ML-DSA keygen, sign and verify through a callback.
• pq/tls_cryptocb/ - a TLS 1.3 client and server that offload the ML-KEM key_share using the SecP256r1MLKEM768 hybrid group.

Each callback delegates to the wolfCrypt software implementation so the examples run without hardware; a real device replaces each case body with its own calls. Built and run with --enable-cryptocb --enable-mlkem --enable-dilithium; the TLS pair is exercised in CI via the examples manifest. A pure, non-hybrid ML-KEM group needs wolfSSL built with --enable-tls-mlkem-standalone.

[aidangarske]

Skoll Code Review

Scan type: review

Overall recommendation: REQUEST_CHANGES
Findings: 2 total — 2 posted, 0 skipped
2 finding(s) posted as inline comments (see file-level comments below)

Posted findings

• [High] TLS setup failures can exit with success status — pq/tls_cryptocb/client-tls13-mlkem.c:107-207; pq/tls_cryptocb/server-tls13-mlkem.c:108-189
• [Medium] Feature guards do not cover all APIs used — pq/tls_cryptocb/client-tls13-mlkem.c:51; pq/tls_cryptocb/server-tls13-mlkem.c:50; pq/tls_cryptocb/mlkem-cryptocb.c:34

Review generated by Skoll

Fixed