quantum-resistant-rustykey 0.7.4 → 0.7.6

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 +6 -5
  2. package/package.json +1 -1
package/README.md CHANGED
@@ -13,10 +13,11 @@ Fast, secure WebAssembly implementations of useful post-quantum-resistant tools
13
13
  - module-lattice-based key-encapsulation mechanism
14
14
  - **ML-KEM-512**, **ML-KEM-768**, and **ML-KEM-1024** using the same stack: [mlkem-native](https://github.com/pq-code-package/mlkem-native) built with **Emscripten**.
15
15
 
16
- ## Why we support SQISign: Helping hurdle the "silent" barrier to post-quantum adoption: 1024-byte buffer limit in many existing FIDO2/WebAuthn implementations
16
+ ### NOTE: Why we support SQISign when it is 'NIST-on-ramp' only
17
+ *TLDR; to help hurdle the "silent" barrier to post-quantum adoption: 1024-byte buffer limit in many existing FIDO2/WebAuthn implementations*
17
18
 
18
- ### WebAuthn PQC Signature "Wall"
19
- Falcon and Dilithium - but not SQISign - are "physical incompatibile" with millions of existing FIDO2/WebAuthn authenticators that rely on the CTAP2 1024-byte buffer limit.
19
+ #### WebAuthn PQC Signature size constraints
20
+ Dilithium variants, and Falcon-1024 are physical incompatibile with millions of existing FIDO2/WebAuthn authenticators that rely on the CTAP2 1024-byte buffer limit.
20
21
 
21
22
  - CTAP2 protocol, which allows browsers to talk to security keys, often operates within tight memory constraints to maintain the speed and low-power requirements of embedded devices.
22
23
 
@@ -27,9 +28,9 @@ Falcon and Dilithium - but not SQISign - are "physical incompatibile" with milli
27
28
  #### Critical use case example
28
29
  For mission-critical applications like low-latency augmented reality remote telesurgery, where ultra-low latency and hardware-rooted trust are non-negotiable. RustyKey® who financially support this repo and the npm package, required a WASM port of SQIsign specifically because the 204-byte signatures are the only PQC option that worked within their current hardware constraints, enabling immediate quantum-resistant public key ceremonies without breaking the existing WebAuthn ecosystem.
29
30
 
30
- ## user-friendly live example testbed and playground
31
+ ## Broad user-friendly live example testbed and playground (coming May 2026)
31
32
 
32
- - live test environment (coming May 2026) where general purpose users and seasoned cryptanalysts, can encrypt and descrypt and play, using all 3 varients of KEM and a test WebAuthn implementations using the signature algorithms
33
+ - live test environment where general purpose users together with seasoned cryptanalysts, can encrypt and descrypt and play, using all 3 varients of KEM and a test WebAuthn implementations using the signature algorithms
33
34
  - lattice-based vs isogeny: run tests to check: Montgomery constant times, the surprising difference in time taken for the various steps
34
35
  - all are encouraged to suggest improvements, and help a wider audience see how PQC works under the hood and adopt it more quickly and without breaking existing infrastructure.
35
36
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "quantum-resistant-rustykey",
3
- "version": "0.7.4",
3
+ "version": "0.7.6",
4
4
  "description": "WebAssembly post-quantum-resistant tools for web",
5
5
  "author": "Antony R Mott <a@auditcanary.com> (https://rustykey.app)",
6
6
  "license": "ISC",