sha1を逆にすることは可能ですか？
Sha1を逆にすることは可能ですか？
Sha1を使用して単純な軽量システムを作成し、暗号化されていない接続で通信する小さな組み込みシステムを認証することを考えています。
「秘密キー」からの入力を使用してこのようなsha1を作成し、タイムスタンプを付けて、shaが常に変更されるようにするとします。
sha1("My Secret Key"+"a timestamp")
次に、このsha1を通信とサーバーに含めます。サーバーは同じ計算を実行できます。そして、うまくいけば、誰もが「秘密鍵」を理解できないでしょう。
しかし、これは本当に本当ですか？
あなたがこれが私がそれをした方法であると知っているなら、あなたは私がそこにタイムスタンプを入れたことを知っているでしょう、そしてあなたはsha1を見るでしょう。次に、これら2つを使用して、「秘密鍵」を把握できますか？
secret_key = bruteforce_sha1(sha1, timestamp)
ありがとうヨハン
Note1：何らかの方法でブルートフォースをかけることができると思いますが、実際にはどのくらいの作業になりますか？
注2：データを暗号化する予定はありません。送信者を知りたいだけです。
いいえ、SHA-1を元に戻すことはできません。これがまさにSecure Hash Algorithmと呼ばれる理由です。
ただし、間違いなくやるべきことは、ハッシュ計算に送信されるメッセージを含めることです。そうしないと、中間者がメッセージをインターセプトし、署名（送信者のキーとタイムスタンプのみを含む）を使用して偽のメッセージ（まだ有効な場合）に添付する可能性があります。
そして、おそらく新しいシステムにSHA-256を使用しているはずです。
sha("My Secret Key"+"a timestamp" + the whole message to be signed)
また、タイムスタンプをクリアで追加送信する必要があります。そうしないと、ダイジェストを検証する方法がありません（もっともらしいタイムスタンプをたくさん試す以外に）。
ブルートフォース攻撃が実行可能かどうかは、秘密鍵の長さに依存します。
システム全体のセキュリティは、この共有シークレットに依存します（送信者と受信者の両方が知る必要があるが、誰も知る必要がないため）。攻撃者はSHA-1を破ろうとするのではなく、キーを追跡しようとします（ただし、ブルートフォース推測またはデバイスから取得しようとします）。
問題は、実際に安全でないセッションで認証する方法です。
これを行う標準的な理由は、メッセージダイジェストを使用することです。 [〜＃〜] hmac [〜＃〜]。
メッセージのプレーンテキストと、そのメッセージの付随するハッシュを、あなたの秘密が混ざっている場所に送信します。
あなたの代わりに：
sha1("My Secret Key"+"a timestamp")
あなたが持っている：
msg,hmac("My Secret Key",sha(msg+msg_sequence_id))
メッセージシーケンスIDは、この「セッション」で交換したメッセージの数を両当事者が追跡するための単純なカウンターです。これにより、攻撃者が以前に表示されたメッセージを単に再生することを防ぎます。
これは、業界標準であり、メッセージが暗号化されているかどうかに関係なく、メッセージを認証する安全な方法です。
（これがハッシュをブルートできない理由です：）
ハッシュは一方向の関数です。つまり、多くの入力がすべて同じ出力を生成します。
秘密を知っていて、タイムスタンプの範囲について賢明な推測をすることができれば、それらすべてのタイムスタンプを反復処理し、ハッシュを計算して比較することができます。
もちろん、調査する範囲内の2つ以上のタイムスタンプが「衝突」する可能性があります。つまり、タイムスタンプは異なりますが、同じハッシュを生成します。
そのため、基本的に、確実にハッシュを反転させる方法はありません。
数学用語では、 全単射関数 のみが逆関数を持ちます。しかし、ハッシュ関数は injective ではなく、同じ出力値（衝突）をもたらす複数の入力値があるためです。
そのため、ハッシュ関数を元に戻すことはできません。しかし、あなたはそのような衝突を探すことができます。
編集
システム間の通信を認証したいので、 [〜＃〜] hmac [〜＃〜] を使用することをお勧めします。メッセージ認証コードを計算するこのコンストラクトでは、異なるハッシュ関数を使用できます。 SHA-1、SHA-256、または任意のハッシュ関数を使用できます。
特定のリクエストに対するレスポンスを認証するには、レスポンスを認証するソルトとして使用する必要があるリクエストとともに nonce を送信します。
SHA-1で暗号化された文字列を反転できないことは完全に真実ではありません。
1つを直接元に戻すことはできませんが、Rainbowテーブルで行うことができます。
ウィキペディア：レインボーテーブルは、通常はパスワードハッシュをクラックするための、暗号化ハッシュ関数を逆にするための事前計算されたテーブルです。通常、テーブルは、限られた文字セットで構成される特定の長さまでの平文パスワードの回復に使用されます。
基本的に、SHA-1は使用されるパスワードの強度と同じくらい安全です。ユーザーがあいまいな文字の組み合わせで長いパスワードを持っている場合、既存のRainbowテーブルに暗号化された文字列のキーがあることはほとんどありません。
ここで暗号化されたSHA-1文字列をテストできます： http://sha1.gromweb.com/
インターネット上には、GoogleがSHA1をリバースするために使用できる他のRainbowテーブルがあります。
MD5およびSHA-1に対する最良の攻撃は、任意の2つの任意のメッセージm1およびm2を見つけることでした。ここでh(m1) = h(m2)またはh(m1) = h(m2) and m1！= m2。m1を見つけるh(m1)はまだ計算上実行不可能です。
また、MAC（メッセージ認証コード）を使用しているため、攻撃者は1つの警告で秘密を知らずにメッセージを忘れることはできません-使用した一般的なMAC構造は長さ拡張攻撃を受けやすい-状況によっては偽造できるメッセージm2 | m3、h（secret、m2 | m3）与えられたm2、h（secret、m2）。これはタイムスタンプだけの問題ではありませんが、任意の長さのメッセージでMACを計算する場合の問題です。事前に保留するのではなく、タイムスタンプに秘密を追加することもできますが、一般に、SHA1ダイジェストでHMACを使用することをお勧めします（HMACは単なる構築であり、MD5またはSHAをダイジェストアルゴリズムとして使用できます）。
最後に、完全なリクエストではなく、タイムスタンプのみに署名しています。アクティブな攻撃者は、特にリプレイ保護がない場合にシステムを簡単に攻撃できます（リプレイ保護を使用しても、この欠陥は存在します）。たとえば、1つのメッセージからタイムスタンプ、HMAC（timestamp with secret）をキャプチャし、それを自分のメッセージで使用すると、サーバーはそれを受け入れます。
十分に長い秘密のメッセージ、HMAC（メッセージ）を送信するのに最適です。サーバーは、メッセージの整合性とクライアントの信頼性を保証できます。
脅威のシナリオに応じて、リプレイ保護を追加するか、メッセージ全体がリプレイされても問題が発生しないため、不要であることに注意できます。
ハッシュは入力に依存しており、同じ入力に対して同じ出力が得られます。
そのため、他の回答に加えて、次のことに留意してください。
パスワードでハッシュを開始する場合、Rainbowテーブルを事前計算し、妥当なタイムスタンプ値をすばやく追加することができます。これは、タイムスタンプで開始する場合ははるかに困難です。
したがって、sha1（ "My Secret Key" + "a timestamp"）を使用するのではなく、
sha1（ "a timestamp" + "My Secret Key"）を探します
受け入れられた答えは技術的に正しいが間違っていると思います。それは、ユースケースに当てはまります。つまり、公的/信頼できない媒体で改ざん証拠データを作成および送信します。
それは技術的にであるが、ブルートフォースまたはリバースするのが非常に難しいSHAハッシュ、プレーンテキスト「データ＆データのハッシュ+シークレット上記のように、インターネットを介して、十分なデータのサンプルをキャプチャした後、インテリジェントに秘密を取得することができます。考えてみてください-データは変更されますが、秘密キーは同じままです。データブロブアウト、基本的なクラッキングアルゴリズムを実行する新しいサンプルです。異なるデータとデータと秘密のハッシュを含む2つ以上のサンプルを使用すると、決定した秘密が正しく、誤検出ではないことを確認できます。
このシナリオは、Wifiクラッカーが十分なデータパケットをキャプチャした後にwifiパスワードをクラックする方法に似ています。十分なデータを収集した後、SHA1またはSHA256を技術的に元に戻していなくても、秘密キーを生成するのは簡単です。データが改ざんされていないことを確認したり、相手と通信している相手を確認したりする唯一の方法は、GPGなど（公開キーと秘密キー）を使用してデータBLOB全体を暗号化することです。ハッシュするデータは、本質的に常に安全ではありません。
実際には、そもそもハッシュする理由とアプリケーションの目的に本当に依存します。必要なセキュリティレベルがささいなものであるか、100％完全に信頼されたネットワーク内にいると言う場合、おそらくハッシュは実行可能なオプションです。ネットワーク上の誰も、または侵入者があなたのデータに興味を持っていないことを願っています。それ以外の場合、現時点で判断できる限り、他の確実に実行可能なオプションはキーベースの暗号化のみです。データBLOB全体を暗号化するか、単に署名することができます。
注：これは、イギリスが第二次世界大戦中にエニグマコードを解読し、連合国を支持する方法の1つでした。
これについて何か考えはありますか？
SHA1は、ハッシュから元のテキストが復元されないように設計されました。ただし、 SHA1データベースが存在する は、SHAハッシュによって一般的なパスワードを検索できます。