#530 derived the Nostr private key as SHA-256(sub || index). The Google
sub claim is not a secret — any app the user signs into with Google
gets the same sub value for that account/OAuth-client pair, and even
across clients it leaks via id_token introspection. That meant any
third party with the sub could regenerate the user's nsec offline. A
non-starter.
Reverts to the #528 design:
- GoogleSignInManager re-acquires the drive.appdata OAuth scope via
AuthorizationClient
- DriveBackupService reads/writes wisp_nsec_<npub>.bin blobs in the
per-app appDataFolder (other apps cannot see this folder)
- BackupCrypto already provided HMAC-SHA256(sub)-derived key + NIP-44
encryption; that file was not touched by #530 and is reused as-is
- GoogleAuthViewModel lists backups, surfaces a chooser with avatar +
display name fetched from kind-0 events, and decrypts only on
explicit Restore
- "Create new account" generates a fresh keypair, encrypts, and
uploads a new blob
The encryption key is still derived from sub, but the attack surface
is fundamentally different: an attacker now needs both the sub AND
read access to Wisp's appDataFolder in the user's Drive. The folder
is sandboxed per-app, so the only paths in are the user's own Google
account or a Wisp app compromise. That's the same trust boundary as
"can sign in to the user's Google account."
Splash button styling kept as-is (dark variant from #530 retained — a
cosmetic choice independent of the security model).
Reverts: 3d3c6e1, de88bdd
Barry Deen
977da039df