これは、ご自身のプレセール用ウォレットへのアクセスを回復するための参考情報です。以下の各項目では、キーボードからキー導出関数に至るまでの過程で、正しく入力されたパスワードがソフトウェアによってどのように改変された可能性があるかを説明しています。いずれの場合も、基盤となる暗号技術の堅牢性は損なわれず、その安全性は維持されています。回復が成功するのは、実際に使用したパスワードを誤りなく再現できた場合のみです。

プレセールではパスワードがどのように暗号化されるのか

標準的なpyethsaletoolのリファレンス実装によると、その処理の流れは簡潔です。まず、パスワードをPBKDF2-HMAC-SHA256 を用いて 2,000 ラウンド（16 バイトに切り詰め）伸長して鍵を生成します。その鍵を用いてencseed を AES で復号し、その結果をハッシュ化して秘密鍵とし、そのアドレスをファイル内のethaddrと照合します。 正しいパスワードのみが、一致するアドレスを生成します。これがhashcatのモード16300です。

リカバリーページで繰り返し言及されているため、ここで3つの誤解を解いておきたい。まず、プレセールではscryptは使用されていない（これは後のV3キーストア、モード15700のものだ）。次に、反復回数は意図的に低く設定されており（2,000回）、これにより候補の探索が現実的な範囲に収まるようになっている。そして、パスワードにはランダムな値がソルトとして追加されるのではなく、パスワード自体がソルトとなる。 この最後の点が、入力にわずかな変更を加えるだけで、まったく異なる結果が得られる理由です。

根本的な原因：「作成」と「復号」の違い

エンコーディングおよび正規化の不具合

• Unicodeの正規化（NFC 対 NFD）— これが主な原因です。同じ文字でも、1つのコードポイント（NFC：é= U+00E9）として扱われる場合もあれば、文字と結合記号の組み合わせ（NFD：e+ U+0301）として扱われる場合もあります。macOSでは多くの場面でアプリケーションにNFD形式のテキストが渡されますが、LinuxやWindowsではNFC形式が使用されます。ある形式で作成されたテキストを別の形式で再入力すると、問題が発生します。4つの形式（NFC、NFD、NFKC、NFKD）すべてをテストすることで、問題の大部分を解決できます。
• UTF-8、Latin-1、UTF-16のバイトフォークの比較。ブラウザによるウムラウトの処理により、現代のツールが想定するUTF-8ではなく、Latin-1の低位バイトや生のUTF-16データが生成された可能性がある。
• 誤ったデコードによる「作成→保存」の処理経路から生じる二重エンコード／文字化け（例：ä が ä に変化する）。
• 転写。ユーザーが特定の文字をある方法で入力したものの、別の方法で思い出すことがあります。例えば、ドイツ語のä↔ae、ß↔ss、スウェーデン語のå↔aa、ノルウェー語のø↔o/oe、スペイン語のñ↔n などです。
• 同形文字の置換。キリル文字またはギリシャ文字のキーボードレイアウトが有効になっている場合、画面上ではラテン文字のように見える文字（a に対応するキリル文字の「а」など）は、実際にはまったく別のコードポイントになります。

macOSの入力に関する癖

• スマートクォートとスマートダッシュ。macOSでは、直線型の‘ “が波型の ‘’“” に、– が–— に自動的に置き換えられます。パスワードの外見は同じですが、バイトデータは異なります。
• デッドキーの「アクセントが固定される」現象。macOSでは、アクサンテギュ／ウムラウト／グラーヴのデッドキーの後に基本文字以外の文字が続くと、アクセント記号のみと文字が組み合わされて表示されます。例えば、「café」と入力した際、システムには「caf´e」として保存されていた可能性があります。
• アクセントメニューを長押しすることや、Caps Lock の操作性に関する問題。アクセント選択ツールや、Caps Lock がオンになったままの状態（一部の Mac では LED による表示が明確でない場合もある）により、ユーザーが意図していない大文字・小文字やアクセントのバリエーションが生じてしまう。

キーボード配列とロケール

