|
1 | 1 | # Upstream DarkFi proposals (crypto / wallet) |
2 | 2 |
|
3 | 3 | Nighthawk cannot land these directly in `darkrenaissance/darkfi`. This list is |
4 | | -for upstream discussion / PRs. Local mobile clients keep a `bin/drk` SQLCipher |
5 | | -overlay at vendor pin `ae0339804` + `bin/drk @ c4d1776` until resolved. |
| 4 | +for upstream discussion / PRs. |
6 | 5 |
|
7 | | -## P1 — Wallet storage encryption for mobile |
| 6 | +**Client pin policy (pre-release):** Android / iOS / desktop UniFFI track tip |
| 7 | +`bin/drk` (turso + experimental aegis256). There is no SQLCipher overlay. |
| 8 | +Moonshine keeps its own SQLCipher pruned DB by design (not `drk`). |
8 | 9 |
|
9 | | -**Problem.** Upstream replaced `drk` rusqlite/SQLCipher with turso + aegis256. |
10 | | -Mobile wallets require SQLCipher (`PRAGMA key`) for existing threat models and |
11 | | -App Store / Play storage expectations. Turso encryption is not SQLCipher-compatible; |
12 | | -existing wallet DBs would not open. |
| 10 | +## P1 — Wallet storage encryption (resolved for Nighthawk UniFFI) |
13 | 11 |
|
14 | | -**Recommended fix.** Either: |
15 | | -1. Restore optional `rusqlite` + `sqlcipher` feature on `bin/drk` alongside turso |
16 | | - (feature-gated backends), or |
17 | | -2. Document a migration path from SQLCipher → turso with explicit re-encrypt |
18 | | - tooling and a stable KDF, then give clients time to migrate. |
| 12 | +**Status.** Adopted upstream tip: `WalletDb` uses turso with experimental |
| 13 | +`aegis256` and `hexkey = blake3(wallet_pass)`. Mobile/desktop pass the same |
| 14 | +`wallet_pass` through `Drk::new`; OS sandbox + encrypted prefs / Keychain / |
| 15 | +desktop PIN vault still protect the passphrase. |
19 | 16 |
|
20 | | -**Why.** Without a SQLCipher-compatible path, mobile cannot track upstream `drk` |
21 | | -without breaking encrypted-at-rest wallets. |
| 17 | +**Residual upstream asks.** |
| 18 | +1. Stabilize turso encryption API (today marked experimental). |
| 19 | +2. Document KDF / cipher parameters as a compatibility contract for light clients. |
| 20 | +3. Optional: feature-gated SQLCipher backend only if a migration story is needed |
| 21 | + for third-party wallets that already shipped SQLCipher (Nighthawk has not). |
22 | 22 |
|
23 | 23 | ## P2 — Secret zeroization in wallet key paths |
24 | 24 |
|
@@ -78,15 +78,5 @@ metadata), so light servers can reject unbound clues. |
78 | 78 |
|
79 | 79 | ## P7 — Net / RPC hardening already upstream |
80 | 80 |
|
81 | | -Recent upstream work (bounded broadcasts, subscriber teardown, host registry |
82 | | -retention, inbound slot leak fix) is valuable. Mobile FFI vendors should track |
83 | | -these once the wallet-DB strategy (P1) is settled — no additional proposal |
84 | | -beyond “keep merging net/rpc hardening”. |
85 | | - |
86 | | ---- |
87 | | - |
88 | | -### Out of scope for upstream (stay Nighthawk-layer) |
89 | | - |
90 | | -- UniFFI surface (`darkfi-mobile-ffi`) |
91 | | -- UnifOMR Param2 / LWD gRPC / decoy clue directory |
92 | | -- TLS pin policy for lightwalletd clients |
| 81 | +Track upstream net acceptor/connector and seed-address updates when bumping the |
| 82 | +client pin; no Nighthawk fork required. |
0 commit comments