【コンピュータネットワークノート8】アプリケーション層(5) HTTPS

HTTPSとは何ですか

HTTPS は HTTP の安全性の問題を解決します

HTTP送信プロセス全体のデータはクリアテキストであり、誰でもリンク内のリクエスト/レスポンスメッセージを傍受、変更、または偽造することができ、データは信頼できません。

① HTTPS は暗号化アルゴリズムを使用してメッセージを暗号化しており、ハッカーがメッセージを傍受しても理解できません。
② HTTPS はダイジェストアルゴリズムを使用してメッセージの整合性を確認します。ハッカーがメッセージを変更すると、HTTPS はそれを適時に検出し、適切に処理できます。
③ HTTPS はデジタル署名を使用して、ハッカーが要求メッセージや応答メッセージを偽造できないようにします。

HTTPS は HTTP + SSL/TLS で構成されます。つまり、SSLセキュアソケットレイヤ ( SSL上で実行されるHTTPプロトコル) がHTTPの下に追加されます。

ここに画像の説明を挿入します

SSLは、OSI 7 層ネットワークモデルの第 5 層 (セッション層) にある Secure Sockets Layer で、1994 年に Netscape によって発明され、v2 と v3 の 2 つのバージョンが一般的に使用されています。

IETF は1999 年にTLS ( Transport Layer Security )と名前を変更し、正式に標準化し、バージョン番号を 1.0 から再計算したため、TLS1.0 は実際には SSLv3.1 になります。

現在、TLS は3 つのバージョン、つまり 2006 年に 1.1、2008 年に 1.2、2018 年に 1.3 を開発しました。最も広く使用されている TLS は 1.2 です。

HTTPS のセキュリティは TLS の暗号化アルゴリズムに基づいているため、HTTPS を理解することは、TLS の背後にある暗号化アルゴリズムの原理を理解することと同じです。

データ暗号化アルゴリズム

古典的な暗号

古代の戦争では、手紙が傍受された場合に重要な情報が漏洩することを防ぐために、人々は手紙を暗号化するようになりました。

シフト暗号化

木の棒に布片を巻きつけて文字を暗号化する暗号スティックなど。

ここに画像の説明を挿入します

暗号化アルゴリズム: ラッピング後に書き込み
キー: スティックのサイズ

代替暗号化

ルールに従って別のテキストを使用して、暗号化の元のテキストを置き換えます。

たとえば、コードテーブル:
元の文字: ABCDEFGHIJKLMNOPQRSTUVWXYZ
パスワード文字: BCDEFGHIJKLMNOPQRSTUVWXYZA
元の文字: I love you
暗号化された文字: J mpwf zpv
解釈後: I love you

暗号化アルゴリズム: 置換テキスト
キー: 置換コード表

古典的な暗号化に対応するのが現代の暗号化であり、主に対称暗号化アルゴリズムと非対称暗号化アルゴリズムの 2 つのカテゴリが含まれます。

あらゆるバイナリデータを暗号化できる
非対称暗号化の出現により、暗号化の用途がさらに広がりました: デジタル署名

対称暗号化アルゴリズム

対称暗号化アルゴリズム:同じキー、異なる暗号化アルゴリズムと復号化アルゴリズムを使用し、平文を暗号化し、暗号文を復号化します。

ここに画像の説明を挿入します

TLSでは、 RC4、DES、3DES、AES、ChaCha20など、選択できる対称暗号化アルゴリズムが多数あります。最初の 3 つは安全ではないと考えられており、現在はAESとChaCha20のみが一般的に使用されています。

AESは「Advanced Encryption Standard 」(Advanced Encryption Standard) を意味し、キーの長さは128ビット (ビット)、192ビット (ビット)、または256ビット (ビット)です。セキュリティ強度が非常に高く、パフォーマンスも非常に優れており、一部のハードウェアが特別に最適化されるため、非常に人気があり、最も広く使用されている対称暗号化アルゴリズムです。
ChaCha20は Google によって設計されたもう 1 つの暗号化アルゴリズムです。キーの長さは256ビットに固定されています。純粋なソフトウェアの実行パフォーマンスはAESよりも優れています。かつてはモバイルクライアントで人気がありましたが、ARMv8以降、 AESハードウェア最適化も追加されました。明らかな利点はありませんが、依然として優れたアルゴリズムです。

