質問

データの暗号化とデータの署名(RSAを使用)の違いは何ですか?

公開鍵と秘密鍵の役割を単純に逆にしますか?

たとえば、秘密鍵を使用してメッセージを生成し、自分だけが送信者になることができるようにします。メッセージを読むために公開鍵を使用したいのですが、誰が読むかは気にしません。特定の情報を暗号化して、ソフトウェアのプロダクトキーとして使用できるようにしたい。これらを生成できるのは自分だけであることにのみ気をつけています。公開鍵をソフトウェアに含めて、鍵の署名を解読/読み取りたいです。誰がキーのデータを読むことができるかは気にしません。それらを生成できる唯一の検証可能な人であるということだけを気にします。

このシナリオで署名は便利ですか?

役に立ちましたか?

解決

暗号化する場合、公開鍵を使用してメッセージを記述し、秘密鍵を使用してメッセージを読み取ります。

署名するとき、あなたの秘密鍵を使用してメッセージの署名を書き、彼らはあなたの公開鍵を使用してそれが本当にあなたのものかどうかを確認します。

  

自分だけが送信者になることができるように、秘密鍵を使用してメッセージを生成したい。

     

メッセージの読み取りに公開キーを使用したいのですが、誰がメッセージを読むかは気にしません

これは署名で、秘密鍵で行われます。

  

特定の情報を暗号化し、ソフトウェアのプロダクトキーとして使用できるようにしたい。

     

これらを生成できるのは私だけだということだけが気になります。

自分自身でそれを知る必要がある場合、これを行うためにキーを台無しにする必要はありません。ランダムデータを生成してデータベースに保存するだけです。

しかし、キーが本当にあなたのものであることを人々に知らせたい場合は、ランダムなデータを生成し、データベースに保存して、キーで署名する必要があります。

  

公開鍵をソフトウェアに含めて、鍵の署名を復号化/読み取りたい。

おそらく、VerisignやThawteなどの商用プロバイダーから公開キーの証明書を購入する必要があります。そうすれば、誰もあなたのソフトウェアを偽造して公開キーを自分のものに置き換えていないことを確認できます。

他のヒント

RSA暗号では、キーペアを生成するときに、公開キーと秘密キーのどちらを選択するかは完全に任意です。一方で暗号化する場合、もう一方で暗号化を解除できます-双方向で機能します。

したがって、受信者が private キーで復号化できるように、受信者の公開キーでメッセージを暗号化する方法を見るのは非常に簡単です。 p>

署名は、署名者が何らかの公開鍵と一致する秘密鍵を持っていることの証明です。これを行うには、その送信者の秘密キーでメッセージを暗号化し、暗号化されたバージョンをプレーンテキストバージョンと共に含めるだけで十分です。送信者を確認するには、暗号化されたバージョンを復号化し、プレーンテキストと同じであることを確認します。

もちろん、これはあなたのメッセージが秘密ではないことを意味します。公開鍵はよく知られているため、誰でも解読できます。しかし、そうするとき、彼らは暗号文の作成者が対応する秘密鍵を持っていることを証明しました。

ただし、これは送信のサイズを2倍にすることを意味します-平文と暗号文を一緒にします(署名の検証に興味のない人にメッセージを読んでもらいたい場合)。そのため、通常、署名はプレーンテキストのハッシュを作成して作成されます。偽のハッシュを作成できないことが重要であるため、SHA-2などの暗号化ハッシュアルゴリズムが使用されます。

だから:

  • 署名を生成するには、プレーンテキストからハッシュを作成し、秘密鍵で暗号化し、プレーンテキストと一緒に含めます。
  • 署名を検証するには、平文からハッシュを作成し、送信者の公開鍵で署名を復号化し、両方のハッシュが同じであることを確認します。

データに署名することは、他の誰も持っていない独自のワックススタンプを与えると考えてください。 完全性と否認防止を達成するために行われます。暗号化は他の誰もデータを見ることができません。これは、機密性を達成するために行われます。ウィキペディア http://en.wikipedia.org/wiki/Information_security#Key_concepts

署名は、秘密鍵を使用して署名されたメッセージのハッシュです。

署名は<!> quot; hash <!> quot;を生成しています。公開鍵で検証できる秘密鍵を使用します。テキストは平文で送信されます。

暗号化では、受信者の公開鍵を使用してデータを暗号化します。デコードは秘密鍵で行われます。

