[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 :)