quantum-resistant-rustykey 0.12.6 → 0.12.8

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.
Files changed (2) hide show
  1. package/README.md +4 -3
  2. package/package.json +17 -19
package/README.md CHANGED
@@ -52,7 +52,7 @@ Live at **[pqc.rustykey.me](https://pqc.rustykey.me)** — a test environment wh
52
52
  ## Security assurance and verification
53
53
 
54
54
  This project relies on upstream `mlkem-native` for arithmetic/security properties.
55
- 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.
56
56
 
57
57
  ### Upstream evidence
58
58
 
@@ -77,10 +77,11 @@ The three parameter sets (512/768/1024) use the same implementation family and d
77
77
 
78
78
  ### We predominantly use C, not Rust for our web-assembly (WASM) modules: Why?
79
79
 
80
- - ***we're not cryptanalysts, not the smartipants type. We choose not to 'roll our own' cryptography. 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.***
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
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. But that's not our way, not right now! It's old-school for the time being: ALL 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.
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.
83
83
 
84
+ ### detail. TLDR; downstream security != upstream security
84
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.
85
86
 
86
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:
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "quantum-resistant-rustykey",
3
- "version": "0.12.6",
3
+ "version": "0.12.8",
4
4
  "description": "WebAssembly post-quantum-resistant tools for web",
5
5
  "author": "Antony R Mott <antony@rustykey.io> (https://rustykey.io)",
6
6
  "license": "ISC",
@@ -45,23 +45,6 @@
45
45
  "files": [
46
46
  "dist"
47
47
  ],
48
- "scripts": {
49
- "clean": "rm -rf dist",
50
- "lint": "biome check --config-path ./biome.json ./src ./scripts ./tsconfig.json ./tsconfig.lint.json ./tsdown.config.ts && tsc --project ./tsconfig.lint.json",
51
- "lint:fix": "biome check --config-path ./biome.json --write ./src ./scripts ./tsconfig.json ./tsconfig.lint.json ./tsdown.config.ts",
52
- "build:wasm": "node scripts/build-wasm.mjs",
53
- "bundle:mlkem": "node scripts/bundle-mlkem.mjs",
54
- "bundle:signatures": "node scripts/bundle-signatures.mjs",
55
- "bundle:accel-worker": "node scripts/bundle-accel-worker.mjs",
56
- "build:vendor": "pnpm build:wasm && pnpm bundle:mlkem && pnpm bundle:signatures",
57
- "build": "pnpm build:vendor && tsdown && pnpm bundle:accel-worker",
58
- "test": "pnpm build:vendor && vitest run",
59
- "verify:dist": "node scripts/verify-dist.mjs",
60
- "prepack": "pnpm verify:dist",
61
- "prepublishOnly": "pnpm verify:dist",
62
- "release": "changeset publish",
63
- "example:browser": "pnpm --filter browser-demo dev"
64
- },
65
48
  "devDependencies": {
66
49
  "@biomejs/biome": "2.4.11",
67
50
  "@changesets/cli": "2.30.0",
@@ -77,5 +60,20 @@
77
60
  },
78
61
  "engines": {
79
62
  "node": ">=26.4.0"
63
+ },
64
+ "scripts": {
65
+ "clean": "rm -rf dist",
66
+ "lint": "biome check --config-path ./biome.json ./src ./scripts ./tsconfig.json ./tsconfig.lint.json ./tsdown.config.ts && tsc --project ./tsconfig.lint.json",
67
+ "lint:fix": "biome check --config-path ./biome.json --write ./src ./scripts ./tsconfig.json ./tsconfig.lint.json ./tsdown.config.ts",
68
+ "build:wasm": "node scripts/build-wasm.mjs",
69
+ "bundle:mlkem": "node scripts/bundle-mlkem.mjs",
70
+ "bundle:signatures": "node scripts/bundle-signatures.mjs",
71
+ "bundle:accel-worker": "node scripts/bundle-accel-worker.mjs",
72
+ "build:vendor": "pnpm build:wasm && pnpm bundle:mlkem && pnpm bundle:signatures",
73
+ "build": "pnpm build:vendor && tsdown && pnpm bundle:accel-worker",
74
+ "test": "pnpm build:vendor && vitest run",
75
+ "verify:dist": "node scripts/verify-dist.mjs",
76
+ "release": "changeset publish",
77
+ "example:browser": "pnpm --filter browser-demo dev"
80
78
  }
81
- }
79
+ }