[ソース1](https://github.com/getAlby/lightning-browser-extension/blob/ce1b4b0e48493ec82fbc4af46fa7237af3ce0d02/src/extension/background-script/state.ts#L98)
`decryptData` は AES。password は平文。
```
const password = get().password as string;
const privateKey = decryptData(account.nostrPrivateKey as string, password);
```
[ソース2](https://github.com/getAlby/lightning-browser-extension/blob/ce1b4b0e48493ec82fbc4af46fa7237af3ce0d02/src/extension/background-script/state.ts#L131)
pick で password を除外されるので `browser.storage.sync` には保存されていないはず。
```
saveToStorage: () => {
const current = get();
const data = {
...browserStorageDefaults,
...pick(current, browserStorageKeys),
};
return browser.storage.sync.set(data);
},
```
```
% cat ~/Library/Application\ Support/Google/Chrome/Default/Sync\ Extension\ Settings/iokeahhehimjnekafflcihljlcjccdbe/000003.log
password はなかった。
```
S. Ota
_@susumuota.github.io
npub1susu...0yu8
A programmer. An author of nostr-keyx. Interests: Reinforcement Learning, Natural Language Processing and Artificial General Intelligence.
NIP-07 の実装の件、Alby はどうなってるのかなと思って調べてみた。
- 秘密鍵は AES で暗号化した上で `browser.storage.sync` に保存
- AES のパスワードは平文だが `browser.storage.sync` には保存していない(おそらくメモリのみ)
- AES のパスワードは Chrome 起動毎に入力
という感じなのでちゃんと実装されているようです。Lightning 方面はさっぱりわかりませんが、NIP-07 に関しては Alby で良いかもしれないです。
詳細は次のポストで。
NIP-05 のこれか。
> Showing just the domain as an identifier
>
> Clients may treat the identifier _@domain as the "root" identifier, and choose to display it as just the <domain>. For example, if Bob owns bob.com, he may not want an identifier like bob@bob.com as that is redundant. Instead, Bob can use the identifier _@bob.com and expect Nostr clients to show and treat that as just bob.com for all purposes.
https://github.com/nostr-protocol/nips/blob/master/05.md#showing-just-the-domain-as-an-identifier
もう少しマシな方法としては、OS が管理しているキーチェーン(macOS なら`キーチェーンアクセス.app`)に秘密鍵を置いて、そこから情報をもらうという方法があります。
Chrome の Native Messaging という仕組みを使うと、外部コマンドと stdin/stdout で情報をやり取りできるようなので、外部コマンド内でキーチェーンにアクセスして秘密鍵を取得して、外部コマンド内で署名を行って、その結果を Chrome に返すという方法があります。これだと Chrome には秘密鍵を保存せずに済みます。
NativeMessagingを用いたnostr NIP-07実装例については #[0] さんがプロトタイプを作成されています。

GitHub
GitHub - gpsnmeajp/nip07ex
Contribute to gpsnmeajp/nip07ex development by creating an account on GitHub.
nostr-keyx では、共通鍵(AES-GCM)で暗号化しているので、共通鍵を手に入れないと復号化は難しいです。共通鍵はメモリに置いているのでディスクのバックアップでコピーされることはないと思います。
% cat 000003.log
encryptedPrivateKey
"[\"0FsY962F4VMLS4My1HyfKWLSm/Rl6fdTM5i/ni0Z251o4Fgbfx5njvj+x5XSHhniZlQsOuxAQSu6y4Zjl+8Xn3bM6+139ov0WYp+APMOu+Q=\",\"/11uhVPrZeKcCbl9vbYE6Q==\",\"m96A5oRooKs9Ut3/aeHkWA==\"]"
共通鍵はメモリに置いているので Chrome を終了すると共通鍵は消去されます。なので Chrome を起動する毎にパスワードを入力して共通鍵を生成しないといけないということと、もし Chrome のメモリを覗き見されて共通鍵がバレると秘密鍵は復号化されてしまいます。

GitHub
GitHub - susumuota/nostr-keyx: A NIP-07 browser extension that uses the OS's keychain or YubiKey to protect your private keys.
A NIP-07 browser extension that uses the OS's keychain or YubiKey to protect your private keys. - susumuota/nostr-keyx
NIP-07 Extension で秘密鍵が平文で保存されている件ですが、例えば nos2x では以下のファイルに秘密鍵が平文で保存されています(macOS の場合。Windows は %APPDATA%\Local\Google\Chrome 内にあるはず)。
% cd ~/Library/Application\ Support/Google/Chrome/Default/Local\ Extension\ Settings/kpgefcfmnafjgpblomihpgmejjdanjjp
% cat 000003.log
private_keyB"1ac49ce7f5eab04de1df56f9a3b1165d79a77237f76953f611a6d4c2c586ad3a"
秘密鍵が平文でファイルに保存されていると、ディスクのバックアップを取るとそのままコピーされてしまうので、現在使っているディスクだけでなくバックアップディスクの取り扱いにも注意が必要になります。
sat 送っていただいた方、ありがとうございます!
NIP-07 を実装したミニマルな Chrome 拡張機能 nostr-keyx に、秘密鍵をAES(共通鍵)で暗号化して保存する機能を追加しました。
秘密鍵を平文ではなく暗号化した状態で `chrome.storage.local`(ファイルシステム)に保存するので少し安全になるかもしれません。AES鍵(共通鍵)は `chrome.storage.session` (メモリ)に保存しています。
- 秘密鍵を暗号化するための AES-GCM 暗号を追加(共通鍵)
- 秘密鍵とパスワードを設定するためのポップアップメニューを追加

GitHub
GitHub - susumuota/nostr-keyx: A NIP-07 browser extension that uses the OS's keychain or YubiKey to protect your private keys.
A NIP-07 browser extension that uses the OS's keychain or YubiKey to protect your private keys. - susumuota/nostr-keyx
Bech32 (`npub...`) から hex に変換するスクリプトを追加しておきました。
https://github.com/susumuota/nostr-keyx/blob/main/bin/npub2hex.ts
npx ts-node-esm bin/npub2hex.ts "nsec..."
npx ts-node-esm bin/npub2hex.ts "npub..."
秘密鍵は環境変数に入れておいたほうがシェルのヒストリに残らないので少し安全かもしれません。
npx ts-node-esm bin/npub2hex.ts $NOSTR_NSEC
npx ts-node-esm bin/npub2hex.ts $NOSTR_NPUB
`chrome.storage.local` が安全かどうかとは別に、秘密鍵を平文であれこれやってるとちょっとしたケアレスミスでどこかに表示されたりするのが怖いです。コマンドヒストリやログなど。
ちなみに nos2x も平文で `browser.storage.local` に置いているので同じリスクがあります。
https://github.com/fiatjaf/nos2x/blob/844d3ea578c7be64c9b30fa33f2f865410699d26/extension/options.jsx#L259
やはり秘密鍵を平文で `chrome.storage.local` に置くのは危険なので、取り急ぎ共通鍵で暗号化して、共通鍵はメモリに載せておくことにしようかと思います。 `chrome.storage.session` というのが使えそう。
共通鍵は当面 Chrome を起動する度に UI から入力させるとかかな。macOS の Keychain が使えるといいんだけど...
Chrome for Developers
chrome.storage | API | Chrome for Developers
NIP-07 を実装したミニマルな Chrome 拡張機能を公開しました。この拡張機能を使うと Iris や Snort 等の Web ベースの Nostr クライアントに秘密鍵を渡す必要がなくなります(少し安全になる)。
- ソースは 200 行程度
- 読みやすい(はず)
- 最小限の依存関係 (@noble/secp256k1 と @scure/base のみ)

GitHub
GitHub - susumuota/nostr-keyx: A NIP-07 browser extension that uses the OS's keychain or YubiKey to protect your private keys.
A NIP-07 browser extension that uses the OS's keychain or YubiKey to protect your private keys. - susumuota/nostr-keyx
Hello!