したがって、キーの使用は取り消されません(そうでない場合、プライベートキーはプライベートではなくなります!)

安全な通信を確立するには、2つの明確ではあるが密接に関連する問題があります

  1. データを暗号化して、許可された人だけが復号化して読み取ることができるようにします。
  2. 送信者のID /認証を確認します。

これらの問題はどちらも、公開鍵暗号を使用してエレガントに解決できます。

I。データの暗号化と復号化

アリスは、誰にも読めないはずのメッセージをボブに送信したいと考えています。

  • アリスはボブの公開鍵でメッセージを暗号化して送信します。
  • Bobはメッセージを受信し、秘密鍵を使用してメッセージを復号化します。
  

AがBにメッセージを送信する場合、AはPublicを使用する必要があることに注意してください   Bのキー(誰でも公開されている)およびパブリックではない   Aの秘密鍵もここにはありません。

だからあなたが私にメッセージを送りたいなら、あなたが私に提供する私の公開鍵を知って使用するべきであり、私だけが対応する秘密鍵にアクセスできるのでメッセージを解読することができます。

II。 送信者の身元を確認する(認証)

アリスは再びボブにメッセージを送信したいと考えています。データを暗号化する問題は、上記の方法を使用して解決されます。

しかし、アリスとボブの間に座って、ボクに「アリス」と自己紹介し、アリスが送信したメッセージを転送する代わりに、ボブに自分のメッセージを送信した場合はどうなりますか。アリスから送信された元のメッセージ(ボブの秘密鍵へのアクセスが必要)を解読して読むことはできませんが、それらの間の会話全体をハイジャックしています。

