wolfCOSE delivers 40 algorithms including post-quantum ML-DSA, all 6 COSE message types (Sign1, Encrypt0, Mac0, Sign, Encrypt, Mac), a built-in CBOR engine, zero heap allocation, and a path to FIPS 140-3 compliance via wolfCrypt. All in under 5,500 lines of C99.

Measurement Methodology

All measurements were taken in March 2026 on identical hardware and toolchain.

• Platform: Raspberry Pi 5 (aarch64), Debian, 8 GB RAM
• Compiler: GCC 14.2.0
• Optimization: -Os (optimize for size)
• NCSL tool: cloc v2.04
• Binary tool: size (Berkeley format)
• Every library was built from source master

Compiled Binary Size

COSE + CBOR Combined (.text, -Os, aarch64, GCC 14.2.0)

Every COSE library needs a CBOR engine. Most depend on an external one. wolfCOSE includes its own. This allows for an insanely lightweight CBOR engine out of the box, with just 2.7 KB used for CBOR. A fair comparison should count both.

wolfCOSE (min)       ███                              7.5 KB (ES256 Sign1)
libcose+NanoCBOR     ███████                         18.8 KB (~2 algos)
wolfCOSE (full)      ██████████                      25.6 KB (40 algos)
t_cose+QCBOR         ████████████                    30.6 KB (7 algos)
COSE-C+cn-cbor       ██████████████████████████████  77.3 KB (~30 algos)

Key takeaways:

• wolfCOSE minimal (Sign1-sign-only, ECC) is 7.5 KB. That is smaller than any other implementation.
• wolfCOSE full is smaller than t_cose+QCBOR while supporting 5.7x more algorithms.
• wolfCOSE is 3x smaller than COSE-C while being pure C99 (COSE-C is C++).
• t_cose’s README claims 3.5 to 4.8 KB of .text. That is t_cose itself. QCBOR adds approximately 25.5 KB of .text (qcbor_decode.o alone is 21.7 KB). The real footprint is around 30.6 KB.
• wolfCOSE’s built-in CBOR engine is 2.7 KB. QCBOR is 25.5 KB (9.4x larger). NanoCBOR is 6.9 KB (2.6x larger).
• libcose is small but only implements approximately 2 algorithms with its libsodium backend (EdDSA + ChaCha20-Poly1305).

Why wolfCOSE Is the Smallest

The size advantage is the result of four deliberate design choices, not a single trick.

1. A CBOR engine purpose-built for COSE. General-purpose CBOR libraries like QCBOR handle every CBOR type, indefinite-length encoding, tagged values, floating point, and deeply nested structures. wolfCOSE’s CBOR engine handles exactly what COSE needs and nothing more. The result is 2.7 KB of .text versus 25.5 KB for QCBOR.
2. 238 compile-time guards. Every message type and algorithm family can be conditionally compiled out via WOLFCOSE_NO_* macros. The minimum build strips down to 7.5 KB. You only pay flash for what you use.
3. Zero dynamic allocation. No malloc, no calloc, no free, and no heap bookkeeping pulled in by the standard library. Every API takes caller-provided buffers and returns a length.
4. Single dependency. wolfCOSE depends on wolfCrypt and nothing else. There is no second CBOR library, no separate crypto backend, and no glue layer linking them together.

Compile-Time Stripping: Pay Only for What You Use

Per-Algorithm Efficiency

wolfCOSE delivers 0.64 KB per algorithm. That is 6.8x more efficient than t_cose+QCBOR.

Source Code Size (NCSL via cloc)

COSE + CBOR Combined

libcose+NanoCBOR     ██████                          2,567 (~2 algos)
wolfCOSE             ██████████████                  5,461 (40 algos)
t_cose+QCBOR         ████████████████                6,525 (7 algos)
go-cose+fxcbor       ██████████████████████          8,610 (7 algos)
COSE-C+cn-cbor       ██████████████████████████████ 11,867 (~30 algos)

Algorithm Density (Algos per 1,000 NCSL)

wolfCOSE delivers 7.3 algorithms per 1,000 lines. That is 6.6x denser than t_cose+QCBOR.

COSE Logic Only (No CBOR)

t_cose is smaller in COSE-only lines but it only supports 7 signing algorithms with no encryption or MAC. wolfCOSE packs 40 algorithms across all 6 COSE message types into 3,342 more lines.

Algorithm Support

At a Glance

Signing Algorithms (COSE_Sign1 / COSE_Sign)

wolfCOSE is the only COSE implementation with ML-DSA (FIPS 204) post-quantum signatures and the only one supporting Ed448.

Encryption Algorithms (COSE_Encrypt0 / COSE_Encrypt)

t_cose and go-cose have zero encryption support.

MAC Algorithms (COSE_Mac0 / COSE_Mac)

t_cose, go-cose, and libcose have zero MAC support.

Key Management Algorithms

t_cose, go-cose, and libcose have zero key management support.