対称暗号化の解読

画期的なアイデア:

1 つ以上の元のテキストと暗号文のペアを取得する
これらの原文と暗号文のペアで原文を暗号文に暗号化できる鍵を見つけ、その暗号文を元の文に復号化すると、クラックは成功します。

ひび割れ防止：

優れた対称暗号化アルゴリズムの基準は、クラッカーがブルートフォース手法よりも効果的なクラッキング手法 (ブルートフォースクラッキング手法) を見つけることができず、ブルートフォース手法のクラッキング時間が十分に長い (たとえば、数千年) ことです。）。

対称暗号化の欠点

対称暗号アルゴリズムが直面する最大の問題は、鍵を安全に相手に転送する方法であり、これを「鍵交換」と呼びます。

ここに画像の説明を挿入します

対称暗号化アルゴリズムの欠点は、キーが漏洩すると暗号化通信が失敗するため、安全でないネットワーク上ではキーを送信できないことです。

非対称暗号化アルゴリズム

非対称暗号化アルゴリズムは、同じ暗号化アルゴリズム + 2 つの異なる鍵 (非対称) を使用し、1 つは公開鍵(公開鍵)と呼ばれ、もう 1 つは秘密鍵(秘密鍵)と呼ばれ、公開鍵は誰でも公開できます。秘密キーは厳重に機密として保管する必要があります。

ここに画像の説明を挿入します

公開キーと秘密キーには、一方向であるという1 つの特徴があります。どちらも暗号化と復号化に使用できますが、公開キーが暗号化された後は、秘密キーでのみ復号化できます。逆に、秘密キーが暗号化された後は、秘密キーでのみ復号化できます。公開キーを使用してのみ復号化できます。

非対称暗号化通信を使用すると、信頼できないネットワーク上で双方の公開キーを相互に渡し、相手の公開キーを使用してメッセージを暗号化し、メッセージを送信する前に自分の秘密キーを使用してメッセージに署名することができます。信頼できないネットワーク信頼性の高いキーの配布とインターネット上の暗号化通信。

ここに画像の説明を挿入します

RSA

非対称暗号化アルゴリズムの設計は対称アルゴリズムよりもはるかに難しく、TLSにはDH、DSA、RSA、ECCなどの数種類しかありません。

RSAはおそらく最も有名なもので、非対称暗号化とほぼ同義であり、そのセキュリティは「整数分解」という数学的問題に基づいており、2 つの非常に大きな素数の積を鍵を生成する材料として使用します。公開鍵からの鍵秘密鍵を推定することは非常に困難です。

10 年前に推奨されていたRSAキーの長さは1024でしたが、コンピューターの計算能力の向上により、1024 はもはや安全ではなくなり、少なくとも2048ビットが必要であると一般に考えられています。

ECC

ECC (楕円曲線暗号) は、非対称暗号化の「新星」です。「楕円曲線離散対数」の数学的問題に基づいており、特定の曲線方程式と基点を使用して公開鍵と秘密鍵を生成します。サブアルゴリズムECDHEは鍵交換に使用され、ECDSA はデジタル署名に使用されます。

現在一般的に使用されている 2 つの曲線は、P-256 (secp256r1、OpenSSL では prime256v1 と呼ばれます) とx25519 です。P-256 は NIST (国立標準技術研究所) と NSA (国家安全保障局) によって推奨される曲線であり、x25519 が最も安全で最速の曲線と考えられています。

RSA と比較すると、ECC にはセキュリティの強度とパフォーマンスの点で明らかな利点があります。160 ビット ECC は 1024 ビット RSA に相当し、224 ビット ECC は 2048 ビット RSA に相当します。キーが短いため、対応する計算量、メモリ、帯域幅の消費量が少なくなり、暗号化と復号化のパフォーマンスが向上し、今日のモバイルインターネットにとって非常に魅力的です。