ボブが受信しているメッセージが実際にアリスによって送信されたことをボブが確認できる方法はありますか?

  • アリスは自分の秘密鍵でメッセージに署名して送信します。 (実際には、署名されるのはメッセージのハッシュです(例:SHA-256またはSHA-512)。
  • ボブはそれを受け取り、アリスの公開鍵を使用して検証します。アリスの公開鍵がメッセージを正常に検証したため、ボブはメッセージがアリスによって署名されたと結論付けることができます。

署名は、署名されたオブジェクトのソースまたは保証であることを示します。ただし、誰でもオブジェクトを読むことができます。

暗号化とは、対応する秘密鍵を持つ人のみがそれを読み取ることができることを意味しますが、署名しないと、暗号化されたオブジェクトの背後にいるという保証はありません。

公開鍵暗号で署名が使用される方法と理由を正確に説明しています。他人から提供された任意のメッセージに署名(または暗号化)することは非常に危険です-これにより、キーを侵害する可能性のあるアルゴリズムへの攻撃が可能になります。

シナリオでは、非対称暗号化の意味で暗号化しません。 <!> quot; encode <!> quot;と呼びたいです。

したがって、データを何らかのバイナリ表現にエンコードしてから、秘密鍵で署名します。公開鍵で署名を検証できない場合、署名されたデータは秘密鍵では生成されないことがわかります。 (<!> quot; verification <!> quot;署名されていないデータには意味がないことを意味します)

機能的には、公開鍵/秘密鍵暗号化を使用して、受信者のみがメッセージを読み取れるようにします。メッセージは暗号化され、受信者の公開鍵を使用して暗号化されます。

メッセージを作成し、転送中に変更されていないことを受信者に知らせるために使用する署名。メッセージの署名は、独自の秘密鍵を使用して行われます。

使用されるアルゴリズムに関しては、これは素数を含みます。より良い説明のためにグーグルで検索したい。

  

データの暗号化とデータの署名(RSAを使用)の違いは何ですか?

暗号化はメッセージ(<!> quot; some data <!> quot;)の機密性を保持しますが、署名は否認防止を提供します。つまり、署名したエンティティのみが署名できます。機能的な違いもあります。読んでください。

  

公開鍵と秘密鍵の役割を単純に逆にしますか?

絶対にそうではありません。署名と復号化(または同様に、検証と暗号化に同じ公開鍵)に同じ秘密鍵を使用することは、目的を混ぜてはいけないので嫌われています。これはそれほど数学的な問題ではありません(RSAは引き続き安全である必要があります)が、キー管理の問題です。署名キーの有効期間は短く、使用する前に保護を強化する必要があります。

同じメッセージに対して、署名には送信者の秘密鍵を使用し、暗号化には受信者の信頼された公開鍵を使用する必要があります。通常、sign-then-encryptが使用されます。そうでない場合、攻撃者は署名を自分の署名に置き換えることができます。同様に、復号化には受信者の秘密鍵を使用し、検証には送信者の信頼できる公開鍵を使用する必要があります。

さらに、署名生成では<!> quot;秘密鍵による暗号化<!> quot;を使用しないことを理解する必要があります。すべてのRSA操作はモジュラーべき乗法に基づいていますが、パディングスキームは署名生成に関してまったく異なります。さらに、公開鍵は、RSAのすべての実用的な使用において、RSA秘密鍵とはまったく異なる特性を持っています。

  

たとえば、自分だけが送信者になれるように、秘密鍵を使用してメッセージを生成したい。

これは否認防止プロパティであり、署名することで実現できます。

  

メッセージを読むために公開鍵を使用したいのですが、誰が読むかは気にしません。

公開鍵はすべての人に知られているとみなされるべきです。全員にメッセージを読んでもらいたい場合は、単に暗号化しないでください。

通常、署名はメッセージの内容には影響しません。メッセージは署名とは別のものと見なされます。公式には、このような署名は<!> quot;付録付きの署名<!> quot;ここで、付録はメッセージです。メッセージは署名よりも重要であると考えられているため、少し奇妙な名前ですが、そうです。少数の署名のみが(部分的な)メッセージ回復を提供します。それらはもはやあまり使用されておらず、一般に非推奨と見なされます。

CMSなどの署名プロトコルは、メッセージと署名の両方を含むコンテナ形式を展開する場合があることに注意してください。その場合、プレーンな.zipアーカイブからファイルを解凍するのと同じように、まずコンテナから暗号化されていないメッセージを取得する必要があります。そのため、メッセージは表示されない可能性があり、その場合は直接使用できません。

  

特定の情報を暗号化し、ソフトウェアのプロダクトキーとして使用できるようにしたい。これらを生成できるのは自分だけであることにだけ気を配ります。

暗号化は、機密性を実現するために使用されます。以前は、RSA署名の生成は<!> quot;秘密鍵による暗号化<!> quot;としばしば考えられていました。ただし、上記で説明したように操作がまったく異なるため、後の標準では必然的に暗号化と署名の生成が別々に試行されます。

  

公開鍵をソフトウェアに含めて、鍵の署名を復号化/読み取りたい。誰がキーのデータを読み取ることができるかは気にしません。それらを生成できる唯一の検証可能な人であるということだけを気にします。

はい、これは公開鍵で信頼を確立することと呼ばれます。ただし、プログラムコードの保護は、メッセージの保護とは大きく異なります。 codを実行できますe署名を行いますが、コードの外部で署名を確認するには何かが必要です 。これを提供するオペレーティングシステムがあります。

たとえば、Microsoft Authenticodeがあります。 iStoreやAndroidアプリストアなどのアプリケーションストアはコード署名を使用する場合と使用しない場合がありますが、アプリケーションが複製されていないか、少なくともストア内で複製されていないことをある程度保証します。結局のところ、暗号化が常に解決策とは限りません。

コードを複製/変更されないようにすることはまったく非常に難しく、そのようにすればDRM領域にしっかりといることになります。

  

このシナリオで署名は便利ですか?

はい、絶対に。公開鍵に信頼がある場合、メッセージがあなただけによって署名されていることを確認するのを確かに助けることができます。 アプリケーションコード/統合公開キーの認証に役立つ場合は、コードを実行する環境に完全に依存します。

質問者がソフトウェアライセンスのソリューションを使用することを意図していたという内容でこの質問に答える場合、要件は次のとおりです。

  1. サードパーティはアプリの逆コンパイルからライセンスキーを生成できません
  2. ソフトウェアキーのコンテンツは安全である必要はありません
  3. ソフトウェアキーは人間が読み取れない

デジタル署名は、キーを作成する生データを秘密キーで署名できるため、この問題を解決します。ただし、秘密キーは安全です。つまり、ソフトウェアのライセンスを誰も作成できません(これがポイントです)。

製品のソフトウェアロックを熟練者が削除できないようにすることはできません。したがって、リリースされた各バージョンをハッキングする必要がある場合。ただし、すべてのバージョンで共有できる製品の新しいキーを生成できるようにしたくはありません。

Python PyNaClのドキュメントには、目的に合った「デジタル署名」の例があります。 http://pynacl.readthedocs.org/en/latest/signing/

そしてNaClプロジェクトのCの例へ

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top