COSE Message Types

What Only wolfCOSE Has

Zero Dynamic Allocation

Zero allocation means: no heap fragmentation, no use-after-free, no double-free, no allocation latency, no OOM crashes. This is a hard requirement for safety-critical embedded systems where malloc is prohibited.

FIPS 140-3 and Certifications

wolfCOSE itself is not FIPS validated. wolfCOSE’s sole cryptographic dependency is wolfCrypt, which holds FIPS 140-3 Certificate #4718. Since wolfCrypt is the only dependency, there is a direct, clean path to FIPS compliance when required.

Other libraries that use OpenSSL as a backend (COSE-C, t_cose) can also achieve FIPS compliance through OpenSSL’s FIPS module, but this requires a separate FIPS-specific OpenSSL build and adds significant binary size and complexity. wolfCrypt is purpose-built for embedded and constrained environments.

MISRA C Compliance

wolfCOSE strives for MISRA C compliance and is checked in CI on every pull request via three complementary checkers (PR #16). Although wolfCOSE is not fully MISRA C compliant, it adheres to as many rules as it can while documenting deviations from the 2023 standard.

Coverage Summary

MISRA C:2012 is fully tested via cppcheck’s MISRA addon. MISRA C:2023 achieves approximately 80% coverage via compiler warnings and clang-tidy checks. Full 2023 verification requires commercial tooling (LDRA, Polyspace).

Post-Quantum Cryptography

wolfCOSE is the only COSE implementation, in any language, with native post-quantum digital signatures.

Roadmap: XMSS, LMS/HSS (FIPS 205), ML-KEM (FIPS 203), SLH-DSA (SPHINCS+).

Testing and CI

Test Suite

Code Coverage

CI Pipeline (15 Workflows)

wolfCOSE has 15 GitHub Actions workflows covering the full development lifecycle. 13 trigger on every pull request, plus a nightly orchestrator and a wolfSSL-versions matrix that run on a schedule overnight.

The nightly.yml orchestrator re-runs the full CI suite on master each night. This catches breakage from upstream changes between PRs. The wolfssl-versions.yml matrix runs nightly against every wolfSSL 5.x release to verify ongoing compatibility with the crypto backend.

Embedded Suitability

Architecture

Tooling: wolfcose_tool

wolfCOSE ships with wolfcose_tool, a full CLI for key generation, signing, verification, encryption, decryption, and automated round-trip testing. No other C COSE library ships a CLI tool.

A Fair Comparison

wolfCOSE implements all 6 COSE message types (Sign1, Encrypt0, Mac0, Sign, Encrypt, Mac) with 40 algorithms. This comparison measures every library the same way: COSE source plus required CBOR dependency, NCSL via cloc, .text via size, excluding tests and examples.

Libraries like COSE-C also support all 6 COSE types plus CounterSign. t_cose, go-cose, and libcose are more limited in scope. The comparison reports exactly what each library does and does not support, and all numbers are from actual builds on the same system.

Summary

Learn More

• All wolfCOSE blog posts: https://aidangarske.github.io/wolfCOSE/
• wolfCOSE wiki and documentation: https://github.com/aidangarske/wolfCOSE/wiki
• Contact wolfSSL for commercial licensing or production support: https://www.wolfssl.com/contact/

Measurements taken March 2026. NCSL via cloc v2.04, excluding tests. Binary sizes on ARM aarch64 (RPi 5), GCC 14.2.0, -Os. Verified by building each project from source.

Most C COSE libraries make you choose. You either get a small footprint with one message type (t_cose does Sign1 only, and depends on QCBOR plus OpenSSL or mbedTLS), or every message type with malloc and OpenSSL (COSE-C does all six but ships at ~77 KB). For embedded teams already in the wolfSSL ecosystem, neither fits without doubling the crypto footprint.

wolfCOSE is the missing third option. It implements the full RFC 9052 message set (Sign1, Sign, Encrypt0, Encrypt, Mac0, Mac) in 7.5 KB minimum .text (25.6 KB full build), with zero dynamic allocation and 40 algorithms including native ML-DSA-44/65/87. As far as we can tell, this is also the first COSE implementation in any language with production-tested post-quantum signatures.

A Note on the Project

wolfCOSE was developed by a wolfSSL developer, with support from wolfSSL engineering. It is currently an experimental project built on wolfCrypt, not an officially adopted wolfSSL product. If you are interested in production use or would like wolfSSL to formally support wolfCOSE, contact facts@wolfssl.com.

What that means concretely:

• The API surface is not frozen. Function signatures may change before 1.0, and the multi-signer / multi-recipient APIs are particularly likely to evolve based on early adopter feedback.
• Test coverage is high (99.3% measured on wolfcose.c, 100% on wolfcose_cbor.c, with a CI-enforced minimum of 97%) but we are still expanding edge-case coverage.
• COSE algorithm IDs for ML-DSA (-48, -49, -50) come from an IETF draft. The cryptographic primitive (FIPS 204 ML-DSA) is final; the integer code points could shift.
• Production deployments should pin a specific commit, review every upgrade, or wait for adoption / 1.0.

If any of that is a blocker, get in touch. Formal support and stability commitments are exactly the conversation I want to have.

Why I Built It

I wrote this project mostly as a challenge, to see how well I could build a library from scratch compared to the other COSE libraries out there. I also noticed that of course there was no wolfcrypt use cases and thought that the world needed blessed with a little wolfcrypt magic! A more practical reason is that wolfBoot, wolfSSL’s secure bootloader, may eventually need a COSE library for SUIT manifest verification. The existing path for COSE in the embedded boot chain requires t_cose, which depends on OpenSSL or mbedTLS for its crypto backend. That dependency is a non-starter for a bootloader that already uses wolfCrypt: it doubles the crypto footprint and introduces a second trust boundary.

wolfCOSE eliminates that dependency entirely. wolfBoot can verify COSE_Sign1 firmware manifests using the same wolfCrypt it already links for secure boot, with no additional crypto library on the flash. The same library also covers the multi-signer and encryption use cases that SUIT profiles are evolving toward.

What Is in It Today

• Full RFC 9052 message set: Sign1, Sign, Encrypt0, Encrypt, Mac0, Mac. Multi-signer and multi-recipient supported, not stubbed.
• 40 algorithms: ECDSA (P-256/384/521), EdDSA, RSA-PSS, AES-GCM, AES-CCM, ChaCha20-Poly1305, AES Key Wrap, HMAC-SHA-256/384/512, ECDH-ES, and ML-DSA-44/65/87. (The CLI tool’s test --all exercises a 17-algorithm round-trip subset of those for quick smoke testing; the 40 figure counts every distinct COSE algorithm ID across signing, encryption, MAC, and key distribution.)
• Zero dynamic allocation. Every API takes caller-provided buffers. Stack crypto material zeroized with wc_ForceZero on every exit.
• Compile-time stripping: 238 #ifdef guards. Minimum build is 7.5 KB; full build is 25.6 KB.
• MISRA-C:2023 striving with three CI checkers.
• Path to FIPS 140-3 via wolfCrypt’s Certificate #4718.
• 15 GitHub Actions workflows (13 on every PR, plus a nightly orchestrator and a wolfSSL-versions matrix), ~240 algorithm-combination tests, AddressSanitizer + UndefinedBehaviorSanitizer in CI, Coverity nightly scan.

What I Would Love from Early Adopters

• Build it on your toolchain. We test on Linux/macOS with GCC 10–14 and Clang 14–18. If you build on something else (IAR, ARMCC, TI CCS, Renesas, embedded Clang variants) and it fails, file an issue.
• Run the lifecycle demo on your target. make demo exercises keygen, sign, verify, and key serialization end to end across ECC, EdDSA, AEAD, HMAC, and ML-DSA-44. For ML-DSA-65 and ML-DSA-87 round-trips, use ./tools/wolfcose_tool test -a ML-DSA-65.
• Tell us if you want production support. If wolfCOSE is on a critical path for you, that is the signal that turns this from an experimental project into a supported one.

Read More

• What is COSE? A short introduction. Background on COSE itself for readers who want context before the technical posts.
• The Smallest Complete COSE Library for Embedded. The size benchmark versus t_cose, libcose, and COSE-C, plus the multi-signer and multi-recipient design and the purpose-built CBOR engine.
• The First COSE Implementation with ML-DSA. How FIPS 204 ML-DSA drops into COSE_Sign1 and COSE_Sign, the hybrid classical-PQC migration story, and the wire-size honesty section.

Try It

git clone https://github.com/aidangarske/wolfCOSE
cd wolfCOSE
make && make test
make tool && ./tools/wolfcose_tool test --all

Repo: https://github.com/aidangarske/wolfCOSE Wiki: https://github.com/aidangarske/wolfCOSE/wiki

GPLv3, with commercial licensing available from wolfSSL upon adoption. For interest in production support, contact facts@wolfssl.com.

github.com/aidangarske/wolfCOSE | facts@wolfssl.com

If you are signing CBOR payloads on an embedded device and you have started worrying about “harvest now, decrypt later,” that worry now extends to signatures too. Long-lived firmware artifacts, attestation reports, supply-chain manifests: anything signed today with ECDSA or RSA can be retroactively forged by an adversary with a cryptographically relevant quantum computer.

wolfCOSE now has native ML-DSA-44, ML-DSA-65, and ML-DSA-87 support. As far as we can tell, this is the first COSE implementation, in any language, with production-tested post-quantum digital signatures.

A note on the project: wolfCOSE was developed by Aidan Garske, a wolfSSL developer, with support from wolfSSL engineering. It is not currently an officially adopted wolfSSL product. It is an experimental project built on wolfCrypt and the wolfSSL ecosystem. If you are interested in using wolfCOSE in production or would like wolfSSL to formally support it, reach out to facts@wolfssl.com and we are happy to discuss adoption and commercial support.

The COSE PQC Landscape

What Is Actually in the Box

The cleanest way to describe wolfCOSE’s ML-DSA implementation is to be precise about which spec each layer comes from:

• The cryptographic primitive is ML-DSA from FIPS 204 final (published August 2024). We get it from wolfCrypt, which holds FIPS 140-3 Certificate #4718. We use the context-aware API (wc_dilithium_sign_ctx_msg), which is what FIPS 204 final requires.
• The COSE algorithm registration comes from draft-ietf-cose-dilithium (consolidating into draft-ietf-cose-pqc-algs). That draft assigns COSE algorithm IDs -48, -49, -50 to ML-DSA-44 / 65 / 87 and defines the COSE_Key encoding (kty=OKP, crv=ML-DSA-*).
• The COSE message envelope is RFC 9052. Once you have a signature primitive and an algorithm ID, ML-DSA drops into COSE_Sign1 and COSE_Sign exactly the way ES256 does.

The honest framing: the cryptography is final and FIPS-validated; the COSE algorithm IDs are still in IETF draft, which means the integer values could shift before the RFC is published. We track the latest draft and will update if IANA assigns different code points. The actual signatures you produce today are FIPS 204 ML-DSA. The integers we wrap them in are the only thing that is draft.

Signing with ML-DSA in COSE_Sign1

Once your wolfSSL is built with --enable-dilithium, signing a CBOR payload with a 2,420-byte ML-DSA-44 signature looks identical to signing it with ES256:

#include <wolfcose/wolfcose.h>
#include <wolfssl/wolfcrypt/dilithium.h>

dilithium_key  dlKey;
WOLFCOSE_KEY   coseKey;
WC_RNG         rng;

wc_InitRng(&rng);
wc_dilithium_init(&dlKey);
wc_dilithium_set_level(&dlKey, WC_ML_DSA_44);
wc_dilithium_make_key(&dlKey, &rng);

wc_CoseKey_Init(&coseKey);
wc_CoseKey_SetDilithium(&coseKey, WOLFCOSE_ALG_ML_DSA_44, &dlKey);

uint8_t scratch[8192];
int ret = wc_CoseSign1_Sign(&coseKey, WOLFCOSE_ALG_ML_DSA_44,
                            NULL, 0,                    /* kid, kidLen */
                            payload, payloadLen,
                            NULL, 0, NULL, 0,           /* detached payload, ext-AAD */
                            scratch, sizeof(scratch),
                            out, sizeof(out), &outLen, &rng);

That is the entire integration surface. The verifier side uses wc_CoseSign1_Verify with a public-only dilithium_key, and the COSE_Key serialization works for ML-DSA the same way it works for Ed25519: kty=OKP, with crv set to the ML-DSA level.

Hybrid Signatures with COSE_Sign

The reason wolfCOSE has full COSE_Sign support (not just Sign1) is that the most likely deployment path for ML-DSA over the next several years is alongside a classical signature, not as a replacement. Standards bodies are explicit that hybrid is the recommended migration approach, and COSE_Sign is the COSE structure for it.

Here is a firmware manifest signed by both ES256 (today’s verifier) and ML-DSA-65 (tomorrow’s verifier), in one COSE structure:

/* eccKey and mlDsaKey are WOLFCOSE_KEY*, set up earlier via
   wc_CoseKey_SetEcc() and wc_CoseKey_SetDilithium() respectively. */
WOLFCOSE_SIGNATURE signers[2] = {
    { .algId  = WOLFCOSE_ALG_ES256,
      .key    = &eccKey,
      .kid    = (const uint8_t*)"vendor-classic", .kidLen = 14 },
    { .algId  = WOLFCOSE_ALG_ML_DSA_65,
      .key    = &mlDsaKey,
      .kid    = (const uint8_t*)"vendor-pqc",     .kidLen = 10 },
};

ret = wc_CoseSign_Sign(signers, 2,
                       firmware, firmwareLen,
                       NULL, 0, NULL, 0,
                       scratch, sizeof(scratch),
                       out, sizeof(out), &outLen, &rng);

Per RFC 9052 §4.1, the verifier walks the COSE_Signature array and selects the signer to validate by matching the alg and kid headers it knows about, not by array position. Devices in the field that still only know ES256 select the vendor-classic signer and skip the ML-DSA one. Newer devices select the vendor-pqc signer and skip the ECC one. When everyone has migrated, you drop the classical signer and your code path is one line shorter. No re-signing campaigns, no flag-day cutovers.

The Wire-Size Impact

Post-quantum signatures are not a free lunch. The wire-size impact is real and worth knowing before you architect a system around it.

A COSE_Sign1 with ML-DSA-44 is about 40x larger than the same message with Ed25519. If you are shipping firmware over LoRaWAN, that matters. If you are storing attestation reports in a database, it matters less. Plan accordingly.

What ML-DSA does not cost you, surprisingly, is verification time. ML-DSA verification is faster than ECDSA P-256 verification on a Cortex-M4, because there is no point multiplication. It is all small-integer arithmetic over polynomial rings. The expensive operation is signing, and even that is manageable. The real cost is the bytes on the wire.

Why We Did This in COSE Now

There is a fair question: why bother integrating ML-DSA into COSE now, before the IETF draft is final? Three reasons:

1. CNSA 2.0 timelines. The NSA’s CNSA 2.0 guidance requires PQC algorithms in software/firmware signing by 2025, full PQC-only by 2030. Devices being designed today will outlive the deadline. Shipping the COSE integration now means people who need to start prototyping have something to build against.
2. The crypto is final, the wire format is the easy part. FIPS 204 is not moving. Whatever IANA assigns as final COSE alg IDs, swapping -48/-49/-50 for the final values is a one-line change on our side and a recompile on yours.
3. Constrained-device PQC needs a real home. Most PQC-in-protocol work has happened in TLS 1.3 and CMS. COSE is what you actually use on a microcontroller that does not have room for an X.509 stack: IoT firmware signing, attestation tokens, sensor authentication. If COSE does not get PQC, the embedded story has a hole in it.

Try It

Build wolfSSL with --enable-dilithium (or --enable-cryptonly --enable-dilithium for a PQC-only build), then:

git clone https://github.com/aidangarske/wolfCOSE
cd wolfCOSE
make tool
./tools/wolfcose_tool keygen -a ML-DSA-44 -o pqc.key
./tools/wolfcose_tool sign -k pqc.key -a ML-DSA-44 -i data.bin -o data.cose
./tools/wolfcose_tool verify -k pqc.key -i data.cose
./tools/wolfcose_tool test -a ML-DSA-87

A complete keygen / sign / verify lifecycle for ML-DSA-44 lives in examples/lifecycle_demo.c and runs via make demo. ML-DSA-65 and ML-DSA-87 round-trips go through the CLI: ./tools/wolfcose_tool test -a ML-DSA-65.

What Is Next

ML-DSA is the first PQC algorithm in wolfCOSE. The roadmap from here:

• SLH-DSA (FIPS 205, SPHINCS+): Stateless hash-based signatures. Slower than ML-DSA but with a different security assumption (hash functions vs. lattices). Useful for certificate roots where signing speed does not matter.
• LMS / XMSS (NIST SP 800-208): Stateful hash-based signatures. The right tool for firmware signing where you can manage the state.
• ML-KEM (FIPS 203, Kyber): For COSE_Encrypt recipient algorithms, replacing ECDH-ES.

If you have a deployment where one of these is on a critical path, get in touch. That is how we prioritize.

Resources

• Repo: https://github.com/aidangarske/wolfCOSE
• Wiki: https://github.com/aidangarske/wolfCOSE/wiki
• FIPS 204 (ML-DSA): https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf
• IETF draft (COSE algorithm IDs): https://datatracker.ietf.org/doc/draft-ietf-cose-dilithium/
• wolfCrypt FIPS 140-3 cert #4718: https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4718

GPLv3, with commercial licensing available from wolfSSL. We do support engagements for teams that need help wiring this into a specific platform, particularly if you are racing a CNSA 2.0 deadline.

github.com/aidangarske/wolfCOSE | facts@wolfssl.com

wolfCOSE now has full multi-signer and multi-recipient support, making it the smallest C COSE library to implement the entire RFC 9052 message set: COSE_Sign1, COSE_Sign, COSE_Encrypt0, COSE_Encrypt, COSE_Mac0, COSE_Mac. No malloc, no external CBOR dependency, no caveats.

If you have worked with COSE on a constrained device, you know the landscape. Most embedded C libraries either implement only COSE_Sign1 (t_cose, go-cose, libcose) or implement everything but require a heap allocator and several thousand lines of dependencies (COSE-C). wolfCOSE fills the gap: a complete RFC 9052 implementation without dragging in OpenSSL or cn-cbor.

A note on the project: wolfCOSE was developed by Aidan Garske, a wolfSSL developer, with support from wolfSSL engineering. It is currently an experimental project built on wolfCrypt, not an officially adopted wolfSSL product. If you are interested in production use or would like wolfSSL to formally support wolfCOSE, contact facts@wolfssl.com.

Why Multi-Actor Messages Matter

COSE_Sign1 is great when one entity signs one payload. It is not enough when:

• You are shipping firmware that requires dual-control approval (silicon vendor + OEM both sign).
• You are rolling out a hybrid classical/PQC signature during the post-quantum migration: one ML-DSA signature, one ECDSA signature, both attached to the same artifact.
• You are broadcasting an encrypted config to a fleet of devices, each with its own KEK or ECDH keypair, and you do not want to encrypt the payload N times.
• You are sending a MAC’d message to a multicast group where each subscriber has a different shared secret with the broadcaster.

These are exactly the scenarios COSE_Sign, COSE_Encrypt, and COSE_Mac were designed for, and they are the ones that disappeared from “alpha” or “experimental” status in most other C COSE libraries.

Dual-Signing a Firmware Manifest

/* vendorKey and oemKey are WOLFCOSE_KEY*, prepared earlier via
   wc_CoseKey_SetEcc() and wc_CoseKey_SetDilithium() respectively. */
WOLFCOSE_SIGNATURE signers[2] = {
    { .algId = WOLFCOSE_ALG_ES256,
      .key   = &vendorKey,
      .kid   = (const uint8_t*)"vendor-2026", .kidLen = 11 },
    { .algId = WOLFCOSE_ALG_ML_DSA_65,
      .key   = &oemKey,
      .kid   = (const uint8_t*)"oem-pqc-1",   .kidLen = 9 },
};

ret = wc_CoseSign_Sign(signers, 2,
                       firmware, firmwareLen,
                       NULL, 0, NULL, 0,
                       scratch, sizeof(scratch),
                       out, sizeof(out), &outLen, &rng);

Two signers, two algorithms, one COSE structure. The verifier picks an index and a public key. Multi-recipient encryption follows the same shape: you hand wolfCOSE an array of WOLFCOSE_RECIPIENT describing how each recipient learns the content key (Direct, AES Key Wrap, ECDH-ES, ECDH-ES+KW), and you get one ciphertext addressable by every recipient.

Honest Comparison

wolfCOSE was benchmarked against the four most-used C / C++ / Go COSE libraries on a Raspberry Pi 5 (aarch64, GCC 14.2, -Os), measuring .text size with size, source lines with cloc. Every library was built from master.

wolfCOSE (min)       ███                              7.5 KB (ES256 Sign1)
libcose+NanoCBOR     ███████                         18.8 KB (~2 algos)
wolfCOSE (full)      ██████████                      25.6 KB (40 algos)
t_cose+QCBOR         ████████████                    30.6 KB (7 algos)
COSE-C+cn-cbor       ██████████████████████████████  77.3 KB (~30 algos)

t_cose’s README claims 3.5 to 4.8 KB of .text. That is t_cose itself. QCBOR, which t_cose requires and ships separately, adds ~25.5 KB of .text on its own (qcbor_decode.o is 21.7 KB). The full footprint is ~30.6 KB once you include the CBOR engine you actually need to parse a COSE message. wolfCOSE’s built-in CBOR engine is 2.7 KB.

libcose is genuinely small (~18.8 KB combined with NanoCBOR), but its libsodium backend implements two algorithms: EdDSA and ChaCha20-Poly1305. If you need ES256, RSA-PSS, AES-GCM, or HMAC-SHA256, you are not comparing the same thing.

COSE-C is the only other library with all six message types, but it is C++ with a C façade, depends on cn-cbor (heap-allocated) and OpenSSL, and clocks in at ~77 KB.

Per-Algorithm Efficiency

wolfCOSE delivers ~6.8x more algorithms per KB of code than t_cose+QCBOR.

A Purpose-Built CBOR Engine

wolfCOSE includes its own CBOR encoder/decoder in a single file (wolfcose_cbor.c, 502 NCSL, 2.7 KB .text). This was a deliberate design choice for embedded targets, not an oversight. General-purpose CBOR libraries like QCBOR (4,908 NCSL, 25.5 KB .text) are full-featured implementations that handle every CBOR type, indefinite-length encoding, tagged values, floating point, and deeply nested structures. wolfCOSE’s CBOR engine handles exactly what COSE needs: definite-length maps, byte strings, text strings, integers, arrays, and CBOR tags. Nothing more.

The tradeoff is clear: wolfCOSE’s CBOR engine is not a general-purpose CBOR library. It does not parse arbitrary CBOR documents, and it is not intended for applications that need full CBOR flexibility. What it does is keep the total COSE + CBOR footprint under 8 KB for a minimal build, which is the difference between fitting on a Cortex-M0 with 64 KB of flash and not fitting at all.

For teams that need wolfCOSE on an embedded target, this is the right tradeoff. The CBOR engine is small because the use case is small: encode and decode COSE messages, nothing else.

Compile-Time Stripping Is the Design

The full library is 22.9 KB of .text for the COSE layer; combined with the 2.7 KB CBOR engine, that is the 25.6 KB full-build total quoted in the comparison above. The “I just need ES256 Sign1 and nothing else” build is 4.8 KB of COSE + 2.7 KB of CBOR = 7.5 KB total. You opt out of features you do not need:

-DWOLFCOSE_NO_SIGN     -DWOLFCOSE_NO_ENCRYPT  -DWOLFCOSE_NO_MAC
-DWOLFCOSE_NO_ENCRYPT0 -DWOLFCOSE_NO_MAC0
-DWOLFCOSE_NO_SIGN1_SIGN

This matters because the people who care most about COSE are the people who care most about flash. 238 compile-time guards across the library ensure you only pay for what you use.

Zero Allocation, MISRA-Striving, FIPS Path

No malloc anywhere in wolfCOSE. Every API takes caller-provided buffers, returns a length, and zeroizes its own stack with wc_ForceZero before returning. Safety-critical embedded teams that ban heap allocation can use this on bare metal.

MISRA-C:2023 striving. Single-exit functions, no recursion, no function pointers in the hot path, three CI checkers (cppcheck --addon=misra for 2012, GCC strict + clang-tidy for ~80% of 2023). Deviations are documented rather than hidden.

A real path to FIPS 140-3. wolfCrypt holds Certificate #4718. wolfCOSE’s crypto goes through one dependency that is FIPS-validated. wolfCOSE is not validated itself, but the path is clean.

CI

wolfCOSE has 15 GitHub Actions workflows: 13 trigger on every PR, plus a nightly orchestrator and a wolfSSL-versions matrix that run on a schedule. Together they cover the full development lifecycle:

• Build + Test: multi-platform (Ubuntu / macOS), multi-compiler (GCC 10 to 14, Clang 14 to 18)
• Static analysis: cppcheck + Clang scan-build + GCC -fanalyzer
• Coverity: nightly scan
• Sanitizers: AddressSanitizer + UndefinedBehaviorSanitizer
• Code coverage: threshold enforced (>=97% on wolfcose.c, 100% on wolfcose_cbor.c)
• MISRA-C:2012: cppcheck --addon=misra with all wolfCOSE macros defined
• MISRA-C:2023: GCC strict warnings + clang-tidy (bugprone-*, cert-*, clang-analyzer-*, misc-*)
• Minimal build matrix: 6 configurations testing different WOLFCOSE_NO_* combinations
• Comprehensive algorithm tests: ~240 algorithm-combination round-trips
• Real-world scenarios: firmware signing, attestation, fleet config, group broadcast, multi-party approval
• Examples build: all example programs compile and link cleanly
• wolfSSL integration: builds against wolfSSL to verify crypto backend compatibility
• Codespell: typo checking across the codebase
• Nightly orchestrator: re-runs the full CI suite on master each night (catches breakage from upstream changes between PRs)
• wolfSSL-versions matrix: nightly compatibility check against every wolfSSL 5.x release

The wolfcose_tool CLI ships with the project and round-trip tests every algorithm with wolfcose_tool test --all.

Why We Built This

A key driver for wolfCOSE was enabling SUIT manifest verification in wolfBoot, wolfSSL’s secure bootloader. The existing path for COSE in the embedded boot chain required t_cose, which depends on OpenSSL or mbedTLS for its crypto backend. That dependency is a non-starter for a bootloader that already uses wolfCrypt: it doubles the crypto footprint and introduces a second trust boundary.

wolfCOSE eliminates that dependency entirely. wolfBoot can verify COSE_Sign1 firmware manifests using the same wolfCrypt it already links for secure boot, with no additional crypto library on the flash. The same library also covers the multi-signer and encryption use cases that SUIT profiles are evolving toward.

t_cose is a well-engineered library with strong COSE_Sign1 support, and COSE-C covers the full message set. wolfCOSE is built for teams that are already in the wolfSSL ecosystem and need COSE without adding OpenSSL, cn-cbor, or a heap allocator to their build.

Try It

git clone https://github.com/aidangarske/wolfCOSE
cd wolfCOSE
make && make test
make tool && ./tools/wolfcose_tool test --all

Repo: https://github.com/aidangarske/wolfCOSE Wiki: https://github.com/aidangarske/wolfCOSE/wiki

GPLv3, with commercial licensing available from wolfSSL upon adoption. For interest in production support, contact facts@wolfssl.com.

github.com/aidangarske/wolfCOSE | facts@wolfssl.com

Numbers measured March 2026 on a Raspberry Pi 5 (aarch64, GCC 14.2, -Os); every library was built from master with its default release flags. File an issue if you spot a build flag we got wrong on your favorite library and we will re-run.

If you have ever shipped a JSON Web Token, you know the JOSE family: JWT, JWS, JWE. They are how the web does authenticated and encrypted structured data. JSON is verbose but human-readable, so the wire format trades bytes for ease of debugging. That tradeoff makes sense in a browser. It does not make sense in a sensor that talks over LoRaWAN with a 51-byte payload budget.

COSE stands for CBOR Object Signing and Encryption. It is defined in RFC 9052 and RFC 9053, and it is the JOSE equivalent for binary, constrained-device protocols.

CBOR in One Paragraph

CBOR (RFC 8949) is a binary serialization format that encodes the same data model as JSON (maps, arrays, integers, byte strings, text strings, booleans, null) but in fewer bytes and with no parsing ambiguity. A small integer is one byte. A short string is its UTF-8 bytes prefixed by a one-byte length. There are no quotes, commas, or whitespace to skip. A typical IoT message is 30 to 50 percent smaller in CBOR than the equivalent JSON, and a CBOR parser fits in 2 to 3 KB of code.

CBOR alone gives you compact serialization. It does not give you signatures, authentication, or encryption. That is what COSE adds.

What COSE Is

COSE wraps cryptographic operations around a CBOR payload. The structures are intentionally close to their JOSE cousins. If you have written JWS, COSE_Sign will look familiar. The difference is that every byte is CBOR.

There are six COSE message types, in three pairs:

The *0 variants are the simple case: one signer, or one recipient, or one MAC. The non-0 variants support multiple actors. That covers multiple signers on the same payload (for hybrid classical/PQC migrations or multi-party approvals), multiple recipients on the same encrypted message (for fleet broadcast), or multiple MAC tags (for multicast groups).

A COSE_Sign1 looks like this on the wire (CBOR diagnostic notation):

18([
  h'A10126',                  / protected: { 1: -7 (alg = ES256) } /
  { 4: h'766B65792D31' },     / unprotected: { 4: "vkey-1" (kid) } /
  h'48656C6C6F',              / payload: "Hello" /
  h'30450221...3045'          / signature: ECDSA over Sig_structure /
])

Three things to notice. First: the algorithm identifier is a small integer (-7 for ES256), not a string like JWT’s "ES256". Second: the protected header is itself CBOR-encoded inside a byte string, so the verifier signs over the exact bytes the signer used (no canonicalization disputes). Third: the whole structure is one CBOR array, four elements long. There is nothing to parse beyond CBOR.

Why Not Just Use JOSE / JWT?

If you are writing a web service, you should probably use JOSE. JWT has tooling, library support in every language, and the verbosity does not matter when you are sending it over HTTP. COSE exists for the cases where JOSE does not fit:

• Wire size matters. Over LoRaWAN, BLE, or NB-IoT, every byte costs power and latency. A COSE_Sign1 with a P-256 signature is roughly 90 bytes; the equivalent JWS with the same key is roughly 250.
• You do not have a JSON parser. A JSON parser plus a Base64URL decoder eats a meaningful chunk of a microcontroller with 256 KB of flash. CBOR + COSE fits in under 10 KB.
• You do not have an X.509 stack. JOSE assumes you can validate certificates. On a sensor running a bare-metal RTOS, you often cannot. COSE works with raw public keys (kty=OKP / kty=EC2 / kty=RSA) referenced by kid, no PKI required.
• Symmetric protocols matter. A surprising amount of IoT runs on shared symmetric keys provisioned at manufacture. COSE_Mac0 and COSE_Encrypt0 map cleanly onto that. JOSE has the same primitives but is rarely deployed that way.

Where COSE Shows Up in the Real World

• Firmware signing. SUIT (Software Updates for IoT) is the IETF working group standardizing OTA firmware updates for constrained devices. SUIT manifests are signed CBOR documents. COSE_Sign1 covers single-vendor signing, and COSE_Sign covers multi-party (silicon vendor + OEM) approval.
• Remote attestation. EAT (Entity Attestation Tokens) is the CBOR/COSE equivalent of a JWT used to attest device boot state, key provenance, and TEE measurements.
• CWT. CBOR Web Tokens are JWT but in CBOR. They are used in OAuth profiles for constrained environments.
• Group communication. OSCORE and Group OSCORE use COSE structures to authenticate CoAP messages between IoT devices and gateways.
• Post-quantum migration. As classical signatures are being replaced with ML-DSA and SLH-DSA, COSE is one of the few protocols that already has draft IANA assignments for PQC algorithm IDs.

What You Need to Use COSE

• A CBOR encoder/decoder (RFC 8949). Many exist; sizes vary from ~2 KB (NanoCBOR, wolfCOSE’s built-in engine) to ~25 KB (QCBOR).
• A crypto library that implements the algorithms you want to use. ECDSA P-256 covers most of what is deployed today; AES-GCM and HMAC-SHA-256 are the common symmetric choices; ML-DSA is the PQC option.
• A COSE library that wires the two together. The current C / C++ options are t_cose (Sign1 only, requires QCBOR + OpenSSL or mbedTLS), COSE-C (full message set, requires cn-cbor + OpenSSL), libcose (Sign1 only, libsodium backend), and wolfCOSE (full message set, wolfCrypt backend, no malloc).

Further Reading

• RFC 9052 defines the COSE structures and processing rules.
• RFC 9053 specifies the initial COSE algorithm set.
• RFC 8949 defines CBOR, the binary serialization format used by COSE.
• The IANA COSE registry lists assigned algorithm identifiers and parameter values.
• The SUIT working group develops firmware update standards built on COSE.

If you have a specific use case (firmware signing, attestation, fleet config) and you are wondering whether COSE is the right tool, the short answer is: probably yes, if your devices are constrained. The longer answer depends on what crypto stack you already have and how much flash you have left.