分析と広告のためのCookie
分析と広告のためにCookieを使っており、どちらもGoogleに送られます。拒否しても、目に見える動作は何も変わりません。プライバシーポリシーを読む
入力するか貼り付けると SHA-1 が得られます。16 進 40 文字です。署名と証明書の用途では 2017 年から壊れており、それでも日常的に必要になります。Git がオブジェクトの識別に使い、15 年触られていない連携が存在するからです。このページが計算するのはそのためであって、新しく作るものに勧められる選択だからではありません。
処理される場所
ファイルがないので、何もアップロードされません。計算はこのページの中で行われます。
順番待ちもアカウントもなし
お使いの機械の速さで答え、あなたが誰かを尋ねることはありません。
何度でも
回数は数えず、上限もありません。もう一度答えることに費用はかからないからです。
Google とアムステルダムの CWI が、同じ SHA-1 を持つ 2 つの異なる PDF を公開しました。並列で約 6,500 CPU 年を要しましたが、以来その価格は下がり続けています。今日では借りた計算資源で数百万円の規模です。
それが壊すのは、もう一方を作れる相手に対して「内容は変わっていない」と主張する能力です。署名、証明書、敵対者のいる完全性検証はここから外れます。壊れないのは原像に対する耐性で、値から元のテキストを復元する実用的な方法はいまもありません。
Git のオブジェクト識別子は SHA-1 です。これを変えることは、世界中のリポジトリ形式を一斉に変えることを意味します。SHA-256 への移行は仕様化され何年も前から進んでいますが、まさにその理由でゆっくりです。
そのあいだ Git は衝突検出を働かせ、既知の攻撃の模様を持つオブジェクトを拒みます。SHA-1 を安全にするわけではなく、実証された具体的な経路を塞ぐだけです。それで足りるかどうかは、あなたのリポジトリに誰かが内容を送り込めるかどうかに依存します。
SHA-1 を 2 回かける、ソルトと混ぜる、2 つのアルゴリズムを連結する。この種の案は定期的に現れます。どれも衝突の弱点を直しません。1 回目で一致した 2 つの入力は 2 回目でも一致します。2 回目は 1 回目の結果しか見ていないからです。
衝突耐性に効くのは別のアルゴリズムだけです。加えて、自作の構成は解析されておらず、部品より悪く振る舞うことすらあります。HMAC が「鍵とメッセージを繋げてハッシュ」ではなく注意深い設計になっているのには理由があります。
Git は識別子を短縮して表示します。伝統的には 7 文字です。28 ビット、約 2 億 6800 万通りで、誕生日のパラドックスにより、リポジトリのオブジェクトが 16,000 個ほどになると衝突が現実味を帯びます。中規模のプロジェクトは苦もなくそこに達します。
Git は必要に応じて短縮形を自動的に伸ばすので、大きなリポジトリでは 8 文字、9 文字、10 文字が見えます。短縮された識別子をスクリプトやチケットに写す人は知っておくべきです。目のための補助であって、安定した識別子ではありません。
SHA-1 は 160 ビットで、16 進 40 桁として書かれます。常に同じ長さです。MD5 の 32 文字、SHA-256 の 64 文字と並べれば、何を相手にしているのか一目で分かります。
古い資料が「ハッシュ」としか書いていないときに時間を節約する検査です。文字を数えれば、残りの文書を読むより先に答えが出て、別のアルゴリズムが生んだ値どうしを突き合わせずに済みます。
Git は各オブジェクトの前に、その種別と長さをゼロバイトで区切って置き、それを含めてハッシュします。したがってファイルの内容そのものの SHA-1 はオブジェクト識別子ではありません。しばしば不具合と取り違えられますが、不具合ではありません。
識別子を手で再現したい人は、まずそのヘッダーを組み立てる必要があります。このページは渡されたテキストを飾りなしでハッシュします。再現したいものが古い署名や、古い連携が期待する値であるときに必要なのはそちらです。
他の 2 つと同じです。Unix の道具はファイルの末尾に改行を書き、テキスト欄は書きません。だから単語ひとつのファイルの `sha1sum` は、ここに書いた同じ単語の SHA-1 と一致しません。
3 つのページで繰り返しているのは、これが 2 つの値が合わない最も多い理由であり、そのうち 1 ページに来た人がほかの 2 ページを読んでいることはまずないからです。結果全体を変える見えない 1 バイトは、毎回言う価値があります。
外部の何かが要求し、それを変えられないなら使ってください。Git のオブジェクト識別子、古いシステムとの連携、20 年前に定義されたファイル形式。その場合の代替は SHA-256 ではなく、相互運用しないことです。
新しいものには選ばないでください。今日どう署名するか、どう完全性を確かめるか、どう識別子を作るかを決めているのなら、SHA-256 が同じ仕事を負債なしでこなします。その負債を引き受けるに値する利点は、SHA-1 の側にひとつもありません。
この種の欄でハッシュされるものは、たいてい実データから来ます。行の値、連携の識別子、古いシステムと突き合わせなければならない内容。計算はページの中で行われるので、そのいずれも当方へ提供されません。
そして他の 2 つと同じく、入力の集合が限られているなら、個人データをハッシュしても匿名化にはなりません。SHA-1 では二重に効きます。速いぶん、候補を試すのが SHA-256 よりさらに安上がりだからです。
外部の何かが要求していて変えられない場合だけです。Git のオブジェクト識別子、古い連携、何十年も前に定義された形式。新しいものにはすべて SHA-256 を使ってください。
変更が世界中のリポジトリ形式を一斉に変えることを意味するからです。SHA-256 への移行は存在し、その理由でゆっくり進んでいます。そのあいだ Git は既知の攻撃の模様を持つオブジェクトを検出して拒みます。
いいえ。1 回目で衝突する 2 つの入力は 2 回目でも衝突します。2 回目は 1 回目の結果しか見ていないからです。衝突耐性に効くのは別のアルゴリズムだけです。
Git がオブジェクトの種別と長さをゼロバイトで区切って前に置き、それを含めてハッシュするからです。内容そのものの SHA-1 は識別子ではありません。
いいえ。このページの中で計算されます。あわせて、取りうる値の集合が小さければ、個人データをハッシュしても匿名化にはならないことを覚えておいてください。