[FEATURE REQUEST] API key encryption for AI

[wardenxyz]

Is your feature request related to a problem? Please describe.
I found that the AI API key in the plugin's data.json is stored locally in plaintext, can you add a feature that can encrypt the AI API key in the data.json

Describe the solution you'd like
Add a feature that encrypts AI API keys in data.json

Additional context

This is the copilot plugin's data.json file, where the copilot plugin encrypts the AI API key.

[chhoumann]

Hey @wardenxyz, thank you for raising this issue.

I agree that storing the key as plain text isn't optimal.
Of course, it would require a malicious plugin or that your vault files have been breached for it to be a problem, as the files are stored locally on your computer.

Nevertheless, I'd like to support encrypting the key. It is better that way.

A few notes.

Most of this depends on your risk profile, and that's obviously subjective & can vary on a per-user basis.

(1) Storing the encrypted API key and an encryption key isn't a relevant solution. That would be like leaving the key next to the locked door. It's a bit more effort, so your key won't get caught in large-scale scraping attacks (e.g. if you publish your vault on GitHub). But any motivated attacker will just be able to use the key to decrypt the key.

(2) With NoteTweet, I've built in encryption for the Twitter API keys. This uses a password to encrypt and decrypt the API key, but requires you enter it on every use. I don't think this is optimal either.

(3) While the Solution Copilot uses is nice, it is not a relevant solution for QuickAdd either. As can be seen here, it uses Electrons SafeStorage. This is platform-dependent. If you imagine a scenario where you load the plugin on your desktop device, add a key which is then encrypted with SafeStorage, and then you sync your changes via e.g. Obsidian Sync. Later, you open your vault on your mobile device. Now you can't use the AI Assistant on that device, because it cannot decrypt the API key.
QuickAdd is, and must be, available on any platform that Obsidian is.

(4) Another solution would be to simply use an algorithm to scramble and unscramble the key. This is about the same as the first solution I presented, where you store your encryption key along with the encrypted API keys. It reduces the risk of you from being victim of large scale attacks (usually they check for some pattern, e.g. sk-...), but any motivated attacker can easily undo the scrambling.

I think the best option is to leave it to the user. Adding an option to select between the viable options (1/4 and 2) seems optimal.

I'm open to input on this :)

[babeal]

@chhoumann for us Obsidian git users we at least need the key in a different file or the ability to read the key from environment variables. I'm having to exclude the data.json file from being checked in and unable to share the rest of the configuration across machines. Take a look at https://github.com/gavvvr/obsidian-imgur-plugin/blob/main/src/uploader/imgUploaderFactory.ts for a reasonable solution. The obsidian imgur plugin uses local storage to store the key for imagur after authentication and would be a good place for the api tokens. This way the key is not on disk, doesn't get backed up to obsidian data service, git, or icloud, and allows the sharing of the rest of the configuration.