SecureKeyStore

Backed by :settings's EncryptedSharedPreferences (MasterKey.AES256_GCM) store.

Where a BYOK provider API key persists between app launches.

Before this, every consumer of AiProviderConfig had to invent its own storage for the key a user pastes in — a plain SharedPreferences string, an in-memory field that forgets on restart, or nothing at all. SecureKeyStore gives every platform one real, at-rest-encrypted place for it (except wasmJs, see that actual's own caveat), so loadAiProviderConfig below can turn "what's saved" into an AiProviderConfig without the app owning any storage code of its own.

Android/iOS/JVM delegate to :settings's SecureSettingsFactory — EncryptedSharedPreferences, Keychain, and an AES-256-GCM-encrypted properties file respectively; that module already carries the crypto, this class only adds the provider-key vocabulary on top of its generic Settings.

Backed by :settings's KeychainSettings (service com.siddharth.kmp.secure).

Backed by :settings's AES-256-GCM-encrypted PropertiesSettings file (default ~/.kmp-toolkit-secure/secure_settings.enc, key file beside it, 0600).

Not secure. window.sessionStorage is plaintext, readable by any script running on the same page (including an XSS payload), and survives only the current tab's lifetime — closing the tab or opening a new one loses the key. This exists so a browser demo has somewhere to put a pasted key rather than re-prompting on every reload of the same tab; it is not the Keystore/ Keychain guarantee the other three platforms give.

// ponytail: no encryption-at-rest is possible in a browser without a server-side proxy holding // the real key — that's a different architecture, not a smaller version of this one. A real web // deployment should route cloud-provider calls through a backend that holds the key server-side // instead of shipping it to the client at all; upgrade path is "don't store a key in the browser", // not a better wasmJs actual.