非対称暗号の解読

画期的なアイデア:

対称暗号との違いは、非対称暗号は公開鍵の入手が容易なため、独自の文と暗号文のペアを作成することが難しくないことです。
したがって、非対称暗号化の鍵は、公開鍵によって暗号化されたすべての暗号文を復号できる正しい秘密鍵を見つけることだけです。そのような秘密鍵を見つけることが成功したクラックです
非対称暗号化の特性により、公開鍵を介して秘密鍵を推測する方法は通常アイデア (RSA など) ですが、多くの場合、最良の方法は依然として網羅的方法です。ただし、対称暗号クラッキングとの違いは、対称暗号化がクラッキングとは、新しいキーが取得した元のテキストと暗号文のペアを暗号化および復号化できるかどうかを常に試行することです。非対称暗号化では、新しい秘密キーと公開キーが相互に復号可能かどうかを常に確認しようとします。

ひび割れ防止：

対称暗号化と同様に、非対称暗号化アルゴリズムが優れている基準は、クラッカーが網羅的手法よりも効果的なクラッキング手法を見つけられず、網羅的手法のクラッキング時間が十分に長いことです。

非対称暗号化の長所と短所

利点: セキュリティで保護されていないネットワーク上でキーを送信できる
短所: 計算が複雑なため、対称暗号化よりもパフォーマンスが大幅に低下します。

対称暗号化 VS 非対称暗号化

対称暗号化	非対称暗号化
鍵交換の問題があります	鍵交換の問題はありません
高速な計算速度	非対称暗号化アルゴリズムは複雑な数学的問題に基づいているため、動作速度は非常に遅く、 ECCですらAESよりも数桁劣ります。

非対称暗号のみを使用した場合、安全性は保証されるものの、通信速度が非常に遅くなり、実用性がゼロになってしまう。

TLS はハイブリッド暗号化を使用します

通信の開始時に、RSA や ECDHEなどの非対称アルゴリズムを使用して、まず鍵交換の問題を解決します。

ハイブリッド暗号化は、対称暗号化アルゴリズムのキー交換問題を解決し、セキュリティとパフォーマンスの両方を考慮します。

ここに画像の説明を挿入します

次に、乱数を使用して対称アルゴリズムで使用される「セッションキー」を生成し、公開キーを使用して暗号化します。セッションキーは短く、通常は 16 バイトまたは 32 バイトのみなので、多少遅くても問題ありません。

データの整合性

要約アルゴリズム

ハッカーはセッションキーを取得できず、暗号文を解読することもできませんが、盗聴によって十分な暗号文を収集し、それを Web サイトに送信する前に変更して再構成しようとすることはできます。完全性の保証がないため、サーバーは「すべてを受け入れる」ことしかできず、サーバーの応答を通じてさらなる手がかりを得ることができ、最終的には平文が解読されます。

整合性を実現する主な手段はダイジェストアルゴリズムです。

ダイジェストアルゴリズムは、このデータの数値を生成するのと同じように、任意の長さのデータを固定長の一意の「要約」文字列に「圧縮」できる特別な圧縮アルゴリズムとしてほぼ理解できます。

ここに画像の説明を挿入します

別の観点から見ると、ダイジェストアルゴリズムは特別な「一方向」暗号化アルゴリズムとも理解できます。アルゴリズムのみがあり、キーはありません。暗号化されたデータを復号することはできず、ダイジェストから元のテキストを推定することもできません。

MD5 (Message-Digest 5) とSHA-1 (Secure Hash Algorithm 1) は、最も一般的に使用される 2 つのダイジェストアルゴリズムであり、16 バイトおよび 20 バイト長のデジタルダイジェストを生成できます。ただし、これら 2 つのアルゴリズムのセキュリティ強度は比較的低く、安全性が十分ではないため、TLSでは使用が禁止されています。

現在、TLS は SHA-1 の後継である SHA-2 を使用することを推奨しています。

