quantum-resistant-rustykey 0.12.0 → 0.12.7
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +22 -14
- package/package.json +19 -6
package/README.md
CHANGED
|
@@ -1,30 +1,35 @@
|
|
|
1
1
|
# <img src="./logo-rustykey.png" width="57" align="center" /> Quantum-resistant RustyKey®
|
|
2
2
|
|
|
3
|
-
Fast, secure WebAssembly implementations of useful post-quantum-resistant tools both for backend (node) and frontend web.
|
|
4
|
-
|
|
5
3
|
[](https://npmjs.com)
|
|
6
4
|
[](https://npmjs.com)
|
|
7
|
-
|
|
6
|
+
|
|
7
|
+
|
|
8
|
+
Fast, secure WebAssembly implementations of useful post-quantum-resistant tools both for backend (node) and frontend web.
|
|
8
9
|
|
|
9
10
|
```bash
|
|
10
|
-
|
|
11
|
+
# Install via pnpm (preferred)
|
|
12
|
+
pnpm i quantum-resistant-rustykey
|
|
13
|
+
# or
|
|
14
|
+
bun add quantum-resistant-rustykey
|
|
15
|
+
npm add quantum-resistant-rustykey
|
|
11
16
|
```
|
|
12
17
|
|
|
13
18
|
## Implementation status: Pre-production (stable for testing)
|
|
14
19
|
|
|
15
20
|
- ***Recommendation***: Await v1.0.0 (following security audit) for production/regulated deployment.
|
|
16
21
|
- includes NIST approved and NIST "on-ramp" round 3 candidate SQISign
|
|
17
|
-
- **SQIsign** Level
|
|
22
|
+
- **SQIsign** Level 5, Level 3, Level 1 NOT approved yet by NIST, refer [cose-sqisign] (https://datatracker.ietf.org/doc/draft-mott-cose-sqisign/)
|
|
18
23
|
- **ML-DSA** ML-DSA-65, ML-DSA-87
|
|
19
24
|
- **FN-DSA** FN-DSA-512, FN-DSA-1024
|
|
20
25
|
- **ML-KEM** 512, 768, 1024 using [mlkem-native](https://github.com/pq-code-package/mlkem-native).
|
|
21
26
|
|
|
22
|
-
### SQISign is 'NIST-on-ramp'
|
|
23
|
-
*TLDR;
|
|
24
|
-
- support our IETF standards track draft
|
|
27
|
+
### SQISign is 'NIST-on-ramp': get ahead and test TODAY, SQISign is the ONLY signature for constrained-development use
|
|
28
|
+
*TLDR; breeze past the "silent" barrier to post-quantum adoption: 1024-byte buffer limit in many existing FIDO2/WebAuthn implementations*
|
|
29
|
+
- support our IETF standards track draft by taking our free code for a spin, the more users enjoying these packages, the faster things go [cose-sqisign](https://www.ietf.org/archive/id/draft-mott-cose-sqisign-03.html)
|
|
25
30
|
|
|
26
|
-
#### ⚠️ IMPORTANT SPECIFICATION NOTICE (as of
|
|
27
|
-
COSE/JOSE Algorithm IDs (-61, -62, -63) and case-sensitive identifier strings (SQIsign-L1, SQIsign-L3, SQIsign-L5)
|
|
31
|
+
#### ⚠️ IMPORTANT SPECIFICATION NOTICE (as of July 2026)
|
|
32
|
+
COSE/JOSE Algorithm IDs (-61, -62, -63) and case-sensitive identifier strings (SQIsign-L1, SQIsign-L3, SQIsign-L5) used in this package are derived directly from the active [cose-sqisign](https://datatracker.ietf.org/doc/draft-mott-cose-sqisign/)Internet-Draft. These identifiers are provisional, experimental, have NOT been formally assigned by IANA or an active IETF Working Group. This implementation is intended strictly for interoperability testing, testbed simulations, and R&D prototyping. Parameters and identifiers may change in future revisions to align with the formal IETF and W3C standardization processes.
|
|
28
33
|
|
|
29
34
|
#### WebAuthn PQC Signature size constraints
|
|
30
35
|
Dilithium variants, and Falcon-1024 are physically incompatible with millions of existing FIDO2/WebAuthn authenticators that rely on the CTAP2 1024-byte buffer limit.
|
|
@@ -47,7 +52,7 @@ Live at **[pqc.rustykey.me](https://pqc.rustykey.me)** — a test environment wh
|
|
|
47
52
|
## Security assurance and verification
|
|
48
53
|
|
|
49
54
|
This project relies on upstream `mlkem-native` for arithmetic/security properties.
|
|
50
|
-
The three parameter sets (512/768/1024) use the same implementation family and differ only by compile-time parameter selection.
|
|
55
|
+
The three parameter sets (512/768/1024) use the same implementation family and differ only by compile-time parameter selection. Bear in mind for testing that the formal proofs validate native C and assembly source code only: the moment we passed that through a custom wasm/Makefile, those upstream formal verification guarantees evaporated.
|
|
51
56
|
|
|
52
57
|
### Upstream evidence
|
|
53
58
|
|
|
@@ -64,7 +69,7 @@ The three parameter sets (512/768/1024) use the same implementation family and d
|
|
|
64
69
|
- Generic Montgomery reduction helper:
|
|
65
70
|
- [mlkem/src/poly.h](https://github.com/pq-code-package/mlkem-native/blob/main/mlkem/src/poly.h)
|
|
66
71
|
|
|
67
|
-
###
|
|
72
|
+
### Constant-time claims and proofs
|
|
68
73
|
|
|
69
74
|
- Constant-time claims and proofs are provided upstream by `mlkem-native` (see links above).
|
|
70
75
|
- This package builds the same source for all three variants by changing only `MLK_CONFIG_PARAMETER_SET` in `wasm/Makefile`.
|
|
@@ -72,9 +77,12 @@ The three parameter sets (512/768/1024) use the same implementation family and d
|
|
|
72
77
|
|
|
73
78
|
### We predominantly use C, not Rust for our web-assembly (WASM) modules: Why?
|
|
74
79
|
|
|
75
|
-
|
|
80
|
+
- ***we're not cryptanalysts, not the smartypants type. We choose not to 'roll our own' cryptography as it's worrying enough we compile the C into web-assembly...what if our work strips out constant-time protections? Think of us as enthusiastic interweb equivalents of stonemasons, ironworkers, mechanics and logistics crew. Our caps might still have the price tag on, but you'll find us exactly when you need us: well below decks in grubby overalls, keeping the engines humming. Far above us lounge the sharply-dressed engineers who long ago earned their Hugo spritzes. We publish frequently 'into the wild' to guarantee our code is battle-tested, bugs found quickly. It only works because we rely absolutely on vetted, peer-reviewed designs from you and the rest of the research community.***
|
|
81
|
+
|
|
82
|
+
It seems all the cool cryptanalyst kids nowadays rely on Rust's proven memory and concurrency safety and high performance without a Garbage Collector. Hre it's old-school for the time being: shipped cryptographic WASM modules will continue to be built via Emscripten from vetted C/C++ upstream code. We do love Rust when used at the right time: Rust/TypeScript will be primarily used for package-level ergonomics and integration layers.
|
|
76
83
|
|
|
77
|
-
|
|
84
|
+
### detail. TLDR; downstream security != upstream security
|
|
85
|
+
A Rust-foward approach is implied in our brand, so building direct form C libraries to web-assembly deserves more explanation. Many developers new to web-assembly migrations (i.e. from other languages) don't realize that final WebAssembly (WASM) bytecode looks completely different inside depending on if one begins with C or Rust. Yes, web-assembly modules from each (Rust or C) will function, about the same speed, and indeed will be equally platform agnostic for deployment. But we observed slight timing differences between web-assembly modules compiled from Rust and from C, so we're sticking with C.
|
|
78
86
|
|
|
79
87
|
RustyKey® current dual approach is a way to balance performance, security-vetted logic, and web compatibility. Some technical factors may make C => emscripten approach acceptable and, in some cases, preferable for post-quantum cryptography:
|
|
80
88
|
|
package/package.json
CHANGED
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "quantum-resistant-rustykey",
|
|
3
|
-
"version": "0.12.
|
|
3
|
+
"version": "0.12.7",
|
|
4
4
|
"description": "WebAssembly post-quantum-resistant tools for web",
|
|
5
|
-
"author": "Antony R Mott <
|
|
5
|
+
"author": "Antony R Mott <antony@rustykey.io> (https://rustykey.io)",
|
|
6
6
|
"license": "ISC",
|
|
7
7
|
"funding": [
|
|
8
8
|
{
|
|
@@ -15,11 +15,21 @@
|
|
|
15
15
|
"url": "git+https://github.com/antonymott/quantum-resistant-rustykey.git"
|
|
16
16
|
},
|
|
17
17
|
"homepage": "https://github.com/antonymott/quantum-resistant-rustykey.git#readme",
|
|
18
|
+
"bugs": {
|
|
19
|
+
"url": "https://github.com"
|
|
20
|
+
},
|
|
18
21
|
"keywords": [
|
|
19
22
|
"NIST",
|
|
20
23
|
"post-quantum",
|
|
24
|
+
"pqc",
|
|
21
25
|
"WebAssembly",
|
|
22
|
-
"
|
|
26
|
+
"wasm",
|
|
27
|
+
"cryptography",
|
|
28
|
+
"crypto",
|
|
29
|
+
"sqisign",
|
|
30
|
+
"ml-dsa",
|
|
31
|
+
"ml-kem",
|
|
32
|
+
"webauthn"
|
|
23
33
|
],
|
|
24
34
|
"type": "module",
|
|
25
35
|
"sideEffects": false,
|
|
@@ -38,16 +48,19 @@
|
|
|
38
48
|
"devDependencies": {
|
|
39
49
|
"@biomejs/biome": "2.4.11",
|
|
40
50
|
"@changesets/cli": "2.30.0",
|
|
41
|
-
"@types/node": "
|
|
51
|
+
"@types/node": "^26.1.0",
|
|
42
52
|
"@webgpu/types": "0.1.71",
|
|
43
53
|
"esbuild": "0.28.0",
|
|
44
|
-
"tsdown": "0.
|
|
54
|
+
"tsdown": "0.22.3",
|
|
45
55
|
"typescript": "6.0.2",
|
|
46
56
|
"vitest": "4.1.4"
|
|
47
57
|
},
|
|
48
58
|
"dependencies": {
|
|
49
59
|
"@noble/post-quantum": "0.6.1"
|
|
50
60
|
},
|
|
61
|
+
"engines": {
|
|
62
|
+
"node": ">=26.4.0"
|
|
63
|
+
},
|
|
51
64
|
"scripts": {
|
|
52
65
|
"clean": "rm -rf dist",
|
|
53
66
|
"lint": "biome check --config-path ./biome.json ./src ./scripts ./tsconfig.json ./tsconfig.lint.json ./tsdown.config.ts && tsc --project ./tsconfig.lint.json",
|
|
@@ -60,7 +73,7 @@
|
|
|
60
73
|
"build": "pnpm build:vendor && tsdown && pnpm bundle:accel-worker",
|
|
61
74
|
"test": "pnpm build:vendor && vitest run",
|
|
62
75
|
"verify:dist": "node scripts/verify-dist.mjs",
|
|
63
|
-
"release": "
|
|
76
|
+
"release": "changeset publish",
|
|
64
77
|
"example:browser": "pnpm --filter browser-demo dev"
|
|
65
78
|
}
|
|
66
79
|
}
|