blockcore も 128 bit のへぼい鍵を生成してた。
snort が 128 bit エントロピーの鍵を使ってたので PR 出したんだけど、 nostr-tools の実装が 128 bit なのが元凶の気がしてきた。
Discussion
BIPをよく理解していないので教えていただきたいのですが、@scure/bip39 での規定値を256に変更することは出来ないのでしょうか、もし出来るのであればそのようにした方が良いかと思っています
@noble/secp256k1 が32byteの秘密鍵を生成するにも関わらず、ニーモニック生成時に16byteの強度では不十分である という知識はあります
自分もその理解です。 128 bit 総当りすれば解けちゃう鍵が生成されているという認識です。
とりあえず、後で scrapbox にまとめておきます。
取り急ぎ、bip39 では既定値については何も書いてないですが、bip32 では 256 bit が勧告 (advised) されています。なので bip39 の既定値は 256 bit であるべきという論拠はありそうです。
自分の理解では、bip32 の場合は、マスターシード(=ニーモニック)から階層的に鍵を導出していくのでシードの強度にそれほど敏感になる必要はないのかもしれませんが、NIP-06 はマスターシードからNostr 秘密鍵を決定論的に導出しているので、マスターシードの強度がそのままに秘密鍵に反映してしまうのではと考えています。
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#master-key-generation
あ、勘違いしていた。BIP-39 を修正する話じゃなくて @scure の実装の既定値の話ですね。多分できると思いますが、今まで 128 bit 前提で実装してしているアプリがどれくらい困るかによると思います。
12 word 前提で UI を作ってたら急に 24 word になって UI がおかしくなるとかはありそうです。
> @scure の実装の既定値の話
それです、説明不足ですみません🙇 BIP-39には128-256bitとあり、セキュリティ面でも規定値は256にしておくのが良い筈ですが、それを踏まえても128を強く推奨する意見があればrejectされるなぁと思いまして
あー確かにスタイル崩れは起こりそうですね…12文字前提でバリデーション掛けてるケースもありそう
nostr側の問題であるならnostr-toolsの実装も勿論ですが、NIP-06に明記した方が良いかもしれないと思いました
@scure の既定値を変えてもらう話はビットコインの実装の話なのであまり筋がよくないと思いますが、NIP-06 で明記するよう求めるのは良いかもしれません。
主張点は先程の BIP-32 で 256 が advised されている件と、Snort で PR が通っているというのが使えると思います。
自分の疑問は、「128 bit のシードを使ったとしてもマスターキーから derive すれば 256 bit と同程度に安全になる」という主張があるのかどうか、です。(例えば derive が重い処理なのでそう簡単に計算出来るわけじゃない、とか)
その点は僕も疑問でした。BlockcoreはBitcoin系の開発者が多くいる筈ですので、とりあえずblockcore-notesに相談がてらPRを出し、その反応を見てnostr-toolsとNIP-06に変更を持ちかけるのが良さそうです