SHA-2は実際には一連のダイジェストアルゴリズムの総称であり、合計 6 種類あります。一般的に使用されるのはSHA224、SHA256、およびSHA384で、それぞれ 28 バイト、32 バイト、および 48 バイトのダイジェストを生成できますそれぞれ。

ここに画像の説明を挿入します

ハッカーが途中の句読点を 1 つでも変更すると、要約はまったく異なるものになり、Web サイトはメッセージが計算と比較によって改ざんされたことがわかり、信頼できなくなります。

デジタル署名

ハッカーは自分自身を Web サイトに偽装して情報を盗むことがあります。さらに、あなたになりすまして、支払い、送金、その他のメッセージを Web サイトに送信することもできますが、Web サイトにはあなたの身元を確認する方法がなく、お金が盗まれる可能性があります。

現実の本人認証の解決策は署名と押印であり、紙に署名または押印さえすれば、その書類が他人ではなく確かに自分が発行したものであることを証明できます。

TLS には、現実世界の署名や印鑑によく似ていて、私だけが保持でき、他の人は保持できないものはありますか? これを使って、デジタル世界で自分の身元を証明してください。

これが非対称暗号における「秘密鍵」であり、秘密鍵とダイジェストアルゴリズムを利用することで「デジタル署名」と「本人認証」を実現します。

デジタル署名は、ダイジェストアルゴリズムによって生成され、秘密キーで暗号化されたダイジェストの内容であり、コンテンツのこの部分は、ID 認証として元のダイジェストとともにメッセージに組み込まれます。

秘密鍵暗号化 - 公開鍵復号化

クライアントが暗号化されたメッセージをサーバーに送信するプロセス:

ここに画像の説明を挿入します

クライアント署名プロセス:

① 平文に対してダイジェストアルゴリズム（SHA-2）を実行し、ダイジェストを生成する
② クライアントの秘密鍵を使用して生成されたダイジェストを暗号化し、署名を生成しますダイジェストが短いため、ダイジェストのみが暗号化され、暗号化と復号が高速になります。
③ 原文にダイジェストと署名を付加し、セッション鍵を使用してメッセージを暗号化し、暗号文を生成して送信します。

ここに画像の説明を挿入します

サーバー側の検証署名プロセス:

① セッションキーを使用して暗号文を復号し、平文を取得します。
②平文に対してダイジェストアルゴリズム(SHA-2)を実行してダイジェストを生成し、メッセージ内のダイジェストを比較する
③ クライアント公開鍵を使用して署名を復号し、ダイジェストの平文を取得し、メッセージ内のダイジェストと比較します。

暗号化されたメッセージをサーバーからクライアントに送信するプロセスは上記と似ています。

サーバー側の署名プロセス:

① 平文に対してダイジェストアルゴリズム（SHA-2）を実行し、ダイジェストを生成する
② 生成されたダイジェストをサーバー秘密鍵を使用して暗号化し、署名を生成します
③ 原文にダイジェストと署名を付加し、セッション鍵を使用してメッセージを暗号化し、暗号文を生成して送信します。

クライアント検証署名プロセス:

① セッションキーを使用して暗号文を復号し、平文を取得します。
②平文に対してダイジェストアルゴリズム(SHA-2)を実行してダイジェストを生成し、メッセージ内のダイジェストを比較する
③ サーバー公開鍵を使用して署名を復号し、ダイジェストの平文を取得し、メッセージ内のダイジェストと比較します。

公開鍵の信頼性の問題

認知された信頼できるサードパーティを見つけて、それを「信頼の開始点と再帰の終了点」として機能させて、公開キーの信頼チェーンを構築します。

この「サードパーティ」は、私たちがよくCA (認証局)と呼ぶものです。オンラインの世界における公安局、教育省、公証人センターのようなもので、非常に信頼性が高く、各公開鍵に署名し、独自の評判を利用して公開鍵が偽造できず、信頼できるものであることを保証します。

CA デジタル証明書

