@qrlwallet/connect 0.1.0 → 3.0.0

package/README.md

@@ -10,7 +10,7 @@ Connect your dApp to QRL Wallet. Users scan a QR code (desktop) or tap a button
 4. Your dApp sends JSON-RPC requests, the wallet prompts for approval
 5. Signed results come back to your dApp
 
-All communication is end-to-end encrypted (ECIES). The relay server never sees your data.
+All communication is end-to-end encrypted with ML-KEM-768 (FIPS 203) key encapsulation and AES-256-GCM. The relay server never sees your data.
 
 ## Install
 
@@ -124,14 +124,16 @@ The main class. Creates a connection manager and EIP-1193 provider.
 | `disconnected` | No active connection |
 | `connecting` | Connecting to relay server |
 | `waiting` | QR displayed, waiting for wallet to scan |
-| `key_exchange` | ECIES key exchange in progress |
+| `key_exchange` | Post-quantum key exchange in progress |
 | `connected` | Wallet connected, ready for requests |
 | `reconnecting` | Attempting to restore a previous session |
 
 ### Supported RPC methods
 
 **Require user approval:**
-`qrl_requestAccounts`, `qrl_sendTransaction`, `qrl_signTransaction`, `qrl_sign`, `personal_sign`, `qrl_signTypedData_v4`, `wallet_addQrlChain`, `wallet_switchQrlChain`
+`qrl_requestAccounts`, `qrl_sendTransaction`, `qrl_signTransaction`, `qrl_signMessage`, `qrl_signTypedData`, `wallet_addQrlChain`, `wallet_switchQrlChain`
+
+`qrl_signMessage` and `qrl_signTypedData` (v3.0.0) replace the Ethereum-flavored `personal_sign` / `qrl_sign` / `qrl_signTypedData_v3` / `qrl_signTypedData_v4`. Both use SHAKE256 + native ML-DSA-87 ctx and return a rich `{ signature, publicKey, signer, digest, schemeVersion }` object; verify locally with `verifyMessage` / `verifyTypedData` exported from this package.
 
 **Auto-proxied (no approval needed):**
 `qrl_getBalance`, `qrl_call`, `qrl_estimateGas`, `qrl_blockNumber`, `qrl_chainId`, `qrl_getTransactionReceipt`, and 30+ more read-only methods.
@@ -151,7 +153,7 @@ Recommended lifecycle:
 
 The relay is a lightweight Socket.IO server that routes encrypted messages between your dApp and the wallet. It runs at `wss://qrlwallet.com/relay`.
 
-- Messages are ECIES-encrypted end-to-end (the relay sees only ciphertext)
+- Messages are end-to-end encrypted with AES-256-GCM keyed from an ML-KEM-768 handshake (the relay sees only ciphertext)
 - Max 2 participants per channel
 - Messages are buffered for up to 5 minutes if the wallet is temporarily offline (e.g., app backgrounded)
 - Channels auto-expire after 30 minutes of inactivity
@@ -167,31 +169,6 @@ const qrl = new QRLConnect({
 });
 ```
 
-## Bundler setup
-
-The SDK depends on Node's `Buffer` via `eciesjs`. If you're using Vite, add the polyfill plugin:
-
-```bash
-npm install vite-plugin-node-polyfills
-```
-
-```js
-// vite.config.js
-import { nodePolyfills } from 'vite-plugin-node-polyfills';
-
-export default defineConfig({
-  plugins: [
-    nodePolyfills({
-      include: ['buffer'],
-      globals: { Buffer: true },
-    }),
-  ],
-  define: { global: 'globalThis' },
-});
-```
-
-For webpack 5, add `buffer` to `resolve.fallback` and the `ProvidePlugin` for `Buffer`.
-
 ## Development
 
 ```bash
@@ -211,7 +188,7 @@ npm test
 npm run lint
 
 # E2E test (starts a local relay, simulates dApp + wallet handshake)
-node test-e2e.js
+node test-e2e.mjs
 ```
 
 ## Running the example dApp
@@ -236,8 +213,12 @@ The example connects to the production relay at `wss://qrlwallet.com/relay` by d
 ## Security
 
 - Private keys and seeds never leave the wallet
-- All relay traffic is ECIES-encrypted (Elliptic Curve Integrated Encryption Scheme)
-- Key exchange uses a 3-step SYN/SYNACK/ACK handshake
+- All relay traffic is end-to-end encrypted with **AES-256-GCM** bound to a
+  **transcript hash** derived from the full handshake (`LABEL || cid || pk || ct`)
+- Session keys are established with **ML-KEM-768** (FIPS 203, NIST Level 3),
+  carried in the QR code so the relay never sees an uncommitted public key
+- Ciphertext tampering is detected exclusively at the AES-GCM tag;
+  ML-KEM's implicit rejection is NOT used for authentication
 - PIN or biometric authentication required for every transaction
 - dApp URL is displayed to the user before connecting
 - Unknown RPC methods are rejected with `-32601`