はい、可能です。コンピューターAliceとBobの両方に、それぞれ1つの秘密鍵と1つの公開鍵があります。
アリスはランダムなトークンを選択し、ボブの公開鍵と独自の秘密鍵で暗号化します。ボブはその秘密鍵とアリスの公開鍵でトークンを復号化し、次にアリスの公開鍵でトークンを再暗号化します。
ボブから元のトークンを受け取ると、アリスはボブがボブの秘密鍵を知っている必要があることを知っているため、ボブである必要があります。トークンはアリスの公開鍵で復号化されているため、ボブはアリスがアリスの秘密鍵を所有していることを知っています。つまり、アリスです。
そして、アリスとボブ以外の誰もが交換されたランダムトークンを知っているわけではないので、アリスとボブの両方がそれを、さらなる通信の交換に適した対称暗号アルゴリズムのキーとして使用できます（RSAもまた使用する可能性がありますが、より高価な計算）：
ALICE = Alice's public key; bob = Bob's private key
Alice chooses K
Alice encrypts with BOB,
then with alice
----> alice(BOB(K)) ---->
Bob knows ALICE and bob,
so can retrieve K
<---- bob(ALICE(K)) <----
(or just ALICE(K))
(or even K, if K need not be secret)
Alice gets confirmation
<---- AES256(K, MESSAGE[0]) ---->
<---- AES256(K, MESSAGE[1]) ---->
...
<---- AES256(K, MESSAGE[N]) ---->
そのような会話の間、Kは時々リフレッシュされるかもしれません。
実生活の例（まあ、一種）
この例では、アリスとボブは2人の友人であり、どちらもOpenSSLユーティリティを持っています。バイナリファイルを投稿できる公開チャネル（Facebookのページなど）を介して通信します。 OpenSSLは実際にASCIIファイルを生成することができますが、この目的にははるかに優れていますが、で実際の生活にできるだけ近づけましょう私たちは、全体を自動化してよりよく機能するOpenSSLスクリプト、またはOpenSSLをラップして同じことをより簡単なインターフェイスで実行するツールを使用します。
「VULN」のマークが付いている警告がいくつかあります。下を見てください。
まず、AliceはRSA公開/秘密鍵ペアを作成し、公開鍵を抽出します。 Bobも同じことをします（彼のファイルはbob- *という名前になります）（VULN-1）。
openssl genrsa -out alice-both.pem 1024
openssl rsa -in alice-both.pem -out alice-public.pem -outform PEM -pubout
これで、アリスとボブの両方がFacebookページでpublicキーを公開します。誰でも読むことができます。
次に、アリスはボブとプライベート会話を交換したいと考えています。アリスは、ボブが自分のソースを認識していることを確認したいと考えています。and彼女は、ボブがファイルを読み取ることができる唯一の人物であることを望んでいます。
これは非対称暗号化のみを使用して行うことができますが、サイズの制約と計算のオーバーヘッドのために、速度が遅く、非効率的です。したがって、彼らは対称暗号化を使用する必要があります。これには、共有秘密（上記ではKと呼ばれていました）を使用する必要があります。
彼らは、Kを選択し、安全なチャネルを介してそれを通信することによってそれを行います。安全なチャネルは、公開チャネル（facebook）を介した非対称暗号化によって提供されます。
ボブは紳士で、パスフレーズを選ぶのはアリスです。
彼女はパスフレーズでテキストファイルを作成することによってそうします...
echo 'the magic words are Squeamish Ossifrage' > phrase.txt
そしてボブのフェイスブックページからダウンロードしたボブの公開キーで暗号化します（VULN-2）
openssl rsautl -encrypt -inkey bob-public.pem -pubin -in phrase.txt -out file1
これで、ボブだけがファイルを復号化できます。問題は、これがボブにこれがアリスからのものであることを確認させる方法です。 Aliceは「file1」を暗号化するのに十分な小ささに切り分けてすべて送信することもできますが、それは必須ではありません。彼女はprivateキーでファイルにsignできます。
openssl dgst -sha256 -sign alice-both.pem -out file1.sign file1
これで、ボブは2つのファイルを受信します。まず、署名をアリスの公開鍵（VULN-2）で検証します。
openssl dgst -sha256 -verify alice-public.pem -signature file1.sign file1
そして、彼は「検証済みOK」を取得します（たとえば、彼の証明書など、他の誰かの証明書が使用されていた場合、「検証失敗」になります）。
したがって、AliceのFacebookページで公開されているキーに対して検証された「file1」は、少なくともAliceのFacebookアカウントと同じくらい信頼できます。
ボブは自分の秘密鍵で復号化を進めます。
openssl rsautl -decrypt -inkey bob-both.pem -in file1 -out secret
これで、ボブは秘密のフレーズ（「秘密」にある）を認識し、そのフレーズを使用してドキュメントを暗号化できます。
openssl enc -in secret-document.txt -out secret.bin -e -aes256 -k "$( cat secret )"
または同等に、
openssl enc -in secret-document.txt -out secret.bin -e -aes256 -k "the magic words are Squeamish Ossifrage"
secret.binが再びBobのページに公開されます。
一方、アリスは、対応するデコードコマンドを実行するだけです。
openssl enc -in secret.bin -out plain.txt -d -aes256 -k "$( cat phrase.txt )"
「plain.txt」を復元します。
VULN-1：アリスとボブは、自分の秘密鍵に誰もアクセスできないようにする必要があります。たとえば、OpenSSLがキーにアクセスするために入力する必要があるパスフレーズでロックすることができます。
VULN-2：イブがアリスのFacebookページにアクセスできる場合、またはボブのコンピューターに他のコンピューターが実際にはFacebookのWebサイトであると思わせることができる場合、彼女はボブをだましてアリスのだと信じてイブの公開キーをダウンロードさせることができます。イブがアリスと同じことができる場合、彼女はボブとしてポーズをとることができます。したがって、アリスはイブが復号化できる形式を使用してイブに「話しかけ」、イブは改ざんした後それを再暗号化してボブに送信します。両端は賢明ではありません。これはman-in-the-middle攻撃になります。これが、公開鍵の信頼性が疑いの余地がない理由です。
AliceもBobも公開したキーを使用する理由がないため（彼らはオリジナルを所有しています）、両方のFacebookページにアクセスすると、Eveは両方のキーを自分が作成した他のキーに置き換えるで、継続的に監視します新しく投稿されたファイルをダウンロードして、適切にデコードされ、改ざんされ、再暗号化されたバージョンに置き換えるために、両方のページ。アリスとボブは自分のファイルを検証する可能性が低く、ファイルの署名を公開していません（公開したとしても、気づかない可能性があります）。変更された）、彼らは物事に気づかないでしょう。 Facebookページのような一般公開では起こりそうにありませんが、他のシナリオでは、キー配布が危険にさらされる可能性があります。もちろん、Eveの監視範囲外にいる誰かがAliceまたはBobと通信しようとしてが失敗するとすぐに、ゲームは公開されます。