CAの公開鍵の署名認証にも形式があり、単に公開鍵を所有者の ID に結び付けるだけでなく、シリアル番号、目的、発行者、有効期限なども含まれます。これらは A パッケージに入力されます。その後、公開鍵に関連付けられたさまざまな情報を完全に証明するために署名され、「デジタル証明書」（証明書）が形成されます。

DigiCert、VeriSign、Entrust、Let's Encrypt など、有名なCA は世界でも数社しかありませんが、発行する証明書はDV、OV、EV の3 種類に分かれており、その違いは認証の程度にあります。信頼性。

DVは最低であり、信頼できるのはドメイン名レベルでのみであり、誰がその背後にいるのかはわかりません。EVは最も高く、法律と監査によって厳密に検証されており、Web サイト所有者の身元を証明できます。

ここに画像の説明を挿入します

質問: CA はどのようにして信頼できることを証明しますか?

小規模なCA は、より大きなCAに署名と認証を許可できますが、チェーンの終端であるルート CA はそれ自体を証明することしかできません。これは「ルート証明書」と呼ばれます。それを信じなければなりません。そうしないと、証明書の信頼チェーン全体が前進しません。

この証明書システムでは、オペレーティングシステムとブラウザに主要なCAのルート証明書が組み込まれています。インターネットをサーフィンするとき、サーバーが証明書を送信している限り、証明書チェーンに従って証明書内の署名を検証できます。検証レイヤールート証明書が見つかるまでレイヤーごとに確認すると、その証明書が信頼できるものであり、内部の公開キーも信頼できるものであることを確認できます。

TLSハンドシェイクプロセス

ここに画像の説明を挿入します

ECDHEとRSAのTLSハンドシェイクプロセスの詳細については、https: //www.processon.com/view/link/62bed0685653bb214fa3d58fを参照してください。

要約する

HTTPS：

HTTPS = HTTP + SSL/TLS。これは、 SSL の上で実行される HTTP プロトコルです。HTTP層の下に、 SSL/TLS セキュアソケット層がトランスポート層の上に追加されます。これは、セッション層の 5 番目の層に位置します。 OSIモデル。

HTTPS のセキュリティは主に次の 3 つの側面に反映されます。

①暗号化アルゴリズムを使用してメッセージを暗号化し、ハッカーが傍受してもメッセージを理解することはできません。
② HTTPS はダイジェストアルゴリズムを使用してメッセージの整合性を確認します。ハッカーがメッセージを変更すると、HTTPS はそれを適時に検出し、適切に処理できます。
③ デジタル署名を使用して、ハッカーが要求メッセージや応答メッセージを偽造できないようにします。

対称暗号化アルゴリズム:

同じキーと異なる暗号化アルゴリズムと復号化アルゴリズムを使用して、平文の暗号化と暗号文の復号化を行います。
TLS の対称暗号化アルゴリズムには、RC4、DES、3DES、AES、ChaCha20などが含まれます。最初の 3 つは安全でないと考えられており、現在、AESとChaCha20のみが一般的に使用されています。
AES : Advanced Encryption Standard (Advanced Encryption Standard)。キーの長さは 128 ビット、192 ビット、または 256 ビットで、高いセキュリティ強度と優れたパフォーマンスを備えています。
ChaCha20 : Google によって設計された、256 ビットの固定キー長を持つ暗号化アルゴリズム。かつてはモバイルクライアントで人気がありましたが、ARMv8 以降に AES ハードウェア最適化が追加されたため、明らかな利点はなくなりましたが、それでも優れたアルゴリズムです。
対称暗号化が解決する必要がある問題は鍵交換ですが、その欠点は、安全でないネットワーク上では鍵を送信できないことです。

非対称暗号化アルゴリズム:

非対称暗号化では、公開キーと秘密キーという 2 つの異なる非対称キーを使用します。公開キーは誰でも使用できるように公開できますが、秘密キーは厳重に機密に保つ必要があります。
公開キーと秘密キーは一方向です。公開キーが暗号化された後は、秘密キーでのみ復号化できます。逆に、秘密キーが暗号化された後は、公開キーでのみ復号化できます。
より有名な非対称暗号化アルゴリズムはRSAです。その安全性は整数分解の数学的問題に基づいています。ECC はRSAよりも安全でパフォーマンスが高く、また数学的問題に基づいたアルゴリズムです。
非対称暗号化アルゴリズムは鍵交換問題を解決しますが、複雑な数学的問題に基づいており、演算速度が非常に遅いため、非対称暗号化だけを使用する場合は実用性がゼロです。

