pqc module: architecture design
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 23
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Description
Design the pqc module before implementation starts. The ntt module was built from the start with Kyber parameters (q=3329, n=256, omega=17), see docs/algorithms/ntt.md, so this builds directly on top of numx_ntt_*.
Decisions needed:
- Parameter sets to support: Kyber-512/768/1024, Dilithium2/3/5, or a subset to start
- Public API surface and file layout (include/numx/pqc.h, src/pqc.c, or split by scheme)
- Stack budget on ESP32-S3 and other constrained targets (Kyber/Dilithium keys and intermediate buffers are larger than anything currently in numx)
- Dependency on the new rng module (#63) for keygen randomness
- Whether this is one module or two (kyber, dilithium) given CONTRIBUTING.md's "test file and benchmark file per module" rule
This is the first task in the milestone; #64, #65, #66 depend on the decisions made here.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with docs/algorithms/ntt.md and CONTRIBUTING.md to understand the existing NTT assumptions and per-module test and benchmark rule. Review the constraints around ESP32-S3 stack usage and the dependency on rng module #63. Done means documenting decisions on supported parameter sets, API and file layout, memory budgets, randomness, and module boundaries so #64, #65, and #66 can proceed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- cryptography, embedded-iot
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100