quantum-resistant-rustykey 0.7.1 → 0.7.3
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 +14 -0
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -44,6 +44,20 @@ The three parameter sets (512/768/1024) use the same implementation family and d
|
|
|
44
44
|
- This package builds the same source for all three variants by changing only `MLK_CONFIG_PARAMETER_SET` in `wasm/Makefile`.
|
|
45
45
|
- Variant sizes/parameters are defined upstream in `mlkem/mlkem_native.h`.
|
|
46
46
|
|
|
47
|
+
### Why we mix C => emscripten with Rust => wasm-bindgen for web-assembly module creation
|
|
48
|
+
Increasingly, developers favor Rust => wasm-bindgen over C => emscripten for Rust's superior compile-time memory safety...and leaning on Rust is implied in our brand! 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:
|
|
49
|
+
- upstream Reliability: Many NIST-standardized PQC algorithms (like ML-KEM) have highly optimized, audited, and "constant-time" reference implementations written in C. Using C => Emscripten allows RustyKey® to port these vetted "upstream" sources directly, reducing the risk of introducing new implementation bugs during a full rewrite into Rust.
|
|
50
|
+
- Constant-Time Guarantees: web-assembly is particularly opaque. In cryptography, protection against side-channel attacks (like timing attacks) is often more critical than general-purpose memory safety. Using audited C code that is already proven to be constant-time may be a safer WASM route than a new Rust implementation that might inadvertently introduce timing leaks. We encourage realtime constant time checks in our testbed site and appreciate any feedback to improve.
|
|
51
|
+
- Toolchain Maturity: Emscripten is a mature leader in the WASM ecosystem (sometimes...bloated!). For projects needing to bridge legacy or specialized C libraries with the web, emscripten provides a stable environment that can, when optimized, outperform wasm-bindgen in raw execution speed for specific linear memory access patterns.
|
|
52
|
+
|
|
53
|
+
### Why we offer WASM implementations of SQISign (NIST on-ramp only) alongside established, standards-track Falcon and Dilithium?
|
|
54
|
+
1. The "SIDH" vs. "SQIsign" Distinction
|
|
55
|
+
- the algorithm that was "spectacularly broken" in 2022 was SIDH. The attack (the Castryck-Decru attack) exploited specific "auxiliary points" for example revealing torsion point information.
|
|
56
|
+
- SQIsign is fundamentally different, and structurally resistant to this specific attack because it does not reveal torsion point information. Security relies on the Deuring correspondence — a mathematical link between supersingular elliptic curves and quaternion algebras — rather than the specific isogeny problem with auxiliary points used by SIDH.
|
|
57
|
+
- To date, SQIsign remains structurally sound against the specific attacks that broke SIDH, which is why NIST accepted it onto the "on-ramp" (the Round 4/Additional Signatures track).
|
|
58
|
+
2. Smaller Signature Size Advantage
|
|
59
|
+
- SQISign has smaller signatures. This npm package is a WASM-based project targeting web or mobile, where signature size is a massive bottleneck for bandwidth.
|
|
60
|
+
|
|
47
61
|
### How users can independently verify
|
|
48
62
|
|
|
49
63
|
From the repository root:
|
package/package.json
CHANGED