TLS はハイブリッド暗号化を使用します。

まず、非対称暗号化アルゴリズムを通じて鍵交換問題を解決し、乱数を使用して対称暗号化アルゴリズムで使用される「セッション鍵」を生成し、次に公開鍵を使用して「セッション鍵」を暗号化し、相手に送信します。「セッションキー」を使用すると、両者は「セッションキー」を使用して対称暗号化アルゴリズムに基づいて通信できます。

1) サーバーは公開鍵を発行します(非対称暗号化アルゴリズム)
2) クライアントは公開鍵を使用して生成された [セッション鍵] を暗号化します (非対称暗号化アルゴリズム)
3) サーバーは秘密鍵を使用してクライアントから送信されたメッセージを復号化します[セッションキー] (非対称暗号化アルゴリズム)
4) 次に、クライアントとサーバーは [セッションキー] を使用して通信します (対称暗号化アルゴリズム)

このようにして、鍵交換問題はまず非対称暗号化アルゴリズムで解決され、対称暗号化アルゴリズムを使用することでパフォーマンスが向上します。

データの整合性：

ダイジェストアルゴリズム:任意の長さのデータを固定長の一意のダイジェスト文字列に圧縮できる特殊な圧縮アルゴリズム、またはハッシュアルゴリズムとして理解できます。特殊なとしても理解できます一方向暗号化アルゴリズムダイジェストから元のテキストを推定することもできません。
一般的に使用されるダイジェストアルゴリズムにはMD5とSHA-1が含まれますが、これら 2 つは安全性が十分ではなく、 TLS によって無効にされています。現在推奨されているのはSHA-2です。SHA -2は一連のダイジェストアルゴリズムです。一般的に使用されるものは SHA224 、それぞれ SHA256、SHA384 28、32、48 バイトのダイジェストを生成可能。

デジタル署名：

① クライアントは秘密鍵を用いてダイジェストを暗号化して署名を生成し、身元認証として署名と暗号化ダイジェストをメッセージに組み込んで「セッションキー」を用いて暗号化送信します。
② サーバーはまず [セッションキー] を使用してメッセージを復号し、次にダイジェストアルゴリズムを実行し、ダイジェストを比較し、データの整合性を検証し、次にクライアントの公開キーを使用して署名を復号し、ダイジェストを比較し、識別を実行します。認証。

これは、クライアントが暗号化されたメッセージをサーバーに送信するプロセスであり、サーバーが暗号化されたメッセージをクライアントに送信するプロセスもこれと似ています。

公開鍵の信頼性の問題:

CA機関は、公開鍵の署名証明を実行し、デジタル証明書を生成します。オペレーティングシステムとブラウザには、主要な CA のルート証明書が組み込まれています。サーバーが証明書を送信する限り、証明書内の署名を検証し、次の手順を実行できます。ルート証明書が見つかるまで層ごとに検証すると、その証明書が信頼できるものであり、内部の公開鍵も信頼できるものであることが確認できます。

インタラクションのフローチャート:

ここに画像の説明を挿入します

他のコーディング関連コンテンツを補足します。

Base64

バイナリデータを 64 文字の文字列に変換するエンコードアルゴリズム。

アルゴリズム: 元のデータの 6 ビットごとに Base 64 インデックステーブルの文字に対応し、それを文字列 (1 文字あたり 8 ビット) に編成します。

Base64 インデックステーブル:

ここに画像の説明を挿入します

エンコード例：Base64エンコード「Man」

ここに画像の説明を挿入します

エンコーディングの例: Base64 の末尾パディング

ここに画像の説明を挿入します

Base64の目的