• キーボード全体のレイアウトの再割り当て— 財団独自の調査で明らかになった、最も明白な単一の仕組みである。入力または転送の時点でOSの入力言語が英語以外だった場合、システムがキーの割り当てを変更したため、入力フィールドに反映された文字はキーキャップに表示されている文字とは異なっていた。
• QWERTZのy/zの入れ替わりや、作成時と再入力時のその他の配列の入れ替わり。
• Gethコンソールの非ASCII文字除去の問題。プレセール用ウォレットを後からGethにインポートした場合、一部のロケールにおいて、コードポイント127を超える文字がコンソール上で黙って削除されてしまうことがありました。その結果、特殊文字を含むパスワードが短縮されたり、空になったりすることがありました。（これは特定のパスに起因するバグであり、2014年のブラウザに起因するものではありません。）

エントリ、ハードウェア、およびファイル関連のバグ

• エントロピー段階の「うっかりミス」。プレセールでは、マウスの動きからシードエントロピーを収集していましたが、その手順中、パスワード入力欄が常に無効化されていたわけではありませんでした。マウスを動かしている最中に誤ってキーを押してしまうと、ユーザーが意図せず、しかも後で思い出せないような文字が追加されてしまう可能性がありました。これはプレセールのUXに特有の問題です。
• 貼り付けによる空白や改行（フィールドへの貼り付け時にキャプチャされた先頭または末尾のスペース、あるいは\n/\r\n）。
• キーが引っかかったり、跳ねたりして、意図しない文字が二重に入力されてしまう。
• 検証後の切り捨て／パスワードが空の場合— フォームのチェックに合格した後に編集されたフィールド。
• 再暗号化による差異。ウォレットをMyEtherWallet、Mist、またはGethにインポートすると、新しい暗号化パラメータを用いて再暗号化されます。そのため、あるコピーは正常に開ける一方で、別のコピーは開けない場合があり、また、インポート時に破損したコピーは永久に開けなくなる可能性があります。すべてのコピーを保存し、テストを行ってください。
• ダウンロードの中断／ファイルの完全性。通信速度の遅い回線でのダウンロードが中断されると、encseedファイルが不完全な状態になる可能性があります。そうなると、いかなるパスワードでもそのファイルを復号することはできません。手間をかける前に、ファイルの整合性を確認してください。

これが景気回復にとって何を意味するのか

実際的な結果は心強いものです。パスワードを覚えていれば、プレセール用ウォレットの復元は、主に1つの既知の文字列に対するこれらの変換をすべて試すだけで済み、何百万ものパスワードを当て当てる必要はありません。適切な順序としては：

• JSONファイルのすべてのコピーを探してください。プレセール時にメールで送られてきたはずです。過去のメール、ドライブ、クラウドバックアップ、古い端末などを確認してください。再暗号化されたコピーはそれぞれ異なるため、コピーが多ければ多いほど成功の可能性が高まります。
• 各ファイルに時間を費やす前に、そのファイルが有効かどうか（JSONとして有効か、encseedの長さが妥当か）を確認してください。
• パスワードマネージャーで、2014年のイーサリアムのクラウドセールを参照するエントリがないか確認してください。また、保存された値が後で編集されている可能性があるため、そのパスワードの履歴も確認してください。
• 最適な候補を、当時使用していたオペレーティングシステムやキーボードに合わせて、上記のエンコーディングや入力方法のバリエーションで試してみてください。

ファイル自体が消えてしまった場合は、誰にも手助けできませんが、もしまだ手元にあるのであれば、多くの所有者が考えているよりもはるかに回復の可能性は高いです。これが私たちの仕事です。イーサリアムのプレセール復旧ガイドをご覧ください。

出典

このカタログは、単なる意見ではなく、一次情報に基づいてまとめられたものです。具体的には、標準的なethereum/pyethsaletoolリファレンス実装およびプレセール用フロントエンド（ethereum/www）、イーサリアム財団自身による「パスワード誤入力」に関する調査（Mist のイシュー #3513 スレッドおよび関連レポート）、 go-ethereumにおけるエンコーディングおよびコンソール入力の処理に関するイシュー；hashcatのモード16300の実装；およびJohn the Ripperのethereum2john。上記の挙動については、これらおよびアカウントにロックアウトされた参加者たちの証言に記録されています。

よくある質問