ウィキペディア（およびその他の情報源）によると、非対称暗号化は常に次のように機能します。
ただし、パーティAが自分のデータを暗号化できるようにしたくはなく、データを復号化できるようにしたいだけです。非対称ロジックを使用すると、次のようになります。
これをある種のライセンス生成/チェックに使用します。クライアントはライセンスを生成しない場合がありますが、ライセンスファイルはクライアント側で読み取り可能である必要があります。
これはまだ非対称暗号化ですか、それとも別の方法を検討する必要がありますか？
パーティAが公開鍵を使用してメッセージを暗号化できることはまったく問題ありません。
それらを（秘密鍵で）復号化できるのはあなただけです。そうする理由がないので、アプリケーションに埋め込まれた公開鍵で何かを暗号化しても害はありません。ユーザーが復号化できないため、役に立たないデータがたくさんあるだけです。
ライセンスについては、秘密鍵を使用してライセンスファイルを暗号化する（または署名する-それで十分です。そうすれば、ユーザーはライセンスファイルの制限などを読み取ることができますが、変更することはできません） 。次に、アプリケーションは、埋め込まれた公開鍵を使用してファイルを復号化します（または署名を検証します）。
公開鍵を抽出してカスタムライセンスファイルに署名するユーザーは、秘密鍵がアプリケーションに埋め込まれている場合にのみ機能するため、使用できませんでした（公開鍵で暗号化されたものを復号化するために必要な鍵であるため）。
ただし、彼はあなたの公開鍵をカスタム鍵（彼も秘密鍵を持っている場合）に置き換えてから、彼の秘密鍵を使用して自分のライセンスファイルに署名/暗号化することができます。ただし、これは暗号化の問題ではありません。埋め込まれた公開鍵の置き換えを困難にするために、クラック防止/変更対策を追加する必要があります。たとえば、いくつかのチェックサム検証を行うことができます。
秘密鍵を金庫に入れて、公開鍵を公開します。ライセンスを作成するときは、秘密鍵で暗号化します。クライアントは公開鍵でのみ復号化できます。
ライセンスをクライアントに制限する場合は、クライアントにキーペアを生成するように依頼し、公開キーを送信します。次に、公開鍵を使用してライセンスを暗号化し、秘密鍵を使用して署名（または再度暗号化）します。
クライアントがライセンスを受け取ったら、1。送信したライセンスの署名を検証（または復号化）する必要があります。2。検証済みのデータを自分の秘密鍵を使用して復号化します。
これにより、1。ライセンスを送信できるのはあなただけであり、2。ライセンスを復号化できるのは彼らだけです。
一般的に行うことは、自分の側でライセンスを生成し、それを秘密鍵で暗号化することです。次に、クライアントは公開鍵を使用してそれを読み取ることができます。これは（非常に大まかに言えば）証明書スキーム（HTTPSを使用した安全なオンラインブラウジングで使用されるものなど）がどのように機能するかです。そして、はい、それでも絶対に非対称暗号化としてカウントされます。
あなたが言っていることに基づいて、非対称暗号化はまだあなたが望むものであり、それはあなたがそれについて考えることに慣れているのとは異なる方法で行われる必要があるだけです。
Aのキーペアを生成するとします。ペアの半分を送信します。実際には問題ではありませんが、プライベートハーフと呼びます。パブリックハーフを使用して暗号化し、Aに送信します。その後、Aはそれを復号化できます。ただし、Aは、A公開鍵から送信されたように見えるメッセージを暗号化できません。これは、A公開鍵には秘密鍵の半分しかなく、鍵の半分しかない場合は残りの半分を把握できないためです。 、あなたがどちらの半分を持っていても。したがって、Aは、秘密として保持している公開鍵によって復号化できるメッセージのみを暗号化できます。
もちろん、他のポスターがすでに述べているように、このプロトコルを設定するためのより良い方法があります。非対称暗号化の詳細を理解し、キーハーフと呼ばれるものと、通常の使用方法を確認したら、これが実際には問題にならない理由を説明しようとしています。
Rhinoのライセンスを見ることができます：http：//hibernatingrhinos.com/open-source/rhino-licensing/introduction
他の回答はすでにそれを行う方法を述べています...ここでは、Bのキーが秘密になっていることに依存している場合、質問で説明したスキームは安全ではないことに注意してください（少なくともRSAでは） 。
RSAの場合、公開鍵と秘密鍵は実際には非対称であり、単純にそれらを交換して同じセキュリティプロパティを期待することはできません。
他の非対称暗号システムにも同様の警告があると思います。常に、指定され、証明されている場合にのみ使用してください。
この場合、2つのキーペアを組み合わせることになります。Bはメッセージに署名/検証するため（メッセージがBによって送信されたことを確認するため）、Aはメッセージを暗号化/復号化するため（Aだけがメッセージを読み取れるようにするため）です。 。
はい。RSAを使用して、Diffie-Hellmanのような交換を行うことができます。これは、関連する1つのペアのキーが通勤するだけでなく、異なるキーペアのキーも通勤できるためです。
alice -> bob: alice.pub
bob -> alice: bob.pub
alice: r = random.secret()
alice -> bob: ( r * (alice.priv * bob.pub) )
bob: r = ( (r * (alice.priv * bob.pub)) * (bob.priv * alice.pub) )
ここで奇妙なことをしたことに注意してください。1つの操作で異なるキーペアからのRSA操作を混合しました。括弧内のオブジェクトは事実上新しい仮想RSAキーであり、これらのキーのいずれも公開されていません。そのRSAキーを直接作成しようとすると、アリスまたはボブのいずれかがペアの両方のキーを認識します。このキーペアは事実上、一方の端に書き込む秘密鍵であり、もう一方の側だけがそれを復号化できますが、自分で書いたものを復号化することはできず、他の誰もメッセージをもう一方の側に暗号化することはできません。
このようなキーペアを組み合わせる人を見たことがありませんが、コードを記述してこれをテストしました。通常、メッセージに秘密鍵を適用するのは「署名」のためであるため、私は何か変わったことをしなければなりませんでした。ただし、署名は通常、秘密をハッシュし、秘密鍵をそのハッシュに適用します。私たちが望まない何か。したがって、私のコードでは、RSAコンポーネント（D、E、N）を任意の精度の数値に抽出すると、次のようになります。つまり、復号化、暗号化、モジュラス...
wormholeSend(me,you,msg) =
(((me ^ {me_D}) \% me_N) ^ {you_E}) \% you_N
少し注意が必要なのは、E（暗号化指数）は実際には予測可能な値ですが、モジュラスNは公開鍵（E、N）にあるということです。Dは各パーティにプライベートです。あなたと私は異なる弾性率Nを持っているので、ここでは注意する必要があります。
これを行ったのは、ユーザーが復号化できるキーをプログラムが暗号化することを許可されているシステムが必要だったためです。これを行うと、ユーザーはキーを暗号化できず、プログラムはキーを復号化できません。