Kagi has a mock toggle for "Save My Search History":
In order to facilitate this, Kagi should implement AES-256 encryption in GCM mode for fast, secure and authenticated encrypted search history entries. This would be client-side encrypted using a password of the user's choice, and the symmetric AES keypair would be stored in Kagi's client-side IndexedDB for fast access in subsequent lookups. Each entry should have its own initialization vector, which is sent to Kagi in plaintext to be retrieved later for decryption (an adversary with the IV would not threaten the ciphertext's security).
Currently, I believe Kagi hashes the user's password server-side, so this encrypted "search history vault" would be encrypted with another password chosen by the user for zero-knowledge purposes.
Should this be implemented, Kagi would ideally use the native window.crypto browser APIs to derive the AES keys using PBKDF2 to minimize bloat and compatibility issues. The salt should be stored in Kagi's database in plaintext for derivation at a later date. Similar to the IV, this value would not weaken the security of the keys.
