From 83b260c2dee05005187fa2a25368cce6d2dfc785 Mon Sep 17 00:00:00 2001 From: aidan garske Date: Fri, 29 May 2026 12:36:40 -0700 Subject: [PATCH] Sync CI and README references for wolfSSL repo --- .github/workflows/build-test.yml | 2 +- .github/workflows/codespell.yml | 2 +- .github/workflows/comprehensive-tests.yml | 2 +- .github/workflows/coverage.yml | 2 +- .github/workflows/coverity.yml | 2 +- .github/workflows/empty-brace-scan.yml | 2 +- .github/workflows/examples.yml | 2 +- .github/workflows/minimal-build.yml | 2 +- .github/workflows/misra-2012.yml | 4 +- .github/workflows/misra-2023.yml | 4 +- .github/workflows/multi-compiler.yml | 2 +- .github/workflows/nightly.yml | 4 +- .github/workflows/sanitizer.yml | 2 +- .github/workflows/scenarios.yml | 2 +- .github/workflows/static-analysis.yml | 2 +- .github/workflows/wolfssl-versions.yml | 2 +- README.md | 32 +- docs/_config.yml | 22 - .../_posts/2026-04-30-introducing-wolfcose.md | 68 --- docs/_posts/2026-04-30-what-is-cose.md | 77 ---- .../2026-04-30-wolfcose-full-rfc9052.md | 152 ------- docs/_posts/2026-04-30-wolfcose-pqc-cose.md | 155 ------- .../2026-05-01-wolfcose-vs-the-field.md | 398 ------------------ docs/index.md | 10 - 24 files changed, 31 insertions(+), 921 deletions(-) delete mode 100644 docs/_config.yml delete mode 100644 docs/_posts/2026-04-30-introducing-wolfcose.md delete mode 100644 docs/_posts/2026-04-30-what-is-cose.md delete mode 100644 docs/_posts/2026-04-30-wolfcose-full-rfc9052.md delete mode 100644 docs/_posts/2026-04-30-wolfcose-pqc-cose.md delete mode 100644 docs/_posts/2026-05-01-wolfcose-vs-the-field.md delete mode 100644 docs/index.md diff --git a/.github/workflows/build-test.yml b/.github/workflows/build-test.yml index 9c0b79d..172b2ca 100644 --- a/.github/workflows/build-test.yml +++ b/.github/workflows/build-test.yml @@ -2,7 +2,7 @@ name: Build and Test on: push: - branches: [ 'master', 'main', 'release/**' ] + branches: [ 'main', 'release/**' ] pull_request: branches: [ '*' ] workflow_dispatch: diff --git a/.github/workflows/codespell.yml b/.github/workflows/codespell.yml index 9abccda..1855d6c 100644 --- a/.github/workflows/codespell.yml +++ b/.github/workflows/codespell.yml @@ -2,7 +2,7 @@ name: Codespell on: push: - branches: [ 'master', 'main', 'release/**' ] + branches: [ 'main', 'release/**' ] pull_request: branches: [ '*' ] workflow_dispatch: diff --git a/.github/workflows/comprehensive-tests.yml b/.github/workflows/comprehensive-tests.yml index 38cd993..f79b970 100644 --- a/.github/workflows/comprehensive-tests.yml +++ b/.github/workflows/comprehensive-tests.yml @@ -2,7 +2,7 @@ name: Comprehensive Tests on: push: - branches: [ 'master', 'main', 'release/**' ] + branches: [ 'main', 'release/**' ] pull_request: branches: [ '*' ] workflow_dispatch: diff --git a/.github/workflows/coverage.yml b/.github/workflows/coverage.yml index 0174004..c86d5cd 100644 --- a/.github/workflows/coverage.yml +++ b/.github/workflows/coverage.yml @@ -2,7 +2,7 @@ name: Code Coverage on: push: - branches: [ 'master', 'main', 'release/**' ] + branches: [ 'main', 'release/**' ] pull_request: branches: [ '*' ] workflow_dispatch: diff --git a/.github/workflows/coverity.yml b/.github/workflows/coverity.yml index 129fe38..013ae84 100644 --- a/.github/workflows/coverity.yml +++ b/.github/workflows/coverity.yml @@ -15,7 +15,7 @@ jobs: runs-on: ubuntu-latest # Only run from the original repo, not forks - if: github.repository == 'aidangarske/wolfCOSE' + if: github.repository == 'wolfSSL/wolfCOSE' steps: - uses: actions/checkout@v4 diff --git a/.github/workflows/empty-brace-scan.yml b/.github/workflows/empty-brace-scan.yml index e694ee0..9ce5d2b 100644 --- a/.github/workflows/empty-brace-scan.yml +++ b/.github/workflows/empty-brace-scan.yml @@ -2,7 +2,7 @@ name: Empty Brace Scope Scan on: push: - branches: [ 'master', 'main', 'release/**' ] + branches: [ 'main', 'release/**' ] pull_request: branches: [ '*' ] workflow_dispatch: diff --git a/.github/workflows/examples.yml b/.github/workflows/examples.yml index 5db507c..962355e 100644 --- a/.github/workflows/examples.yml +++ b/.github/workflows/examples.yml @@ -2,7 +2,7 @@ name: Examples on: push: - branches: [ 'master', 'main', 'release/**' ] + branches: [ 'main', 'release/**' ] pull_request: branches: [ '*' ] workflow_dispatch: diff --git a/.github/workflows/minimal-build.yml b/.github/workflows/minimal-build.yml index 6ebf99f..6838774 100644 --- a/.github/workflows/minimal-build.yml +++ b/.github/workflows/minimal-build.yml @@ -2,7 +2,7 @@ name: Minimal Build on: push: - branches: [ 'master', 'main', 'release/**' ] + branches: [ 'main', 'release/**' ] pull_request: branches: [ '*' ] workflow_dispatch: diff --git a/.github/workflows/misra-2012.yml b/.github/workflows/misra-2012.yml index fcdba9d..8677f80 100644 --- a/.github/workflows/misra-2012.yml +++ b/.github/workflows/misra-2012.yml @@ -5,7 +5,7 @@ name: MISRA C 2012 on: push: - branches: [ 'master', 'main', 'release/**' ] + branches: [ 'main', 'release/**' ] pull_request: branches: [ '*' ] workflow_dispatch: @@ -73,7 +73,7 @@ jobs: # Recipients, Key Wrap, ECDH, CBOR, Key encode/decode, Float # # MISRA C:2012 Deviations (documented at - # https://github.com/aidangarske/wolfCOSE/wiki/MISRA-Compliance): + # https://github.com/wolfSSL/wolfCOSE/wiki/MISRA-Compliance): # # Rule 2.5 — Feature-gate macros (WOLFCOSE_SIGN1 etc.) are defined # conditionally; cppcheck false-positive when both parent diff --git a/.github/workflows/misra-2023.yml b/.github/workflows/misra-2023.yml index b51b5e7..aaa6847 100644 --- a/.github/workflows/misra-2023.yml +++ b/.github/workflows/misra-2023.yml @@ -6,7 +6,7 @@ name: MISRA C 2023 Compliance on: push: - branches: [ 'master', 'main', 'release/**' ] + branches: [ 'main', 'release/**' ] pull_request: branches: [ '*' ] workflow_dispatch: @@ -193,7 +193,7 @@ jobs: run: | export WOLFSSL_DIR=$HOME/wolfssl-install # Deviations (documented at - # https://github.com/aidangarske/wolfCOSE/wiki/MISRA-Compliance): + # https://github.com/wolfSSL/wolfCOSE/wiki/MISRA-Compliance): # # -bugprone-branch-clone: Different COSE algorithms intentionally # map to the same wolfCrypt value (e.g. ES512 and EdDSA both diff --git a/.github/workflows/multi-compiler.yml b/.github/workflows/multi-compiler.yml index ebb1eab..89314ba 100644 --- a/.github/workflows/multi-compiler.yml +++ b/.github/workflows/multi-compiler.yml @@ -2,7 +2,7 @@ name: Multiple Compilers on: push: - branches: [ 'master', 'main', 'release/**' ] + branches: [ 'main', 'release/**' ] pull_request: branches: [ '*' ] workflow_dispatch: diff --git a/.github/workflows/nightly.yml b/.github/workflows/nightly.yml index 5afca56..a411b75 100644 --- a/.github/workflows/nightly.yml +++ b/.github/workflows/nightly.yml @@ -13,7 +13,7 @@ jobs: trigger: name: Trigger All CI Workflows runs-on: ubuntu-latest - if: github.repository == 'aidangarske/wolfCOSE' + if: github.repository == 'wolfSSL/wolfCOSE' steps: - name: Dispatch all workflows @@ -44,7 +44,7 @@ jobs: owner: context.repo.owner, repo: context.repo.repo, workflow_id: workflow, - ref: 'master', + ref: 'main', }); results.push(` OK ${workflow}`); core.info(`Triggered ${workflow}`); diff --git a/.github/workflows/sanitizer.yml b/.github/workflows/sanitizer.yml index a3290a6..5b87334 100644 --- a/.github/workflows/sanitizer.yml +++ b/.github/workflows/sanitizer.yml @@ -2,7 +2,7 @@ name: Sanitizer on: push: - branches: [ 'master', 'main', 'release/**' ] + branches: [ 'main', 'release/**' ] pull_request: branches: [ '*' ] workflow_dispatch: diff --git a/.github/workflows/scenarios.yml b/.github/workflows/scenarios.yml index d86ddb5..9e5c659 100644 --- a/.github/workflows/scenarios.yml +++ b/.github/workflows/scenarios.yml @@ -2,7 +2,7 @@ name: Scenario Examples on: push: - branches: [ 'master', 'main', 'release/**' ] + branches: [ 'main', 'release/**' ] pull_request: branches: [ '*' ] workflow_dispatch: diff --git a/.github/workflows/static-analysis.yml b/.github/workflows/static-analysis.yml index 1bdcf08..9750cbc 100644 --- a/.github/workflows/static-analysis.yml +++ b/.github/workflows/static-analysis.yml @@ -2,7 +2,7 @@ name: Static Analysis on: push: - branches: [ 'master', 'main', 'release/**' ] + branches: [ 'main', 'release/**' ] pull_request: branches: [ '*' ] workflow_dispatch: diff --git a/.github/workflows/wolfssl-versions.yml b/.github/workflows/wolfssl-versions.yml index 33b9b43..7c8f81f 100644 --- a/.github/workflows/wolfssl-versions.yml +++ b/.github/workflows/wolfssl-versions.yml @@ -2,7 +2,7 @@ name: wolfSSL Version Matrix on: push: - branches: [ 'master', 'main', 'release/**' ] + branches: [ 'main', 'release/**' ] pull_request: branches: [ '*' ] workflow_dispatch: diff --git a/README.md b/README.md index 569eb22..8242f60 100644 --- a/README.md +++ b/README.md @@ -146,9 +146,9 @@ make coverage-force-failure # Include crypto failure path testing Coverity Scan Build Status - + CI Status + src="https://img.shields.io/github/actions/workflow/status/wolfSSL/wolfCOSE/build-test.yml?label=CI&logo=github"/> Skoll Review @@ -159,22 +159,16 @@ make coverage-force-failure # Include crypto failure path testing ## Documentation -Full documentation is available in the [Wiki](https://github.com/aidangarske/wolfCOSE/wiki): +Full documentation is available in the [Wiki](https://github.com/wolfSSL/wolfCOSE/wiki): -- [Getting Started](https://github.com/aidangarske/wolfCOSE/wiki/Getting-Started): Build instructions and first steps -- [Message Types](https://github.com/aidangarske/wolfCOSE/wiki/Message-Types): All six RFC 9052 messages (Sign1, Sign, Encrypt0, Encrypt, Mac0, Mac) with code samples -- [Algorithms](https://github.com/aidangarske/wolfCOSE/wiki/Algorithms): Complete list of 40 supported algorithms with COSE IDs -- [API Reference](https://github.com/aidangarske/wolfCOSE/wiki/API-Reference): Function signatures, data structures, error codes -- [Macros](https://github.com/aidangarske/wolfCOSE/wiki/Macros): Compile-time configuration options -- [Testing](https://github.com/aidangarske/wolfCOSE/wiki/Testing): Test infrastructure, coverage, and failure injection -- [MISRA Compliance](https://github.com/aidangarske/wolfCOSE/wiki/MISRA-Compliance): MISRA C:2012 and C:2023 compliance status and deviation rationale -- [Project Structure](https://github.com/aidangarske/wolfCOSE/wiki/Project-Structure): Source file layout - -## Blogs - -Blogs and update can be found here: - -[wolfCOSE Blogs](https://aidangarske.github.io/wolfCOSE/) +- [Getting Started](https://github.com/wolfSSL/wolfCOSE/wiki/Getting-Started): Build instructions and first steps +- [Message Types](https://github.com/wolfSSL/wolfCOSE/wiki/Message-Types): All six RFC 9052 messages (Sign1, Sign, Encrypt0, Encrypt, Mac0, Mac) with code samples +- [Algorithms](https://github.com/wolfSSL/wolfCOSE/wiki/Algorithms): Complete list of 40 supported algorithms with COSE IDs +- [API Reference](https://github.com/wolfSSL/wolfCOSE/wiki/API-Reference): Function signatures, data structures, error codes +- [Macros](https://github.com/wolfSSL/wolfCOSE/wiki/Macros): Compile-time configuration options +- [Testing](https://github.com/wolfSSL/wolfCOSE/wiki/Testing): Test infrastructure, coverage, and failure injection +- [MISRA Compliance](https://github.com/wolfSSL/wolfCOSE/wiki/MISRA-Compliance): MISRA C:2012 and C:2023 compliance status and deviation rationale +- [Project Structure](https://github.com/wolfSSL/wolfCOSE/wiki/Project-Structure): Source file layout ## License @@ -184,6 +178,4 @@ Copyright (C) 2026 wolfSSL Inc. ## Support -> **Note:** While wolfCOSE is currently maintained by wolfSSL developers, it is not yet classified as an officially supported product. It was designed from the ground up to meet the same quality standards as the rest of the wolfSSL suite with future adoption in mind. We are eager to transition this to a fully supported product as demand grows; if your organization requires official support or has specific feature requirements or you just have general questions or guidance with product, please reach out. - -For commercial licensing, professional support contracts, or to discuss moving wolfCOSE into your production environment, contact [wolfSSL](https://www.wolfssl.com/contact/). +wolfCOSE is a wolfSSL product, built and maintained to the same quality standards as the rest of the wolfSSL suite. For commercial licensing, professional support contracts, feature requests, or general questions, contact [wolfSSL](https://www.wolfssl.com/contact/) or email facts@wolfssl.com. diff --git a/docs/_config.yml b/docs/_config.yml deleted file mode 100644 index a4ee0cd..0000000 --- a/docs/_config.yml +++ /dev/null @@ -1,22 +0,0 @@ -title: wolfCOSE -description: Zero-allocation C COSE/CBOR for embedded, FIPS, and PQC -baseurl: "/wolfCOSE" -url: "https://aidangarske.github.io" -theme: minima - -permalink: /blog/:title/ - -plugins: - - jekyll-feed - - jekyll-seo-tag - -social: - name: wolfCOSE - links: - - https://github.com/aidangarske/wolfCOSE - -exclude: - - Gemfile - - Gemfile.lock - - vendor - - .bundle diff --git a/docs/_posts/2026-04-30-introducing-wolfcose.md b/docs/_posts/2026-04-30-introducing-wolfcose.md deleted file mode 100644 index 1ec40e1..0000000 --- a/docs/_posts/2026-04-30-introducing-wolfcose.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -layout: post -title: "wolfCOSE: zero alloc C COSE for embedded" -date: 2026-04-30 12:00:00 ---- - -*An experimental project from a wolfSSL developer* - -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 . - -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](https://csrc.nist.gov/projects/cryptographic-module-validation-program/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]({{ "/blog/what-is-cose/" | relative_url }}). Background on COSE itself for readers who want context before the technical posts. -- [The Smallest Complete COSE Library for Embedded]({{ "/blog/wolfcose-full-rfc9052/" | relative_url }}). 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]({{ "/blog/wolfcose-pqc-cose/" | relative_url }}). 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 - -```bash -git clone https://github.com/aidangarske/wolfCOSE -cd wolfCOSE -make && make test -make tool && ./tools/wolfcose_tool test --all -``` - -Repo: -Wiki: - -GPLv3, with commercial licensing available from wolfSSL upon adoption. For interest in production support, contact . - -`github.com/aidangarske/wolfCOSE | facts@wolfssl.com` diff --git a/docs/_posts/2026-04-30-what-is-cose.md b/docs/_posts/2026-04-30-what-is-cose.md deleted file mode 100644 index 3f0e217..0000000 --- a/docs/_posts/2026-04-30-what-is-cose.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -layout: post -title: "What is COSE? A short introduction" -date: 2026-04-30 09:00:00 ---- - -*CBOR Object Signing and Encryption: JOSE for the embedded world* - -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](https://www.rfc-editor.org/rfc/rfc9052) and [RFC 9053](https://www.rfc-editor.org/rfc/rfc9053), and it is the JOSE equivalent for binary, constrained-device protocols. - -## CBOR in One Paragraph - -CBOR ([RFC 8949](https://www.rfc-editor.org/rfc/rfc8949)) 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: - -| Operation | One-actor variant | Many-actor variant | -|---|---|---| -| Digital signature | `COSE_Sign1` | `COSE_Sign` | -| Authenticated encryption | `COSE_Encrypt0` | `COSE_Encrypt` | -| Message authentication code | `COSE_Mac0` | `COSE_Mac` | - -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](https://datatracker.ietf.org/wg/suit/about/) (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](https://datatracker.ietf.org/wg/rats/about/) (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](https://www.rfc-editor.org/rfc/rfc8392) 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](https://github.com/aidangarske/wolfCOSE) (full message set, wolfCrypt backend, no malloc). - -## Further Reading - -- [RFC 9052](https://www.rfc-editor.org/rfc/rfc9052) defines the COSE structures and processing rules. -- [RFC 9053](https://www.rfc-editor.org/rfc/rfc9053) specifies the initial COSE algorithm set. -- [RFC 8949](https://www.rfc-editor.org/rfc/rfc8949) defines CBOR, the binary serialization format used by COSE. -- The [IANA COSE registry](https://www.iana.org/assignments/cose/cose.xhtml) lists assigned algorithm identifiers and parameter values. -- The [SUIT working group](https://datatracker.ietf.org/wg/suit/about/) 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. diff --git a/docs/_posts/2026-04-30-wolfcose-full-rfc9052.md b/docs/_posts/2026-04-30-wolfcose-full-rfc9052.md deleted file mode 100644 index 511694d..0000000 --- a/docs/_posts/2026-04-30-wolfcose-full-rfc9052.md +++ /dev/null @@ -1,152 +0,0 @@ ---- -layout: post -title: "The Smallest Complete COSE Library for Embedded" -date: 2026-04-30 10:00:00 ---- - -*Single-Actor and Multi-Actor Sign, Encrypt, and MAC in One Library* - -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 . - -## 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 - -```c -/* 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 - -| Library | Total .text | Algorithms | KB / Algorithm | -|---|---|---|---| -| **wolfCOSE (full)** | 25.6 KB | 40 | **0.64 KB** | -| COSE-C+cn-cbor | 77.3 KB | ~30 | 2.58 KB | -| t_cose+QCBOR | 30.6 KB | 7 | 4.37 KB | -| libcose+NanoCBOR | 18.8 KB | ~2 | 9.40 KB | - -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](https://csrc.nist.gov/projects/cryptographic-module-validation-program/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 - -```bash -git clone https://github.com/aidangarske/wolfCOSE -cd wolfCOSE -make && make test -make tool && ./tools/wolfcose_tool test --all -``` - -Repo: -Wiki: - -GPLv3, with commercial licensing available from wolfSSL upon adoption. For interest in production support, contact . - -`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. diff --git a/docs/_posts/2026-04-30-wolfcose-pqc-cose.md b/docs/_posts/2026-04-30-wolfcose-pqc-cose.md deleted file mode 100644 index 6ba6b8b..0000000 --- a/docs/_posts/2026-04-30-wolfcose-pqc-cose.md +++ /dev/null @@ -1,155 +0,0 @@ ---- -layout: post -title: "The First COSE Implementation with ML-DSA" -date: 2026-04-30 11:00:00 ---- - -*Production-Tested Post-Quantum Signatures in wolfCOSE* - -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 and we are happy to discuss adoption and commercial support. - -## The COSE PQC Landscape - -| Library | PQC Support | -|---|---| -| **wolfCOSE** | **ML-DSA-44 / 65 / 87** | -| t_cose | None | -| COSE-C | None | -| pycose | None | -| go-cose | None | -| libcose | None | -| COSE-JAVA | None | - -## 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](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf) (published August 2024). We get it from wolfCrypt, which holds [FIPS 140-3 Certificate #4718](https://csrc.nist.gov/projects/cryptographic-module-validation-program/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`](https://datatracker.ietf.org/doc/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: - -```c -#include -#include - -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: - -```c -/* 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. - -| Algorithm | Public Key | Signature | NIST Level | -|---|---|---|---| -| ES256 (P-256) | 64 B | 64 B | (classical 128) | -| Ed25519 | 32 B | 64 B | (classical 128) | -| ML-DSA-44 | 1,312 B | 2,420 B | 2 | -| ML-DSA-65 | 1,952 B | 3,293 B | 3 | -| ML-DSA-87 | 2,592 B | 4,595 B | 5 | - -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](https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSI_CNSA_2.0_ALGORITHMS_.PDF) 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: - -```bash -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: -- Wiki: -- FIPS 204 (ML-DSA): -- IETF draft (COSE algorithm IDs): -- wolfCrypt FIPS 140-3 cert #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` diff --git a/docs/_posts/2026-05-01-wolfcose-vs-the-field.md b/docs/_posts/2026-05-01-wolfcose-vs-the-field.md deleted file mode 100644 index bd31222..0000000 --- a/docs/_posts/2026-05-01-wolfcose-vs-the-field.md +++ /dev/null @@ -1,398 +0,0 @@ ---- -layout: post -title: "wolfCOSE vs The Field: The Smallest, Most Complete COSE Implementation" -date: 2026-05-01 10:00:00 ---- - -*The Smallest, Most Complete COSE Implementation* - -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. - -| Library | COSE .text | CBOR .text | Total .text | .data | .bss | Algos | -|---|---|---|---|---|---|---| -| **wolfCOSE (min)** | 4.8 KB | 2.7 KB | **7.5 KB** | 0 | 0 | ES256 | -| **wolfCOSE (full)** | 22.9 KB | 2.7 KB | **25.6 KB** | 0 | 0 | 40 | -| libcose+NanoCBOR | 11.9 KB | 6.9 KB | 18.8 KB | 0 | 16 | ~2 | -| t_cose+QCBOR | 5.1 KB | 25.5 KB | 30.6 KB | 0 | 16 | 7 | -| COSE-C+cn-cbor | 68.5 KB | 8.7 KB | 77.3 KB | 96 | 88 | ~30 | - -``` -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 - -| Config | COSE .text | CBOR .text | Total | Included | -|---|---|---|---|---| -| Full (all 40 algos, all 6 types) | 22.9 KB | 2.7 KB | 25.6 KB | Everything | -| Minimal (`Sign1`-sign, ECC-only) | 4.8 KB | 2.7 KB | 7.5 KB | ES256 Sign1 + CBOR + Key | - -## Per-Algorithm Efficiency - -| Library | Total .text | Algorithms | KB per Algorithm | -|---|---|---|---| -| **wolfCOSE (full)** | 25.6 KB | 40 | **0.64 KB** | -| libcose+NanoCBOR | 18.8 KB | ~2 | 9.40 KB | -| COSE-C+cn-cbor | 77.3 KB | ~30 | 2.58 KB | -| t_cose+QCBOR | 30.6 KB | 7 | 4.37 KB | - -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 - -| Library | Lang | COSE | CBOR | Total NCSL | Ratio | Algos | -|---|---|---|---|---|---|---| -| **wolfCOSE** | C99 | 4,959 | 502 | **5,461** | 1.0x | 40 | -| t_cose+QCBOR | C99 | 1,617 | 4,908 | 6,525 | 1.2x | 7 | -| libcose+NanoCBOR | C99 | 1,678 | 889 | 2,567 | 0.5x | ~2 | -| COSE-C+cn-cbor | C++ | 10,579 | 1,288 | 11,867 | 2.2x | ~30 | -| go-cose+fxcbor | Go | 2,637 | 5,973 | 8,610 | 1.6x | 7 | -| pycose | Py | 3,495 | (ext) | 3,495+ | 0.6x+ | ~12 | -| COSE-JAVA | Java | 3,478 | (ext) | 3,478+ | 0.6x+ | ~8 | - -``` -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) - -| Library | Total NCSL | Algorithms | Algos / 1K Lines | -|---|---|---|---| -| **wolfCOSE** | 5,461 | 40 | **7.3** | -| pycose | 3,495+ | ~12 | ~3.4 | -| COSE-C+cn-cbor | 11,867 | ~30 | 2.5 | -| COSE-JAVA | 3,478+ | ~8 | ~2.3 | -| t_cose+QCBOR | 6,525 | 7 | 1.1 | -| go-cose+fxcbor | 8,610 | 7 | 0.8 | - -wolfCOSE delivers 7.3 algorithms per 1,000 lines. That is 6.6x denser than `t_cose+QCBOR`. - -### COSE Logic Only (No CBOR) - -| Library | COSE-Only | CBOR Dep | Algorithms | COSE Algos/KLOC | -|---|---|---|---|---| -| **wolfCOSE** | 4,959 | 502 (built-in) | 40 | **8.1** | -| t_cose | 1,617 | 4,908 (QCBOR) | 7 | 4.3 | -| libcose | 1,678 | 889 (NanoCBOR) | ~2 | 1.2 | -| COSE-C | 10,579 | 1,288 (cn-cbor) | ~30 | 2.8 | - -`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 - -| Library | Lang | Sign | Enc | MAC | Key Mgmt | Total | PQ | FIPS Path | -|---|---|---|---|---|---|---|---|---| -| **wolfCOSE** | C99 | 11 | 12 | 7 | 10 | **40** | ML-DSA | Via wolfCrypt #4718 | -| COSE-C | C++ | ~4 | ~12 | ~7 | ~7 | ~30 | No | Via OpenSSL FIPS | -| pycose | Py | ~7 | ~3 | ~2 | | ~12 | No | No | -| COSE-JAVA | Java | ~4 | ~2 | ~2 | | ~8 | No | No | -| t_cose | C99 | 7 | 0 | 0 | 0 | 7 | No | Via OpenSSL FIPS | -| go-cose | Go | 7 | 0 | 0 | 0 | 7 | No | No | -| libcose | C99 | 1 | 1 | 0 | 0 | ~2 | No | No | - -### Signing Algorithms (COSE_Sign1 / COSE_Sign) - -| Algorithm | wolfCOSE | t_cose | COSE-C | go-cose | libcose | -|---|---|---|---|---|---| -| ES256 (P-256) | Yes | Yes | Yes | Yes | No | -| ES384 (P-384) | Yes | Yes | Yes | Yes | No | -| ES512 (P-521) | Yes | Yes | Yes | Yes | No | -| EdDSA (Ed25519) | Yes | Yes | Yes | Yes | Yes | -| EdDSA (Ed448) | Yes | No | No | No | No | -| PS256 (RSA-PSS) | Yes | Yes | No | Yes | No | -| PS384 (RSA-PSS) | Yes | Yes | No | Yes | No | -| PS512 (RSA-PSS) | Yes | Yes | No | Yes | No | -| ML-DSA-44 | Yes | No | No | No | No | -| ML-DSA-65 | Yes | No | No | No | No | -| ML-DSA-87 | Yes | No | No | No | No | -| **Total** | **11** | 7 | ~4 | 7 | 1 | - -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) - -| Algorithm | wolfCOSE | COSE-C | libcose | -|---|---|---|---| -| A128GCM | Yes | Yes | No | -| A192GCM | Yes | Yes | No | -| A256GCM | Yes | Yes | No | -| ChaCha20-Poly1305 | Yes | No | Yes | -| AES-CCM (8 variants) | Yes (all 8) | Yes (all 8) | No | -| **Total** | **12** | ~12 | 1 | - -`t_cose` and `go-cose` have zero encryption support. - -### MAC Algorithms (COSE_Mac0 / COSE_Mac) - -| Algorithm | wolfCOSE | COSE-C | libcose | -|---|---|---|---| -| HMAC-256/256 | Yes | Yes | No | -| HMAC-384/384 | Yes | Yes | No | -| HMAC-512/512 | Yes | Yes | No | -| AES-MAC-128-64 | Yes | Yes | No | -| AES-MAC-256-64 | Yes | Yes | No | -| AES-MAC-128-128 | Yes | Yes | No | -| AES-MAC-256-128 | Yes | Yes | No | -| **Total** | **7** | ~7 | 0 | - -`t_cose`, `go-cose`, and `libcose` have zero MAC support. - -### Key Management Algorithms - -| Algorithm | wolfCOSE | COSE-C | -|---|---|---| -| Direct | Yes | Yes | -| A128KW / A192KW / A256KW | Yes | Yes | -| ECDH-ES + HKDF-256/512 | Yes | Yes | -| ECDH-SS + HKDF-256/512 | Yes | Yes | -| ECDH-ES + A128KW / A192KW / A256KW | Yes | Partial | -| **Total** | **10** | ~7 | - -`t_cose`, `go-cose`, and `libcose` have zero key management support. - -### COSE Message Types - -| Type | wolfCOSE | t_cose | COSE-C | libcose | go-cose | -|---|---|---|---|---|---| -| Sign1 | Yes | Yes | Yes | Yes | Yes | -| Encrypt0 | Yes | No | Yes | Yes | No | -| Mac0 | Yes | No | Yes | No | No | -| Sign (multi-signer) | Yes | No | Yes | Yes | No | -| Encrypt (multi-recipient) | Yes | No | Yes | Yes | No | -| Mac (multi-recipient) | Yes | No | Yes | No | No | -| **Total** | **6/6** | 1/6 | 6/6 | 4/6 | 1/6 | - -## What Only wolfCOSE Has - -| Capability | wolfCOSE | t_cose | COSE-C | libcose | go-cose | -|---|---|---|---|---|---| -| Post-Quantum (ML-DSA) | Yes | No | No | No | No | -| Path to FIPS 140-3 | Yes | No | No | No | No | -| DO-178C path with wolfTPM | Yes | No | No | No | No | -| Secure boot path with wolfBoot | Yes | No | No | No | No | -| Zero heap allocation | Yes | Yes | No | Yes | No | -| Built-in CBOR | Yes | No | No | No | No | -| MISRA-C compliance (striving) | Yes | No | No | No | N/A | -| Ed448 support | Yes | No | No | No | No | -| All 6 COSE types | Yes | No | Yes | No | No | -| CLI tool | Yes | No | No | No | No | -| 15 CI workflows | Yes | No | No | No | No | -| Coverity + ASan CI | Yes | No | No | No | No | -| COSE_Key all types | Yes | No | Partial | No | No | - -## Zero Dynamic Allocation - -| Library | Heap Alloc | Notes | -|---|---|---| -| **wolfCOSE** | Zero | Safety-critical: automotive, aerospace, medical | -| t_cose | Zero | Similar embedded design | -| libcose | Zero | Minimal allocation model | -| COSE-C | malloc/calloc | OpenSSL heap dependency, cn-cbor uses calloc | -| go-cose | GC-managed | Go runtime + garbage collector | -| pycose | GC-managed | Python interpreter + GC | -| COSE-JAVA | GC-managed | JVM + garbage collector | - -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](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4718). Since wolfCrypt is the only dependency, there is a direct, clean path to FIPS compliance when required. - -| Certification | wolfCOSE (via wolfCrypt) | All Others | -|---|---|---| -| FIPS 140-3 | Path via wolfCrypt #4718 | Via OpenSSL FIPS | -| DO-178C | Path via wolfCrypt and wolfTPM | None | -| Common Criteria | Path via wolfCrypt EAL4+ | None | - -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 - -| Area | cppcheck (2012) | Compiler + clang-tidy (2023) | Commercial | -|---|---|---|---| -| Syntax Rules | High (~90%) | High (~95%) | 100% | -| Essential Types | Medium (~50%) | High (~80%) | 100% | -| Data Flow | Low (~30%) | Medium (~50%) | 100% | -| Std Lib Safety | Low (~20%) | Medium (~60%) | 100% | - -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. - -| PQ Algorithm | wolfCOSE | All Others | -|---|---|---| -| ML-DSA-44 (FIPS 204, Level 2) | Native | None | -| ML-DSA-65 (FIPS 204, Level 3) | Native | None | -| ML-DSA-87 (FIPS 204, Level 5) | Native | None | - -Roadmap: XMSS, LMS/HSS (FIPS 205), ML-KEM (FIPS 203), SLH-DSA (SPHINCS+). - -## Testing and CI - -### Test Suite - -| Metric | wolfCOSE | t_cose | COSE-C | libcose | -|---|---|---|---|---| -| Test functions | 176 | ~15 | ~20 | ~10 | -| Test NCSL | 15,173 | | | | -| Test tiers | 3 (unit, comp, scenario) | 1 | 1 | 1 | -| Round-trip all algos | `wolfcose_tool test --all` | No | No | No | -| Interop tests | Yes (RFC vectors) | Partial | Yes | No | -| Error path injection | Yes (`force_failure.c`) | No | No | No | -| Real-world scenarios | 5 | No | No | No | - -### Code Coverage - -| File | Line Coverage | Branch Coverage | -|---|---|---| -| `wolfcose.c` | 99.3% | High | -| `wolfcose_cbor.c` | 100% | 100% | - -### 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. - -| CI Workflow | wolfCOSE | t_cose | COSE-C | libcose | -|---|---|---|---|---| -| `build-test.yml` (Ubuntu latest + 22.04, macOS) | Yes | Yes | Yes | Yes | -| `multi-compiler.yml` (GCC 10 to 14, Clang 14 to 18) | Yes | | | | -| `static-analysis.yml` (cppcheck, scan-build, `-fanalyzer`) | Yes | | | | -| `coverity.yml` (nightly Coverity defect analysis) | Yes | | | | -| `sanitizer.yml` (ASan + UBSan) | Yes | | | | -| `coverage.yml` (gcov + lcov, threshold enforced) | Yes | | | | -| `minimal-build.yml` (minimal wolfSSL configuration) | Yes | | | | -| `misra-2012.yml` (cppcheck addon) | Yes | | | | -| `misra-2023.yml` (compiler strict + clang-tidy) | Yes | | | | -| `comprehensive-tests.yml` (~240 algorithm combinations) | Yes | | | | -| `examples.yml` (lifecycle demo + tool round-trip) | Yes | | | | -| `scenarios.yml` (real-world scenario examples) | Yes | | | | -| `codespell.yml` (spell checking) | Yes | | | | -| `nightly.yml` (nightly orchestrator on master) | Yes | | | | -| `wolfssl-versions.yml` (every wolfSSL 5.x release, nightly) | Yes | | | | - -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 - -| Requirement | wolfCOSE | t_cose | COSE-C | libcose | -|---|---|---|---|---| -| No malloc | Yes | Yes | No | Yes | -| No floating point | Yes | Yes | No | Yes | -| No external CBOR | Yes | No (QCBOR) | No (cn-cbor) | No (NanoCBOR) | -| Fixed-size buffers | Yes | Yes | No | Yes | -| C99, no C++ | Yes | Yes | No (C++) | Yes | -| Bare-metal compatible | Yes | Yes | No | Yes | -| RTOS compatible | Yes | Yes | Partial | Yes | -| `#ifdef` configurability | 238 guards | Minimal | Minimal | Minimal | -| Stack usage (`.su`) | Yes | No | No | No | - -## Architecture - -| Property | wolfCOSE | t_cose | COSE-C | libcose | -|---|---|---|---|---| -| Language | C99 | C99 | C++ (C API) | C99 | -| Source files | 2 (.c) | 5 (.c)+adapter | 14 (.cpp) | 11 (.c) | -| MISRA-C | Striving (2012+2023) | No | No | No | -| Dependencies | wolfCrypt only | QCBOR+OpenSSL | cn-cbor+OpenSSL | NanoCBOR+libsodium | -| Crypto backend | wolfCrypt (FIPS path) | OpenSSL/PSA | OpenSSL | libsodium | -| COSE_Key support | All types | No | Partial | Minimal | -| All 6 COSE types | Yes | No (Sign1 only) | Yes | Partial | - -## 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. - -| Capability | wolfCOSE | Others | -|---|---|---| -| Keygen (ECC, EdDSA, RSA, ML-DSA) | Yes | None | -| `COSE_Sign1` sign/verify | Yes | None | -| `COSE_Encrypt0` encrypt/decrypt | Yes | None | -| `COSE_Mac0` create/verify | Yes | None | -| Round-trip test all algorithms | `test --all` | None | -| Single algorithm test | `test -a ES256` | None | - -## 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 - -| Claim | Evidence | -|---|---| -| Smallest minimal `.text` | 7.5 KB (Sign1-sign-only, ECC) vs 18.8 KB (libcose), 30.6 KB (t_cose+QCBOR) | -| Smallest full `.text` | 25.6 KB / 40 algos vs 30.6 KB / 7 (t_cose+QCBOR), 77.3 KB / ~30 (COSE-C) | -| Most algorithms | 40 vs next-best ~30 (COSE-C) | -| Best per-algo efficiency | 0.64 KB/algo vs 4.37 (t_cose+QCBOR), 2.58 (COSE-C) | -| Only PQ-native COSE | ML-DSA-44/65/87 built in. No other has any. | -| Path to FIPS 140-3 | Via wolfCrypt Certificate #4718 (sole dependency) | -| Zero heap allocation | No `malloc` in any code path | -| Built-in CBOR | 502-line / 2.7 KB engine vs 4,908 / 25.5 KB (QCBOR) | -| All 6 COSE types | Sign1, Encrypt0, Mac0, Sign, Encrypt, Mac | -| Most comprehensive CI | 15 workflows: Coverity, ASan, UBSan, multi-compiler, MISRA, nightly orchestrator, wolfSSL-versions matrix | -| Highest code coverage | `wolfcose.c` >= 99.3%, `wolfcose_cbor.c` = 100% | -| Only full CLI tool | keygen, sign, verify, encrypt, decrypt, round-trip all algos | -| Highest algo density | 7.3 algos/KLOC vs next-best ~3.4 (pycose) | -| MISRA-C striving | 2012 fully checked, 2023 ~80% via 3 free checkers | - -## Learn More - -* All wolfCOSE blog posts: -* wolfCOSE wiki and documentation: -* Contact wolfSSL for commercial licensing or production support: - -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. diff --git a/docs/index.md b/docs/index.md deleted file mode 100644 index fb7765b..0000000 --- a/docs/index.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -layout: home -title: "wolfCOSE Blogs" ---- - -Welcome to the wolfCOSE blog. wolfCOSE is a zero-allocation C library that implements the full RFC 9052 COSE message set. It includes native post-quantum signatures (ML-DSA-44/65/87) and offers a path to FIPS 140-3 validation through wolfCrypt. - -These posts cover the design decisions, the technical details, and the intended use cases for the project. They are written for embedded and IoT developers, security engineers, and anyone evaluating COSE for constrained-device deployments. They also serve an educational purpose, explaining what COSE is and what wolfCOSE does for readers who are new to the standard. - -The source code lives at [github.com/aidangarske/wolfCOSE](https://github.com/aidangarske/wolfCOSE). For commercial inquiries or production support, contact [facts@wolfssl.com](mailto:facts@wolfssl.com).