バイナリデータの保存および送信方法を拡張します (たとえば、データをテキストファイルに保存したり、チャットダイアログボックスやテキストメッセージを通じてバイナリデータを送信したり、URL に単純なバイナリデータを追加したりできます)。
通常の文字列は Base64 でエンコードされると肉眼では読めなくなるため、特定の条件下でのぞき見防止に使用できます (あまり一般的ではありません)。

Base64の欠点

独自の原理 (6 ビットから 8 ビット) により、 Base64 エンコードごとにデータが約 1/3 増加し、ストレージと送信のパフォーマンスに影響します。

「Base64 暗号化画像送信はより安全で効率的です」? ? ?

いいえ。まず、Base64 は暗号化ではありません。さらに、Base64 はデータを 1/3 増加させ、ネットワークパフォーマンスを低下させ、ユーザートラフィックのオーバーヘッドを増加させますが、これは不必要な手順です。
画像の Base64 エンコードは、画像をテキスト形式で送信する必要がある場合に便利です。それ以外に、画像の追加処理に Base64 を使用する必要はまったくありません。

バリアント: Base58

ビットコインで使用されるエンコード方式では、Base64 の数字の「0」、大文字の「O」、大文字の「I」、小文字の「l」、および「+」および「/」記号が削除されます。アドレスのビットコイン表現で使用されます。
Base58 Base64 への変更の主な目的は、ユーザーの利便性です。Base58 は、区別できない文字を削除することで「手動転写」に便利です。さらに、「+」と「/」記号を削除すると、ほとんどのソフトウェアでダブルクリック選択が便利になります。

圧縮と解凍

圧縮: ストレージ上の利点がさらに大きいエンコードアルゴリズムを使用してデータをエンコードします。
解凍: 圧縮データをデコードし、使いやすいように元の形式に復元します。

圧縮の目的は、データが占めるストレージ容量を削減することです。

粗雑なアルゴリズムの例

次のテキストコンテンツを圧縮します。

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

特定のアルゴリズムを使用して圧縮されたデータは次のとおりです。

compress:a:1062;b:10

注: 特定の圧縮シナリオが多数あるため、圧縮アルゴリズムはさらに複雑になります。上記は単なるプロトタイプアルゴリズムです。

圧縮エンコードですか？

はい。いわゆるエンコードとは、データをある形式から別の形式に変換することです。圧縮プロセスはエンコードプロセスに属し、伸長プロセスはデコードプロセスに属します。

一般的な圧縮アルゴリズム: DEFLATE、JPEG、MP3 など。

ハッシュ

任意のデータを指定されたサイズ範囲内のデータ (通常は 256 バイト以内など非常に小さい) に変換します。

機能: データから概要情報を抽出することに相当するため、主な用途はデジタル指紋です。

ハッシュの実際の使用法:

Java のメソッドなどの一意性の検証hashCode()。(hashCode メソッドを書き直すにはどうすればよいですか?equals()メソッド内で等しいかどうかを判断するために使用されるすべての変数をhashCode()に入れて、可能な限り衝突を避ける整数を生成します。)
データ完全性検証：インターネットからファイルをダウンロードした後、ファイルのハッシュ値（MD5、SHA1など）を比較することで、ダウンロードしたファイルが破損していないかを確認できます。ダウンロードされたファイルのハッシュ値が、ファイルプロバイダーによって提供されたハッシュ値と一致する場合、ダウンロードされたファイルが無傷であることが証明されます。
HashMap のようなクイック検索
プライバシー保護: 重要なデータを公開する必要がある場合、元のデータのセキュリティを確保するためにそのハッシュ値 (MD5 など) を公開することを選択できます。たとえば、Web サイトにログインするときに保存できるのはユーザーのパスワードのハッシュ値だけであり、各ログイン検証では、入力されたパスワードのハッシュ値とデータベースに保存されているハッシュ値を比較するだけで済みます。ユーザーのパスワードを知る必要はありません。このようにして、Web サイトのデータが盗まれた場合でも、ユーザーはパスワードを盗まれず、他の Web サイトのセキュリティが危険にさらされることはありません。