非対称暗号化の暗号化と署名の違いは何ですか？
データの暗号化とデータの署名（RSAを使用）の違いは何ですか？
公開鍵と秘密鍵の役割を単純に逆にしますか？
たとえば、秘密キーを使用してメッセージを生成したいので、自分だけが送信者になることができます。メッセージを読むために公開鍵を使用したいのですが、誰が読むかは気にしません。特定の情報を暗号化して、ソフトウェアのプロダクトキーとして使用できるようにしたい。これらを生成できるのは自分だけであることにのみ気をつけています。公開鍵をソフトウェアに含めて、鍵の署名を解読/読み取りたいです。キーのデータを誰が読み取れるかは気にしません。それらを生成できる唯一の検証可能なユーザーであるということだけを気にします。
このシナリオで署名は便利ですか？
暗号化するときは、メッセージを書き込むために公開鍵を使用し、メッセージを読み取るために秘密鍵を使用します。
署名するときは、あなたの秘密鍵を使用してメッセージの署名を記述し、あなたの公開鍵を使用してそれが本当にあなたのものかどうかを確認します。
私だけが送信者になれるように、秘密鍵を使用してメッセージを生成したい。
メッセージの読み取りに公開キーを使用したいのですが、誰がメッセージを読むかは気にしません
これはsigningであり、秘密鍵で行われます。
特定の情報を暗号化して、ソフトウェアのプロダクトキーとして使用できるようにしたい。
これらを生成できるのは自分だけであることにのみ気をつけています。
自分で知る必要があるだけなら、これを行うためにキーをいじる必要はありません。ランダムなデータを生成してデータベースに保存するだけです。
しかし、キーが本当にあなたのものであることを人々に知ってもらいたい場合は、ランダムなデータを生成し、データベースに保存して、キーで署名する必要があります。
公開鍵をソフトウェアに含めて、鍵の署名を復号化/読み取りたいと思います。
おそらく、VerisignやThawteなどの商用プロバイダーから公開鍵の証明書を購入する必要があります。そうすれば、誰もあなたのソフトウェアを偽造して公開鍵を自分のものに置き換えていないことを確認できます。
RSA暗号では、キーペアを生成するとき、公開キーと秘密キーのどちらを選択するかは完全に任意です。片方で暗号化すると、もう片方で復号化できます。両方向で機能します。
したがって、受信者がprivateキーでメッセージを復号化できるように、receiver's publicキーでメッセージを暗号化する方法を確認するのは非常に簡単です。
署名は、署名者が何らかの公開鍵と一致する秘密鍵を持っていることの証明です。これを行うには、その送信者のプライベートキーでメッセージを暗号化し、暗号化されたバージョンをプレーンテキストバージョンと一緒に含めるだけで十分です。送信者を確認するには、暗号化されたバージョンを復号化し、プレーンテキストと同じであることを確認します。
もちろん、これはあなたのメッセージが秘密ではないことを意味します。公開鍵はよく知られているため、誰でも解読できます。しかし、そうするとき、彼らは暗号文の作成者が対応する秘密鍵を持っていることを証明しました。
ただし、これは送信のサイズを2倍にすることを意味します-プレーンテキストと暗号文を一緒にします（署名の検証に興味のない人にメッセージを読んでもらいたい場合）。そのため、通常、プレーンテキストのhashを作成して署名を作成します。偽のハッシュを作成できないことが重要であるため、SHA-2などの暗号化ハッシュアルゴリズムが使用されます。
そう：
- 署名を生成するには、プレーンテキストからハッシュを作成し、プライベートキーで暗号化し、プレーンテキストと一緒に含めます。
- 署名を検証するには、プレーンテキストからハッシュを作成し、送信者の公開キーで署名を復号化し、両方のハッシュが同じであることを確認します。
データに署名することは、他の誰も持っていない独自のワックススタンプを与えると考えてください。 整合性と否認防止を達成するために行われます。暗号化は他の誰もデータを見ることができません。これは、機密性を達成するために行われます。ウィキペディアを参照してください http://en.wikipedia.org/wiki/Information_security#Key_concepts
署名は、秘密鍵を使用して署名されたメッセージのハッシュです。
署名とは、公開鍵で検証できる秘密鍵で「ハッシュ」を生成することです。テキストは平文で送信されます。
暗号化では、受信者の公開鍵を使用してデータを暗号化します。復号化は秘密鍵を使用して行われます。
そのため、キーの使用は取り消されません（そうでない場合、プライベートキーはプライベートではなくなります！）。
安全な通信を確立するには、2つの異なるが密接に関連する問題があります。
- データを暗号化して、許可された人だけが復号化して読み取ることができるようにします。
- 送信者のID /認証を確認します。
これらの問題は両方とも、公開鍵暗号を使用してエレガントに解決できます。
I。データの暗号化と復号化
アリスは、誰にも読めないメッセージをボブに送信したいと考えています。
- アリスはボブの公開鍵でメッセージを暗号化して送信します。
- ボブはメッセージを受信し、彼の秘密鍵を使用してそれを解読します。
AがBにメッセージを送信したい場合、AはBの公開キー（誰でも公開されている）を使用する必要があり、Aの公開キーも秘密キーもここに表示されないことに注意してください。
したがって、メッセージを私に送信したい場合は、私に提供する私の公開鍵を知って使用する必要があります。対応する秘密鍵にアクセスできるのは私だけなので、私だけがメッセージを解読できます。
II。 送信者のIDを確認する（認証）
アリスは再びボブにメッセージを送信したいと考えています。データを暗号化する問題は、上記の方法を使用して解決されます。
しかし、アリスとボブの間に座って、自分をボブに「アリス」として紹介し、アリスが送信したメッセージを転送する代わりに、ボブに自分のメッセージを送信した場合はどうなるでしょう。アリスが送信した元のメッセージ（ボブの秘密鍵へのアクセスが必要）を解読して読み取ることはできませんが、それらの間の会話全体を乗っ取ります。
ボブが、受信しているメッセージが実際にアリスによって送信されたことを確認できる方法はありますか？
- アリスは自分の秘密鍵でメッセージに署名して送信します。 （実際には、署名されるのはメッセージのハッシュです（例：SHA-256またはSHA-512）。）
- ボブはそれを受け取り、アリスの公開鍵を使用して検証します。アリスの公開鍵がメッセージを正常に検証したため、ボブはメッセージがアリスによって署名されたと結論付けることができます。
署名は、署名したオブジェクトのソースまたは保証であることを示します。ただし、誰でもオブジェクトを読み取ることができます。
暗号化とは、対応する秘密鍵を持つ人だけがそれを読み取ることができることを意味しますが、署名なしでは、暗号化されたオブジェクトの背後にいるという保証はありません。
公開鍵暗号で署名が使用される方法と理由を正確に説明しています。他の人が提供する任意のメッセージに署名（または暗号化）することは非常に危険です-これにより、キーを侵害する可能性のあるアルゴリズムへの攻撃が可能になります。
シナリオでは、非対称暗号化の意味で暗号化しません。むしろ「エンコード」と呼びます。
そのため、データを何らかのバイナリ表現にエンコードしてから、秘密鍵で署名します。公開鍵で署名を検証できない場合、署名されたデータは秘密鍵では生成されないことがわかります。 （「検証」は、署名されていないデータに意味がないことを意味します）
データの暗号化とデータの署名（RSAを使用）の違いは何ですか？
暗号化はメッセージ（「一部のデータ」）の機密性を保持し、署名は否認防止を提供します。つまり、署名したエンティティのみが署名できます。機能的な違いもあります。読む。
公開鍵と秘密鍵の役割を単純に逆にしますか？
絶対違う。署名と復号化（または同様に、検証と暗号化）に同じ公開鍵を使用することは、目的を混ぜてはならないため、眉をひそめられます。これは数学的な問題ではありません（RSAはまだ安全である必要があります）が、キー管理の問題です。署名キーの有効期間は短く、使用する前に保護を強化する必要があります。
同じメッセージに対して、署名には送信者の秘密鍵を使用し、暗号化には受信者の信頼された公開鍵を使用する必要があります。通常、sign-then-encryptが使用されます。そうでない場合、攻撃者は署名を自分の署名に置き換えることができます。同様に、復号化には受信者の秘密鍵を使用し、検証には送信者のtrusted公開鍵を使用する必要があります。
さらに、署名生成では「秘密鍵による暗号化」が使用されないことを理解する必要があります。すべてのRSA操作はモジュラーべき乗法に基づいていますが、パディングスキームは署名生成に関してまったく異なります。さらに、公開鍵は、RSAのすべての実用的な使用において、RSA秘密鍵とはまったく異なる特性を持っています。
たとえば、秘密キーを使用してメッセージを生成したいので、自分だけが送信者になることができます。
これは否認防止性のプロパティであり、署名することで実現できます。
メッセージを読むために公開鍵を使用したいのですが、誰が読むかは気にしません。
公開鍵はすべての人に知られていると見なされるべきです。全員にメッセージを読んでもらいたい場合は、単に暗号化しないでください。
通常、署名はメッセージの内容には影響しません。メッセージは署名とは別のものと見なされます。公式には、このような署名は、付録がメッセージである「付録付き署名」として知られています。メッセージは署名よりも重要であると考えられているため、少し奇妙な名前ですが、そうです。少数の署名のみが（部分的な）メッセージ回復を提供します。それらはもはやあまり使用されておらず、一般に非推奨と見なされています。
CMSなどの署名プロトコルは、メッセージと署名の両方を含むコンテナ形式を展開する場合があることに注意してください。その場合、プレーンな.Zipアーカイブからファイルを解凍するのと同じように、最初にコンテナから暗号化されていないメッセージを取得する必要があります。そのため、メッセージは表示されない可能性があり、その場合は直接使用できません。
特定の情報を暗号化して、ソフトウェアのプロダクトキーとして使用できるようにしたい。これらを生成できるのは自分だけであることにのみ気をつけています。
暗号化は、機密性を実現するために使用されます。過去において、RSA署名の生成は「秘密鍵による暗号化」としばしば考えられていました。ただし、上記で説明したように、操作はまったく異なり、後の標準では、暗号化と署名の生成を必死に試みます。
公開鍵をソフトウェアに含めて、鍵の署名を復号化/読み取りたいと思います。誰がキーのデータを読むことができるかは気にしません。私がそれらを生成できる唯一の検証可能な人であるということだけを気にします。
はい、これは公開鍵でtrustを確立することと呼ばれます。ただし、プログラムコードの保護は、メッセージの保護とは大きく異なります。 コード署名を実行できますが、署名を確認するために何かが必要になりますコード外。これを提供するオペレーティングシステムがあります。
たとえば、Microsoft Authenticodeがあります。 iStoreやAndroidアプリストアなどのアプリケーションストアは、コード署名を使用する場合と使用しない場合がありますが、アプリケーションがクローン化されていないか、少なくともストア内でクローン化されていないことをある程度保証します。結局のところ、暗号化が常に解決策とは限りません。
コードが複製/変更されないようにするまったくは非常に難しく、そのように行けばDRM領域にしっかりといることになります。
このシナリオでは署名は便利ですか？
そのとおり。公開鍵に信頼がある場合、メッセージがあなただけによって署名されていることを確認するのを確かに助けることができます。 アプリケーションコード/統合公開キーの認証に役立つ場合は、コードを実行する予定の環境に完全に依存します。
機能的には、公開/秘密キー暗号化を使用して、受信者のみがメッセージを読み取れるようにします。メッセージは暗号化され、受信者の公開鍵を使用して暗号化されます。
署名を使用して、メッセージを作成し、転送中に変更されていないことを受信者に知らせるために使用します。メッセージの署名は、独自の秘密鍵を使用して行われます。
使用されるアルゴリズムに関して：これは素数を含みます。より良い説明のためにグーグルで検索をしたいと思います。
質問者の意図がソフトウェアライセンスのソリューションを使用することであったという内容でこの質問に答える場合、要件は次のとおりです。
- サードパーティは、アプリの逆コンパイルからライセンスキーを生成できません
- ソフトウェアキーの内容は安全である必要はありません
- ソフトウェアキーは人間が読み取れない
キーを作成する生データは秘密キーで署名できるため、デジタル署名はこの問題を解決します。しかし、秘密鍵は安全であるため、だれもソフトウェアのライセンスを作成できません（これがポイントです）。
熟練者が製品のソフトウェアロックを解除するのを防ぐことはできないことを忘れないでください。したがって、リリースされた各バージョンをハッキングする必要がある場合。ただし、すべてのバージョンで共有できる製品の新しいキーを生成できるようにすることは望ましくありません。
Python PyNaClのドキュメントには、目的に合った「デジタル署名」の例があります。 http://pynacl.readthedocs.org/en/latest/signing/
そして、NaClプロジェクトのCの例