• NIP-XX (draft): Cloud-Account Key Backup
  • Motivation
  • Terminology
  • Derivation
    • Why scrypt cost is a security parameter, not just UX
  • Passphrase
  • Encryption
  • The backup event
  • Relays
  • Flows
    • Create / import (first backup)
    • Restore (returning user, any client)
  • Versioning
  • Security considerations
    • Inherent — disclose, cannot be fixed
    • Threat model
    • Privacy
  • Client requirements
  • Test vector
  • Prior art
  • Open questions

(This nip is implemented in mill and you can try it here: https://oslim.dev/nostr-mill)

§NIP-XX (draft): Cloud-Account Key Backup

draft optional

A low-assurance convenience mechanism for cross-client backup and recovery of
a Nostr secret key, anchored to a third-party cloud account (e.g. “Sign in with
Google”) and protected by a strong passphrase. A user who creates their key in
one client can sign into any other client that implements this NIP — same cloud
account, same passphrase — and recover the same key.

This is not custody and not a recovery service. It publishes a
passphrase-encrypted secret key to public relays. It exists to lower the
friction of starting on Nostr while preserving the option to take full
control later. It is not a replacement for the user independently saving
their nsec/ncryptsec, and clients MUST treat it as such (see
Client requirements). Read the
Security considerations before implementing —
several risks are inherent to the approach and can only be disclosed, not
engineered away.

§Motivation

Onboarding non-technical users to Nostr is hard because the private key is the
account and there is no reset. Several clients have independently built “sign in
with Google” flows that stash an encrypted key in the user’s cloud storage — but
each is a silo. Google Drive’s appDataFolder is scoped per OAuth client:
two different apps get separate, mutually invisible folders for the same user
(Google docs). So “log
in with Google” yields a different Nostr identity in every app.

This NIP uses the one shared, permissionless medium Nostr already has —
relays — as the rendezvous, at an address derived from the cloud account and
passphrase, so any implementing client can find and decrypt the backup. The
cloud account supplies a stable per-user salt and a familiar login; all
confidentiality comes from the passphrase, which is therefore required to be
strong.

§Terminology

• Provider: an OpenID Connect identity provider, lowercase ASCII (google).
• Account subject (sub): the provider’s stable identifier for the user. It
  MUST be globally stable across OAuth clients (Google satisfies this;
  Sign in with Apple does NOT
  — its sub is per-team — and cannot be used).
• Passphrase: the sole cryptographic protection. Because the ciphertext is
  public and permanent, the passphrase MUST meet a real entropy floor
  (see Passphrase).
• Backup identity: a keypair derived from the passphrase and account, used
  only to author and address the backup event — never the user’s real key.

§Derivation

All parameters are fixed constants so that independent clients reproduce the same
values. These constants are frozen for the lifetime of this format version;
changing any of them is a new kind, not a new value here (see
Versioning).

Let provider be lowercased and sub the raw subject string.

1. Salt (public, per-user separation; not secret). With US = the ASCII unit
   separator byte 0x1F:
   salt = SHA-256( UTF8("nostr-cloud-key-backup" ‖ US ‖ provider ‖ US ‖ sub) ) (32 bytes)

2. Root from the passphrase:
   root = scrypt( password = NFKC(passphrase) as UTF-8, salt, N = 2^18, r = 8, p = 1, dkLen = 32 ).

   • NFKC only. No trimming, no case-folding. The same normalized byte
     string MUST be used here and for the payload (step 4), or the address is
     found but decryption fails.

3. Backup identity key via HKDF (domain-separated):
   backup_seckey = HKDF-SHA256( ikm = root, salt = "" (empty), info = UTF8("nostr-cloud-key-backup/identity"), L = 32 ).
   Interpret as a secp256k1 scalar. If it is 0 or ≥ n (curve order),
   reject and re-derive with info suffixed by an incrementing counter byte
   (probability ≈ 2^-128; specified only for determinism).
   backup_pubkey = the BIP-340 x-only public key.

§Why scrypt cost is a security parameter, not just UX

backup_pubkey is published in cleartext and is a deterministic function of the
passphrase, so it is an offline passphrase-verification oracle: an attacker
guesses a passphrase, runs the derivation, and checks for a match — no ciphertext
needed. This caps the whole scheme’s strength at the addressing scrypt cost,
which — unlike the NIP-49 payload’s self-describing cost — cannot be raised
later without moving every user’s address. Two consequences the spec commits to:

• The addressing scrypt cost and the payload log_n are both fixed at 18
  and MUST be equal. Raising only the payload buys nothing (the attacker attacks
  the cheaper oracle). N = 2^18 (256 MiB) is chosen as the highest cost broadly
  feasible in browsers and on mobile; it is above the OWASP 2^17 password-storage
  minimum but is not by itself sufficient against a determined attacker.
• Therefore the passphrase entropy floor is the primary control, not the KDF
  cost. See below.

§Passphrase

For a permanent, public, offline-crackable blob, a short passphrase is
equivalent to no protection. At N = 2^18, a human-chosen 8-character passphrase
(~28 bits) falls to a rented GPU cluster in minutes; a 5-word diceware phrase
(~65 bits) does not. Therefore:

• Clients MUST enforce a floor of ≥ 70 bits of estimated entropy, using a
  real estimator (e.g. zxcvbn) or, preferably, by generating the passphrase
  for the user as ≥ 6 diceware-style words. A raw length check is NOT
  sufficient and MUST NOT be the only gate.
• Clients MUST warn that the encrypted key is published publicly and can
  never be un-published, so a weak passphrase means eventual compromise as
  hardware improves.
• A numeric PIN MUST NOT be used for this NIP (it is acceptable only for a
  provider-access-controlled local copy, which is out of scope here).

§Encryption

payload = nip49_encrypt( user_seckey, passphrase, log_n = 18, key_security_byte = 0x00 )

• NIP-49 ncryptsec
  is the payload so the encrypted key is a format the ecosystem already reads.
  It is self-describing (carries its own salt/nonce/log_n), so readers decrypt
  without pre-agreeing on log_n; verify by decrypting, not by byte comparison.
• key_security_byte = 0x00 (“handled insecurely”) is required: this key is
  encrypted and then published to public relays, which is exactly that
  condition. Importing clients should treat it as potentially exposed.

§The backup event

A parameterized replaceable event (NIP-01,
range 30000–39999), authored and signed by backup_seckey:

{
  "kind": 30049,                         // PROVISIONAL — pending assignment
  "pubkey": "<backup_pubkey>",
  "content": "ncryptsec1...",            // the NIP-49 payload
  "tags": [
    ["d", "primary"],                    // identity label; "primary" for the default
    ["n", "<monotonic counter>"]         // integer, increments each write
  ],
  "created_at": <unix seconds>,
  "sig": "<signed by backup_seckey>"
}

• Signing with the derived backup key, never the user’s identity key, is what
  keeps the event from publicly linking the cloud account to the user’s npub,
  and is what makes the address unforgeable: only a holder of the passphrase can
  write or overwrite it. Clients MUST NOT sign with the user’s real key.
• d label. The primary identity uses the literal "primary" — a non-empty
  value, because relay indexing of empty-string tag values is inconsistent.
  Additional identities under one account+passphrase use d = <hex npub of that identity>. Because all identities share one backup_pubkey, a client holding
  the passphrase enumerates them by querying {authors:[backup_pubkey], kinds:[30049]} with no #d filter.
• n counter. An integer that MUST increase on every write. Restoring
  clients reconcile on n (then created_at) to defeat clock-skew and
  stale-relay hazards (see Retrieval).
• No provider name, sub, or account data appears in the event.

§Relays

A rendezvous needs an agreed meeting point. Two facts make “just use the user’s
relays / the open network” unworkable, so this NIP pins a set:

1. backup_pubkey is a brand-new key with no profile, no NIP-05, no follows, no
   payment — the exact profile that modern write policies (WoT gates, paid
   allowlists, anti-spam plugins) reject. Generic public relays will refuse the
   write.
2. Two independent clients must publish and read at the same relays or they
   never meet.

Therefore:

• This NIP defines a pinned, versioned relay set (bound to the kind).
  Provisional for v1: ["wss://TBD-backup-relay-1", "wss://TBD-backup-relay-2"]
  — to be replaced with concrete, purpose-run relays before assignment. These
  relays accept kind:30049 from any pubkey but bound abuse structurally.
• Backup relays SHOULD enforce: one event per (pubkey, d) (addressable
  semantics already bound this), a per-pubkey quota, and either a small
  NIP-13 proof-of-work
  on the event or NIP-42
  AUTH as backup_pubkey, to price spam.
• Clients MUST connect over wss:// only, and MUST NOT publish or fetch
  the backup on the user’s identity relays or over a connection multiplexed with
  identity traffic (a relay could otherwise link backup_pubkey to the user’s
  npub). Use a separate connection; jitter timing after login.
• Generic public relays are not a viable transport for this NIP; do not rely
  on them.

§Flows

§Create / import (first backup)

1. Obtain user_seckey (generate, or import an existing key).
2. Authenticate with the provider; obtain sub. Prompt for a passphrase meeting
   the floor (generate one by default).
3. Derive backup_seckey; payload = nip49_encrypt(user_seckey, passphrase, 18, 0x00).
4. Build the kind-30049 event with n = 1, sign with backup_seckey, publish
   to the pinned relay set.
5. Before treating the backup as usable, the client MUST have offered the
   user their raw nsec/ncryptsec (see Client requirements).

§Restore (returning user, any client)

1. Authenticate; obtain sub. Prompt for the passphrase.
2. Derive backup_seckey → backup_pubkey.
3. Query all pinned relays: { "authors": ["<backup_pubkey>"], "kinds": [30049], "#d": ["<label>"] }.
4. Reconcile: collect all matching events across relays; select the one with
   the highest n, breaking ties by highest created_at, then lowest event id
   (NIP-01). A single relay’s response is not authoritative.
5. On a hit: user_seckey = nip49_decrypt(content, passphrase).
6. On no hit, the client MUST NOT silently create a new identity. It MUST
   distinguish (a) relay unreachable — a quorum of the pinned relays did not
   respond → surface “couldn’t verify, retry”, never new-key; from (b)
   authoritatively absent — quorum responded, no event → this may be a first-time
   user or a mistyped passphrase, which are indistinguishable, so the client
   MUST require an explicit, informed confirmation (“If you have used this Google
   account before, your passphrase is mistyped. Only continue to create a NEW
   account if this is genuinely your first time.”) before generating a key.

§Versioning

The derivation constants (salt string, scrypt params, HKDF
info) are frozen. Any incompatible change MUST use a new kind, so
distinct formats occupy distinct addresses and cannot silently clobber each
other. The n tag is a per-record counter, not a format version. Do not
put a format version inside the salt (it would fork every address on a bump).

§Security considerations

§Inherent — disclose, cannot be fixed

• Permanent public honeypot. Every backup is a passphrase-encrypted secret
  key, public and immutable on relays, scrapable into a corpus that is attacked
  offline forever, with compute only getting cheaper. Each crack is a full,
  irreversible account takeover plus retroactive DM decryption. NIP-49 explicitly
  warns against publishing ncryptsec to relays for this reason. This NIP accepts
  that risk in exchange for permissionless portability and pushes back only with
  a mandatory strong passphrase — which is unenforceable at the protocol level
  (one non-compliant client permanently poisons the corpus). Implementers who are
  unwilling to accept a public corpus should use a provider-access-controlled
  store instead (which sacrifices cross-client interop — the tradeoff is real and
  unavoidable).
• Irrevocable; rotation ≠ revocation. You cannot un-publish. Changing the
  passphrase orphans the old blob at its old address (still crackable under the
  old passphrase); rotating the key while keeping the passphrase reuses the
  address but old ciphertext may linger on non-compliant relays. A passphrase or
  key change MUST be treated as: the previously-published key is potentially
  compromised.
• Best-effort durability. Relays may drop events, especially from
  graphless pubkeys — exactly the returning/inactive user this feature targets.
  Clients MUST NOT claim “safely backed up”. See Client requirements.
• No recovery, no lockout. Forgotten passphrase = permanent loss. There is no
  rate-limiting (offline against the corpus; unmetered online against relays).
  “Sign in with Google” normally implies recoverability and lockout; here Google
  is only a lookup salt. This gap MUST be disclosed prominently.

§Threat model

• Google account compromise alone ≠ key compromise — but only because the
  passphrase is needed to both locate and decrypt. This is a real property, and it
  reduces to passphrase entropy: an attacker who learns the victim’s sub (which
  every app the user authorizes receives) can grind passphrases offline and
  precompute against the known per-user salt. State this property with the
  caveat; do not imply passphrase-derived addressing adds anti-targeting strength
  beyond entropy.
• Malicious client sees the passphrase, sub, and user_seckey in the clear
  — total compromise, inherent. This NIP additionally trains users to type a
  key-protecting passphrase into many clients (a larger phishing surface than an
  nsec, which users are told never to paste) and lets a client that captured the
  passphrase once overwrite the backup later. Clients SHOULD present a provenance
  story; users SHOULD be warned to enter the passphrase only into trusted clients.
• Malicious relay cannot forge signatures (so cannot overwrite/poison without
  the passphrase) but can omit or serve a stale version — mitigated by the n
  counter and cross-relay reconciliation, not eliminated.

§Privacy

The backup event is authored by the derived key, so it does not link the npub
to the provider account in content. That protection is defeated if backup and
identity traffic share a relay/connection — hence the relay isolation
requirements. d labels other than "primary" are hex npubs (opaque); do not
use human-meaningful labels, which leak in cleartext. Note that anyone querying
learns backup_pubkey ↔ their own IP; and a lone kind-30049 from a graphless
pubkey on the pinned relays self-identifies as a backup user.

§Client requirements

A conforming client:

• MUST offer the user their raw nsec/ncryptsec and confirm they have
  saved it, before presenting this backup as usable. This is the escape hatch
  that makes best-effort durability acceptable.
• MUST NOT describe this as durable, guaranteed, or “safely backed up”, and
  MUST NOT present Google as a recovery method.
• MUST NOT silently create a new identity on a failed restore (see
  Restore).
• MUST enforce the passphrase floor.
• SHOULD gate the feature as explicitly experimental while the kind and
  relay set are provisional, and plan for a format migration.

§Test vector

The backup-identity derivation is deterministic. The NIP-49 payload is not
(random salt/nonce) — verify it by decrypting.

provider      = "google"
sub           = "103547991597142817347"
passphrase    = "raven ledger cactus plume amber tunnel"     // illustrative; NOT a safe reuse

salt          = ab3b151969ba0b598b9f3caaf97d34710274a4a5590da48e8b777494c3c60199
root          = b2b42084c2ab00cf65a6caae9561b04137088dbd72c5d1639297034e46e1169d
backup_seckey = 50f4cf826d272bb1ed29b595453f1abc5d308405d2b90b828fe90379f89b4fdf
backup_pubkey = 759d333bfbe82b961dec0cf1971873d50b649ce3c8a2780aca97f6181725bf53   (x-only)

salt = SHA-256("nostr-cloud-key-backup" ‖ 0x1F ‖ "google" ‖ 0x1F ‖ "103547991597142817347");
root = scrypt(NFKC(passphrase), salt, N=2^18, r=8, p=1, 32);
backup_seckey = HKDF-SHA256(root, "", "nostr-cloud-key-backup/identity", 32);
backup_pubkey is the x-only schnorr public key of backup_seckey.

§Prior art

• NIP-49 — the
  ncryptsec payload format.
• NIP-199 proposal —
  username/password → derived, relay-stored encrypted key; closest prior pattern.
• NIP-46, nsec.app /
  noauth — remote-signer portability, a
  different (non-copy) trust model.

§Open questions

• Final kind assignment (30049 is provisional).
• The concrete pinned relay set, and who operates it (an open-ended,
  spam-resistant, free-hosting commitment).
• Whether a strong-secret second factor (a cloud-stored high-entropy value mixed
  into the KDF) should be offered for users who accept reduced portability, to
  remove reliance on human passphrase entropy.
• Multi-identity d-label canonicalization beyond “hex npub”.